You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Galen Meurer <si...@galenmeurer.com> on 2004/02/13 22:54:14 UTC
has binding type conversion (toString) changed in beta-4?
I just upgraded our small, fledgling application to beta-4. Everything works
great, except one thing:
<input type="text" jwcid=order@TextField
value="ognl:picklistValue.sequenceNumber"/>
This used to display and now results in the following stack trace:
++
org.apache.tapestry.BindingException
Parameter value (1) is an instance of java.lang.Integer, which does not
inherit from java.lang.String.
binding: ExpressionBinding[PicklistEditor picklistValue.sequenceNumber]
location: context:/PicklistEditor.html, line 84
Stack Trace:
org.apache.tapestry.binding.AbstractBinding.getObject(AbstractBinding.java:2
70)
org.apache.tapestry.form.TextField.readValue(TextField.java:77)
org.apache.tapestry.form.AbstractTextField.renderComponent(AbstractTextField
.java:124)
[...]
++
sequenceNumber is indeed an Integer, but it used to silently convert to a
String and on update, back to an Integer in the fabulous magic conversion
that is Tapestry. I've compared the source of AbstractBinding.java from v1.7
(beta-3) and 1.9 (beta-4) and it hasn't changed WRT the implementation of
getObject -- but this behavior certainly appears to have changed for some
reason.
As a minimal test case, I added a TextField with an Integer value to the
border example and then upgraded it to beta-4 and it exhibits the same
behavior.
I'm not sure where to look. Does anybody have any idea that can help me out?
Should this work and I'm doing it wrong or have I messed up the upgrade in
some way?
Should this work and it's a bug in beta-4?
Is this an intentional change of behavior from beta-3? Have I abused the
type conversion mechanism?
Best,
Galen
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: has binding type conversion (toString) changed in beta-4?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
When I said global I didn't mean to put it in global but simply a global
declaration like the engine. I don't thing we need to hold on to the
delegate and the validators. The lifecycle will still remain as it is
now - request, page, none ...
-Harish
Erik Hatcher wrote:
> On Feb 16, 2004, at 9:17 PM, Harish Krishnaswamy wrote:
>
>>> The type conversion can tie into validation too, such that if
>>> desired, a type conversion failure is a validation exception and
>>> does not set things to a default value. Flexibility is key here.
>>
>>
>> That's true, in which case you will need the delegate anyway at least
>> the way it is now. I can certainly see us needing a global
>> delegate/validators for the application instead of having one per
>> page and then you essentially have what you want with a more fine
>> grained control over type conversion. The type converter on the other
>> hand will be applied globally if I am not mistaken? Don't get me
>> wrong, I still support the TypeConverter, only I like the validation
>> framework better, although it could certainly use polish ;)
>
>
> The global delegate/validators is something I was planning on wrapping
> into our code to simplify page development. I've yet to try this, so
> I'm not sure if I'll encounter any issues with it. But doing
> "global.delegate" would be cleaner than putting in the <bean>
> definitions and "beans.delegate" everywhere. Actually it'll likely
> need to be page or visit specific and not global, right? Otherwise it
> would conflict with other users?
>
> Yes, currently the TypeConverter extension is global. If defined, it
> applies to all expression bindings.
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: has binding type conversion (toString) changed in beta-4?
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Feb 16, 2004, at 9:17 PM, Harish Krishnaswamy wrote:
>> The type conversion can tie into validation too, such that if
>> desired, a type conversion failure is a validation exception and does
>> not set things to a default value. Flexibility is key here.
>
> That's true, in which case you will need the delegate anyway at least
> the way it is now. I can certainly see us needing a global
> delegate/validators for the application instead of having one per page
> and then you essentially have what you want with a more fine grained
> control over type conversion. The type converter on the other hand
> will be applied globally if I am not mistaken? Don't get me wrong, I
> still support the TypeConverter, only I like the validation framework
> better, although it could certainly use polish ;)
The global delegate/validators is something I was planning on wrapping
into our code to simplify page development. I've yet to try this, so
I'm not sure if I'll encounter any issues with it. But doing
"global.delegate" would be cleaner than putting in the <bean>
definitions and "beans.delegate" everywhere. Actually it'll likely
need to be page or visit specific and not global, right? Otherwise it
would conflict with other users?
Yes, currently the TypeConverter extension is global. If defined, it
applies to all expression bindings.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: has binding type conversion (toString) changed in beta-4?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Erik Hatcher wrote:
> On Feb 17, 2004, at 8:04 AM, Harish Krishnaswamy wrote:
>
>> I assume the convertValue would be a series of if esle (arghhh) for
>> converting each type? And I presume the TypeConverter is internally
>> used by OGNL when setValue is called? If so, how does the setValue
>> determine what toType to pass in to TypeConverter?
>
>
> A converter could be as ugly (if/else) or as elegant (mappings via
> configuration) as you like of course. A built-in converter for
> primitive/wrappers wouldn't need to be very elegant - just a couple of
> if instanceof's.
>
> Yes, a registered type converter is used for setValue. See
> ExpressionBinding.setObject. The toType comes from the type of the
> object the expression refers to.
Ah, yes of course.
> Say we have "ognl:age" on a TextField and there is a setAge(Integer
> age). toType would be Integer. So, it would be cool if Ognl.setValue
> was used for both directions, allowing the type converter to be in the
> middle.
Yes that would be really helpful.
> The toType for rendering a TextField would always be a String, of
> course.
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: has binding type conversion (toString) changed in beta-4?
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Feb 17, 2004, at 8:04 AM, Harish Krishnaswamy wrote:
> I assume the convertValue would be a series of if esle (arghhh) for
> converting each type? And I presume the TypeConverter is internally
> used by OGNL when setValue is called? If so, how does the setValue
> determine what toType to pass in to TypeConverter?
A converter could be as ugly (if/else) or as elegant (mappings via
configuration) as you like of course. A built-in converter for
primitive/wrappers wouldn't need to be very elegant - just a couple of
if instanceof's.
Yes, a registered type converter is used for setValue. See
ExpressionBinding.setObject. The toType comes from the type of the
object the expression refers to. Say we have "ognl:age" on a TextField
and there is a setAge(Integer age). toType would be Integer. So, it
would be cool if Ognl.setValue was used for both directions, allowing
the type converter to be in the middle. The toType for rendering a
TextField would always be a String, of course.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: has binding type conversion (toString) changed in beta-4?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
I assume the convertValue would be a series of if esle (arghhh) for
converting each type? And I presume the TypeConverter is internally used
by OGNL when setValue is called? If so, how does the setValue determine
what toType to pass in to TypeConverter?
-Harish
Erik Hatcher wrote:
> On Feb 16, 2004, at 9:45 PM, Harish Krishnaswamy wrote:
>
>> Looking at the TypeConverter, I am not sure how the converter
>> determines the type to convert to when the passed in value is always
>> a String. Seems like I am missing something here.
>
>
> There is a toType, which is a Class.
>
> The TypeConverter interface itself is a bit complicated. But
> extending DefaultTypeConverter, as
> <http://www.ognl.org/2.6.3/Documentation/html/typeConversion.html>
> recommends, and overriding the simpler convertValue method it exposes
> is the way to go. There is actually a test case in Tapestry for this
> that should illustrate the API a bit clearer (MockTypeConverter).
>
> Erik
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: has binding type conversion (toString) changed in beta-4?
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Feb 16, 2004, at 9:45 PM, Harish Krishnaswamy wrote:
> Looking at the TypeConverter, I am not sure how the converter
> determines the type to convert to when the passed in value is always a
> String. Seems like I am missing something here.
There is a toType, which is a Class.
The TypeConverter interface itself is a bit complicated. But extending
DefaultTypeConverter, as
<http://www.ognl.org/2.6.3/Documentation/html/typeConversion.html>
recommends, and overriding the simpler convertValue method it exposes
is the way to go. There is actually a test case in Tapestry for this
that should illustrate the API a bit clearer (MockTypeConverter).
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: has binding type conversion (toString) changed in beta-4?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Looking at the TypeConverter, I am not sure how the converter determines
the type to convert to when the passed in value is always a String.
Seems like I am missing something here.
-Harish
Harish Krishnaswamy wrote:
>
>
> Erik Hatcher wrote:
>
>> On Feb 16, 2004, at 9:52 AM, Harish Krishnaswamy wrote:
>>
>>>> No. I'd want it to set the value to the basic primitive default
>>>> value (zero for numerics, false for boolean). This is exactly what
>>>> Struts does. And don't take this to mean I want Tapestry to be
>>>> like Struts, just that I know what folks are coming from and what
>>>> they'll expect.
>>>>
>>> Are you saying if the user typed "xyz" where a number is expected,
>>> it would simply convert it to the primitive default? I don't think
>>> that's the correct solution.
>>
>>
>>
>> I'm simply making a couple of points:
>>
>> 1) this used to work as I described in b3! (how did it break? what
>> code changed to make this happen? and why?)
>
>
> This is certainly something to investigate. But I am certain it did
> not work way back when I had tried something like this. So it has to
> be a bug somewhere along the way.
>
>>
>> 2) Howard and I will be evangelizing Tapestry substantially around
>> the country this spring and beyond, so hopefully lots of Struts folks
>> will come try out Tapestry. His book will be a huge selling point
>> and will sway many folks to tune into tapestry-user and see what all
>> the hype is about. Struts does the conversions as I say, and it is a
>> good thing. To change the type of a field from a float to a double
>> only requires code change, not template change or from any other
>> basic type to another. Tapestry makes this harder than Struts
>> currently. Don't let that last sentence be said much longer! :)
>>
>>>> Just give me some control injection options, that is all I ask :))
>>>
>>>
>>>
>>> I am not against the use of TypeConverter, it can certainly be
>>> *another* option ;) I prefer the typed fields instead.
>>
>>
>>
>> With a TypeConverter in between, you essentially have typed fields
>> with no effort. So there! :)
>>
>> The type conversion can tie into validation too, such that if
>> desired, a type conversion failure is a validation exception and does
>> not set things to a default value. Flexibility is key here.
>
>
> That's true, in which case you will need the delegate anyway at least
> the way it is now. I can certainly see us needing a global
> delegate/validators for the application instead of having one per page
> and then you essentially have what you want with a more fine grained
> control over type conversion. The type converter on the other hand
> will be applied globally if I am not mistaken? Don't get me wrong, I
> still support the TypeConverter, only I like the validation framework
> better, although it could certainly use polish ;)
>
>>
>> Erik
>
>
> -Harish
>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: has binding type conversion (toString) changed in beta-4?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Erik Hatcher wrote:
> On Feb 16, 2004, at 9:52 AM, Harish Krishnaswamy wrote:
>
>>> No. I'd want it to set the value to the basic primitive default
>>> value (zero for numerics, false for boolean). This is exactly what
>>> Struts does. And don't take this to mean I want Tapestry to be like
>>> Struts, just that I know what folks are coming from and what they'll
>>> expect.
>>>
>> Are you saying if the user typed "xyz" where a number is expected, it
>> would simply convert it to the primitive default? I don't think
>> that's the correct solution.
>
>
> I'm simply making a couple of points:
>
> 1) this used to work as I described in b3! (how did it break? what
> code changed to make this happen? and why?)
This is certainly something to investigate. But I am certain it did not
work way back when I had tried something like this. So it has to be a
bug somewhere along the way.
>
> 2) Howard and I will be evangelizing Tapestry substantially around the
> country this spring and beyond, so hopefully lots of Struts folks will
> come try out Tapestry. His book will be a huge selling point and will
> sway many folks to tune into tapestry-user and see what all the hype
> is about. Struts does the conversions as I say, and it is a good
> thing. To change the type of a field from a float to a double only
> requires code change, not template change or from any other basic type
> to another. Tapestry makes this harder than Struts currently. Don't
> let that last sentence be said much longer! :)
>
>>> Just give me some control injection options, that is all I ask :))
>>
>>
>> I am not against the use of TypeConverter, it can certainly be
>> *another* option ;) I prefer the typed fields instead.
>
>
> With a TypeConverter in between, you essentially have typed fields
> with no effort. So there! :)
>
> The type conversion can tie into validation too, such that if desired,
> a type conversion failure is a validation exception and does not set
> things to a default value. Flexibility is key here.
That's true, in which case you will need the delegate anyway at least
the way it is now. I can certainly see us needing a global
delegate/validators for the application instead of having one per page
and then you essentially have what you want with a more fine grained
control over type conversion. The type converter on the other hand will
be applied globally if I am not mistaken? Don't get me wrong, I still
support the TypeConverter, only I like the validation framework better,
although it could certainly use polish ;)
>
> Erik
-Harish
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: has binding type conversion (toString) changed in beta-4?
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Feb 16, 2004, at 9:52 AM, Harish Krishnaswamy wrote:
>> No. I'd want it to set the value to the basic primitive default
>> value (zero for numerics, false for boolean). This is exactly what
>> Struts does. And don't take this to mean I want Tapestry to be like
>> Struts, just that I know what folks are coming from and what they'll
>> expect.
>>
> Are you saying if the user typed "xyz" where a number is expected, it
> would simply convert it to the primitive default? I don't think that's
> the correct solution.
I'm simply making a couple of points:
1) this used to work as I described in b3! (how did it break? what
code changed to make this happen? and why?)
2) Howard and I will be evangelizing Tapestry substantially around the
country this spring and beyond, so hopefully lots of Struts folks will
come try out Tapestry. His book will be a huge selling point and will
sway many folks to tune into tapestry-user and see what all the hype is
about. Struts does the conversions as I say, and it is a good thing.
To change the type of a field from a float to a double only requires
code change, not template change or from any other basic type to
another. Tapestry makes this harder than Struts currently. Don't let
that last sentence be said much longer! :)
>> Just give me some control injection options, that is all I ask :))
>
> I am not against the use of TypeConverter, it can certainly be
> *another* option ;) I prefer the typed fields instead.
With a TypeConverter in between, you essentially have typed fields with
no effort. So there! :)
The type conversion can tie into validation too, such that if desired,
a type conversion failure is a validation exception and does not set
things to a default value. Flexibility is key here.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: has binding type conversion (toString) changed in beta-4?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
Erik Hatcher wrote:
> On Feb 16, 2004, at 7:21 AM, Harish Krishnaswamy wrote:
>
>> I presume if coercion fails you would want to throw a message?
>
>
> No. I'd want it to set the value to the basic primitive default value
> (zero for numerics, false for boolean). This is exactly what Struts
> does. And don't take this to mean I want Tapestry to be like Struts,
> just that I know what folks are coming from and what they'll expect.
>
Are you saying if the user typed "xyz" where a number is expected, it
would simply convert it to the primitive default? I don't think that's
the correct solution.
>> For this reason I think using the validator is probably appropriate.
>> But I do agree that the plumbing is a little hideous. But there are
>> type specific components in contrib that you could use -
>> NumericField, DateField etc. Richard has been lobbying to move them
>> into the core and I kinda like them too. But you still can't do away
>> with the delegate which is trivial as compared to the validator
>> declarations, I think.
>
>
> It is not trivial compared to the XDoclet usage pattern myself and
> tons of others using Struts are using now. It's a single tag on a
> form bean setter to add a validation constraint, and just as easy to
> add a pointer to a custom error message resource for that one field,
> and control any of the validator variables such as a min/max length
> constraint.
>
> Part of Tapestry is about not letting type matter. OGNL expressions
> do coercion, and the TypeConverter facility is nice. If a TextField
> used an OGNL "set" for both directions all would be well and it could
> be left up to the developer to control how this coercion occurs (or
> does not occur if you want to thrown an exception) with the OGNL
> TypeConverter extension I added. Currently it is not using OGNL in
> this manner, which may have changed between b3 and b4.
>
> Just give me some control injection options, that is all I ask :))
I am not against the use of TypeConverter, it can certainly be *another*
option ;) I prefer the typed fields instead.
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: has binding type conversion (toString) changed in beta-4?
Posted by Larry Streepy <la...@staffmix.com>.
I've got to agree with Erik 100% on this topic. In all cases we should
strive for the "axiom of least surprise." In this context, that would mean
that a TextField can be handed any form of object and converts it to a
string for display. This is consistent with other frameworks (thus the
least surprise), and IMO, doesn't violate any hard rules in Tapestry.
On the validation side, I'll go back to my other argument which is to make
the base components more configurable so new users aren't immediately faced
with writing lots of java code, or working with multiple intertwined objects
to perform a simple task. In that vein, TextField should be extended to
support an attribute that controls the behavior on failure to convert the
supplied text back into the object form. Let the programmer decide if it
should be ignored (resulting in a default value, like null, 0, or false), or
have it throw an exception.
I'm a strong proponent of declarative programming. Frameworks often provide
significant leaps in programmer productivity because of declarative models.
I simply tell the system how I want it to behave, and avoid writing the
detail code to make that behavior manifest.
Unfortunately, Tapestry does not support inheritance of components, which
means that changing simple behavior in an existing component is difficult -
you have to create a completely new component. Given that limitation, I
argue strongly to have the "common" needs be supported within the basic
components and have them be configurable so as to deal with the common
variations on a theme.
When a programmer needs to go beyond that built-in support, they'll have to
learn more about the system. But, by that time they should be well down the
road to Tapestry enlightenment and the additional work will not feel as bad.
Ok, that's enough of a rant for this morning. :-)
Thanks.
Larry.
> -----Original Message-----
> From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> Sent: Monday, February 16, 2004 6:32 AM
> To: Tapestry users
> Subject: Re: has binding type conversion (toString) changed in beta-4?
>
> On Feb 16, 2004, at 7:21 AM, Harish Krishnaswamy wrote:
> > I presume if coercion fails you would want to throw a message?
>
> No. I'd want it to set the value to the basic primitive default value
> (zero for numerics, false for boolean). This is exactly what Struts
> does. And don't take this to mean I want Tapestry to be like Struts,
> just that I know what folks are coming from and what they'll expect.
>
> > For this reason I think using the validator is probably appropriate.
> > But I do agree that the plumbing is a little hideous. But there are
> > type specific components in contrib that you could use - NumericField,
> > DateField etc. Richard has been lobbying to move them into the core
> > and I kinda like them too. But you still can't do away with the
> > delegate which is trivial as compared to the validator declarations, I
> > think.
>
> It is not trivial compared to the XDoclet usage pattern myself and tons
> of others using Struts are using now. It's a single tag on a form bean
> setter to add a validation constraint, and just as easy to add a
> pointer to a custom error message resource for that one field, and
> control any of the validator variables such as a min/max length
> constraint.
>
> Part of Tapestry is about not letting type matter. OGNL expressions do
> coercion, and the TypeConverter facility is nice. If a TextField used
> an OGNL "set" for both directions all would be well and it could be
> left up to the developer to control how this coercion occurs (or does
> not occur if you want to thrown an exception) with the OGNL
> TypeConverter extension I added. Currently it is not using OGNL in
> this manner, which may have changed between b3 and b4.
>
> Just give me some control injection options, that is all I ask :))
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: has binding type conversion (toString) changed in beta-4?
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Feb 16, 2004, at 7:21 AM, Harish Krishnaswamy wrote:
> I presume if coercion fails you would want to throw a message?
No. I'd want it to set the value to the basic primitive default value
(zero for numerics, false for boolean). This is exactly what Struts
does. And don't take this to mean I want Tapestry to be like Struts,
just that I know what folks are coming from and what they'll expect.
> For this reason I think using the validator is probably appropriate.
> But I do agree that the plumbing is a little hideous. But there are
> type specific components in contrib that you could use - NumericField,
> DateField etc. Richard has been lobbying to move them into the core
> and I kinda like them too. But you still can't do away with the
> delegate which is trivial as compared to the validator declarations, I
> think.
It is not trivial compared to the XDoclet usage pattern myself and tons
of others using Struts are using now. It's a single tag on a form bean
setter to add a validation constraint, and just as easy to add a
pointer to a custom error message resource for that one field, and
control any of the validator variables such as a min/max length
constraint.
Part of Tapestry is about not letting type matter. OGNL expressions do
coercion, and the TypeConverter facility is nice. If a TextField used
an OGNL "set" for both directions all would be well and it could be
left up to the developer to control how this coercion occurs (or does
not occur if you want to thrown an exception) with the OGNL
TypeConverter extension I added. Currently it is not using OGNL in
this manner, which may have changed between b3 and b4.
Just give me some control injection options, that is all I ask :))
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: has binding type conversion (toString) changed in beta-4?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
I presume if coercion fails you would want to throw a message? For this
reason I think using the validator is probably appropriate. But I do
agree that the plumbing is a little hideous. But there are type specific
components in contrib that you could use - NumericField, DateField etc.
Richard has been lobbying to move them into the core and I kinda like
them too. But you still can't do away with the delegate which is trivial
as compared to the validator declarations, I think.
-Harish
Erik Hatcher wrote:
> On Feb 13, 2004, at 7:20 PM, Howard M. Lewis Ship wrote:
>
>> For a TextField's value parameter, there's no point in coercing an
>> Integer property to String
>
>
> I disagree strongly.
>
> The point of a framework is to make life easier for developers.
>
> Many developers eyeing Tapestry will be coming from Struts where this
> native type conversion is done from all the primitives and wrapper
> types. I don't view validation and conversion as the same process.
> Everything coming back in HTTP is a string. Checkbox works with a
> boolean. Connecting a TextField to an integer seems natural, and the
> effort to add in a ValidField makes Tapestry look much harder than
> Struts in this respect.
>
>> Use a ValidField with a NumberValidator.
>
>
> Speaking of validation though...
> The toughest thing (you even called it "plumbing" in your book) with
> Tapestry is validation. There are several intertwined pieces to
> validation (delegate, ValidField, FieldLabel, and more) that require
> much more work than seems pleasant. In our environment, we have thus
> far avoided delving too far into validation because I wanted to truly
> understand it before integrating it. It seems that to do it elegantly
> for us, we will need to add some higher level pieces (a resuable
> delegate and validators, perhaps custom wrapper components for form
> and fields?) such that they will not need to be specified everywhere
> and validation can be added with minimal work (here's a field, make it
> required and a date).
>
> Validation in Struts was certainly not pretty either with the form
> bean validate() method, then the Validator framework and it's hideous
> structure, but then I built the XDoclet validation.xml generator
> making my above example be this simple:
>
> /**
> * @struts.validator type="required"
> * @struts.validator type="date"
> */
> public void setField(String date) { .... }
>
> All of the plumbing was already taken care of with a <custom:label>
> tag and the ActionErrors infrastructure.
>
> Tapestry's infrastructure is far superior, but currently there is a
> bit more grunt work to tie things together
>
> Whatever changed to make the implicit conversion break between beta3
> and beta4 should be investigated. Perhaps whatever made it work
> before is not the right thing to do, but I strongly feel that a
> TextField should be connectable to primitives and their corresponding
> wrappers at least (except possibly Boolean/boolean, but then again
> Struts supports this too). If conversion fails, setting to null or
> zero seems fine. This is much more the expected result for many
> users, I suspect, than getting a typecast error.
>
> Feel like a plumber?
> Get out from under the sink
> One word: Tapestry
>
> http://www.blogscene.org/erik/Computers/Speaking/haiku.html
>
> Erik "not a plumber" Hatcher
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: has binding type conversion (toString) changed in beta-4?
Posted by SWC <ma...@crissman.net>.
I agree with Erik on this issue 100%. Especially during the
prototyping phase, being able to just use a text field and go with it
is such a time saver. Doing away with this ability seems like a big
step backwards, not from a technical standpoint, but from a usability /
convenience one.
On Feb 16, 2004, at 1:22 AM, Erik Hatcher wrote:
> I disagree strongly.
>
> The point of a framework is to make life easier for developers.
>
> Many developers eyeing Tapestry will be coming from Struts where this
> native type conversion is done from all the primitives and wrapper
> types. I don't view validation and conversion as the same process.
> Everything coming back in HTTP is a string. Checkbox works with a
> boolean. Connecting a TextField to an integer seems natural, and the
> effort to add in a ValidField makes Tapestry look much harder than
> Struts in this respect.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: has binding type conversion (toString) changed in beta-4?
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Feb 13, 2004, at 7:20 PM, Howard M. Lewis Ship wrote:
> For a TextField's value parameter, there's no point in coercing an
> Integer property to String
I disagree strongly.
The point of a framework is to make life easier for developers.
Many developers eyeing Tapestry will be coming from Struts where this
native type conversion is done from all the primitives and wrapper
types. I don't view validation and conversion as the same process.
Everything coming back in HTTP is a string. Checkbox works with a
boolean. Connecting a TextField to an integer seems natural, and the
effort to add in a ValidField makes Tapestry look much harder than
Struts in this respect.
> Use a ValidField with a NumberValidator.
Speaking of validation though...
The toughest thing (you even called it "plumbing" in your book) with
Tapestry is validation. There are several intertwined pieces to
validation (delegate, ValidField, FieldLabel, and more) that require
much more work than seems pleasant. In our environment, we have thus
far avoided delving too far into validation because I wanted to truly
understand it before integrating it. It seems that to do it elegantly
for us, we will need to add some higher level pieces (a resuable
delegate and validators, perhaps custom wrapper components for form and
fields?) such that they will not need to be specified everywhere and
validation can be added with minimal work (here's a field, make it
required and a date).
Validation in Struts was certainly not pretty either with the form bean
validate() method, then the Validator framework and it's hideous
structure, but then I built the XDoclet validation.xml generator making
my above example be this simple:
/**
* @struts.validator type="required"
* @struts.validator type="date"
*/
public void setField(String date) { .... }
All of the plumbing was already taken care of with a <custom:label> tag
and the ActionErrors infrastructure.
Tapestry's infrastructure is far superior, but currently there is a bit
more grunt work to tie things together
Whatever changed to make the implicit conversion break between beta3
and beta4 should be investigated. Perhaps whatever made it work before
is not the right thing to do, but I strongly feel that a TextField
should be connectable to primitives and their corresponding wrappers at
least (except possibly Boolean/boolean, but then again Struts supports
this too). If conversion fails, setting to null or zero seems fine.
This is much more the expected result for many users, I suspect, than
getting a typecast error.
Feel like a plumber?
Get out from under the sink
One word: Tapestry
http://www.blogscene.org/erik/Computers/Speaking/haiku.html
Erik "not a plumber" Hatcher
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: has binding type conversion (toString) changed in beta-4?
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
For a TextField's value parameter, there's no point in coercing an Integer property to String, since
when the form is submitted, it will definately fail trying to assign a String property to an
Integer.
Use a ValidField with a NumberValidator.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components
http://howardlewisship.com
> -----Original Message-----
> From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> Sent: Friday, February 13, 2004 7:11 PM
> To: Tapestry users
> Subject: Re: has binding type conversion (toString) changed in beta-4?
>
>
> On Feb 13, 2004, at 6:50 PM, Erik Hatcher wrote:
> > Also keep in mind the OGNL type converter is now a pluggable
> > extension. (ExpressionBinding for details)
>
> *ugh* - I just tried it with a simple TextField/Integer
> example and had
> the same problem even with the type converter. Looks like
> OGNL doesn't
> use the type converter on a "get" operation, which makes
> sense since it
> doesn't have a destination type. I'm sure a little bit of
> AbstractBinding or ExpressionBinding magic could get the type
> conversions going in the get operation as well somehow but for now it
> doesn't work.
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: has binding type conversion (toString) changed in beta-4?
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Feb 13, 2004, at 6:50 PM, Erik Hatcher wrote:
> Also keep in mind the OGNL type converter is now a pluggable
> extension. (ExpressionBinding for details)
*ugh* - I just tried it with a simple TextField/Integer example and had
the same problem even with the type converter. Looks like OGNL doesn't
use the type converter on a "get" operation, which makes sense since it
doesn't have a destination type. I'm sure a little bit of
AbstractBinding or ExpressionBinding magic could get the type
conversions going in the get operation as well somehow but for now it
doesn't work.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: has binding type conversion (toString) changed in beta-4?
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
Also keep in mind the OGNL type converter is now a pluggable extension.
(ExpressionBinding for details)
You could use it to convert back and forth, although I'm not sure how
this cooperates with TextField.
Erik
On Feb 13, 2004, at 5:33 PM, Galen Meurer wrote:
> Thanks for the incredibly quick response.
>
> I swear to you that it "worked" in beta-3, though clearly it is not the
> correct way to be putting Integers in forms.
>
> I'll switch to ValidField.
>
> Galen
>
> ----- Original Message -----
> From: "Harish Krishnaswamy" <hk...@comcast.net>
> To: "Tapestry users" <ta...@jakarta.apache.org>
> Sent: Friday, February 13, 2004 1:58 PM
> Subject: Re: has binding type conversion (toString) changed in beta-4?
>
>
>> The TextField component does no convertion at all ever, AFAIK. It is
>> always bound to a String property. If you want type conversion you
>> sould
>> be using the ValidField instead with the appropriate Validator
>> (NumberValidator in your case).
>>
>> -Harish
>>
>> Galen Meurer wrote:
>>
>>> I just upgraded our small, fledgling application to beta-4.
>>> Everything
> works
>>> great, except one thing:
>>>
>>> <input type="text" jwcid=order@TextField
>>> value="ognl:picklistValue.sequenceNumber"/>
>>>
>>> This used to display and now results in the following stack trace:
>>>
>>> ++
>>> org.apache.tapestry.BindingException
>>> Parameter value (1) is an instance of java.lang.Integer, which does
>>> not
>>> inherit from java.lang.String.
>>> binding: ExpressionBinding[PicklistEditor
>>> picklistValue.sequenceNumber]
>>> location: context:/PicklistEditor.html, line 84
>>> Stack Trace:
>>
>> org.apache.tapestry.binding.AbstractBinding.getObject(AbstractBinding.
>> java:
> 2
>>> 70)
>>> org.apache.tapestry.form.TextField.readValue(TextField.java:77)
>>
>> org.apache.tapestry.form.AbstractTextField.renderComponent(AbstractTex
>> tFiel
> d
>>> .java:124)
>>> [...]
>>> ++
>>>
>>> sequenceNumber is indeed an Integer, but it used to silently convert
>>> to a
>>> String and on update, back to an Integer in the fabulous magic
>>> conversion
>>> that is Tapestry. I've compared the source of AbstractBinding.java
>>> from
> v1.7
>>> (beta-3) and 1.9 (beta-4) and it hasn't changed WRT the
>>> implementation of
>>> getObject -- but this behavior certainly appears to have changed for
>>> some
>>> reason.
>>>
>>> As a minimal test case, I added a TextField with an Integer value to
>>> the
>>> border example and then upgraded it to beta-4 and it exhibits the
>>> same
>>> behavior.
>>>
>>> I'm not sure where to look. Does anybody have any idea that can help
>>> me
> out?
>>>
>>> Should this work and I'm doing it wrong or have I messed up the
>>> upgrade
> in
>>> some way?
>>>
>>> Should this work and it's a bug in beta-4?
>>>
>>> Is this an intentional change of behavior from beta-3? Have I abused
>>> the
>>> type conversion mechanism?
>>>
>>> Best,
>>> Galen
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail:
>>> tapestry-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: has binding type conversion (toString) changed in beta-4?
Posted by Galen Meurer <si...@galenmeurer.com>.
Thanks for the incredibly quick response.
I swear to you that it "worked" in beta-3, though clearly it is not the
correct way to be putting Integers in forms.
I'll switch to ValidField.
Galen
----- Original Message -----
From: "Harish Krishnaswamy" <hk...@comcast.net>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Friday, February 13, 2004 1:58 PM
Subject: Re: has binding type conversion (toString) changed in beta-4?
> The TextField component does no convertion at all ever, AFAIK. It is
> always bound to a String property. If you want type conversion you sould
> be using the ValidField instead with the appropriate Validator
> (NumberValidator in your case).
>
> -Harish
>
> Galen Meurer wrote:
>
> >I just upgraded our small, fledgling application to beta-4. Everything
works
> >great, except one thing:
> >
> ><input type="text" jwcid=order@TextField
> >value="ognl:picklistValue.sequenceNumber"/>
> >
> >This used to display and now results in the following stack trace:
> >
> >++
> >org.apache.tapestry.BindingException
> >Parameter value (1) is an instance of java.lang.Integer, which does not
> >inherit from java.lang.String.
> >binding: ExpressionBinding[PicklistEditor picklistValue.sequenceNumber]
> >location: context:/PicklistEditor.html, line 84
> >Stack Trace:
>
>org.apache.tapestry.binding.AbstractBinding.getObject(AbstractBinding.java:
2
> >70)
> >org.apache.tapestry.form.TextField.readValue(TextField.java:77)
>
>org.apache.tapestry.form.AbstractTextField.renderComponent(AbstractTextFiel
d
> >.java:124)
> >[...]
> >++
> >
> >sequenceNumber is indeed an Integer, but it used to silently convert to a
> >String and on update, back to an Integer in the fabulous magic conversion
> >that is Tapestry. I've compared the source of AbstractBinding.java from
v1.7
> >(beta-3) and 1.9 (beta-4) and it hasn't changed WRT the implementation of
> >getObject -- but this behavior certainly appears to have changed for some
> >reason.
> >
> >As a minimal test case, I added a TextField with an Integer value to the
> >border example and then upgraded it to beta-4 and it exhibits the same
> >behavior.
> >
> >I'm not sure where to look. Does anybody have any idea that can help me
out?
> >
> >Should this work and I'm doing it wrong or have I messed up the upgrade
in
> >some way?
> >
> >Should this work and it's a bug in beta-4?
> >
> >Is this an intentional change of behavior from beta-3? Have I abused the
> >type conversion mechanism?
> >
> >Best,
> >Galen
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: has binding type conversion (toString) changed in beta-4?
Posted by Harish Krishnaswamy <hk...@comcast.net>.
The TextField component does no convertion at all ever, AFAIK. It is
always bound to a String property. If you want type conversion you sould
be using the ValidField instead with the appropriate Validator
(NumberValidator in your case).
-Harish
Galen Meurer wrote:
>I just upgraded our small, fledgling application to beta-4. Everything works
>great, except one thing:
>
><input type="text" jwcid=order@TextField
>value="ognl:picklistValue.sequenceNumber"/>
>
>This used to display and now results in the following stack trace:
>
>++
>org.apache.tapestry.BindingException
>Parameter value (1) is an instance of java.lang.Integer, which does not
>inherit from java.lang.String.
>binding: ExpressionBinding[PicklistEditor picklistValue.sequenceNumber]
>location: context:/PicklistEditor.html, line 84
>Stack Trace:
>org.apache.tapestry.binding.AbstractBinding.getObject(AbstractBinding.java:2
>70)
>org.apache.tapestry.form.TextField.readValue(TextField.java:77)
>org.apache.tapestry.form.AbstractTextField.renderComponent(AbstractTextField
>.java:124)
>[...]
>++
>
>sequenceNumber is indeed an Integer, but it used to silently convert to a
>String and on update, back to an Integer in the fabulous magic conversion
>that is Tapestry. I've compared the source of AbstractBinding.java from v1.7
>(beta-3) and 1.9 (beta-4) and it hasn't changed WRT the implementation of
>getObject -- but this behavior certainly appears to have changed for some
>reason.
>
>As a minimal test case, I added a TextField with an Integer value to the
>border example and then upgraded it to beta-4 and it exhibits the same
>behavior.
>
>I'm not sure where to look. Does anybody have any idea that can help me out?
>
>Should this work and I'm doing it wrong or have I messed up the upgrade in
>some way?
>
>Should this work and it's a bug in beta-4?
>
>Is this an intentional change of behavior from beta-3? Have I abused the
>type conversion mechanism?
>
>Best,
>Galen
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org