[T5] Default ValidationTracker clearing needed?

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

[T5] Default ValidationTracker clearing needed?

Vjeran Marcinko
Hi all.

I posted this as a comment on some closed Jira issue, but nevertheless, I
would like to see comments from everybody...

ValidationTracker in its current form clears its input values before
"success" event. I guess it is done this way assuming that no error can
happen anymore when "success" is triggered, and one doesn't want to see
those values even if staying on same page.

Two frequent cases come to my mind when this simply doesn't hold water...

1. Cases when SOME validation is performed inside business methods, thrown
as checked exceptions when not satisfied. This validation cannot be
performed prior to calling business method. I don't believe that in those
cases I should place calling the business method inside unnatural onValidate
handler. I believe it should still be placed inside onSuccess, since all a
priori validation has passed well.

Example is typical call on UserDao from within EditPage.onSuccess() method :

UserDao.save(User user) throws UsernameReservedException

I still have to be able to catch this exception and somehow dispay error
with all input values still shown.

2. Frequently, when using search forms, I display search results on same
page where form resides. Being able to show all search form criteria values
is great stuff, since user can see what criteria he just entered. Since this
is normal type of request flow, input values should ont be cleared before
"success".


MY SUGGESTION:

ValidationTracker should be persisted wtih "flash" strategy, and values
should never be cleared. If one stays on same page, regardless if there was
an error (in any handler method - onValidate, onSuccess...)  or not, input
values would still be there. If user decides to leave the page, "flash"
strategy will ensure that these values will not be visible he comes back to
this page later.
In rare cases when user wants to stay on the same page, but doesn't want to
see input values, he can explicitly clear those values.

Thoughts?

-Vjeran


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

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Default ValidationTracker clearing needed?

Kristian Marinkovic
hi,

the Form component was changed some time ago to
use the "flash" persistence strategy for the ValidationTracker

from the code:
    @Persist(PersistenceConstants.FLASH)
    private ValidationTracker defaultTracker;

g,
kris




"Vjeran Marcinko" <[hidden email]>
07.07.2008 21:15
Bitte antworten an
"Tapestry users" <[hidden email]>


An
<[hidden email]>
Kopie

Thema
[T5] Default ValidationTracker clearing needed?







Hi all.

I posted this as a comment on some closed Jira issue, but nevertheless, I
would like to see comments from everybody...

ValidationTracker in its current form clears its input values before
"success" event. I guess it is done this way assuming that no error can
happen anymore when "success" is triggered, and one doesn't want to see
those values even if staying on same page.

Two frequent cases come to my mind when this simply doesn't hold water...

1. Cases when SOME validation is performed inside business methods, thrown

as checked exceptions when not satisfied. This validation cannot be
performed prior to calling business method. I don't believe that in those
cases I should place calling the business method inside unnatural
onValidate
handler. I believe it should still be placed inside onSuccess, since all a

priori validation has passed well.

Example is typical call on UserDao from within EditPage.onSuccess() method
:

UserDao.save(User user) throws UsernameReservedException

I still have to be able to catch this exception and somehow dispay error
with all input values still shown.

2. Frequently, when using search forms, I display search results on same
page where form resides. Being able to show all search form criteria
values
is great stuff, since user can see what criteria he just entered. Since
this
is normal type of request flow, input values should ont be cleared before
"success".


MY SUGGESTION:

ValidationTracker should be persisted wtih "flash" strategy, and values
should never be cleared. If one stays on same page, regardless if there
was
an error (in any handler method - onValidate, onSuccess...)  or not, input

values would still be there. If user decides to leave the page, "flash"
strategy will ensure that these values will not be visible he comes back
to
this page later.
In rare cases when user wants to stay on the same page, but doesn't want
to
see input values, he can explicitly clear those values.

Thoughts?

-Vjeran


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


Reply | Threaded
Open this post in threaded view
|

Re: [T5] Default ValidationTracker clearing needed?

Vjeran Marcinko
Oh, I didn't know that since I've seen some discussions before that it was
"session".
Nevertheless, clearing of the input values prior to "success" event still
poses slight problem IMO.

I am not fond of persisting some entity objects between requests just to be
able to see those input values rendered, since this can raise some Hibernate
session problems etc...

-Vjeran

----- Original Message -----
From: "Kristian Marinkovic" <[hidden email]>
To: "Tapestry users" <[hidden email]>
Sent: Tuesday, July 08, 2008 11:16 AM
Subject: Re: [T5] Default ValidationTracker clearing needed?


