I think that the ParameterWorker is outside of my comfort zone. I'll leave it the tapestry dev team's capable hands.
Feel free to use the selenium test from my patch. On 26 March 2013 16:57, Lance Java <lance.j...@googlemail.com> wrote: > > As I've said in the dev mailing list... this should be fixed in the way > Tapestry handles parameters > Damn!! Wish I'd read this before I started > > > To me it's clear how to make it do what I want. The question how should > the symbol binding work > In my opinion, if a binding is invariant, I think a PerThreadValue should > be initialized and future get() operations pass through to the > PerThreadValue. > > > On 26 March 2013 16:53, Barry Books <trs...@gmail.com> wrote: > >> > The code that handles the parameters is in the parameter worker. I >> think it could be fixed here but it's a bit messy. The real problem is the >> symbol binding is invariant but you want to set it. Should that be an error >> or not? >> >> From looking at the code it's clear the symbol binding can just ignore >> the set because it only calls the get once. >> >> I also think it would still work if the symbol binding was invariant. >> >> To me it's clear how to make it do what I want. The question how should >> the symbol binding work >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> >
