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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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/
signature.asc
Description: This is a digitally signed message part