> hi,
>
> the Form component was changed some time ago to
> use the "flash" persistence strategy for the ValidationTracker
>
> from the code:
>    @Persist(PersistenceConstants.FLASH)
>    private ValidationTracker defaultTracker;
>
> g,
> kris
>
>
>
>
> "Vjeran Marcinko" <[hidden email]>
> 07.07.2008 21:15
> Bitte antworten an
> "Tapestry users" <[hidden email]>
>
>
> An
> <[hidden email]>
> Kopie
>
> Thema
> [T5] Default ValidationTracker clearing needed?
>
>
>
>
>
>
>
> Hi all.
>
> I posted this as a comment on some closed Jira issue, but nevertheless, I
> would like to see comments from everybody...
>
> ValidationTracker in its current form clears its input values before
> "success" event. I guess it is done this way assuming that no error can
> happen anymore when "success" is triggered, and one doesn't want to see
> those values even if staying on same page.
>
> Two frequent cases come to my mind when this simply doesn't hold water...
>
> 1. Cases when SOME validation is performed inside business methods, thrown
>
> as checked exceptions when not satisfied. This validation cannot be
> performed prior to calling business method. I don't believe that in those
> cases I should place calling the business method inside unnatural
> onValidate
> handler. I believe it should still be placed inside onSuccess, since all a
>
> priori validation has passed well.
>
> Example is typical call on UserDao from within EditPage.onSuccess() method
> :
>
> UserDao.save(User user) throws UsernameReservedException
>
> I still have to be able to catch this exception and somehow dispay error
> with all input values still shown.
>
> 2. Frequently, when using search forms, I display search results on same
> page where form resides. Being able to show all search form criteria
> values
> is great stuff, since user can see what criteria he just entered. Since
> this
> is normal type of request flow, input values should ont be cleared before
> "success".
>
>
> MY SUGGESTION:
>
> ValidationTracker should be persisted wtih "flash" strategy, and values
> should never be cleared. If one stays on same page, regardless if there
> was
> an error (in any handler method - onValidate, onSuccess...)  or not, input
>
> values would still be there. If user decides to leave the page, "flash"
> strategy will ensure that these values will not be visible he comes back
> to
> this page later.
> In rare cases when user wants to stay on the same page, but doesn't want
> to
> see input values, he can explicitly clear those values.
>
> Thoughts?
>
> -Vjeran
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.138 / Virus Database: 270.4.6/1539 - Release Date: 7.7.2008
> 18:35
>
>


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

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Default ValidationTracker clearing needed?

Kristian Marinkovic
hi,

this is how i do it... one of many possible ways :)

i let tapestry populate a DTO bean that is sent during the validate
event through a facade (IOC service) to my businesslayer. there
the DTO is then mapped to my BOs. (as in the theory :)

because i don't want to write these stupid DTO- BO mappings i have
a DTO and a BO interface. the view layer knows only the DTO
interface with getter and setter methods. the only thing the facade does
is to perform a cast from the DTO interface to the BO interface and to
call the BOs validate method.

my facade returns a validationResult instance that contains the error
messages that are fed into the form component preventing the success
event. and sometimes i have to call save() to get a result (username/
password). in this cases i dont use the success event at all (in the login
example i return a Link to the welcome page).

btw. the facade will catch any exception that might occur during
the business transaction. so the view (tapestry) will not know anything
about it, except the error messages i set.

Another thing you can do is to create a tapestry page that is desgined
to display a certain exception. Take a look at the ExcpetionReporter page.

IMHO the events provided by tapestry are just fine. most of the time the
way the application is designed is the problem. a clean separation of
view and businesslayer is crucial.

have a look at  "Pojos in Action" by Chris Richardson  or "Domain
Driven Design" by Eric Evans... they are really worth reading.

g,
kris






"Vjeran Marcinko" <[hidden email]>
08.07.2008 12:03
Bitte antworten an
"Tapestry users" <[hidden email]>


An
"Tapestry users" <[hidden email]>
Kopie

Thema
Re: [T5] Default ValidationTracker clearing needed?







Oh, I didn't know that since I've seen some discussions before that it was

"session".
Nevertheless, clearing of the input values prior to "success" event still
poses slight problem IMO.

I am not fond of persisting some entity objects between requests just to
be
able to see those input values rendered, since this can raise some
Hibernate
session problems etc...

