You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Kalle Korhonen <ka...@gmail.com> on 2009/01/16 00:19:52 UTC
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 <te...@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 <hl...@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 <te...@gmail.com> wrote:
> > > Yep, that did it.
> > > Thanks!
> > >
> > > 2008/1/18, Howard Lewis Ship <hl...@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 <te...@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-unsubscribe@tapestry.apache.org
> > > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Howard M. Lewis Ship
> > > >
> > > > Creator Apache Tapestry and Apache HiveMind
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > /ted
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> >
> >
> >
> > --
> > Howard M. Lewis Ship
> >
> > Creator Apache Tapestry and Apache HiveMind
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
> --
> /ted
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: T5: Reading context before persistent fields are read
Posted by Francois Armand <fa...@linagora.com>.
Kalle Korhonen wrote:
> Just FYI for those interested; I made the initial implementation of my
> conversation-within-page concept available as an independent Trails module:
> trails-conversations (for T5). More information at
> http://markmail.org/message/42mxcp3ioiv5tdug#query:conversations%20in%20trails+page:1+mid:42mxcp3ioiv5tdug+state:resultsand
> http://docs.codehaus.org/display/TRAILS/Conversations+in+Trails.
>
> Kalle
>
That seems really cool, thanks for the module and for the work on Trail
--
Francois Armand
Etudes & Développements J2EE
Groupe Linagora - http://www.linagora.com
Tél.: +33 (0)1 58 18 68 28
-----------
http://fanf42.blogspot.com
InterLDAP - http://interldap.org
FederID - http://www.federid.org/
Open Source identities management and federation
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5: Reading context before persistent fields are read
Posted by Kalle Korhonen <ka...@gmail.com>.
Just FYI for those interested; I made the initial implementation of my
conversation-within-page concept available as an independent Trails module:
trails-conversations (for T5). More information at
http://markmail.org/message/42mxcp3ioiv5tdug#query:conversations%20in%20trails+page:1+mid:42mxcp3ioiv5tdug+state:resultsand
http://docs.codehaus.org/display/TRAILS/Conversations+in+Trails.
Kalle
On Fri, Jan 16, 2009 at 12:29 AM, Kalle Korhonen <kalle.o.korhonen@gmail.com
> wrote:
> 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.marinkovic@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 <ka...@gmail.com>
>> 16.01.2009 00:19
>> Bitte antworten an
>> "Tapestry users" <us...@tapestry.apache.org>
>>
>>
>> An
>> Tapestry users <us...@tapestry.apache.org>
>> Kopie
>> ted.steen@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 <te...@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 <hl...@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 <te...@gmail.com> wrote:
>> > > > Yep, that did it.
>> > > > Thanks!
>> > > >
>> > > > 2008/1/18, Howard Lewis Ship <hl...@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 <te...@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-unsubscribe@tapestry.apache.org
>> > > > > > For additional commands, e-mail: users-help@tapestry.apache.org
>> > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Howard M. Lewis Ship
>> > > > >
>> > > > > Creator Apache Tapestry and Apache HiveMind
>> > > > >
>> > > > >
>> ---------------------------------------------------------------------
>> > > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > > > > For additional commands, e-mail: users-help@tapestry.apache.org
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > > --
>> > > > /ted
>> > > >
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > > > For additional commands, e-mail: users-help@tapestry.apache.org
>> > > >
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Howard M. Lewis Ship
>> > >
>> > > Creator Apache Tapestry and Apache HiveMind
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > > For additional commands, e-mail: users-help@tapestry.apache.org
>> > >
>> > >
>> >
>> >
>> > --
>> > /ted
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >
>> >
>>
>>
>
Re: T5: Reading context before persistent fields are read
Posted by Kristian Marinkovic <kr...@porsche.co.at>.
hi kalle,
i consider it still experimental. it is only possible to start and stop a
conversation
programmatically. it is still based on Tapestry 5.0.7-SNAPSHOT.
i will try to update it to 5.0.18 over the weekend...
g,
kris
Kalle Korhonen <ka...@gmail.com>
16.01.2009 09:29
Bitte antworten an
"Tapestry users" <us...@tapestry.apache.org>
An
Tapestry users <us...@tapestry.apache.org>
Kopie
Thema
Re: T5: Reading context before persistent fields are read
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.marinkovic@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 <ka...@gmail.com>
> 16.01.2009 00:19
> Bitte antworten an
> "Tapestry users" <us...@tapestry.apache.org>
>
>
> An
> Tapestry users <us...@tapestry.apache.org>
> Kopie
> ted.steen@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 <te...@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 <hl...@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 <te...@gmail.com> wrote:
> > > > Yep, that did it.
> > > > Thanks!
> > > >
> > > > 2008/1/18, Howard Lewis Ship <hl...@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 <te...@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-unsubscribe@tapestry.apache.org
> > > > > > For additional commands, e-mail:
users-help@tapestry.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Howard M. Lewis Ship
> > > > >
> > > > > Creator Apache Tapestry and Apache HiveMind
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > /ted
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Howard M. Lewis Ship
> > >
> > > Creator Apache Tapestry and Apache HiveMind
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> >
> >
> > --
> > /ted
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
Re: T5: Reading context before persistent fields are read
Posted by Kalle Korhonen <ka...@gmail.com>.
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.marinkovic@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 <ka...@gmail.com>
> 16.01.2009 00:19
> Bitte antworten an
> "Tapestry users" <us...@tapestry.apache.org>
>
>
> An
> Tapestry users <us...@tapestry.apache.org>
> Kopie
> ted.steen@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 <te...@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 <hl...@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 <te...@gmail.com> wrote:
> > > > Yep, that did it.
> > > > Thanks!
> > > >
> > > > 2008/1/18, Howard Lewis Ship <hl...@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 <te...@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-unsubscribe@tapestry.apache.org
> > > > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Howard M. Lewis Ship
> > > > >
> > > > > Creator Apache Tapestry and Apache HiveMind
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > /ted
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Howard M. Lewis Ship
> > >
> > > Creator Apache Tapestry and Apache HiveMind
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> >
> >
> > --
> > /ted
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
Re: T5: Reading context before persistent fields are read
Posted by Kristian Marinkovic <kr...@porsche.co.at>.
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 <ka...@gmail.com>
16.01.2009 00:19
Bitte antworten an
"Tapestry users" <us...@tapestry.apache.org>
An
Tapestry users <us...@tapestry.apache.org>
Kopie
ted.steen@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 <te...@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 <hl...@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 <te...@gmail.com> wrote:
> > > Yep, that did it.
> > > Thanks!
> > >
> > > 2008/1/18, Howard Lewis Ship <hl...@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 <te...@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-unsubscribe@tapestry.apache.org
> > > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Howard M. Lewis Ship
> > > >
> > > > Creator Apache Tapestry and Apache HiveMind
> > > >
> > > >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > > For additional commands, e-mail: users-help@tapestry.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > /ted
> > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> >
> >
> >
> > --
> > Howard M. Lewis Ship
> >
> > Creator Apache Tapestry and Apache HiveMind
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
> --
> /ted
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: T5: Reading context before persistent fields are read
Posted by Kalle Korhonen <ka...@gmail.com>.
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
<ka...@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 <te...@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 <hl...@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 <te...@gmail.com> wrote:
>> > > Yep, that did it.
>> > > Thanks!
>> > >
>> > > 2008/1/18, Howard Lewis Ship <hl...@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 <te...@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-unsubscribe@tapestry.apache.org
>> > > > > For additional commands, e-mail: users-help@tapestry.apache.org
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Howard M. Lewis Ship
>> > > >
>> > > > Creator Apache Tapestry and Apache HiveMind
>> > > >
>> > > >
>> ---------------------------------------------------------------------
>> > > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > > > For additional commands, e-mail: users-help@tapestry.apache.org
>> > > >
>> > > >
>> > >
>> > >
>> > > --
>> > > /ted
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > > For additional commands, e-mail: users-help@tapestry.apache.org
>> > >
>> > >
>> >
>> >
>> >
>> > --
>> > Howard M. Lewis Ship
>> >
>> > Creator Apache Tapestry and Apache HiveMind
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: users-help@tapestry.apache.org
>> >
>> >
>>
>>
>> --
>> /ted
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>