Am Mi, 13.06.2007, 10:39, schrieb Al Sutton:
> On your first point; I'm not sure how you see url and set differing, from
> what I can see url is just a set that constructs the value in a specific
> way, so imho the two should be consistent, and so one of them needs to
> change.
>

I'd rather change bean and url then (if we would really decide to be in
need for this!), and not set tag, as we would get inconsistent with any ui
related html and struts2 tag having the id attribute being used the html
way! Simple rule on a html/jsp page should be: id of any element must be
unique to the page. After all we're talking about setting "named"
properties with set/url/bean, not "id"ed. On the other hand, any ui tag
used for reading a value set up by set-tag will reference it either by
it's value attribute (providing an ognl expression) or ... it's name
attribute:
<s:set name="foo" value="'bar'" />
<s:textfield name="foo"/>
will print out bar as content of the textfield.

Talking about confusion: Let's say we have changed the attribute usage to
id instead of name for the set tag. What would the user expect when seeing
the following code?:
<s:set id="foo" value="'bar'" />
<s:property id="foo" />
Probably the user would think he will get bar as an output, but he won't,
since the id attribute of property has the "html meaning".
In this example, he will just get the top of the stack, where the bar
value could in fact reside by incident.

> On your second point; if name is deprecated it will still be available, it
> just won't be the best practice. It could be deprecated in 2.x, and
> removed
> in 3.x or whatever the next major version is, that way all documnetation
> referring to S2 is still valid, and if S3 ever happens it can remove the
> backwards compatibility baggage in favour of a consistant approach.
>

Sure, that's how deprecation works. But we have enough examples on how bad
it is to get even our own wiki docs in shape after doing similar changes.
For such a heavy used tag as set (in users source code, as well as
documentation resources), we will most probably have lots of messed up
examples, code fragment etc in future. As an example: I bet you will still
find a lot of code examples in s2-docs using deprecated tag syntax,
although it is deprecated for at least two years now (in WW2). And this
only references the resources we can manage to get our hands on ...

Regards,
Rene

> -----Original Message-----
> From: Rene Gielen [mailto:[EMAIL PROTECTED]
> Sent: 13 June 2007 07:58
> To: Struts Developers List
> Subject: Re: name inconsistency
>
> -1 for that from my point of view:
>
> - id in html page context refers the unique identifier on a page, whereas
> name lets you bind to a named target, not necessarily having to be unique
> on
> the page. set clearly references a name from that understanding (set the
> named property). I would find id quite misleading.
> - TONS of documentation resources, including third party, reference the
> set
> tag (as a WW2 / S2 / even WW1 tag). It is one of the most used tags.
> Once we deprecate this, this docs will have to be changed or will confuse
> users.
>
> Regards,
> Rene
>
> Musachy Barroso schrieb:
>> This is a really minor thing, but it gets me all the time, the set tag
>> uses the "name" attribute for the variable name, while the url, and
>> bean tags use "id", anybody against deprecating the "name" attribute
>> in set and using "id"
>> instead?
>>
>> regards
>> musachy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
> commands, e-mail: [EMAIL PROTECTED]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Rene Gielen  | http://it-neering.net/
Aachen       | PGP-ID: BECB785A
Germany      | gielen at it-neering.net


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

Reply via email to