Pages, embedded components, dialogs, persisting entities across requests and submitting forms

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Pages, embedded components, dialogs, persisting entities across requests and submitting forms

Poggenpohl, Daniel
Hello everyone,

I want to finally adress the problem that crops up when persisting page properties (which I do not want to).

For example, I have a Page P1, containing a component C1. I also define a jquery dialog J1 in my page, which is opened inside C1 via a dialogajaxlink. The dialog contains component C2.
So, basically:
P1->C1
P1->J1->C2

For this example, I have to entity classes: E1 and E2.
E1 contains a list of E2's.

P1 receives an activation context, the id of an E1.
In setupRender I fetch the E1 entity and use it to render the page.
C1 currently receives the E1 entity as a parameter and accesses one of the contained E2's.

Now, C1 is shown, I click something and raise an event that should update the shown C1.
If I @Persist the E1 entity, all is okay, because the ID and class is saved between requests and so the E1 entity can be retrieved again.

1.       But I don't want to store with @Persist. What are my options?

Let's do another:
In another example, P1 displays E1 entities and loops the component C1 over all E2 entities contained in E1. In every C1 loop iteration (containing an E2 entity) there is a button opening the dialog J1 respectively the component C2 with the E2 id as a parameter, to edit E2's in a Form.


2.       When I submit the form to update the E2, what should I do then? The id parameter is lost if @Persist is not used with E1, because then the E1 entity is lost and thus no list of E2's can be reproduced.

I hope that wasn't too formal and someone can help me understand.

Regards,
Daniel P.
Reply | Threaded
Open this post in threaded view
|

Re: Pages, embedded components, dialogs, persisting entities across requests and submitting forms

Chris Poulsen
@BeginRender is only triggered during rendering.

Page activation is always called and there are a couple of "prepare" events
fired when you have a form in the mix.

--
Chris

On Mon, Jul 20, 2015 at 3:31 PM, Poggenpohl, Daniel <
[hidden email]> wrote:

> Hello everyone,
>
> I want to finally adress the problem that crops up when persisting page
> properties (which I do not want to).
>
> For example, I have a Page P1, containing a component C1. I also define a
> jquery dialog J1 in my page, which is opened inside C1 via a
> dialogajaxlink. The dialog contains component C2.
> So, basically:
> P1->C1
> P1->J1->C2
>
> For this example, I have to entity classes: E1 and E2.
> E1 contains a list of E2's.
>
> P1 receives an activation context, the id of an E1.
> In setupRender I fetch the E1 entity and use it to render the page.
> C1 currently receives the E1 entity as a parameter and accesses one of the
> contained E2's.
>
> Now, C1 is shown, I click something and raise an event that should update
> the shown C1.
> If I @Persist the E1 entity, all is okay, because the ID and class is
> saved between requests and so the E1 entity can be retrieved again.
>
> 1.       But I don't want to store with @Persist. What are my options?
>
> Let's do another:
> In another example, P1 displays E1 entities and loops the component C1
> over all E2 entities contained in E1. In every C1 loop iteration
> (containing an E2 entity) there is a button opening the dialog J1
> respectively the component C2 with the E2 id as a parameter, to edit E2's
> in a Form.
>
>
> 2.       When I submit the form to update the E2, what should I do then?
> The id parameter is lost if @Persist is not used with E1, because then the
> E1 entity is lost and thus no list of E2's can be reproduced.
>
> I hope that wasn't too formal and someone can help me understand.
>
> Regards,
> Daniel P.
>
Reply | Threaded
Open this post in threaded view
|

Re: Pages, embedded components, dialogs, persisting entities across requests and submitting forms

Chris Poulsen
Case one is a candidate for activation and case 2 could be a matter of
using form context / prepare events.

Beware that the activate event is triggered in many situations.

--
Chris

On Mon, Jul 20, 2015 at 3:39 PM, Chris Poulsen <[hidden email]>
wrote:

