Hey Kristian, yeah I ended up with decorators as well. Did your implementation get any further than experimental stage? If it's available somewhere, I'd gladly take a look to compare. Eventually I'll probably make this or some improved version available as part of Trails 2.
Kalle On Fri, Jan 16, 2009 at 12:21 AM, Kristian Marinkovic < kristian.marinko...@porsche.co.at> wrote: > hi Kalle, > > i did some experiments on this some time back. my solution was to provide > a decorator for the > PersistentFieldManager service. This decorator would know it it was in a > conversation and save > the persistent fields respectivley. I also used the LinkFactory and the > LinkFactoryListener to add > the conversation id transparently to every link. > > g, > kris > > > > > > Kalle Korhonen <kalle.o.korho...@gmail.com> > 16.01.2009 00:19 > Bitte antworten an > "Tapestry users" <users@tapestry.apache.org> > > > An > Tapestry users <users@tapestry.apache.org> > Kopie > ted.st...@gmail.com > Thema > Re: T5: Reading context before persistent fields are read > > > > > > > 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 > > > > > >
