Home
The Toolkit for Online Communities
17200 Community Members, 0 members online, 2048 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Development : template::forward and the 2,083 IE limit

Forum OpenACS Development: template::forward and the 2,083 IE limit

Icon of envelope Request notifications

Collapse
Posted by Brad Duell on
We've been using the wizard, but the wizard uses this proc, and consequently breaks in Internet Explorer on this proc and the redirect when the wizard is processing large form postings.

Has anyone had similar problems or any success with this problem?

Thanks!

Collapse
Posted by Don Baccus on
I wish we could limit the world to 2,083 IE copies, sure would simplify life! :)

You might want to look into session variables for passing larger chunks of stuff from page to page.  The APM does this if you're looking for an example.

Collapse
Posted by Jun Yamog on
Hi Brad,

I think Don's suggestion is what you need.  On the project that I used the wizard I created a package similar to ad_set/get_client_property.

Although I am not sure how you have surpassed 2,000 get url chars easily.  We have a 4 level wizard and also pass around the wizard url as return url.  We haven't reached that 2,000 char limit yet.  Although most of our forms also a lot of processing already.  We just normally pass object_id, setting_id, etc.

Either you use ad_set/get_client_property or save the stuff you did in a temp table or row while in the wizard steps.

Either approach will work, it will depend on what you are doing.

Collapse
Posted by Don Baccus on
ad_set/get_client_property caches the value and works with any length of data so it's probably almost always better than using a temp table on your own ...
Collapse
Posted by Brad Duell on
We have an advanced reporting package that we've been developing which allows users to query data they are granted access to, and build reports from this data (doing print jobs, mail merges, etc.).  The wizard allows them to filter this data to better suit what report they are currently generating.  During this filtering process, especially when using date ranges, the 2,083 IE limit is crushed.

So I set out on using user session variables and decided that perhaps some things might make using these variables a little easier in the toolkit.

Instead of allowing template::forward to only use ad_returnredirect (which could, and does, ultimately break the IE character limit of 2,083) I thought a procedure such as ad_cache_returnredirect would help those pages using the the templating system (those that wanted to) cache values between pages of a package for a user's session (see http://openacs.org/bugtracker/openacs/patch?patch_number=237 and http://openacs.org/bugtracker/openacs/patch?patch_number=239).  This procedure still uses ad_returnredirect with any variables excluded after values are cached.

Having a "cached" key and filter in ad_page_contract could help a page retrieve those values that it expects *may* be in cache for the calling page and package, and allows all other filters to still act accordingly (see http://openacs.org/bugtracker/openacs/patch?patch_number=238).

This has eliminated the IE character limit for us, and seems to make session variables much easier to work with.

Collapse
Posted by Jun Yamog on
Hi Brad,

These are really very good additions.  I will add them in to the wizard once they have accepted the patches.

All,

I hope Brad's patches be accepted.  They are really good additions.  Thanks.

Collapse
Posted by Brad Duell on
Thanks, Jun.

Any chance these changes and Jun's wizard might make it in the toolkit?  Thanks!

Collapse
Posted by Don Baccus on
I've applied 237 and 238 but was wondering if 238 might be better if we used the named parameter facility of ad_proc for the "cached_p" parameter rather than just look for "t" as the first element of the args list?
Collapse
Posted by Jun Yamog on
Ok great.  I will commit this weekend the caching aware wizard.  I need help on testing, I guess not much since the cache code is just being called.  If cache code works, I would assume calls to it should work.