The problem at hand is: what actions need to be run on the server-side to
correctly process the form submission? When you start to factor in very dynamic
components like BeanEditor, multiple blocks (possible coming from disparate
pages, possibly from 3rd party libraries, etc.) it becomes very non-trivial.
The T3/T4 solution was the dreaded form rewind: basically, you would get a
complete re-render of the page on the server side when the form was submitted.
It sucked. :) Given the state of web dev frameworks in java at the time,
Tapestry still outdid the competition. But the "rewind" still sucked.
ComponentActions are a pragmatic solution to the problem: /nothing/ happens on
the server side when a form is submitted except for what components /declare/
should happen. Now it doesn't matter /where/ the components come from, or how
dynamic the page render is, you get the correct action on the server side. One
alternative to this would be to serialize the component tree into the session
(which is what Wicket does, if I recall correctly). I think this is more
developer friendly, to be honest, but the Tapestry team has chosen not to go
this route for various reasons (mostly performance/scalability). The very
dynamic nature of the render (components coming from all over the place) and
the lack of a serialized tree makes it virtually impossible to guarantee that
you will fire a "onPrepareForSubmissionFromFormSupport" on all components
involved in the component render.
That said, it would definitely be nice to hide a lot of these plumbing details
and make things easier to developers. We could devise some way for components
to register themselves with, eg, form support. Maybe something like:
formSupport.registerForFormNotifications(componentResources);
Ideally, the method would actually take the component as a parameter, but
requiring the component resources is a bit more straightforward, and I think
not too onerous on the developer. Or maybe there is no method at all... maybe
it's a new annotation (I'd have to mull over that one for awhile). In any
event, with some registration like that, formSupport could auto-add one or more
component actions that use the component resources to trigger events on the
components (onPrepareForSubmission, onProcessSubmission, or whatever). That's a
real possibility. If we can work out the registration scheme. :)
Robert
On Aug 30, 2011, at 8/307:52 AM , Geoff Callender wrote:
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
