Re: [jira] Commented: (WICKET-605) Stataless form skips page parameters
Ok, let's go for it then. Who's taking it up? Eelco On 6/5/07, Matej Knopp <[EMAIL PROTECTED]> wrote: I'm definitely +1 for metadata. The thread locals are clumsy and extremely dangerous. -Matej On 6/5/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > > > But i also need it for other stuff that are specific to specific > > > implementations of certain things > > > for example the AccessStackStore doesn't need such a thread locale but > > SLC > > > does.. > > > > Fair enough. So you would use such a 'bag' in request cycle to store > > stuff like dirtyObjects (session)? Aren't you afraid this will open up > > a new can of worms (users misusing this facility rather then providing > > their own request cycle implementation for instance)? > > > > Isn't that the problem we also should then have on Session or Component? > And i don't see it miss used a lot (at least all the examples i get from > people here on the lists/web) > also don't think that will happen a lot because most people (you and me > included!) like > to have a simple get/setter. But the problem is that we as the framework > just can't do that > for specific/default implementations of stuff. Then Requestcycle would > become polluted. > > The nice thing about metadata is (compare to a pure put/get like hashmap) > then they can be generified > so with java5 you don't have to cast >
Re: [jira] Commented: (WICKET-605) Stataless form skips page parameters
I'm definitely +1 for metadata. The thread locals are clumsy and extremely dangerous. -Matej On 6/5/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > But i also need it for other stuff that are specific to specific > > implementations of certain things > > for example the AccessStackStore doesn't need such a thread locale but > SLC > > does.. > > Fair enough. So you would use such a 'bag' in request cycle to store > stuff like dirtyObjects (session)? Aren't you afraid this will open up > a new can of worms (users misusing this facility rather then providing > their own request cycle implementation for instance)? Isn't that the problem we also should then have on Session or Component? And i don't see it miss used a lot (at least all the examples i get from people here on the lists/web) also don't think that will happen a lot because most people (you and me included!) like to have a simple get/setter. But the problem is that we as the framework just can't do that for specific/default implementations of stuff. Then Requestcycle would become polluted. The nice thing about metadata is (compare to a pure put/get like hashmap) then they can be generified so with java5 you don't have to cast
Re: [jira] Commented: (WICKET-605) Stataless form skips page parameters
> But i also need it for other stuff that are specific to specific > implementations of certain things > for example the AccessStackStore doesn't need such a thread locale but SLC > does.. Fair enough. So you would use such a 'bag' in request cycle to store stuff like dirtyObjects (session)? Aren't you afraid this will open up a new can of worms (users misusing this facility rather then providing their own request cycle implementation for instance)? Isn't that the problem we also should then have on Session or Component? And i don't see it miss used a lot (at least all the examples i get from people here on the lists/web) also don't think that will happen a lot because most people (you and me included!) like to have a simple get/setter. But the problem is that we as the framework just can't do that for specific/default implementations of stuff. Then Requestcycle would become polluted. The nice thing about metadata is (compare to a pure put/get like hashmap) then they can be generified so with java5 you don't have to cast
Re: [jira] Commented: (WICKET-605) Stataless form skips page parameters
But i also need it for other stuff that are specific to specific implementations of certain things for example the AccessStackStore doesn't need such a thread locale but SLC does.. Fair enough. So you would use such a 'bag' in request cycle to store stuff like dirtyObjects (session)? Aren't you afraid this will open up a new can of worms (users misusing this facility rather then providing their own request cycle implementation for instance)? Eelco
Re: [jira] Commented: (WICKET-605) Stataless form skips page parameters
don't we pretty much already have that map? RequestCycle.get().getRequest().getRequestParameters().getParameters() that one is parsed in the first step. (but mutable) but that one is going into the PAgeParameters except that PP has a little bit more that is not done in the first step but in the second one of the request cycle because bookmarkable mounts can introduce any kind of parameters from the url. and this is done in more then one place So the only thing i see to really do it right is to make sure that our base page has a PageParameters constructor and users should call that super() so that we can set the real one in the request cycle johan On 6/4/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: Sorry, but I don't agree. I think it's YAGNI. Metadata is a bit uglier to read (at least the code to access it), it's harder to trace in the debugger and just less obvious. I actually don't think it would be that out of place to put the (immutable instance of) request parameters as parsed in the first step of request cycle processing in the request. Eelco On 6/4/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > On 6/4/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > > i am getting a bit tired of all those threadlocals that have to be > > > cleaned... I already discussed this with matej and i thing we should > > > give the RequestCycle metadata... then we can store any thing we want > > > and it is auto cleanup > > > > Agreed. RequestCycle currently doesn't have metadata though. What's > > the advantage of using meta data there instead of a normal property? I > > think none... > > I think the advantage of metadata is to have less tight coupling of > other parts to the request cycle. We are going to use the request > cycle as a Bag of stuff, which is needed during RC processing, but > don't have a direct relationship to the RC, other than that it is part > of the RC. > > Having a metadata facility in the RC will facilitate this, and not > make the RC 'bloated'. > > Just thinking out loud. > > Martijn > > -- > Join the wicket community at irc.freenode.net: ##wicket > Wicket 1.2.6 contains a very important fix. Download Wicket now! > http://wicketframework.org >
Re: [jira] Commented: (WICKET-605) Stataless form skips page parameters
the second level cache has now a thread local Session has 2 thread locals especially the first one of the SLC do you really want to have a property on the RequestCycle for that? then you get really strange coupling. i am not talking about the PageParameters. That could maybe go into the request cycle because that is pretty much core (is it web only or not??) But i also need it for other stuff that are specific to specific implementations of certain things for example the AccessStackStore doesn't need such a thread locale but SLC does.. johan On 6/4/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > i am getting a bit tired of all those threadlocals that have to be > cleaned... I already discussed this with matej and i thing we should > give the RequestCycle metadata... then we can store any thing we want > and it is auto cleanup Agreed. RequestCycle currently doesn't have metadata though. What's the advantage of using meta data there instead of a normal property? I think none... Eelco
Re: [jira] Commented: (WICKET-605) Stataless form skips page parameters
Sorry, but I don't agree. I think it's YAGNI. Metadata is a bit uglier to read (at least the code to access it), it's harder to trace in the debugger and just less obvious. I actually don't think it would be that out of place to put the (immutable instance of) request parameters as parsed in the first step of request cycle processing in the request. Eelco On 6/4/07, Martijn Dashorst <[EMAIL PROTECTED]> wrote: On 6/4/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > i am getting a bit tired of all those threadlocals that have to be > > cleaned... I already discussed this with matej and i thing we should > > give the RequestCycle metadata... then we can store any thing we want > > and it is auto cleanup > > Agreed. RequestCycle currently doesn't have metadata though. What's > the advantage of using meta data there instead of a normal property? I > think none... I think the advantage of metadata is to have less tight coupling of other parts to the request cycle. We are going to use the request cycle as a Bag of stuff, which is needed during RC processing, but don't have a direct relationship to the RC, other than that it is part of the RC. Having a metadata facility in the RC will facilitate this, and not make the RC 'bloated'. Just thinking out loud. Martijn -- Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org
Re: [jira] Commented: (WICKET-605) Stataless form skips page parameters
On 6/4/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > i am getting a bit tired of all those threadlocals that have to be > cleaned... I already discussed this with matej and i thing we should > give the RequestCycle metadata... then we can store any thing we want > and it is auto cleanup Agreed. RequestCycle currently doesn't have metadata though. What's the advantage of using meta data there instead of a normal property? I think none... I think the advantage of metadata is to have less tight coupling of other parts to the request cycle. We are going to use the request cycle as a Bag of stuff, which is needed during RC processing, but don't have a direct relationship to the RC, other than that it is part of the RC. Having a metadata facility in the RC will facilitate this, and not make the RC 'bloated'. Just thinking out loud. Martijn -- Join the wicket community at irc.freenode.net: ##wicket Wicket 1.2.6 contains a very important fix. Download Wicket now! http://wicketframework.org
Re: [jira] Commented: (WICKET-605) Stataless form skips page parameters
i am getting a bit tired of all those threadlocals that have to be cleaned... I already discussed this with matej and i thing we should give the RequestCycle metadata... then we can store any thing we want and it is auto cleanup Agreed. RequestCycle currently doesn't have metadata though. What's the advantage of using meta data there instead of a normal property? I think none... Eelco
Re: [jira] Commented: (WICKET-605) Stataless form skips page parameters
i am getting a bit tired of all those threadlocals that have to be cleaned... I already discussed this with matej and i thing we should give the RequestCycle metadata... then we can store any thing we want and it is auto cleanup On 6/4/07, Eelco Hillenius (JIRA) <[EMAIL PROTECTED]> wrote: [ https://issues.apache.org/jira/browse/WICKET-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12501258 ] Eelco Hillenius commented on WICKET-605: The best hack I can currently imagine is to set the current PageParameters instance as a threadlocal somewhere (RequestCycle?) when the WebPage(PageParameters) constructor is called (btw, I see no reason why this constructor couldn't be moved to Page... we can do that regardless), and clean it up again in RequestCycle#detach. It would be yet another threadlocal unfortunately, but otoh it is valuable information to have accesible, which is hard to get to right now. WDYT? > Stataless form skips page parameters > > > Key: WICKET-605 > URL: https://issues.apache.org/jira/browse/WICKET-605 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: trunk > Environment: linux, glassfish v2 >Reporter: József Börcsök >Assignee: Eelco Hillenius > > Page parameters are not included in stataless form action parameter. > I think stateless form should override urlFor(RequestListenerInterface listener) method and append page parameters. (Submit works if I manually add them at runtime ie. with firebug plugin in browser.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
