PEAR is discontinued

This is a static archive preserving historical releases and metadata. No new packages or updates will be published. For updates to existing packages, or to publish new packages, please use Composer and Packagist.

Home » HTML » HTML_QuickForm_Controller » Bug #1932

Remove dependancy on GET variable when performing a $page->handle('jump');

Details

Request #1932Remove dependancy on GET variable when performing a $page->handle('jump');
Submitted2004-07-21 01:15 UTC
Fromstudio at peptolab dot com
StatusWont fix
PackageHTML_QuickForm_Controller
PHP VersionIrrelevant
OSn/a
Roadmaps(Not assigned)

Comments

[2004-07-21 01:15 UTC] studio at peptolab dot com

Description:
------------
Currently when performing the 'Jump' action, the
'display' action is set as a GET variable, which I feel
looks inelegant from an end-user perspective.

I have experimented with the 'Jump' and 'Controller'
classes to temporarily use the container's SESSION
variables to store these values instead, which keeps the
URL much cleaner.

Reproduce code:
---------------
View the files 'Controller.php' and 'Jump.php' at:-

http://www.peptolab.com/developer/pear/Controller.phps

- The function getActionName() has been modified to use the session action/name in the event that no valid REQUEST variables are present. If no valid session action is available, then use the 'default' action.

http://www.peptolab.com/developer/pear/Jump.phps

- A reference to the SESSION is made, the page and action are set, the URL is constructed as normal and the redirection occurs.

P.S. Is there any reason the HTTP::redirect method is not used?

Expected result:
----------------
The controller will function as expected, but not
display any url query throughout the process

Actual result:
--------------
As above (hopefully!)

[2004-07-21 11:39 UTC] studio at peptolab dot com

What sort of arrogant, patronising response is that?

It DOESN'T break the next/forward browser buttons (if
you had bothered to test the code).

The wonderful technology called "Frames" DOES break
next/forward buttons, especially when it comes to
multiple frame changes.

I can't believe a member of this group would reply with
such a terse response when submitting objective
suggestions. Open source, closed mind.