JumpStart Edit example - prepareForSubmit event handler

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

JumpStart Edit example - prepareForSubmit event handler

Poggenpohl, Daniel
Hi,

http://jumpstart.doublenegative.com.au/jumpstart/examples/input/edit1/1

describes an example where a BeanEditForm is used to edit some object and update the database.

The example uses the following code:

    // Form bubbles up the PREPARE_FOR_SUBMIT event during form submission.

    void onPrepareForSubmit() throws Exception {
        // Get objects for the form fields to overlay.
        person = findPerson(personId);
    }

When I implement the example and set a few breakpoints, every time this event handler is called, the person object already is the same as is found by findPerson(personId). I can't seem to find the reason that the handler retrieves the same object from the database once again.

Is this done because of detached objects? Or is there some other reasoning behind this?

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: JumpStart Edit example - prepareForSubmit event handler

JumpStart
If the field has retained its state in some way (such as @Persist or @SessionState) then this is to be expected. Otherwise, it’s an illusion. Try using person, in code, before findPerson(…) is executed and you’ll find it is, in fact, null.

The illusion is something to do with byte code enhancement and not being in production mode. Lance is very good at explaining this. Lance?

> On 8 May 2015, at 11:55 pm, Poggenpohl, Daniel <[hidden email]> wrote:
>
> Hi,
>
> http://jumpstart.doublenegative.com.au/jumpstart/examples/input/edit1/1
>
> describes an example where a BeanEditForm is used to edit some object and update the database.
>
> The example uses the following code:
>
>    // Form bubbles up the PREPARE_FOR_SUBMIT event during form submission.
>
>    void onPrepareForSubmit() throws Exception {
>        // Get objects for the form fields to overlay.
>        person = findPerson(personId);
>    }
>
> When I implement the example and set a few breakpoints, every time this event handler is called, the person object already is the same as is found by findPerson(personId). I can't seem to find the reason that the handler retrieves the same object from the database once again.
>
> Is this done because of detached objects? Or is there some other reasoning behind this?
>
> 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]

Reply | Threaded
Open this post in threaded view
|

Re: JumpStart Edit example - prepareForSubmit event handler

Jens Breitenstein
In reply to this post by Poggenpohl, Daniel
Hi Daniel,

Do you use Hibernate? Maybe your instance is stored in the Hibernate Session Cache thus you get the same object? I had a similar issue when working with HSQL/Hibernate...

Jens

Von meinem iPhone gesendet

> Am 08.05.2015 um 15:55 schrieb Poggenpohl, Daniel <[hidden email]>:
>
> Hi,
>
> http://jumpstart.doublenegative.com.au/jumpstart/examples/input/edit1/1
>
> describes an example where a BeanEditForm is used to edit some object and update the database.
>
> The example uses the following code:
>
>    // Form bubbles up the PREPARE_FOR_SUBMIT event during form submission.
>
>    void onPrepareForSubmit() throws Exception {
>        // Get objects for the form fields to overlay.
>        person = findPerson(personId);
>    }
>
> When I implement the example and set a few breakpoints, every time this event handler is called, the person object already is the same as is found by findPerson(personId). I can't seem to find the reason that the handler retrieves the same object from the database once again.
>
> Is this done because of detached objects? Or is there some other reasoning behind this?
>
> 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]

Reply | Threaded
Open this post in threaded view
|

Re: JumpStart Edit example - prepareForSubmit event handler

Lance Java
In reply to this post by JumpStart
I haven't really been following this thread... But tapestry uses byte code
manipulation magic to change component properties to PerThreadValues which
means the actual member variables are unused.

In development mode, tapestry mirrors the values to the member variables to
make debugging easier. In production mode this mirroring does not occur.