No, there's no need for complete page state in any request. In the example I gave, we restored the necessary state with just one query parameter: "filter". Component contexts looked after the rest.
Think of it as bringing @ActivationRequestParameter down from the page level to the component/zone level, just for AJAX. When there's no AJAX, @ActivationRequestParameter works fine: during page render every requester in the page (Form, EventLink, etc) gets the activation request parameters baked into its URLs. Every request that comes in sets the @ActivationRequestParameter. But when there is AJAX, each server-side component needs a way to return its activation request parameters and have the client-side update every URL in the page, not just the URLs in the returned zone(s). That's all I'm proposing. On 20/03/2014, at 12:59 AM, Chris Poulsen wrote: > Hi, > > The over all idea is really interesting and nice, but I think it is a hard > one to implement correctly in the framework. > > Having complete page state in GET requests (as context/parameters) may be > troublesome for complex pages with a lot of state (there seem to be an URL > size limit around 2000 chars). > > Using POST may be an option for some things or a totally different paradigm > where state is kept server side and the key to locate the state is passed > around could be possible... Even though the existing solutions with the > server side state clearly has their own set of issues. > > The discussion is very interesting though ;) > > -- > Chris --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
