You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Martin Grotzke <ma...@javakaffee.de> on 2007/06/14 10:44:29 UTC
Re: T5 Invoke ValidationTracker
recordError with elementName instead of Field
On Thu, 2007-06-14 at 09:44 +0200, Jiri Mares wrote:
> Hi,
>
> > Yeah, but what to do when the test fails then? Rewrite creation
> > of dummy fields to whatever, or pull all fields for the whole
> > application in page classes.
> >
> > Unit tests help to detect the problem then, but do not solve it
> > basically ;)
> >
> > And I'm still interested, why the interface expects a Field,
> > if only the element name is used - mostly there's some reason... ;)
>
> you have to encapsulate to code into one method to be able to change it easilly, nothing more ...
Sorry, but I don't understand what you want to say with this...
Cheers,
Martin
>
> >> How are you satisfied with using Hibernate Validator?
> > Two issues until now:
> > - the NotNull validator is applied even if you turn off validation,
> > however, all other validators are not applied. We wrote our own
> > NotNull validator as a workaround - really simple
> > - integration with spring is not designed if you have your own
> > validators - so there's no validatorfactory or anything, so
> > that you have to pull other resources like DAOs or services
> > from the spring bean factory if you need them
> >
> > Apart from that it feels really good.
>
> Thanks for your opinion ...
>
> Jirka
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
--
Martin Grotzke
http://www.javakaffee.de/blog/
Re: T5
Invoke ValidationTracker recordError with elementName instead of Field
Posted by Martin Grotzke <ma...@javakaffee.de>.
On Thu, 2007-06-14 at 11:18 +0200, Jiri Mares wrote:
> >>>> you have to encapsulate to code into one method to be able to change it easilly, nothing more ...
> >>> Sorry, but I don't understand what you want to say with this...
> >> The code adding the field error have to be on one place, not spread through whole application to be easilly changed when
> >> the future versions of Tapestry will require.
> >>
> >> Eg. method:
> >>
> >> void addValidationError(HibernateValidateException ex) {
> >> Field f = new MyField(getFieldNameFromValidateException(ex));
> >> recordError(f, getErrorMessageFromValidateException(ex));
> >> }
> >>
> >> This method you would invoke everywhere where the validation exception is catched, so when the change will be necessary,
> >> anly this method will be changed.
> > Yes, but as I already said previously, IMHO this is not really solid:
> > what do you do when T5 starts using the equals method of the Field
> > in some way? Or it would start to use other informations - ok, there is
> > not much in the Field - but according to the interface it would be
> > totally legal... Do you see my point?
>
> Yes, I understand ... then the addValidationError method would in some way look up the Field instances via Page and the
> name ...
Ok, solution for this case ;)
Cheers,
Martin
>
> Jirka
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
--
Martin Grotzke
http://www.javakaffee.de/blog/
Re: T5 Invoke ValidationTracker recordError with elementName instead
of Field
Posted by Jiri Mares <Ji...@svt.cz>.
>>>> you have to encapsulate to code into one method to be able to change it easilly, nothing more ...
>>> Sorry, but I don't understand what you want to say with this...
>> The code adding the field error have to be on one place, not spread through whole application to be easilly changed when
>> the future versions of Tapestry will require.
>>
>> Eg. method:
>>
>> void addValidationError(HibernateValidateException ex) {
>> Field f = new MyField(getFieldNameFromValidateException(ex));
>> recordError(f, getErrorMessageFromValidateException(ex));
>> }
>>
>> This method you would invoke everywhere where the validation exception is catched, so when the change will be necessary,
>> anly this method will be changed.
> Yes, but as I already said previously, IMHO this is not really solid:
> what do you do when T5 starts using the equals method of the Field
> in some way? Or it would start to use other informations - ok, there is
> not much in the Field - but according to the interface it would be
> totally legal... Do you see my point?
Yes, I understand ... then the addValidationError method would in some way look up the Field instances via Page and the
name ...
Jirka
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5 Invoke
ValidationTracker recordError with elementName instead of Field
Posted by Martin Grotzke <ma...@javakaffee.de>.
On Thu, 2007-06-14 at 10:54 +0200, Jiri Mares wrote:
> >> you have to encapsulate to code into one method to be able to change it easilly, nothing more ...
> > Sorry, but I don't understand what you want to say with this...
>
> The code adding the field error have to be on one place, not spread through whole application to be easilly changed when
> the future versions of Tapestry will require.
>
> Eg. method:
>
> void addValidationError(HibernateValidateException ex) {
> Field f = new MyField(getFieldNameFromValidateException(ex));
> recordError(f, getErrorMessageFromValidateException(ex));
> }
>
> This method you would invoke everywhere where the validation exception is catched, so when the change will be necessary,
> anly this method will be changed.
Yes, but as I already said previously, IMHO this is not really solid:
what do you do when T5 starts using the equals method of the Field
in some way? Or it would start to use other informations - ok, there is
not much in the Field - but according to the interface it would be
totally legal... Do you see my point?
I just wanted to ask why the interface is looking like that and if it
would be possible to simplify it.
So if there's absolutely no way in this direction I think we have to
accept it - though it's the first thing that introduces breakability
into our app. Apart from this one issue T5 is really wonderful!
Cheers,
Martin
>
> Jirka
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
--
Martin Grotzke
http://www.javakaffee.de/blog/
Re: T5 Invoke ValidationTracker recordError with elementName instead
of Field
Posted by Jiri Mares <Ji...@svt.cz>.
>> you have to encapsulate to code into one method to be able to change it easilly, nothing more ...
> Sorry, but I don't understand what you want to say with this...
The code adding the field error have to be on one place, not spread through whole application to be easilly changed when
the future versions of Tapestry will require.
Eg. method:
void addValidationError(HibernateValidateException ex) {
Field f = new MyField(getFieldNameFromValidateException(ex));
recordError(f, getErrorMessageFromValidateException(ex));
}
This method you would invoke everywhere where the validation exception is catched, so when the change will be necessary,
anly this method will be changed.
Jirka
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org