> -----Original Message-----
> From: Tom Morris [mailto:[EMAIL PROTECTED]] 
> Sent: maandag 19 november 2001 18:35
> To: '[EMAIL PROTECTED]'
> Subject: HTML Link Tags Seem Clumsy
> 
> 
> Hello there,
> 
> I'm starting to use Struts and was wondering If I'm correct 
> in thinking
> that it's a little inflexible when it comes to choosing datatypes for
> form-bean properties.
> 
> Displaying a query-parameter based HREF link is annoying 
> since, it only
> accepts String types.
> It would be nice to model my beans in their true form, and 
> have Struts apply
> 'toString()'
> on all non-String data. For example I can't have Integer form-bean
> properties participate
> in a 'html:link' tag.
> 
> Am I missing some fundamental Struts design decision?

I think the main reason for only allowing Strings (and I thought
booleans also), are the setter methods: if Struts receives some String
(from the http response) and wants to set the property of the according
server-side bean, it has no way of knowing (a) which type is required
for the setter, and moreover (b) how to do the conversion. And allowing
for getter methods to return different types than the setter methods
require, seems to be incompliant with the javabeans spec (although I'm
not sure about that)

> Building 'html:link' tags seems particularly awkward when 
> parameters are
> required.
> The Map approach seems ugly since it requires an extra method 
> on every bean
> which
> goes through a population process on some object that 
> implements 'Map'.
> Why was the tag-lib attribute interface not extended in some way?

I don't know 'the Map approach'... You're always welcome to enlighten me
with some url :-) But I agree that html:link could have nicer design for
GET parameters (nested tags would be nice... is this possible with
taglibs? Does anybody know the right syntax for the tld for this?)

> I was going to post this to the dev-list, but felt that I 
> must have the
> wrong end-of-the stick.
> 
> Many thanks for your help (and understanding...)

Hope you get something out of this,
tomK

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to