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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Martin Grotzke http://www.javakaffee.de/blog/
signature.asc
Description: This is a digitally signed message part
