You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Erik Hatcher <er...@ehatchersolutions.com> on 2004/02/15 20:44:45 UTC
Implicit type conversion (was Re: Form Submit Question)
On Feb 15, 2004, at 1:16 PM, F. Da Costa wrote:
> This is how i did it (and it worked perfectly fine before the handling
> of TextField changed on me with the validators and all :-(( ).
There have been several reports of an implicit type conversion changing
behavior from beta 3 to beta 4. I did a diff of the two revisions and
have not found the cause of this yet. Are we chalking this up with the
new behavior being as desired? Was this break intentional? And what
code changed that made this occur (so I can learn!)?
I'm a big fan of some framework provided implicit type conversion.
Putting a text field on a screen to accept an Integer shouldn't require
a ValidField, in my opinion. Sure, some handling of what happens if a
non-integer is keyed in needs to happen. With OGNL this can be
customized with the type converter facility at least, on setting. But
the getting is a different story, but in this case TextField could
simply do the .toString to display and let conversion be dealt with
upon form submission with OGNL.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Implicit type conversion (was Re: Form Submit Question)
Posted by "F. Da Costa" <da...@xs4all.nl>.
Erik Hatcher wrote:
> On Feb 15, 2004, at 1:16 PM, F. Da Costa wrote:
>
>> This is how i did it (and it worked perfectly fine before the handling
>> of TextField changed on me with the validators and all :-(( ).
>
>
> There have been several reports of an implicit type conversion changing
> behavior from beta 3 to beta 4. I did a diff of the two revisions and
> have not found the cause of this yet. Are we chalking this up with the
> new behavior being as desired? Was this break intentional? And what
> code changed that made this occur (so I can learn!)?
>
> I'm a big fan of some framework provided implicit type conversion.
Well, that makes, at least, two of us.
> Putting a text field on a screen to accept an Integer shouldn't require
> a ValidField, in my opinion.Sure, some handling of what happens if a
> non-integer is keyed in needs to happen. With OGNL this can be
If you thinnk from the screen than indeed there is only String even if one
were to use complex numbers (as in math) it would still be a string.
> customized with the type converter facility at least, on setting. But
It certainly is one way.
> the getting is a different story, but in this case TextField could
> simply do the .toString to display and let conversion be dealt with upon
> form submission with OGNL.
This is exactly what i basically did creating a 'dummy' Validator that just
sends out the toString().
The hit (from a perf pespective) is probably not too big but why introduce
more code than is really necessary?
Now that the new structure is in place could it not be an idea to have a
default setting that behaves as b3 did (with implicit typeconversion/ just
do the toString via a DefaultValidator). This way one might argue that a
very good point has been created to insert Tapestry-induced typechecking if
this is what the developer wants. Obviously it also still carries the
framework type conversion.
Basically this is what i'm doing now (did cost me a couple of days though)
and i'm not even sure that i've resolved the whole thing yet, but that
might have something to do with the fact that i'm still a 6m+ student ;-)
of the Tapestry mysteries.
Just my 2c. It does not take anything away from Tapestry's power. On the
contrary one could possibly use it to increase it. What other framework
allows you to switch implicit type-checking on or off in 2 secs flat?
Fermin DCG
>
> 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: Implicit type conversion (was Re: Form Submit Question)
Posted by Galen Meurer <si...@galenmeurer.com>.
I don't know if this is helpful or not, but I did a minimal test case using
the border example to verify that it really was converting, both for the get
and the for update.
+++
Border.html
<span jwcid="@Form">
<span jwcid="@TextField" value="ognl:foo"/>
<input type="submit" value="foo"/>
</span>
+++
Border.java
Integer foo = new Integer(1);
[...]
public Integer getFoo() {
System.out.println("returning foo " + foo);
return foo;
}
public void setFoo(Integer foo) {
System.out.println("setting foo to " + foo + "; foo's class is " +
foo.getClass().getName());
this.foo = foo;
}
+++
server.log
11:40:53,234 INFO [STDOUT] returning foo1
[snip...]
11:40:57,062 INFO [STDOUT] setting foo to 2; foo's class is
java.lang.Integer
11:40:57,062 INFO [STDOUT] returning foo2
I can't say if the behavior change was or is desired, but I can say that it
really does seem to have changed from b3 (converts) to b4 (fails).
In our actual application, I had only used a TextField in the first place as
a quick-and-dirty mockup for this property and had the intention of changing
it (quickly). I think that counting on the user to type in a valid Integer
into a text box without using a ValidField is a dangerous proposition and
shouldn't be done for any real application. On the other hand, the implicit
conversion made it really easy to do a quick mock-up.
Galen
----- Original Message -----
From: "Erik Hatcher" <er...@ehatchersolutions.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Sunday, February 15, 2004 11:44 AM
Subject: Implicit type conversion (was Re: Form Submit Question)
> On Feb 15, 2004, at 1:16 PM, F. Da Costa wrote:
> > This is how i did it (and it worked perfectly fine before the handling
> > of TextField changed on me with the validators and all :-(( ).
>
> There have been several reports of an implicit type conversion changing
> behavior from beta 3 to beta 4. I did a diff of the two revisions and
> have not found the cause of this yet. Are we chalking this up with the
> new behavior being as desired? Was this break intentional? And what
> code changed that made this occur (so I can learn!)?
>
> I'm a big fan of some framework provided implicit type conversion.
> Putting a text field on a screen to accept an Integer shouldn't require
> a ValidField, in my opinion. Sure, some handling of what happens if a
> non-integer is keyed in needs to happen. With OGNL this can be
> customized with the type converter facility at least, on setting. But
> the getting is a different story, but in this case TextField could
> simply do the .toString to display and let conversion be dealt with
> upon form submission with OGNL.
>
> 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