I know. Implementation was quicker then
thought (stick to Java serialization for simplicity) and
a lot more time was was wasted in investigating unecessary 
workarounds.

Its a pitty. So if it is needed, implement it.


Cheers,

Martin (Kersten)

-----Ursprüngliche Nachricht-----
Von: Filip S. Adamsen [mailto:[EMAIL PROTECTED] 
Gesendet: Donnerstag, 6. März 2008 13:23
An: Tapestry users
Betreff: Re: AW: AW: T5: Preventing form success

Yeah, that's what I've been wanting to do for a while, but I haven't had the 
time for it. Thanks for the pointers.

-Filip

Martin Kersten skrev:
> Hi Filip,
> 
>   the problem of persiting objects using @Persist might lead to 
> serious problems when the user uses views the page in different 
> browser tabs.
> 
> When you are using a database and you are going to distribute you 
> might use the conversation pattern. Just persist a conversation for 
> this form. We using something home breed here. Just a serialization 
> store in database using a unique (autoincrement) conversation id. Last 
> change date is recorded to remove outdated conversations. Since this 
> store is independent from session, it introduces little overhead.
> 
> Only thing to change is having a conversation id on the form.
> 
> As far as I know, Tapestry still have no support for this kind of 
> conversation-driven approach. And I am also not aware of any 
> sub-projects. But using hibernate or SQL one should implement this 
> approach in about 5 to 10 hours.
> 
> 
> Cheers,
> 
> Martin (Kersten)
> 
> -----Ursprüngliche Nachricht-----
> Von: Filip S. Adamsen [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 6. März 2008 10:10
> An: Tapestry users
> Betreff: Re: AW: T5: Preventing form success
> 
> Hi,
> 
> Well, due to the nature of the content being created/edited, it's necessary 
> to have the preview on the same page as the form. (This is for a content 
> management system.) I know about the two requests per page behaviour of 
> Tapestry, but consider that when a validation error occurs, the user input is 
> not discarded but saved by the ValidationTracker. I guess I shouldn't take 
> advantage of this, really, as it doesn't have anything to do with validation.
> 
> And yeah, I'm persisting my objects. I just thought there might be an easier 
> way.
> 
> -Filip
> 
> Martin Kersten skrev:
>> Hi Fillip,
>>
>>    I would instantly go for a multi stage / multi-page formular.
>> Sounds that this preview is a real functionality and so should be 
>> reflected by your component.
>>
>> The lost of the data is caused by the two requests per response 
>> behavior of tapestry. You may go with persist but I guess a better 
>> way would be using the context during redirect.
>>
>>
>> Cheers,
>>
>> Martin (Kersten)
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Filip S. Adamsen [mailto:[EMAIL PROTECTED]
>> Gesendet: Mittwoch, 5. März 2008 20:40
>> An: Tapestry users
>> Betreff: T5: Preventing form success
>>
>> Hi,
>>
>> I have to show a preview of some content submitted through a form for 
>> verification before it is added/updated in my database. What's the best way 
>> to do this? Right now I set a flag in my onSelectedFromPreview method and 
>> check it in my onSuccessFromAdd/Update method where I return null if the 
>> flag is set. This, unfortunately, results in the user input being lost if I 
>> don't the object I want to add/update.
>>
>> Is there a way to prevent the form submit from succeeding without causing a 
>> validation failure?
>>
>> -Filip
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to