> @BeginRender is only triggered during rendering.
>
> Page activation is always called and there are a couple of "prepare"
> events fired when you have a form in the mix.
>
> --
> Chris
>
> On Mon, Jul 20, 2015 at 3:31 PM, Poggenpohl, Daniel <
> [hidden email]> wrote:
>
>> Hello everyone,
>>
>> I want to finally adress the problem that crops up when persisting page
>> properties (which I do not want to).
>>
>> For example, I have a Page P1, containing a component C1. I also define a
>> jquery dialog J1 in my page, which is opened inside C1 via a
>> dialogajaxlink. The dialog contains component C2.
>> So, basically:
>> P1->C1
>> P1->J1->C2
>>
>> For this example, I have to entity classes: E1 and E2.
>> E1 contains a list of E2's.
>>
>> P1 receives an activation context, the id of an E1.
>> In setupRender I fetch the E1 entity and use it to render the page.
>> C1 currently receives the E1 entity as a parameter and accesses one of
>> the contained E2's.
>>
>> Now, C1 is shown, I click something and raise an event that should update
>> the shown C1.
>> If I @Persist the E1 entity, all is okay, because the ID and class is
>> saved between requests and so the E1 entity can be retrieved again.
>>
>> 1.       But I don't want to store with @Persist. What are my options?
>>
>> Let's do another:
>> In another example, P1 displays E1 entities and loops the component C1
>> over all E2 entities contained in E1. In every C1 loop iteration
>> (containing an E2 entity) there is a button opening the dialog J1
>> respectively the component C2 with the E2 id as a parameter, to edit E2's
>> in a Form.
>>
>>
>> 2.       When I submit the form to update the E2, what should I do then?
>> The id parameter is lost if @Persist is not used with E1, because then the
>> E1 entity is lost and thus no list of E2's can be reproduced.
>>
>> I hope that wasn't too formal and someone can help me understand.
>>
>> Regards,
>> Daniel P.
>>
>
>
Reply | Threaded
Open this post in threaded view
|

AW: Pages, embedded components, dialogs, persisting entities across requests and submitting forms

Poggenpohl, Daniel
Hi,

but I don't use  @BeginRender, just @SetupRender. Did you mean that?

You mean onActivate, don't you? Do you mean adding more (optional) parameters to the activation context?

Regards,
Daniel P.


-----Ursprüngliche Nachricht-----
Von: Chris Poulsen [mailto:[hidden email]]
Gesendet: Montag, 20. Juli 2015 15:42
An: Tapestry users
Betreff: Re: Pages, embedded components, dialogs, persisting entities across requests and submitting forms

Case one is a candidate for activation and case 2 could be a matter of using form context / prepare events.

Beware that the activate event is triggered in many situations.

--
Chris

On Mon, Jul 20, 2015 at 3:39 PM, Chris Poulsen <[hidden email]>
wrote:

> @BeginRender is only triggered during rendering.
>
> Page activation is always called and there are a couple of "prepare"
> events fired when you have a form in the mix.
>
> --
> Chris
>
> On Mon, Jul 20, 2015 at 3:31 PM, Poggenpohl, Daniel <
> [hidden email]> wrote:
>
>> Hello everyone,
>>
>> I want to finally adress the problem that crops up when persisting
>> page properties (which I do not want to).
>>
>> For example, I have a Page P1, containing a component C1. I also
>> define a jquery dialog J1 in my page, which is opened inside C1 via a
>> dialogajaxlink. The dialog contains component C2.
>> So, basically:
>> P1->C1
>> P1->J1->C2
>>
>> For this example, I have to entity classes: E1 and E2.
>> E1 contains a list of E2's.
>>
>> P1 receives an activation context, the id of an E1.
>> In setupRender I fetch the E1 entity and use it to render the page.
>> C1 currently receives the E1 entity as a parameter and accesses one
>> of the contained E2's.
>>
>> Now, C1 is shown, I click something and raise an event that should
>> update the shown C1.
>> If I @Persist the E1 entity, all is okay, because the ID and class is
>> saved between requests and so the E1 entity can be retrieved again.
>>
>> 1.       But I don't want to store with @Persist. What are my options?
>>
>> Let's do another:
>> In another example, P1 displays E1 entities and loops the component
>> C1 over all E2 entities contained in E1. In every C1 loop iteration
>> (containing an E2 entity) there is a button opening the dialog J1
>> respectively the component C2 with the E2 id as a parameter, to edit
>> E2's in a Form.
>>
>>
>> 2.       When I submit the form to update the E2, what should I do then?
>> The id parameter is lost if @Persist is not used with E1, because
>> then the
>> E1 entity is lost and thus no list of E2's can be reproduced.
>>
>> I hope that wasn't too formal and someone can help me understand.
>>
>> Regards,
>> Daniel P.
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Pages, embedded components, dialogs, persisting entities across requests and submitting forms

