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 09:19:54 UTC
Re: T5 Invoke ValidationTracker recordError
with elementName instead of Field
On Thu, 2007-06-14 at 07:51 +0200, Jiri Mares wrote:
> Okay,
>
> I understand, write test for checking this particular thing and you can be calm.
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... ;)
>
> 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.
Cheers,
Martin
>
> jirka
>
> Martin Grotzke napsal(a):
> > Yes, we already did this, but this works only as long as the internals
> > of tapestry do not change. E.g. if another property of Field would be
> > used or e.g. the hashCode or equals methods would be used, our
> > application would be broken.
> >
> > That's why I ask for a modification of the interface.
> >
> > Cheers,
> > Martin
> >
> >
> > On Wed, 2007-06-13 at 09:26 +0200, Jiri Mares wrote:
> >> Hi Martin,
> >>
> >> why not to implement your own Field and fill it with the name and pass it into recordError?
> >>
> >> Jirka
> >>
> >> Martin Grotzke napsal(a):
> >>> Yes, I totally understand and it's of course very important that
> >>> you do not change the API each time a user asks for it.
> >>>
> >>> The question in this case is then: why does the interface require
> >>> a Field? It's only the Field's elementName that is used for the
> >>> recordError functionality, so is it only for convenience, that
> >>> recordError expects a Field, so that users do not have to do
> >>> s.th. like recordError(_field.getElementName(), "foo")?
> >>>
> >>> Or is there another reason why recordError asks for a Field?
> >>>
> >>> Cheers,
> >>> Martin
> >>>
> >>>
> >>> On Tue, 2007-06-12 at 10:54 -0700, Howard Lewis Ship wrote:
> >>>> There's a long history in Tapestry of any time there's a hint of extra
> >>>> API, people find a way to abuse it. So I'm being very, very
> >>>> conservative!
> >>>>
> >>>> On 6/12/07, Martin Grotzke <ma...@javakaffee.de> wrote:
> >>>>> And what are your concerns with an additional method
> >>>>> recordError(String,String) on the ValidationTracker (and Form)?
> >>>>>
> >>>>> Cheers,
> >>>>> Martin
> >>>>>
> >>>>>
> >>>>> On Tue, 2007-06-12 at 09:19 -0700, Howard Lewis Ship wrote:
> >>>>>> I'm not familiar enough with Hibernate Validator to say.
> >>>>>>
> >>>>>> On 6/11/07, Martin Grotzke <ma...@javakaffee.de> wrote:
> >>>>>>> Hi Howard,
> >>>>>>>
> >>>>>>> On Sat, 2007-06-09 at 22:44 +0200, Martin Grotzke wrote:
> >>>>>>>> Does this enable us to use hibernate validator in our business layer
> >>>>>>>> that is completely independent from tapestry?
> >>>>>>>> Hibernate validator is right now our favorite option for validation,
> >>>>>>>> but it might be that we have to use an own implementation - we're still
> >>>>>>>> evaluating.
> >>>>>>>>
> >>>>>>>> What we're sure about is that in the business layer validation is
> >>>>>>>> performed and that for each validation error details are provided
> >>>>>>>> that should allow the presentation layer to map this information
> >>>>>>>> to a specific field/element.
> >>>>>>>>
> >>>>>>>> IMHO a good solution for this use case is recording the error with
> >>>>>>>> the element name, without being forced to have a Field for each
> >>>>>>>> element.
> >>>>>>>>
> >>>>>>>> What do you think?
> >>>>>>> Do you have any comments/feedback concerning this?
> >>>>>>>
> >>>>>>> Thanx && cheers,
> >>>>>>> Martin
> >>>>>>>
> >>>>>>>
> >>>>>>>> Cheers,
> >>>>>>>> Martin
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Sat, 2007-06-09 at 12:48 -0700, Howard Lewis Ship wrote:
> >>>>>>>>> That's true ... though I expect to make Tapestry smarter about
> >>>>>>>>> recognizing the Hibernate annotations and producing automatic client-
> >>>>>>>>> and server-side validation for them.
> >>>>>>>>>
> >>>>>>>>> On 6/9/07, Martin Grotzke <ma...@javakaffee.de> wrote:
> >>>>>>>>>> We want to do validation in the business layer (with hibernate
> >>>>>>>>>> validator) and get back an exception with a list of invalid values,
> >>>>>>>>>> where each invalid value provides the property path.
> >>>>>>>>>>
> >>>>>>>>>> Then we want to have a mapping of the property path to the element
> >>>>>>>>>> name and record an error for this on the tapestry form.
> >>>>>>>>>>
> >>>>>>>>>> The value is to be able to use hibernate validator in our business
> >>>>>>>>>> layer and not to be forced to define each Field in the page class,
> >>>>>>>>>> which is better in terms of performance and saves unnecessary work.
> >>>>>>>>>>
> >>>>>>>>>> Cheers,
> >>>>>>>>>> Martin
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Sat, 2007-06-09 at 10:07 -0700, Howard Lewis Ship wrote:
> >>>>>>>>>>> I don't see the value ... how would you obtain the element name
> >>>>>>>>>>> without getting the field itself; and if you've injected the field (to
> >>>>>>>>>>> invoke getElementName() ), then why wouldn't you just pass the field
> >>>>>>>>>>> to the tracker?
> >>>>>>>>>>>
> >>>>>>>>>>> Convince me there's something actually missing.
> >>>>>>>>>>>
> >>>>>>>>>>> On 6/9/07, Martin Grotzke <ma...@freiheit.com> wrote:
> >>>>>>>>>>>> Hello,
> >>>>>>>>>>>>
> >>>>>>>>>>>> right now there's a recordError(Field,String) method for storing
> >>>>>>>>>>>> errors for elements of the page.
> >>>>>>>>>>>>
> >>>>>>>>>>>> We would like to have also a method recordError(String,String) where
> >>>>>>>>>>>> the first parameter is the element name.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The ValidationTrackerImpl seems to use only the elementName of the
> >>>>>>>>>>>> Field:
> >>>>>>>>>>>>
> >>>>>>>>>>>> private FieldTracker get(Field field)
> >>>>>>>>>>>> {
> >>>>>>>>>>>> String key = field.getElementName();
> >>>>>>>>>>>>
> >>>>>>>>>>>> refreshFieldToTracker();
> >>>>>>>>>>>>
> >>>>>>>>>>>> FieldTracker result = InternalUtils.get(_fieldToTracker, key);
> >>>>>>>>>>>>
> >>>>>>>>>>>> if (result == null)
> >>>>>>>>>>>> result = new FieldTracker(key);
> >>>>>>>>>>>>
> >>>>>>>>>>>> return result;
> >>>>>>>>>>>> }
> >>>>>>>>>>>>
> >>>>>>>>>>>> so an additional method seems to be not a big issue.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Would this be possible to add to T5? Shall we submit a patch for this
> >>>>>>>>>>>> here in the list or enter an issue?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanx && cheers,
> >>>>>>>>>>>> Martin
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> Martin Grotzke
> >>>>>>>>>>>> Dipl.-Inf.
> >>>>>>>>>>>>
> >>>>>>>>>>>> freiheit.com technologies gmbh
> >>>>>>>>>>>> Straßenbahnring 22 / 20251 Hamburg, Germany
> >>>>>>>>>>>> fon +49 (0)40 / 890584-0
> >>>>>>>>>>>> fax +49 (0)40 / 890584-20
> >>>>>>>>>>>> HRB Hamburg 70814
> >>>>>>>>>>>>
> >>>>>>>>>>>> eb0e 645c 9730 c8a3 ee2f 1b9a 5de5 21cb c259 fe34
> >>>>>>>>>>>> Geschäftsführer: Claudia Dietze, Stefan Richter, Jörg Kirchhof
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Martin Grotzke
> >>>>>>>>>> http://www.javakaffee.de/blog/
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>> --
> >>>>>>> Martin Grotzke
> >>>>>>> http://www.javakaffee.de/blog/
> >>>>>>>
> >>>>>>>
> >>>>> --
> >>>>> Martin Grotzke
> >>>>> http://www.javakaffee.de/blog/
> >>>>>
> >>>>>
>
--
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
Re: T5 Invoke ValidationTracker
recordError with elementName instead of Field
Posted by Martin Grotzke <ma...@javakaffee.de>.
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 Jiri Mares <Ji...@svt.cz>.
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 ...
>> 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