You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Arron Bates <ar...@keyboardmonkey.com> on 2001/12/10 08:27:42 UTC
Freetext attribute for all tags...
Idea...
There was just that too and fro in "additional properties needed on
html:image..." bug in that there was the argument over what to support
and what not to support... if there was a standard property (ie:
"freetext", "freeform", "uglytext" or something) where developers could
add a string to be included in the tag as they provide it (with an extra
space at the front and back to avoid collisions).
If a developer wants to include something to be rendered for one reason
or another, Struts not supporting it or otherwise, they can without
issue and code hacks that will have to be re-done the next version of
the tag, tld etc...
It means that the html:image and html:text can do whatever and the
developer can still get the width, height and wrap stuff that he needs
for nice formatting.
Probably not *proper* for all the die -hards out there... but certainly
useable, especially for html creatives that seek that extra level of
control that Struts hasn't been around yet, doesn't want to or whatever.
Just an idea.
Arron.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Freetext attribute for all tags...
Posted by Oleg V Alexeev <oa...@apache.org>.
Hello Ted,
[+1] 'custom'
Monday, December 10, 2001, 2:02:01 PM, you wrote:
TH> Is freetext all right with everyone, or should we use something like
TH> literal
TH> custom
TH> or
TH> verbatim
TH> It's just that I feel we have not paid close enough attention to the
TH> naming of things in the past, and we might want "measure twice" before
TH> we document this.
TH> -- Ted Husted, Husted dot Com, Fairport NY USA.
TH> -- Custom Software ~ Technical Services.
TH> -- Tel +1 716 737-3463
TH> -- http://www.husted.com/struts/
TH> --
TH> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
TH> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Best regards,
Oleg mailto:oalexeev@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Freetext attribute for all tags...
Posted by Arron Bates <ar...@keyboardmonkey.com>.
I really think questions of "compliance" and "properness" are out of
context in all truth. You get Html outside that of the struts tags...
let's say... 96% of the markup are you're in the most free text you've
ever seen in your life. You aint seen the fun of free markup until
you've left off a double quote in a table tag ;)
Look... if someone wants to get that wrap tag they'll end up managing it
on their own....
<textarea wrap="soft"><bean:write name="mybean" property="myProperty"
/></textarea>
...and drop Struts all together.
Hell, I did just this the other day. :)
Peoples, I'm sure we can all agree there's a lot more fun ways to screw
your code than some freetext in your tags.
The technology either helps you, and lets you get where you need to go
(and for some people that's a wrap attribute) or it stands in your way
and you have to get around it. People who create non-standard Html would
have done so in other parts of their markup, and who is Struts to tell
them "you aint going to make sloppy markup with our stuff".
Arron.
Ted Husted wrote:
>Can we let it ride for a week, to see what else comes up?
>
>I appreciate input from the developers, but we might want to also see
>what the other committers have to say.
>
>I also just thought of another one: "output" - since that is what we
>are really doing, outputting something into the body of tag.
>
>I do agree with Craig, that compliance has to be the "Prime Directive".
>
>If that sometimes means making things more difficult for people who
>choose to use Struts, because other products choose to be non-compliant,
>then so be it.
>
>I also agree that the framework should encourage proper use, and I do
>support a number of other design choices we've made in the place, which
>are not always popular with developers.
>
>Like Craig (I imagine), I would instantly veto something like a wrap tag
>for textarea being part of a tag, since that is a vendor-supplied
>extension, and not part of the W3C specification.
>
>This has always seemed like a likely compromise to me, and I've
>mentioned doing it several times myself. Though, the argument that there
>should be no non-standard attributes, carries some weight with me, since
>that is why we have this problem in the first place. People ran around
>doing whatever they pleased, standards be dammed.
>
>The other question I would ask, is how does this fit in with JSPTL? I
>don't think any of want to continue supporting tags that overlap with
>those. If we allow a literal attribute in all of our tags now, is that
>going trip people up later when we migrate. Might the Jakarta Input
>taglib's people have any thoughts on this? Eventually, we might want to
>hook up, and fill in the JSPTL gaps with a single set of Jakarta
>extensions.
>
>But now that we've let the genie out of the bottle, lets hang back and
>see what other people have to say.
>
>-Ted.
>
>
>
>Oleg V Alexeev wrote:
>
>>Hello Ted,
>>
>>So, votes for naming of free style attribute for html tags -
>>
>> literal - 2
>> freetext - 1.5 (already extst)
>> custom - 1
>>
>>Any other votes or variants? If nothing then it will became 'literal'.
>>
>>Monday, December 10, 2001, 2:02:01 PM, you wrote:
>>
>>TH> Is freetext all right with everyone, or should we use something like
>>
>>TH> literal
>>
>>TH> custom
>>
>>TH> or
>>
>>TH> verbatim
>>
>>TH> It's just that I feel we have not paid close enough attention to the
>>TH> naming of things in the past, and we might want "measure twice" before
>>TH> we document this.
>>
>>TH> -- Ted Husted, Husted dot Com, Fairport NY USA.
>>TH> -- Custom Software ~ Technical Services.
>>TH> -- Tel +1 716 737-3463
>>TH> -- http://www.husted.com/struts/
>>
>>TH> --
>>TH> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>TH> For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>>--
>>Best regards,
>> Oleg mailto:oalexeev@apache.org
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>
>-- Ted Husted, Husted dot Com, Fairport NY USA.
>-- Custom Software ~ Technical Services.
>-- Tel +1 716 737-3463
>-- http://www.husted.com/struts/
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Freetext attribute for all tags...
Posted by Ted Husted <hu...@apache.org>.
I'm sure there would be a way to rollback the CVS; Craig or Martin may
know more about that.
But, since there haven't been any other changes here, the simplest
thing, as you said, might be to retrieve the prior versions from a
nightly build, and paste those over the current version, and commit them
back.
Oleg V Alexeev wrote:
>
> Hello Ted,
>
> Ok. How can I revert changes? Is there are any standart way to do so
> with CVS? If no then I'l retrieve previous file versions, resave it
> and commit to CVS. Is it right?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Freetext attribute for all tags...
Posted by Oleg V Alexeev <oa...@apache.org>.
Hello Ted,
Ok. How can I revert changes? Is there are any standart way to do so
with CVS? If no then I'l retrieve previous file versions, resave it
and commit to CVS. Is it right?
Tuesday, December 11, 2001, 2:46:16 PM, you wrote:
TH> A product change, like adding the freetext attribute, is subject to lazy
TH> consensus. You have the right to make the change, and any other
TH> committer has the right to veto it.
TH> http://jakarta.apache.org/site/decisions.html
TH> People often announce a short-term plans, not so much because we have
TH> to, but because we are fishing for vetos.
TH> The committers own the codebase jointly and severally. If any of us do
TH> not want to support non-standard attributes, then we cannot support
TH> non-standard attributes.
TH> This is how Jakarta keeps its product standards high. There are no
TH> compromises. We must all agree, or at least not disagree, or it doesn't
TH> happen.
TH> This way, one person cannot come along, add some difficult features and
TH> then walk away, leaving the rest of us holding the bag. We all have the
TH> opportunity to veto a change. If we don't exercize our veto, then we are
TH> agreeing to support that change in the future. This helps keep the
TH> voting lags to a minimum. You don't have to call for a vote, but
TH> everything we do is subject to a vote, and the approval of every other
TH> committer.
TH> Martin's veto includes a number of reasonable justifications; it is
TH> valid, and so the changes should be rolled back.
TH> At least we have hashed this out, and can refer to this thread in the
TH> future, or bring it up in the FAQ (along with why ActionForms are not a
TH> *@#$!&% interface ;-)
TH> -- Ted Husted, Husted dot Com, Fairport NY USA.
TH> -- Custom Software ~ Technical Services.
TH> -- Tel +1 716 737-3463
TH> -- http://www.husted.com/struts/
TH> Oleg V Alexeev wrote:
>>
>> Hello Ted,
>>
>> It is interesting situation now... 8)) I think it was in some letters
>> before - a number of words about 'custom' or 'literal' attribute. But
>> only after commit we have a some kind of discussion in list... 8)
>> Yes, of course, may be my activity is wrong - I think that 'right'
>> solution with [VOTE] messages don't affect developers so actively. Now
>> anybody can check it at his own environment and VOTE after this... No
>> problem if such idea is wrong - I can revert all changes
>> and make html tags 'clear' again. 8)
>>
>> It is eternal problem - to balance between standarts and solution
>> useful for programmers...
>>
>> Monday, December 10, 2001, 9:28:17 PM, you wrote:
>>
>> TH> Can we let it ride for a week, to see what else comes up?
>>
>> TH> I appreciate input from the developers, but we might want to also see
>> TH> what the other committers have to say.
>>
>> TH> I also just thought of another one: "output" - since that is what we
>> TH> are really doing, outputting something into the body of tag.
>>
>> TH> I do agree with Craig, that compliance has to be the "Prime Directive".
>>
>> TH> If that sometimes means making things more difficult for people who
>> TH> choose to use Struts, because other products choose to be non-compliant,
>> TH> then so be it.
>>
>> TH> I also agree that the framework should encourage proper use, and I do
>> TH> support a number of other design choices we've made in the place, which
>> TH> are not always popular with developers.
>>
>> TH> Like Craig (I imagine), I would instantly veto something like a wrap tag
>> TH> for textarea being part of a tag, since that is a vendor-supplied
>> TH> extension, and not part of the W3C specification.
>>
>> TH> This has always seemed like a likely compromise to me, and I've
>> TH> mentioned doing it several times myself. Though, the argument that there
>> TH> should be no non-standard attributes, carries some weight with me, since
>> TH> that is why we have this problem in the first place. People ran around
>> TH> doing whatever they pleased, standards be dammed.
>>
>> TH> The other question I would ask, is how does this fit in with JSPTL? I
>> TH> don't think any of want to continue supporting tags that overlap with
>> TH> those. If we allow a literal attribute in all of our tags now, is that
>> TH> going trip people up later when we migrate. Might the Jakarta Input
>> TH> taglib's people have any thoughts on this? Eventually, we might want to
>> TH> hook up, and fill in the JSPTL gaps with a single set of Jakarta
>> TH> extensions.
>>
>> TH> But now that we've let the genie out of the bottle, lets hang back and
>> TH> see what other people have to say.
>>
>> TH> -Ted.
>>
>> --
>> Best regards,
>> Oleg mailto:oalexeev@apache.org
>>
>> --
>> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>> For additional commands, e-mail: <ma...@jakarta.apache.org>
TH> --
TH> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
TH> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Best regards,
Oleg mailto:oalexeev@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Freetext attribute for all tags...
Posted by Ted Husted <hu...@apache.org>.
A product change, like adding the freetext attribute, is subject to lazy
consensus. You have the right to make the change, and any other
committer has the right to veto it.
http://jakarta.apache.org/site/decisions.html
People often announce a short-term plans, not so much because we have
to, but because we are fishing for vetos.
The committers own the codebase jointly and severally. If any of us do
not want to support non-standard attributes, then we cannot support
non-standard attributes.
This is how Jakarta keeps its product standards high. There are no
compromises. We must all agree, or at least not disagree, or it doesn't
happen.
This way, one person cannot come along, add some difficult features and
then walk away, leaving the rest of us holding the bag. We all have the
opportunity to veto a change. If we don't exercize our veto, then we are
agreeing to support that change in the future. This helps keep the
voting lags to a minimum. You don't have to call for a vote, but
everything we do is subject to a vote, and the approval of every other
committer.
Martin's veto includes a number of reasonable justifications; it is
valid, and so the changes should be rolled back.
At least we have hashed this out, and can refer to this thread in the
future, or bring it up in the FAQ (along with why ActionForms are not a
*@#$!&% interface ;-)
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
Oleg V Alexeev wrote:
>
> Hello Ted,
>
> It is interesting situation now... 8)) I think it was in some letters
> before - a number of words about 'custom' or 'literal' attribute. But
> only after commit we have a some kind of discussion in list... 8)
> Yes, of course, may be my activity is wrong - I think that 'right'
> solution with [VOTE] messages don't affect developers so actively. Now
> anybody can check it at his own environment and VOTE after this... No
> problem if such idea is wrong - I can revert all changes
> and make html tags 'clear' again. 8)
>
> It is eternal problem - to balance between standarts and solution
> useful for programmers...
>
> Monday, December 10, 2001, 9:28:17 PM, you wrote:
>
> TH> Can we let it ride for a week, to see what else comes up?
>
> TH> I appreciate input from the developers, but we might want to also see
> TH> what the other committers have to say.
>
> TH> I also just thought of another one: "output" - since that is what we
> TH> are really doing, outputting something into the body of tag.
>
> TH> I do agree with Craig, that compliance has to be the "Prime Directive".
>
> TH> If that sometimes means making things more difficult for people who
> TH> choose to use Struts, because other products choose to be non-compliant,
> TH> then so be it.
>
> TH> I also agree that the framework should encourage proper use, and I do
> TH> support a number of other design choices we've made in the place, which
> TH> are not always popular with developers.
>
> TH> Like Craig (I imagine), I would instantly veto something like a wrap tag
> TH> for textarea being part of a tag, since that is a vendor-supplied
> TH> extension, and not part of the W3C specification.
>
> TH> This has always seemed like a likely compromise to me, and I've
> TH> mentioned doing it several times myself. Though, the argument that there
> TH> should be no non-standard attributes, carries some weight with me, since
> TH> that is why we have this problem in the first place. People ran around
> TH> doing whatever they pleased, standards be dammed.
>
> TH> The other question I would ask, is how does this fit in with JSPTL? I
> TH> don't think any of want to continue supporting tags that overlap with
> TH> those. If we allow a literal attribute in all of our tags now, is that
> TH> going trip people up later when we migrate. Might the Jakarta Input
> TH> taglib's people have any thoughts on this? Eventually, we might want to
> TH> hook up, and fill in the JSPTL gaps with a single set of Jakarta
> TH> extensions.
>
> TH> But now that we've let the genie out of the bottle, lets hang back and
> TH> see what other people have to say.
>
> TH> -Ted.
>
> --
> Best regards,
> Oleg mailto:oalexeev@apache.org
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Freetext attribute for all tags...
Posted by Oleg V Alexeev <oa...@apache.org>.
Hello Ted,
It is interesting situation now... 8)) I think it was in some letters
before - a number of words about 'custom' or 'literal' attribute. But
only after commit we have a some kind of discussion in list... 8)
Yes, of course, may be my activity is wrong - I think that 'right'
solution with [VOTE] messages don't affect developers so actively. Now
anybody can check it at his own environment and VOTE after this... No
problem if such idea is wrong - I can revert all changes
and make html tags 'clear' again. 8)
It is eternal problem - to balance between standarts and solution
useful for programmers...
Monday, December 10, 2001, 9:28:17 PM, you wrote:
TH> Can we let it ride for a week, to see what else comes up?
TH> I appreciate input from the developers, but we might want to also see
TH> what the other committers have to say.
TH> I also just thought of another one: "output" - since that is what we
TH> are really doing, outputting something into the body of tag.
TH> I do agree with Craig, that compliance has to be the "Prime Directive".
TH> If that sometimes means making things more difficult for people who
TH> choose to use Struts, because other products choose to be non-compliant,
TH> then so be it.
TH> I also agree that the framework should encourage proper use, and I do
TH> support a number of other design choices we've made in the place, which
TH> are not always popular with developers.
TH> Like Craig (I imagine), I would instantly veto something like a wrap tag
TH> for textarea being part of a tag, since that is a vendor-supplied
TH> extension, and not part of the W3C specification.
TH> This has always seemed like a likely compromise to me, and I've
TH> mentioned doing it several times myself. Though, the argument that there
TH> should be no non-standard attributes, carries some weight with me, since
TH> that is why we have this problem in the first place. People ran around
TH> doing whatever they pleased, standards be dammed.
TH> The other question I would ask, is how does this fit in with JSPTL? I
TH> don't think any of want to continue supporting tags that overlap with
TH> those. If we allow a literal attribute in all of our tags now, is that
TH> going trip people up later when we migrate. Might the Jakarta Input
TH> taglib's people have any thoughts on this? Eventually, we might want to
TH> hook up, and fill in the JSPTL gaps with a single set of Jakarta
TH> extensions.
TH> But now that we've let the genie out of the bottle, lets hang back and
TH> see what other people have to say.
TH> -Ted.
--
Best regards,
Oleg mailto:oalexeev@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Freetext attribute for all tags...
Posted by Ted Husted <hu...@apache.org>.
Can we let it ride for a week, to see what else comes up?
I appreciate input from the developers, but we might want to also see
what the other committers have to say.
I also just thought of another one: "output" - since that is what we
are really doing, outputting something into the body of tag.
I do agree with Craig, that compliance has to be the "Prime Directive".
If that sometimes means making things more difficult for people who
choose to use Struts, because other products choose to be non-compliant,
then so be it.
I also agree that the framework should encourage proper use, and I do
support a number of other design choices we've made in the place, which
are not always popular with developers.
Like Craig (I imagine), I would instantly veto something like a wrap tag
for textarea being part of a tag, since that is a vendor-supplied
extension, and not part of the W3C specification.
This has always seemed like a likely compromise to me, and I've
mentioned doing it several times myself. Though, the argument that there
should be no non-standard attributes, carries some weight with me, since
that is why we have this problem in the first place. People ran around
doing whatever they pleased, standards be dammed.
The other question I would ask, is how does this fit in with JSPTL? I
don't think any of want to continue supporting tags that overlap with
those. If we allow a literal attribute in all of our tags now, is that
going trip people up later when we migrate. Might the Jakarta Input
taglib's people have any thoughts on this? Eventually, we might want to
hook up, and fill in the JSPTL gaps with a single set of Jakarta
extensions.
But now that we've let the genie out of the bottle, lets hang back and
see what other people have to say.
-Ted.
Oleg V Alexeev wrote:
>
> Hello Ted,
>
> So, votes for naming of free style attribute for html tags -
>
> literal - 2
> freetext - 1.5 (already extst)
> custom - 1
>
> Any other votes or variants? If nothing then it will became 'literal'.
>
> Monday, December 10, 2001, 2:02:01 PM, you wrote:
>
> TH> Is freetext all right with everyone, or should we use something like
>
> TH> literal
>
> TH> custom
>
> TH> or
>
> TH> verbatim
>
> TH> It's just that I feel we have not paid close enough attention to the
> TH> naming of things in the past, and we might want "measure twice" before
> TH> we document this.
>
> TH> -- Ted Husted, Husted dot Com, Fairport NY USA.
> TH> -- Custom Software ~ Technical Services.
> TH> -- Tel +1 716 737-3463
> TH> -- http://www.husted.com/struts/
>
> TH> --
> TH> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> TH> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
> --
> Best regards,
> Oleg mailto:oalexeev@apache.org
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Re[2]: Freetext attribute for all tags...
Posted by David Winterfeldt <dw...@yahoo.com>.
I like literal out of the three listed. A static or
staticText field would be the only other ideas I have
for naming.
David
--- Oleg V Alexeev <oa...@apache.org> wrote:
> Hello Ted,
>
> So, votes for naming of free style attribute for
> html tags -
>
> literal - 2
> freetext - 1.5 (already extst)
> custom - 1
>
> Any other votes or variants? If nothing then it will
> became 'literal'.
>
> Monday, December 10, 2001, 2:02:01 PM, you wrote:
>
> TH> Is freetext all right with everyone, or should
> we use something like
>
> TH> literal
>
> TH> custom
>
> TH> or
>
> TH> verbatim
>
> TH> It's just that I feel we have not paid close
> enough attention to the
> TH> naming of things in the past, and we might want
> "measure twice" before
> TH> we document this.
>
>
> TH> -- Ted Husted, Husted dot Com, Fairport NY USA.
> TH> -- Custom Software ~ Technical Services.
> TH> -- Tel +1 716 737-3463
> TH> -- http://www.husted.com/struts/
>
> TH> --
> TH> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> TH> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
> --
> Best regards,
> Oleg
> mailto:oalexeev@apache.org
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Freetext attribute for all tags...
Posted by Oleg V Alexeev <oa...@apache.org>.
Hello Ted,
So, votes for naming of free style attribute for html tags -
literal - 2
freetext - 1.5 (already extst)
custom - 1
Any other votes or variants? If nothing then it will became 'literal'.
Monday, December 10, 2001, 2:02:01 PM, you wrote:
TH> Is freetext all right with everyone, or should we use something like
TH> literal
TH> custom
TH> or
TH> verbatim
TH> It's just that I feel we have not paid close enough attention to the
TH> naming of things in the past, and we might want "measure twice" before
TH> we document this.
TH> -- Ted Husted, Husted dot Com, Fairport NY USA.
TH> -- Custom Software ~ Technical Services.
TH> -- Tel +1 716 737-3463
TH> -- http://www.husted.com/struts/
TH> --
TH> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
TH> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Best regards,
Oleg mailto:oalexeev@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Freetext attribute for all tags...
Posted by Arron <ar...@keyboardmonkey.com>.
Also what has to be considered is not just the immediate name, but what
it takes from the pool of names that can be better used in the future,
and its clarity of what it does along side future names & functionality.
I feel that verbatim and literal have more of a place possibly defining
rules someplace else, and in the futre will become esoteric and
developers will have to hunt down docco for their meaning more often.
freetext - For the reason above & the same reason that Tom said not to.
It says "do what you want"... and that add's its own nature of "there is
power here, but don't be stupid" and still has the open & texty feel of it.
custom - A close second. Almost as cool as freetext
verbatim & literal - for my money they just state more as to how
something is handled and not describing what it is that it provides.
All attributes of a tag are taken as "literal". Just a little too ambiguous.
freetext is for me.
Most important is that when one is picked... one is picked.
Arron.
Will Jaynes wrote:
>[+1] literal
>
>----- Original Message -----
>From: "Ted Husted" <hu...@apache.org>
>To: "Struts Developers List" <st...@jakarta.apache.org>
>Sent: Monday, December 10, 2001 6:02 AM
>Subject: Re: Freetext attribute for all tags...
>
>
>>Is freetext all right with everyone, or should we use something like
>>
>>literal
>>
>>custom
>>
>>or
>>
>>verbatim
>>
>>It's just that I feel we have not paid close enough attention to the
>>naming of things in the past, and we might want "measure twice" before
>>we document this.
>>
>>
>>-- Ted Husted, Husted dot Com, Fairport NY USA.
>>-- Custom Software ~ Technical Services.
>>-- Tel +1 716 737-3463
>>-- http://www.husted.com/struts/
>>
>>--
>>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>>For additional commands, e-mail: <ma...@jakarta.apache.org>
>>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Freetext attribute for all tags...
Posted by Will Jaynes <wj...@mediaone.net>.
[+1] literal
----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Monday, December 10, 2001 6:02 AM
Subject: Re: Freetext attribute for all tags...
> Is freetext all right with everyone, or should we use something like
>
> literal
>
> custom
>
> or
>
> verbatim
>
> It's just that I feel we have not paid close enough attention to the
> naming of things in the past, and we might want "measure twice" before
> we document this.
>
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel +1 716 737-3463
> -- http://www.husted.com/struts/
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Freetext attribute for all tags...
Posted by Ted Husted <hu...@apache.org>.
Is freetext all right with everyone, or should we use something like
literal
custom
or
verbatim
It's just that I feel we have not paid close enough attention to the
naming of things in the past, and we might want "measure twice" before
we document this.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Freetext attribute for all tags...
Posted by Oleg V Alexeev <oa...@apache.org>.
Hello Arron,
I add such attribute to the tags -
Button
Cancel
Checkbox
File
Hidden
Image
Img
Link
Multibox
Password
Radio
Reset
Select
Submit
Textarea
Text
Now all non supported by struts attributes can be added to the target
tag via 'freetext' attribute. This attribute contents will directly
rendered to the tag's start part.
Monday, December 10, 2001, 10:27:42 AM, you wrote:
AB> Idea...
AB> There was just that too and fro in "additional properties needed on
AB> html:image..." bug in that there was the argument over what to support
AB> and what not to support... if there was a standard property (ie:
AB> "freetext", "freeform", "uglytext" or something) where developers could
AB> add a string to be included in the tag as they provide it (with an extra
AB> space at the front and back to avoid collisions).
AB> If a developer wants to include something to be rendered for one reason
AB> or another, Struts not supporting it or otherwise, they can without
AB> issue and code hacks that will have to be re-done the next version of
AB> the tag, tld etc...
AB> It means that the html:image and html:text can do whatever and the
AB> developer can still get the width, height and wrap stuff that he needs
AB> for nice formatting.
AB> Probably not *proper* for all the die -hards out there... but certainly
AB> useable, especially for html creatives that seek that extra level of
AB> control that Struts hasn't been around yet, doesn't want to or whatever.
AB> Just an idea.
AB> Arron.
AB> --
AB> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
AB> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Best regards,
Oleg mailto:oalexeev@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Freetext attribute for all tags...
Posted by Arron Bates <ar...@keyboardmonkey.com>.
It's all reality. Standards and non-compliant realities alike.
Take the new DOM scripting model... NS copied IE in the
getElementById()... why... because it's truly sweet. But it's not in the
spec. It's an example where the spec is not as good as the
implementation. W3C are recommendations, and should be treaded as such.
I truly feel supporting them only to the limits of their definition is
as bad in a "reality" sense as letting everything through flood-gate
style (Like an NS4 layer tag. There's a standard for ya :).
It's also a chicken and the egg situation. Specs are more of a snapshot
of the here, now and has been. Someone has to break the new ground and
implement something for the idea to be had and the need created. Like
the NS4 layer tag.
But, a committer has already said no, so everything else as they say is
"pissing in the wind".
(It's good to remind people the rules of the system, thanks Ted.)
With that, I'm going to get back to my day job.
:)
Arron.
Ted Husted wrote:
>Jon Wall wrote:
>
>>Do you want Struts to be a framework for building just
>>mass-market web sites (portals, ecommerce, etc)??
>>
>
>It's my personal feeling that we are providing the tag extensions as a
>convenience, and that they are ancilliary to the actual framework. I
>think this will become more evident as other presentation systems, like
>Velocity, come to support Struts.
>
>With the rise of Jakarta Taglibs and the JSPTL, there are fewer and
>fewer reasons for us to host our own tag extensions. Something that is
>forefront in my mind right now, is that we should continue to stay the
>course on the extensions during this transitional period.
>
>As it stands, any tag you might want to use can easily be created using
>bean:write or html:write, and the best thing to do might be for us
>(meaning me) to better document those techniques.
>
>And, as it stands, there is nothing to prevent people from using their
>own tag extensions with Struts. I think as team we encourage that idea
>whenever we can. If someone wanted to create and maintain their a set of
>tag extensions, that supported non-standard attributes, we'd be happy to
>link to those from the Resource page. But someone else will have to
>accept that burden.
>
>-- Ted Husted, Husted dot Com, Fairport NY USA.
>-- Custom Software ~ Technical Services.
>-- Tel +1 716 737-3463
>-- http://www.husted.com/struts/
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Freetext attribute for all tags...
Posted by Ted Husted <hu...@apache.org>.
Jon Wall wrote:
> Do you want Struts to be a framework for building just
> mass-market web sites (portals, ecommerce, etc)??
It's my personal feeling that we are providing the tag extensions as a
convenience, and that they are ancilliary to the actual framework. I
think this will become more evident as other presentation systems, like
Velocity, come to support Struts.
With the rise of Jakarta Taglibs and the JSPTL, there are fewer and
fewer reasons for us to host our own tag extensions. Something that is
forefront in my mind right now, is that we should continue to stay the
course on the extensions during this transitional period.
As it stands, any tag you might want to use can easily be created using
bean:write or html:write, and the best thing to do might be for us
(meaning me) to better document those techniques.
And, as it stands, there is nothing to prevent people from using their
own tag extensions with Struts. I think as team we encourage that idea
whenever we can. If someone wanted to create and maintain their a set of
tag extensions, that supported non-standard attributes, we'd be happy to
link to those from the Resource page. But someone else will have to
accept that burden.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Freetext attribute for all tags...
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 11 Dec 2001, Jon Wall wrote:
> Date: Tue, 11 Dec 2001 07:24:58 -0800 (PST)
> From: Jon Wall <jw...@yahoo.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>,
> jwall@patientkeeper.com
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: Re: Freetext attribute for all tags...
>
> Amen Arron.
>
> It seems like the top priority of web development and
> this list in particular has become complying with
> standards. While I agree that is important and we've
> shot ourselves in the foot before, I think we're
> forgetting that the absolute number one priority in
> any UI development should be to make the user's life
> easier.
>
As nice as this goal sounds, it is not sufficient to describe why I
created Struts in the first place. My top-level goal with regards to
usability is "make it easier for the user to do the right thing instead of
the wrong thing."
Why did MVC used to be hard? Because you had to do it all yourself, so
even people who understood the benefits were dissuaded by the amount of
work. Presto -- a controller servlet and configuration mechanism makes it
easier enough for people to be willing to invest the effort, and therefore
benefit from the result. They had to work harder in the beginning (to
understand the framework, and build all the pieces, but in the long run it
really is easier on them.
Does that stop people from writing Model-1-type code? Of course not --
you're perfectly free to do that to yourself. But Struts won't help you
in that direction.
This is why the HTML tag library in Struts has always stuck with the W3C
definitions for which elements it supports. You can continue to support
old browsers by workarounds (like the explicit <textarea> tag quoted
earlier in this thread). Just don't expect the framework to encourage
this.
In an increasingly XML-based world, developers are going to learn that
there are more benefits than penalties to sticking with standards (not the
least of which is that XML parsers will through away your web services
transactions if they don't conform to the corresponding DTD or schema :-).
The browser legacy issues, of course, continue to exist due to the really
lousy way that Netscape and Microsoft evolved the HTML implementations in
their browsers. They chose to avoid standardization -- tell me, do *you*
think that the need for browser-detection scripts to deal with all the
differences makes life *easier* for developers??? But that doesn't mean
that Struts needs to encourage a continuation of that by enabling the
continued use of non-standard browser features directly. Put that kind of
stuff in the template text where it belongs.
Craig McClanahan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Freetext attribute for all tags...
Posted by Jon Wall <jw...@yahoo.com>.
Amen Arron.
It seems like the top priority of web development and
this list in particular has become complying with
standards. While I agree that is important and we've
shot ourselves in the foot before, I think we're
forgetting that the absolute number one priority in
any UI development should be to make the user's life
easier.
Arron makes a good point - not all apps are the same.
If you're building a portal site, yes you absolutely
need to comply with standards and support every
browser possible. But increasingly that isn't the
case. Currently I'm working on an intranet tool that
is being used to administer a much broader
application. So even though it is a fairly extensive
web app, there are relatively few users. We have the
luxury of making very strict requirements on the
browsers that our customers use for several reasons:
there are a finite number of users, we know what kind
of PC's they are using, and we know what browsers
they're using. So we require Windows, IE 5.5+ and
JavaScript. So if I'm developing a page and there's
an IE specific tag or attribute or DOM property or
whatever that I can use which would greatly improve my
user's experience (say what you will about the Evil
Empire, but there are a LOT of these), can you tell me
why I shouldn't deviate from compliancy??
> Otherwise... I vote to have the project name changed
> to "Struts - a W3C
> explicit implementation". [+1]
Do you want Struts to be a framework for building just
mass-market web sites (portals, ecommerce, etc)??
my $.02,
-jon
--- Arron Bates <ar...@keyboardmonkey.com> wrote:
> How about leaving it up to the developer who uses
> the attribute?... we
> can warn them about it. But let's leave it to them.
>
> Why should this group decide if a developer with
> different requirements
> / demands etc has the ability to add something to a
> tag?
>
> It's valuable to have it there simply for the
> anything unforeseen.
> Including allowing a developer to create a page for
> a specific browser,
> right down to a very specific one they hacked from
> an open source
> project for use in a custom data kiosk or something.
>
> Is there a plan to *enforce* Xhtml?... It's
> currently an "option", but
> why don't we just enforce it. It's a w3C spec.
> I get browser specific requests for things all the
> time, but can I ever
> turn back to my project manager and say that it
> can't be done because
> it's not in a W3C recommendation.
>
> I work for a large multinational, and have to
> support browsers 4+. Many
> large companies do, and there's no reason at all why
> it can't be done.
> Many of these older browsers have little properties
> that have to be used
> to get them to do what it is that you need them to
> do.
>
> eg. to get rid of the white space around your html
> layout for 4+ browsers...
> <body marginwidth="0" marginheight="0"
> leftmargin="0" topmargin="0"
> rightmargin="0">
>
> Which ones are W3C?... But I have to do it because
> my business manager
> signed off on a document that was generated by a
> graphic designer in
> another department. Struts doesn't have a html:body
> tag... and just as well.
>
> Is struts meant to be an adaptable tool for
> reality?...
>
> Otherwise... I vote to have the project name changed
> to "Struts - a W3C
> explicit implementation". [+1]
> Almost being restrictive for the sake of it. There's
> no burden to bare,
> just a few lines of code that never have to be
> touched, just frisbee
> that little attribute... and just maybe it'll allow
> someone to do
> something they need to do.
>
>
> Arron.
>
> * (Something tells me I'm going to stay out of
> things like this in the
> future).
>
>
> Martin Cooper wrote:
>
> >-1
> >
> >I guess I started this by marking the associated
> bug report invalid, and
> >adding the comments I received privately from the
> original reporter.
> >
> >The reasons I am -1 on this are:
> >
> >1) The attributes for which this has been suggested
> are not valid per the
> >W3C standards. I do not believe that Struts should
> be catering to
> >non-standard solutions. Yes, I realise that some
> browsers support
> >"extensions" to the standard. However, suppose that
> attribute 'foo',
> >currently supported by browser X, is eventually
> standardised such that the
> >standard values are not consistent with what
> browser X supported. What
> >should we do now?
> >2) name collisions
> >3) syntax validation
> >4) duplication
> >5) XHTML (need to ignore when value is set)
> >
> >
> >----- Original Message -----
> >From: "Arron Bates" <ar...@keyboardmonkey.com>
> >To: "Struts Developers List"
> <st...@jakarta.apache.org>
> >Sent: Sunday, December 09, 2001 11:27 PM
> >Subject: Freetext attribute for all tags...
> >
> >
> >>Idea...
> >>
> >>There was just that too and fro in "additional
> properties needed on
> >>html:image..." bug in that there was the argument
> over what to support
> >>and what not to support... if there was a standard
> property (ie:
> >>"freetext", "freeform", "uglytext" or something)
> where developers could
> >>add a string to be included in the tag as they
> provide it (with an extra
> >>space at the front and back to avoid collisions).
> >>
> >>If a developer wants to include something to be
> rendered for one reason
> >>or another, Struts not supporting it or otherwise,
> they can without
> >>issue and code hacks that will have to be re-done
> the next version of
> >>the tag, tld etc...
> >>
> >>It means that the html:image and html:text can do
> whatever and the
> >>developer can still get the width, height and wrap
> stuff that he needs
> >>for nice formatting.
> >>
> >>Probably not *proper* for all the die -hards out
> there... but certainly
> >>useable, especially for html creatives that seek
> that extra level of
> >>control that Struts hasn't been around yet,
> doesn't want to or whatever.
> >>
> >>Just an idea.
> >>
> >>
> >>Arron.
> >>
> >>
> >>
> >>--
> >>To unsubscribe, e-mail:
> >>
> ><ma...@jakarta.apache.org>
> >
> >>For additional commands, e-mail:
> >>
> ><ma...@jakarta.apache.org>
> >
> >
> >
> >--
> >To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> >For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Freetext attribute for all tags...
Posted by Arron Bates <ar...@keyboardmonkey.com>.
How about leaving it up to the developer who uses the attribute?... we
can warn them about it. But let's leave it to them.
Why should this group decide if a developer with different requirements
/ demands etc has the ability to add something to a tag?
It's valuable to have it there simply for the anything unforeseen.
Including allowing a developer to create a page for a specific browser,
right down to a very specific one they hacked from an open source
project for use in a custom data kiosk or something.
Is there a plan to *enforce* Xhtml?... It's currently an "option", but
why don't we just enforce it. It's a w3C spec.
I get browser specific requests for things all the time, but can I ever
turn back to my project manager and say that it can't be done because
it's not in a W3C recommendation.
I work for a large multinational, and have to support browsers 4+. Many
large companies do, and there's no reason at all why it can't be done.
Many of these older browsers have little properties that have to be used
to get them to do what it is that you need them to do.
eg. to get rid of the white space around your html layout for 4+ browsers...
<body marginwidth="0" marginheight="0" leftmargin="0" topmargin="0"
rightmargin="0">
Which ones are W3C?... But I have to do it because my business manager
signed off on a document that was generated by a graphic designer in
another department. Struts doesn't have a html:body tag... and just as well.
Is struts meant to be an adaptable tool for reality?...
Otherwise... I vote to have the project name changed to "Struts - a W3C
explicit implementation". [+1]
Almost being restrictive for the sake of it. There's no burden to bare,
just a few lines of code that never have to be touched, just frisbee
that little attribute... and just maybe it'll allow someone to do
something they need to do.
Arron.
* (Something tells me I'm going to stay out of things like this in the
future).
Martin Cooper wrote:
>-1
>
>I guess I started this by marking the associated bug report invalid, and
>adding the comments I received privately from the original reporter.
>
>The reasons I am -1 on this are:
>
>1) The attributes for which this has been suggested are not valid per the
>W3C standards. I do not believe that Struts should be catering to
>non-standard solutions. Yes, I realise that some browsers support
>"extensions" to the standard. However, suppose that attribute 'foo',
>currently supported by browser X, is eventually standardised such that the
>standard values are not consistent with what browser X supported. What
>should we do now?
>2) name collisions
>3) syntax validation
>4) duplication
>5) XHTML (need to ignore when value is set)
>
>
>----- Original Message -----
>From: "Arron Bates" <ar...@keyboardmonkey.com>
>To: "Struts Developers List" <st...@jakarta.apache.org>
>Sent: Sunday, December 09, 2001 11:27 PM
>Subject: Freetext attribute for all tags...
>
>
>>Idea...
>>
>>There was just that too and fro in "additional properties needed on
>>html:image..." bug in that there was the argument over what to support
>>and what not to support... if there was a standard property (ie:
>>"freetext", "freeform", "uglytext" or something) where developers could
>>add a string to be included in the tag as they provide it (with an extra
>>space at the front and back to avoid collisions).
>>
>>If a developer wants to include something to be rendered for one reason
>>or another, Struts not supporting it or otherwise, they can without
>>issue and code hacks that will have to be re-done the next version of
>>the tag, tld etc...
>>
>>It means that the html:image and html:text can do whatever and the
>>developer can still get the width, height and wrap stuff that he needs
>>for nice formatting.
>>
>>Probably not *proper* for all the die -hards out there... but certainly
>>useable, especially for html creatives that seek that extra level of
>>control that Struts hasn't been around yet, doesn't want to or whatever.
>>
>>Just an idea.
>>
>>
>>Arron.
>>
>>
>>
>>--
>>To unsubscribe, e-mail:
>>
><ma...@jakarta.apache.org>
>
>>For additional commands, e-mail:
>>
><ma...@jakarta.apache.org>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Freetext attribute for all tags...
Posted by Martin Cooper <ma...@tumbleweed.com>.
-1
I guess I started this by marking the associated bug report invalid, and
adding the comments I received privately from the original reporter.
The reasons I am -1 on this are:
1) The attributes for which this has been suggested are not valid per the
W3C standards. I do not believe that Struts should be catering to
non-standard solutions. Yes, I realise that some browsers support
"extensions" to the standard. However, suppose that attribute 'foo',
currently supported by browser X, is eventually standardised such that the
standard values are not consistent with what browser X supported. What
should we do now?
2) name collisions
3) syntax validation
4) duplication
5) XHTML (need to ignore when value is set)
----- Original Message -----
From: "Arron Bates" <ar...@keyboardmonkey.com>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Sunday, December 09, 2001 11:27 PM
Subject: Freetext attribute for all tags...
> Idea...
>
> There was just that too and fro in "additional properties needed on
> html:image..." bug in that there was the argument over what to support
> and what not to support... if there was a standard property (ie:
> "freetext", "freeform", "uglytext" or something) where developers could
> add a string to be included in the tag as they provide it (with an extra
> space at the front and back to avoid collisions).
>
> If a developer wants to include something to be rendered for one reason
> or another, Struts not supporting it or otherwise, they can without
> issue and code hacks that will have to be re-done the next version of
> the tag, tld etc...
>
> It means that the html:image and html:text can do whatever and the
> developer can still get the width, height and wrap stuff that he needs
> for nice formatting.
>
> Probably not *proper* for all the die -hards out there... but certainly
> useable, especially for html creatives that seek that extra level of
> control that Struts hasn't been around yet, doesn't want to or whatever.
>
> Just an idea.
>
>
> Arron.
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Freetext attribute for all tags...
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 10 Dec 2001, Arron Bates wrote:
> Date: Mon, 10 Dec 2001 18:27:42 +1100
> From: Arron Bates <ar...@keyboardmonkey.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: Freetext attribute for all tags...
>
> Idea...
>
> There was just that too and fro in "additional properties needed on
> html:image..." bug in that there was the argument over what to support
> and what not to support... if there was a standard property (ie:
> "freetext", "freeform", "uglytext" or something) where developers could
> add a string to be included in the tag as they provide it (with an extra
> space at the front and back to avoid collisions).
>
> If a developer wants to include something to be rendered for one reason
> or another, Struts not supporting it or otherwise, they can without
> issue and code hacks that will have to be re-done the next version of
> the tag, tld etc...
>
> It means that the html:image and html:text can do whatever and the
> developer can still get the width, height and wrap stuff that he needs
> for nice formatting.
>
> Probably not *proper* for all the die -hards out there... but certainly
> useable, especially for html creatives that seek that extra level of
> control that Struts hasn't been around yet, doesn't want to or whatever.
>
> Just an idea.
>
I can sympathize with this point. However, "freetext" as currently
proposed (and as Oleg checked in) lets you define *any* attribute that
happens to be supported by the tag you're inside, even if it's an
attribute that Struts already generates elsewhere.
IMHO, this is going to lead to more user problems, along with the ability
to generate non-HTML-standard browser tags. It also goes against the
grain of movement towards XHTML, where there is no such thing as a
non-standard attribute.
I'm at least -0 on the current approach, but leaning towards -1.
(I'm also OK with "freetext" as the name for this concept if we keep it,
versus the other alternatives -- you are "free" to hang yourself with it
:-).
>
> Arron.
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>