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 11:13:13 UTC

Re: T5 Invoke ValidationTracker recordError with elementName instead of Field

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 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