-Vjeran

----- Original Message -----
From: "Kristian Marinkovic" <[hidden email]>
To: "Tapestry users" <[hidden email]>
Sent: Tuesday, July 08, 2008 11:16 AM
Subject: Re: [T5] Default ValidationTracker clearing needed?


> hi,
>
> the Form component was changed some time ago to
> use the "flash" persistence strategy for the ValidationTracker
>
> from the code:
>    @Persist(PersistenceConstants.FLASH)
>    private ValidationTracker defaultTracker;
>
> g,
> kris
>
>
>
>
> "Vjeran Marcinko" <[hidden email]>
> 07.07.2008 21:15
> Bitte antworten an
> "Tapestry users" <[hidden email]>
>
>
> An
> <[hidden email]>
> Kopie
>
> Thema
> [T5] Default ValidationTracker clearing needed?
>
>
>
>
>
>
>
> Hi all.
>
> I posted this as a comment on some closed Jira issue, but nevertheless,
I
> would like to see comments from everybody...
>
> ValidationTracker in its current form clears its input values before
> "success" event. I guess it is done this way assuming that no error can
> happen anymore when "success" is triggered, and one doesn't want to see
> those values even if staying on same page.
>
> Two frequent cases come to my mind when this simply doesn't hold
water...
>
> 1. Cases when SOME validation is performed inside business methods,
thrown
>
> as checked exceptions when not satisfied. This validation cannot be
> performed prior to calling business method. I don't believe that in
those
> cases I should place calling the business method inside unnatural
> onValidate
> handler. I believe it should still be placed inside onSuccess, since all
a
>
> priori validation has passed well.
>
> Example is typical call on UserDao from within EditPage.onSuccess()
method

> :
>
> UserDao.save(User user) throws UsernameReservedException
>
> I still have to be able to catch this exception and somehow dispay error
> with all input values still shown.
>
> 2. Frequently, when using search forms, I display search results on same
> page where form resides. Being able to show all search form criteria
> values
> is great stuff, since user can see what criteria he just entered. Since
> this
> is normal type of request flow, input values should ont be cleared
before
> "success".
>
>
> MY SUGGESTION:
>
> ValidationTracker should be persisted wtih "flash" strategy, and values
> should never be cleared. If one stays on same page, regardless if there
> was
> an error (in any handler method - onValidate, onSuccess...)  or not,
input

>
> values would still be there. If user decides to leave the page, "flash"
> strategy will ensure that these values will not be visible he comes back
> to
> this page later.
> In rare cases when user wants to stay on the same page, but doesn't want
> to
> see input values, he can explicitly clear those values.
>
> Thoughts?
>
> -Vjeran
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.138 / Virus Database: 270.4.6/1539 - Release Date: 7.7.2008

> 18:35
>
>


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


Reply | Threaded
Open this post in threaded view
|

Re: [T5] Default ValidationTracker clearing needed?

Vjeran Marcinko
Hi,

Thanx for suggestion, but I really don't see that I have any issue with my
application design. The facade that you described here is just nice
*view-layer* convenience that prepares error messages in bottom layer for
web pages above. I emphasize this *view-layer facade* since business/service
layer is not supose to manage any error messages at all, just throw
exceptions and client layer (web pages in this case) should catch it if
interested and display apropriate message.

As I mentioned before, for sake of atomicity and elegance of business layer,
I cannot and would not separate validation portion from business method
itself.
In other words, in case of:
userDao.save(User user) throws UsernameReservedException; // during
"success" event

, it would be wrong to separate it into:
userDao.checkUsername(String username); // during "validateForm" event
userDao.save(User user); // during "success" event

Maybe the way to solve the issue here would be to call nbuness method during
"validaeFomr" event, but that seems a bit strange considering purpose of the
method. And still, even that way would not suit for cases where I want to
stay on same page after successful form submit (as case with mentioned
search result page in my last post).

I don't have any issues with Tapestry event system in general, it's really
great. Only clearing of ValidationTracker input fields bothers me here.

And I've read Evans' DDD book. One of the greatest.

Regards,
Vjeran

----- Original Message -----
From: "Kristian Marinkovic" <[hidden email]>
To: "Tapestry users" <[hidden email]>
Sent: Tuesday, July 08, 2008 1:26 PM
Subject: Re: [T5] Default ValidationTracker clearing needed?


