I'm not quite sure what you mean by "set back" the values in the model, but it
sounds like you're extracting information in setup render that the component
needs to determine how to render, and that the same information is necessary
for correctly processing the form submission?
In any event, the way components typically interact with a form submission is
by using the "FormSupport" environmental object:
@Environmental
FormSupport formSupport;
It let's you store and execute "ComponentAction" objects. For instance, this
is from AbstractField:
formSupport.storeAndExecute(this, new Setup(controlName));
formSupport.store(this, PROCESS_SUBMISSION_ACTION);
storeAndExecute will take the provided ComponentAction and execute it
immediately. It will also be "stored" into the form and when the form is
submitted, the ComponentAction will be executed again.
The "store" call is similar, except that it only executes on form submission.
So if you have some logic that needs to execute before rendering the component,
and also before processing the form submission, refactor that logic into a
ComponentAction and use formSupport.storeAndExecute.
Robert
On Aug 22, 2011, at 8/223:26 PM , Jens Breitenstein wrote:
> Hi Robert!
>
> I have a hugh and complex form and tried to create components and cut down
> the page code. Each component gets access to the model by a parameter and in
> setupRender each component extracts the relevant data and adjusts the visual
> elements like text / checkbox accordingly to reflect the state which just
> works perfect. Furthermore this opens the door to dynamically show different
> components (other visual elements like dropdown instead of list of radio
> btns) without touching the page any longer (more or less).
>
> So I achieved the first half. I wonder how a component can participate on
> form events (especially onSubmit) which would give me a chance to "set back"
> the values in my model. This is more or less full OO as the component is
> responsible for displaying info from a model and updating the model and the
> page becomes just a container for components without "transfer" logic. This
> would allow me to reuse my componts much easier.
>
> I can use @property(write = false) and add a setter to keep track of the
> input values of each component element, but to me it feels just wrong as I
> depend on many single set calls instead of one submit method which clearly
> indicates it's sole purpose on a page.
>
>
> Jens
>
>
>
> Am 22.08.11 22:10, schrieb Robert Zeigler:
>> No. Events bubble up, so if you have:
>>
>> <t:form>
>> <t:somecomponent>
>> </t:form>
>>
>> The form can "see" the events from somecomponent, and the page will see
>> events from form and somecomponent, but somecomponent won't see the form's
>> event.
>>
>> What are you trying to accomplish?
>>
>> Robert
>>
>> On Aug 22, 2011, at 8/223:04 PM , Jens Breitenstein wrote:
>>
>>> Hi all!
>>>
>>> is it possible for a component to listen to the "success" event from the
>>> enclosing form?
>>> I tried various onEvent combinations but my annotated component method is
>>> never called...
>>>
>>>
>>> Jens
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
