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" <[EMAIL PROTECTED]>
08.07.2008 12:03
Bitte antworten an
"Tapestry users" <users@tapestry.apache.org>
An
"Tapestry users" <users@tapestry.apache.org>
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" <[EMAIL PROTECTED]
>
To: "Tapestry users" <users@tapestry.apache.org>
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" <[EMAIL PROTECTED]>
07.07.2008 21:15
Bitte antworten an
"Tapestry users" <users@tapestry.apache.org>
An
<users@tapestry.apache.org>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