JumpStart
Every page request and every component event request will include the page’s activation context, ie. an E1 id. If you include that id in the parameters of C1, J1, and C2, then they will all have access to the E1 id.

I’m assuming that each E2 does not know its E1 (ie. not a many-to-one relationship). Otherwise C1 and C2 could derive E1 when needed.

Also keep in mind that Form has a context parameter which can be helpful.

> On 20 Jul 2015, at 11:49 pm, Poggenpohl, Daniel <[hidden email]> wrote:
>
> Hi,
>
> but I don't use  @BeginRender, just @SetupRender. Did you mean that?
>
> You mean onActivate, don't you? Do you mean adding more (optional) parameters to the activation context?
>
> Regards,
> Daniel P.
>
>
> -----Ursprüngliche Nachricht-----
> Von: Chris Poulsen [mailto:[hidden email]]
> Gesendet: Montag, 20. Juli 2015 15:42
> An: Tapestry users
> Betreff: Re: Pages, embedded components, dialogs, persisting entities across requests and submitting forms
>
> Case one is a candidate for activation and case 2 could be a matter of using form context / prepare events.
>
> Beware that the activate event is triggered in many situations.
>
> --
> Chris
>
> On Mon, Jul 20, 2015 at 3:39 PM, Chris Poulsen <[hidden email]>
> wrote:
>
>> @BeginRender is only triggered during rendering.
>>
>> Page activation is always called and there are a couple of "prepare"
>> events fired when you have a form in the mix.
>>
>> --
>> Chris
>>
>> On Mon, Jul 20, 2015 at 3:31 PM, Poggenpohl, Daniel <
>> [hidden email]> wrote:
>>
>>> Hello everyone,
>>>
>>> I want to finally adress the problem that crops up when persisting
>>> page properties (which I do not want to).
>>>
>>> For example, I have a Page P1, containing a component C1. I also
>>> define a jquery dialog J1 in my page, which is opened inside C1 via a
>>> dialogajaxlink. The dialog contains component C2.
>>> So, basically:
>>> P1->C1
>>> P1->J1->C2
>>>
>>> For this example, I have to entity classes: E1 and E2.
>>> E1 contains a list of E2's.
>>>
>>> P1 receives an activation context, the id of an E1.
>>> In setupRender I fetch the E1 entity and use it to render the page.
>>> C1 currently receives the E1 entity as a parameter and accesses one
>>> of the contained E2's.
>>>
>>> Now, C1 is shown, I click something and raise an event that should
>>> update the shown C1.
>>> If I @Persist the E1 entity, all is okay, because the ID and class is
>>> saved between requests and so the E1 entity can be retrieved again.
>>>
>>> 1.       But I don't want to store with @Persist. What are my options?
>>>
>>> Let's do another:
>>> In another example, P1 displays E1 entities and loops the component
>>> C1 over all E2 entities contained in E1. In every C1 loop iteration
>>> (containing an E2 entity) there is a button opening the dialog J1
>>> respectively the component C2 with the E2 id as a parameter, to edit
>>> E2's in a Form.
>>>
>>>
>>> 2.       When I submit the form to update the E2, what should I do then?
>>> The id parameter is lost if @Persist is not used with E1, because
>>> then the
>>> E1 entity is lost and thus no list of E2's can be reproduced.
>>>
>>> I hope that wasn't too formal and someone can help me understand.
>>>
>>> Regards,
>>> Daniel P.
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]