One proper solution to this is to add a decorator to handle() operations of PageRenderRequestHandler and/or ComponentEventRequestHandler that sticks the required parameters from the activation context somewhere, for example to a request attribute to keep it simple, to make it available to your custom PersistentFieldStrategy. Now I have a generic in-page conversational scope working well enough with a support for multiple tabs, not bad for one day's worth of work. A testament to the extensibility of T5, props to Howard for that!
Kalle On Thu, Jan 15, 2009 at 3:19 PM, Kalle Korhonen <kalle.o.korho...@gmail.com>wrote: > Hey Ted, > > I happened to run into the same exact problem you were having while trying > to get my custom conversational PersistentFieldStrategy implemented. Did you > manage the solve the problem (reading values from activation context before > gathering persistent fields) in any satisfactory way? > > Kalle > > > > On Fri, Jan 18, 2008 at 4:59 AM, Ted Steen <ted.st...@gmail.com> wrote: > >> Hmm, i must have been very tired when i tested this yesterday. >> >> It doesnt work. The ComponentActionRequestFilter is handled after the >> persistent fields are gathered. So my activation context variable that >> I need when gathering persistent fields is not set before I gather the >> fields. >> I have tried to add the filter with "before:*" >> >> A solution would be to inject the Request into the >> PersistentFieldStrategy and get/decode the context from the path (or >> post variables when posting) .. but that is not very clean in my >> opinion. >> >> It would be nice if the gathering of fields was done a little later or >> maybe we could extend the Request API with a Object[] >> getActivationContext() >> >> Or do you have any other ideas. >> >> I feel I should explain my use case here.. >> We are developing a checkout service where the current cart beeing >> processed is passed around via a activation context variable (the >> cart-hash). This means that the persistent variables in the components >> should be "per cart-hash". This can be done transparently by >> implementing a custom PersistentFieldStrategy which uses the first >> value in the activation context (we decided that the cart-hash should >> always be the first value). >> >> Or the hash could be a part of the domain like hash.mydomain.com, then >> the session is made unique per host and everything will work like >> expected. >> this is a third solution >> >> >> 2008/1/18, Howard Lewis Ship <hls...@gmail.com>: >> > The pipelines and chains of command make it easy to "slip in" specific >> logic. >> > >> > OH, an alternative to defining a service to contain the data is to >> > just write it as a Request attribute. I've used that approach for >> > handling a few awkward cases. >> > >> > On Jan 17, 2008 5:56 PM, Ted Steen <ted.st...@gmail.com> wrote: >> > > Yep, that did it. >> > > Thanks! >> > > >> > > 2008/1/18, Howard Lewis Ship <hls...@gmail.com>: >> > > >> > > > If you mean the event context (as opposed to the page activation >> > > > context), then ... >> > > > >> > > > The path of least resistance is: >> > > > >> > > > 1) Define a service with a simple read/write property to store the >> > > > context. Make sure this is perthread scope. >> > > > 2) Contribute a filter to the ComponentActionRequestHandler >> pipeline. >> > > > The filter can capture the event context and store it in your >> service. >> > > > 3) In your PersistentFieldStrategy, inject the context-storing >> service >> > > > and read the context. >> > > > >> > > > You might simplify #1 to just store the piece of data you need from >> the context. >> > > > >> > > > The approach is similar if you need page activation context, but >> > > > you'll need to contribute a similar filter into the >> > > > PageRenderRequestHandler pipeline as well. >> > > > >> > > > On Jan 17, 2008 12:13 PM, Ted Steen <ted.st...@gmail.com> wrote: >> > > > > I need to hook in somewhere between where the context is available >> and >> > > > > the persistent fields are read. >> > > > > I need to read a context variable just before my >> > > > > PersistentFieldStrategy tries to read from the session, as I need >> a >> > > > > value from the context when reading from the session. >> > > > > >> > > > > What should I inject into my PersistentFieldStrategy in order to >> be >> > > > > able to read the context? >> > > > > >> > > > > >> --------------------------------------------------------------------- >> > > > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> > > > > For additional commands, e-mail: users-h...@tapestry.apache.org >> > > > > >> > > > > >> > > > >> > > > >> > > > >> > > > -- >> > > > Howard M. Lewis Ship >> > > > >> > > > Creator Apache Tapestry and Apache HiveMind >> > > > >> > > > >> --------------------------------------------------------------------- >> > > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> > > > For additional commands, e-mail: users-h...@tapestry.apache.org >> > > > >> > > > >> > > >> > > >> > > -- >> > > /ted >> > > >> > > >> > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> > > For additional commands, e-mail: users-h...@tapestry.apache.org >> > > >> > > >> > >> > >> > >> > -- >> > Howard M. Lewis Ship >> > >> > Creator Apache Tapestry and Apache HiveMind >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> > For additional commands, e-mail: users-h...@tapestry.apache.org >> > >> > >> >> >> -- >> /ted >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> >
