You are viewing a plain text version of this content. The canonical link for it is here.
Posted to axkit-dev@xml.apache.org by Kip Hampton <kh...@totalcinema.com> on 2003/09/26 01:03:25 UTC
RFC: AVT for XSP's element and attribute
What:
Extend attribute-value-template behavior to include the 'name' attribute
for XSP's <xsp:element> and <xsp:attribute>.
Why:
Syntactic sugar, really. We now offer AVT for attribute values in
literal output, so, why not have it for the generated names of elements
and attributes created via <xsp:element> and <xsp:attribute> to save
users a bit of verbosity? Compare,
<xsp:element>
<xsp:name><xsp:expr>$perl_expression<xsp:expr></xsp:name>
<!-- contents -->
</xsp:element>
vs.
<xsp:element name="{$perl_expression}">
<!-- contents -->
</xsp:element>
Incurred Risk:
Well, any edit to the house of cards that is XSP.pm is a risk, IMO, but
this is a two-line change. If this RFC gets a +1 I'll add test files as
well, just to be sure.
Thoughts?
-kip
Re: RFC: AVT for XSP's element and attribute
Posted by Michael A Nachbaur <mi...@nachbaur.com>.
On Thursday 25 September 2003 04:03 pm, Kip Hampton wrote:
> What:
>
> Extend attribute-value-template behavior to include the 'name' attribute
> for XSP's <xsp:element> and <xsp:attribute>.
[snip]
> Well, any edit to the house of cards that is XSP.pm is a risk, IMO, but
> this is a two-line change. If this RFC gets a +1 I'll add test files as
> well, just to be sure.
+1
I love the idea, since this would make my life, if not easier, then a bit less
painful.
--
/* Michael A. Nachbaur <mi...@nachbaur.com>
* http://nachbaur.com/pgpkey.asc
*/
"Rome wasn't burned in a day. "
Re: RFC: AVT for XSP's element and attribute
Posted by Michael A Nachbaur <mi...@nachbaur.com>.
On Friday 26 September 2003 07:41 am, Kip Hampton wrote:
> > But I do worry slightly that this is the thin end of the wedge... So we
> > should either make sure the AVT function is fully exposed so other
> > taglibs can (ab)use it, or decide now it should remain private.
>
> Hmmm... I can certianly see where providing access to the AVT behavior
> could be helpful/useful to taglibrarians. OTOH, the more we bolt on to
> the current XSP.pm, the harder we make it to refactor later without
> breaking back-compat (and it *will* be refactored, my friend, oh, yes.
> and with extreme prejudice :-). I cast a tenative vote for "make it
> public". Other thoughts?
-1 to making it public, at least for now.
I think adding AVT functionality for the name attribute is a good stop-gap
measure, helping to clean up code, but if there's no guarentee this sort of
functionality would be available in a refactored XSP, then making it public
"just because we can" doesn't sound like much of a code-maintainer's
paradise.
--
/* Michael A. Nachbaur <mi...@nachbaur.com>
* http://nachbaur.com/pgpkey.asc
*/
"Oh no, not again."
Re: RFC: AVT for XSP's element and attribute
Posted by Kip Hampton <kh...@totalcinema.com>.
Matt Sergeant wrote:
> And the "value" attribute for xsp:attribute.
Funny, I thought about this originally, too, but there's no such animal.
XSP's 'attribute' element has the same behavior as XSLT's[1]. That is,
the value for the newly created attribute may appear only as the text
contents of the 'attribute' element and there is no 'value' (or similar)
attribute.
Or... where you suggesting that we add a 'value' attribute? (FWIW, I say
leave it as it is now and keep conceptual compatability w/ XSLT).
>
> But I do worry slightly that this is the thin end of the wedge... So we
> should either make sure the AVT function is fully exposed so other
> taglibs can (ab)use it, or decide now it should remain private.
Hmmm... I can certianly see where providing access to the AVT behavior
could be helpful/useful to taglibrarians. OTOH, the more we bolt on to
the current XSP.pm, the harder we make it to refactor later without
breaking back-compat (and it *will* be refactored, my friend, oh, yes.
and with extreme prejudice :-). I cast a tenative vote for "make it
public". Other thoughts?
-kip
[1] http://www.w3.org/TR/xslt#creating-attributes
Re: RFC: AVT for XSP's element and attribute
Posted by Jörg Walter <jw...@garni.ch>.
On Friday, 26. September 2003 15:26, Jörg Walter wrote:
> And I still worry about the insane quoting rules. We should really devise
> something that won't break as soon as it's more than {$foo}. I beg for some
> Text::Balanced-like syntax, plus the traditional backslash.
Note that I volunteer for this, and I already have a test collection.
--
CU
Joerg
PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc
PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94
Re: RFC: AVT for XSP's element and attribute
Posted by Jörg Walter <jw...@garni.ch>.
On Friday, 26. September 2003 09:26, Matt Sergeant wrote:
> But I do worry slightly that this is the thin end of the wedge... So we
> should either make sure the AVT function is fully exposed so other
> taglibs can (ab)use it, or decide now it should remain private.
And I still worry about the insane quoting rules. We should really devise
something that won't break as soon as it's more than {$foo}. I beg for some
Text::Balanced-like syntax, plus the traditional backslash.
+1 for the current patch.
--
CU
Joerg
PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc
PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94
Re: RFC: AVT for XSP's element and attribute
Posted by Robin Berjon <ro...@knowscape.com>.
Matt Sergeant wrote:
> But I do worry slightly that this is the thin end of the wedge... So we
> should either make sure the AVT function is fully exposed so other
> taglibs can (ab)use it, or decide now it should remain private.
I think it should be abusable by other taglibs as well. It would make a lot of
the XSP I've had to write much more readable.
Also, <plusOne/> on the feature in general.
Re: RFC: AVT for XSP's element and attribute
Posted by Matt Sergeant <ma...@sergeant.org>.
On 26 Sep 2003, at 0:03, Kip Hampton wrote:
> What:
>
> Extend attribute-value-template behavior to include the 'name'
> attribute
> for XSP's <xsp:element> and <xsp:attribute>.
>
> Why:
>
> Syntactic sugar, really. We now offer AVT for attribute values in
> literal output, so, why not have it for the generated names of elements
> and attributes created via <xsp:element> and <xsp:attribute> to save
> users a bit of verbosity?
And the "value" attribute for xsp:attribute.
But I do worry slightly that this is the thin end of the wedge... So we
should either make sure the AVT function is fully exposed so other
taglibs can (ab)use it, or decide now it should remain private.
Anyway, +1