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, n
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 change
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 spr
>> 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
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
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
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 cla
Okay,
I understand, write test for checking this particular thing and you can be calm.
How are you satisfied with using Hibernate Validator?
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 pro
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,
Ma
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
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 co
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 Validation
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 PROTE
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 tapestr
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
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
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)
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 tapest
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 <[
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:
pr
20 matches
Mail list logo
