Hi all,
The whole business of writing and storing ComponentActions does my head in -
it's plumbing, and for the most part Tapestry is very good at hiding plumbing,
but not when it comes to input components.
It seems that the source of the problem is that events bubble up from Form, not
down. Of course, that shouldn't change. But what if, behind the scenes,
something like FormSupport could trigger events in each component within the
Form? Maybe then we would only have to implement event handlers like these:
onPrepareForSubmissionFromFormSupport() {..}
onProcessSubmissionFromFormSupport() {..}
Maybe it's not possible, because I note that some components conditionally
store certain ComponentActions during render - maybe that decision can only be
made in beforeRender() or afterRender(). Or maybe that could be solved by
enabling the conditioning value to be stored by the rendering phase methods and
retrieved by the event handling methods? Perhaps this is what Wulf had in mind
with @Persist("Form")?
Just a thought.
Cheers,
Geoff
On 30/08/2011, at 10:47 PM, Wechsung, Wulf wrote:
> Hi All,
>
> okay, obviously my understanding of formsupport.store is flawed and I need to
> have a closer look at the sources. The general problem I want to solve is to
> have some value in a component that is restored on form submit because I've
> been running into situations in custom forms where that's necessary. For now,
> I've just changed all relevant values to be created on the fly which if
> possible is preferable anyway.
>
> Thanks for your input!
>
> Kind Regards, Wulf
>
>
> -----Original Message-----
> From: Thiago H. de Paula Figueiredo [mailto:thiag...@gmail.com]
> Sent: Dienstag, 30. August 2011 13:22
> To: Tapestry users
> Subject: Re: Formsupport store
>
> On Tue, 30 Aug 2011 06:40:39 -0300, Wechsung, Wulf <wulf.wechs...@sap.com>
> wrote:
>
>> Hello Thiago,
>
> Hi!
>
>> thanks for your reply.
>
> :)
>
>> I understand that store could be used to hook any code into form
>> submission. I was trying to say that sometimes this is used to simply
>> save some value to the form and restore it to the component on form
>> submit.
>
> Again, this is not true.
>
>> For an example, see controlName in AbstractField.
>
> This is not AbstractField saving a value: it's saving the control name
> (a.k.a. query parameter) that will receive the value the user provided for
> this field.
>
>> What I wanted to know is if this specific usage of formsupport.store
>> could be implemented as Persistence strategy in addition to Session,
>> Flash and Client if that makes any sense. It's not even that I want you
>> guys to implement this, just if you think this is possible and would
>> makes sense.
>
> IMHO, this doesn't make any sense because FormSupport.store* don't store
> field values. The information is stored in a hidden field inside the Form.
> Again, you haven't said what you want to accomplish, so we can't suggest
> anything for you.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
> and instructor
> Owner, Ars Machina Tecnologia da Informação Ltda.
> http://www.arsmachina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