> hi,
>
> this is how i do it... one of many possible ways :)
>
> i let tapestry populate a DTO bean that is sent during the validate
> event through a facade (IOC service) to my businesslayer. there
> the DTO is then mapped to my BOs. (as in the theory :)
>
> because i don't want to write these stupid DTO- BO mappings i have
> a DTO and a BO interface. the view layer knows only the DTO
> interface with getter and setter methods. the only thing the facade does
> is to perform a cast from the DTO interface to the BO interface and to
> call the BOs validate method.
>
> my facade returns a validationResult instance that contains the error
> messages that are fed into the form component preventing the success
> event. and sometimes i have to call save() to get a result (username/
> password). in this cases i dont use the success event at all (in the login
> example i return a Link to the welcome page).
>
> btw. the facade will catch any exception that might occur during
> the business transaction. so the view (tapestry) will not know anything
> about it, except the error messages i set.
>
> Another thing you can do is to create a tapestry page that is desgined
> to display a certain exception. Take a look at the ExcpetionReporter page.
>
> IMHO the events provided by tapestry are just fine. most of the time the
> way the application is designed is the problem. a clean separation of
> view and businesslayer is crucial.
>
> have a look at  "Pojos in Action" by Chris Richardson  or "Domain
> Driven Design" by Eric Evans... they are really worth reading.
>
> g,
> kris
>
>
>
>
>
>
> "Vjeran Marcinko" <[hidden email]>
> 08.07.2008 12:03
> Bitte antworten an
> "Tapestry users" <[hidden email]>
>
>
> An
> "Tapestry users" <[hidden email]>
> Kopie
>
> Thema
> Re: [T5] Default ValidationTracker clearing needed?
>
>
>
>
>
>
>
> Oh, I didn't know that since I've seen some discussions before that it was
>
> "session".
> Nevertheless, clearing of the input values prior to "success" event still
> poses slight problem IMO.
>
> I am not fond of persisting some entity objects between requests just to
> be
> able to see those input values rendered, since this can raise some
> Hibernate
> session problems etc...
>
> -Vjeran
>
> ----- Original Message -----
> From: "Kristian Marinkovic" <[hidden email]>
> To: "Tapestry users" <[hidden email]>
> Sent: Tuesday, July 08, 2008 11:16 AM
> Subject: Re: [T5] Default ValidationTracker clearing needed?
>
>
>> hi,
>>
>> the Form component was changed some time ago to
>> use the "flash" persistence strategy for the ValidationTracker
>>
>> from the code:
>>    @Persist(PersistenceConstants.FLASH)
>>    private ValidationTracker defaultTracker;
>>
>> g,
>> kris
>>
>>
>>
>>
>> "Vjeran Marcinko" <[hidden email]>
>> 07.07.2008 21:15
>> Bitte antworten an
>> "Tapestry users" <[hidden email]>
>>
>>
>> An
>> <[hidden email]>
>> Kopie
>>
>> Thema
>> [T5] Default ValidationTracker clearing needed?
>>
>>
>>
>>
>>
>>
>>
>> Hi all.
>>
>> I posted this as a comment on some closed Jira issue, but nevertheless,
> I
>> would like to see comments from everybody...
>>
>> ValidationTracker in its current form clears its input values before
>> "success" event. I guess it is done this way assuming that no error can
>> happen anymore when "success" is triggered, and one doesn't want to see
>> those values even if staying on same page.
>>
>> Two frequent cases come to my mind when this simply doesn't hold
> water...
>>
>> 1. Cases when SOME validation is performed inside business methods,
> thrown
>>
>> as checked exceptions when not satisfied. This validation cannot be
>> performed prior to calling business method. I don't believe that in
> those
>> cases I should place calling the business method inside unnatural
>> onValidate
>> handler. I believe it should still be placed inside onSuccess, since all
> a
>>
>> priori validation has passed well.
>>
>> Example is typical call on UserDao from within EditPage.onSuccess()
> method
>> :
>>
>> UserDao.save(User user) throws UsernameReservedException
>>
>> I still have to be able to catch this exception and somehow dispay error
>> with all input values still shown.
>>
>> 2. Frequently, when using search forms, I display search results on same
>> page where form resides. Being able to show all search form criteria
>> values
>> is great stuff, since user can see what criteria he just entered. Since
>> this
>> is normal type of request flow, input values should ont be cleared
> before
>> "success".
>>
>>
>> MY SUGGESTION:
>>
>> ValidationTracker should be persisted wtih "flash" strategy, and values
>> should never be cleared. If one stays on same page, regardless if there
>> was
>> an error (in any handler method - onValidate, onSuccess...)  or not,
> input
>>
>> values would still be there. If user decides to leave the page, "flash"
>> strategy will ensure that these values will not be visible he comes back
>> to
>> this page later.
>> In rare cases when user wants to stay on the same page, but doesn't want
>> to
>> see input values, he can explicitly clear those values.
>>
>> Thoughts?
>>
>> -Vjeran
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - http://www.avg.com
>> Version: 8.0.138 / Virus Database: 270.4.6/1539 - Release Date: 7.7.2008
>
>> 18:35
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
>
> No virus found in this incoming message.
> Checked by AVG - http://www.avg.com
> Version: 8.0.138 / Virus Database: 270.4.6/1539 - Release Date: 7.7.2008
> 18:35
>
>


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

