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 [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
Re: T5 Invoke ValidationTracker recordError with elementName instead of Field
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 Invoke ValidationTracker recordError with elementName instead of Field
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: [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
Re: T5 Invoke ValidationTracker recordError with elementName instead of Field
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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: [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
Re: T5 Invoke ValidationTracker recordError with elementName instead of Field
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 Invoke ValidationTracker recordError with elementName instead of Field
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: [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
Re: T5 Invoke ValidationTracker recordError with elementName instead of Field
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,
Re: T5 Invoke ValidationTracker recordError with elementName instead of Field
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/
--
Jiří Mareš (mailto:[EMAIL PROTECTED])
ČSAD SVT Praha, s.r.o. (http://www.svt.cz)
Czech Republic
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 Invoke ValidationTracker recordError with elementName instead of Field
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/
--
Re: T5 Invoke ValidationTracker recordError with elementName instead of Field
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 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
Re: T5 Invoke ValidationTracker recordError with elementName instead of Field
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/
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 Invoke ValidationTracker recordError with elementName instead of Field
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/
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 Invoke ValidationTracker recordError with elementName instead of Field
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/
signature.asc
Description: This is a digitally signed message part
Re: T5 Invoke ValidationTracker recordError with elementName instead of Field
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
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: T5 Invoke ValidationTracker recordError with elementName instead of Field
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?
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/
signature.asc
Description: This is a digitally signed message part