Reply | Threaded
Open this post in threaded view
|

Re: [T5] Default ValidationTracker clearing needed?

JumpStart
Hi Vjeran,

I completely agree with everything you just said.

Cheers,

Geoff

On 08/07/2008, at 11:20 PM, Vjeran Marcinko wrote:

> Hi,
>
> Thanx for suggestion, but I really don't see that I have any issue  
> with my application design. The facade that you described here is  
> just nice *view-layer* convenience that prepares error messages in  
> bottom layer for web pages above. I emphasize this *view-layer  
> facade* since business/service layer is not supose to manage any  
> error messages at all, just throw exceptions and client layer (web  
> pages in this case) should catch it if interested and display  
> apropriate message.
>
> As I mentioned before, for sake of atomicity and elegance of  
> business layer, I cannot and would not separate validation portion  
> from business method itself.
> In other words, in case of:
> userDao.save(User user) throws UsernameReservedException; // during  
> "success" event
>
> , it would be wrong to separate it into:
> userDao.checkUsername(String username); // during "validateForm" event
> userDao.save(User user); // during "success" event
>
> Maybe the way to solve the issue here would be to call nbuness  
> method during "validaeFomr" event, but that seems a bit strange  
> considering purpose of the method. And still, even that way would  
> not suit for cases where I want to stay on same page after  
> successful form submit (as case with mentioned search result page in  
> my last post).
>
> I don't have any issues with Tapestry event system in general, it's  
> really great. Only clearing of ValidationTracker input fields  
> bothers me here.
>
> And I've read Evans' DDD book. One of the greatest.
>
> Regards,
> Vjeran
>
> ----- Original Message ----- From: "Kristian Marinkovic" <[hidden email]
> >
> To: "Tapestry users" <[hidden email]>
> Sent: Tuesday, July 08, 2008 1:26 PM
> Subject: Re: [T5] Default ValidationTracker clearing needed?
>
>
>> hi,
>>
>> this is how i do it... one of many possible ways :)
>>
>> i let tapestry populate a DTO bean that is sent during the validate
>> event through a facade (IOC service) to my businesslayer. there
>> the DTO is then mapped to my BOs. (as in the theory :)
>>
>> because i don't want to write these stupid DTO- BO mappings i have
>> a DTO and a BO interface. the view layer knows only the DTO
>> interface with getter and setter methods. the only thing the facade  
>> does
>> is to perform a cast from the DTO interface to the BO interface and  
>> to
>> call the BOs validate method.
>>
>> my facade returns a validationResult instance that contains the error
>> messages that are fed into the form component preventing the success
>> event. and sometimes i have to call save() to get a result (username/
>> password). in this cases i dont use the success event at all (in  
>> the login
>> example i return a Link to the welcome page).
>>
>> btw. the facade will catch any exception that might occur during
>> the business transaction. so the view (tapestry) will not know  
>> anything
>> about it, except the error messages i set.
>>
>> Another thing you can do is to create a tapestry page that is  
>> desgined
>> to display a certain exception. Take a look at the  
>> ExcpetionReporter page.
>>
>> IMHO the events provided by tapestry are just fine. most of the  
>> time the
>> way the application is designed is the problem. a clean separation of
>> view and businesslayer is crucial.
>>
>> have a look at  "Pojos in Action" by Chris Richardson  or "Domain
>> Driven Design" by Eric Evans... they are really worth reading.
>>
>> g,
>> kris
>>
>>
>>
>>
>>
>>
>> "Vjeran Marcinko" <[hidden email]>
>> 08.07.2008 12:03
>> Bitte antworten an
>> "Tapestry users" <[hidden email]>
>>
>>
>> An
>> "Tapestry users" <[hidden email]>
>> Kopie
>>
>> Thema
>> Re: [T5] Default ValidationTracker clearing needed?
>>
>>
>>
>>
>>
>>
>>
>> Oh, I didn't know that since I've seen some discussions before that  
>> it was
>>
>> "session".
>> Nevertheless, clearing of the input values prior to "success" event  
>> still
>> poses slight problem IMO.
>>
>> I am not fond of persisting some entity objects between requests  
>> just to
>> be
>> able to see those input values rendered, since this can raise some
>> Hibernate
>> session problems etc...
>>
>> -Vjeran
>>
>> ----- Original Message ----- From: "Kristian Marinkovic" <[hidden email]
>> >
>> To: "Tapestry users" <[hidden email]>
>> Sent: Tuesday, July 08, 2008 11:16 AM
>> Subject: Re: [T5] Default ValidationTracker clearing needed?
>>
>>
>>> hi,
>>>
>>> the Form component was changed some time ago to
>>> use the "flash" persistence strategy for the ValidationTracker
>>>
>>> from the code:
>>>   @Persist(PersistenceConstants.FLASH)
>>>   private ValidationTracker defaultTracker;
>>>
>>> g,
>>> kris
>>>
>>>
>>>
>>>
>>> "Vjeran Marcinko" <[hidden email]>
>>> 07.07.2008 21:15
>>> Bitte antworten an
>>> "Tapestry users" <[hidden email]>
>>>
>>>
>>> An
>>> <[hidden email]>
>>> Kopie
>>>
>>> Thema
>>> [T5] Default ValidationTracker clearing needed?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Hi all.
>>>
>>> I posted this as a comment on some closed Jira issue, but  
>>> nevertheless,
>> I
>>> would like to see comments from everybody...
>>>
>>> ValidationTracker in its current form clears its input values before
>>> "success" event. I guess it is done this way assuming that no  
>>> error can
>>> happen anymore when "success" is triggered, and one doesn't want  
>>> to see
>>> those values even if staying on same page.
>>>
>>> Two frequent cases come to my mind when this simply doesn't hold
>> water...
>>>
>>> 1. Cases when SOME validation is performed inside business methods,
>> thrown
>>>
>>> as checked exceptions when not satisfied. This validation cannot be
>>> performed prior to calling business method. I don't believe that in
>> those
>>> cases I should place calling the business method inside unnatural
>>> onValidate
>>> handler. I believe it should still be placed inside onSuccess,  
>>> since all
>> a
>>>
>>> priori validation has passed well.
>>>
>>> Example is typical call on UserDao from within EditPage.onSuccess()
>> method
>>> :
>>>
>>> UserDao.save(User user) throws UsernameReservedException
>>>
>>> I still have to be able to catch this exception and somehow dispay  
>>> error
>>> with all input values still shown.
>>>
>>> 2. Frequently, when using search forms, I display search results  
>>> on same
>>> page where form resides. Being able to show all search form criteria
>>> values
>>> is great stuff, since user can see what criteria he just entered.  
>>> Since
>>> this
>>> is normal type of request flow, input values should ont be cleared
>> before
>>> "success".
>>>
>>>
>>> MY SUGGESTION:
>>>
>>> ValidationTracker should be persisted wtih "flash" strategy, and  
>>> values
>>> should never be cleared. If one stays on same page, regardless if  
>>> there
>>> was
>>> an error (in any handler method - onValidate, onSuccess...)  or not,
>> input
>>>
>>> values would still be there. If user decides to leave the page,  
>>> "flash"
>>> strategy will ensure that these values will not be visible he  
>>> comes back
>>> to
>>> this page later.
>>> In rare cases when user wants to stay on the same page, but  
>>> doesn't want
>>> to
>>> see input values, he can explicitly clear those values.
>>>
>>> Thoughts?
>>>
>>> -Vjeran
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - http://www.avg.com
>>> Version: 8.0.138 / Virus Database: 270.4.6/1539 - Release Date:  
>>> 7.7.2008
>>
>>> 18:35
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - http://www.avg.com
>> Version: 8.0.138 / Virus Database: 270.4.6/1539 - Release Date:  
>> 7.7.2008 18:35
>>
>
>
> ---------------------------------------------------------------------
> 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]