cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathaniel Alfred" <>
Subject RE: [RFE] Some enhancements to XSP
Date Thu, 26 May 2005 14:34:13 GMT
>-----Original Message-----
>From: Vadim Gritsenko []
>Sent: Mittwoch, 25. Mai 2005 20:47
>Subject: Re: [RFE] Some enhancements to XSP

>>>3. A mechanism for expression replacement as in XSLT or JXTG, replacing 
>>>"{expression}" with a xsp:attribute element in attributes and with a 
>>>xsp:expr element in character data. This could be implemented in the 
>>>PreProcessFilter of XSPMarkupLanguage. The feature would be disabled by 
>>>default and enabled on a per-XSP-basis, maybe through a processing 
>>><!-- Hey, this looks almost like JXTG :) -->
>>><img src="{source}" width="{width}" height="{height}"/>
>>><h1>Hello {username}</h1>
>>>is more readable and easier to use than
>>>       <xsp:attribute 
>>>       <xsp:attribute 
>>>       <xsp:attribute 
>>><h1>Hello <xsp:expr>username</xsp:expr></h1>
>>>Any comments?
>I'm not in favour of <h1>Hello {username}</h1>.
>>>(I hope this hasn't been proposed already, but I 
>>>didn't find anything about it)
>See [1].
>> Don't think in-text replacement is a good idea.
>I think it's great idea, and, moreover, it is already implemented in another XSP 
>implementation - AxKit [1]. So implementing the feature makes sense - it will 
>consolidate XSP standard.
>> The preprocess would
>> need too much knowledge about xsp markup in order not to try expanding
>> curlies inside xsp:logic, xsp:expr etc.
>Curlies (should) are always expanded in the attribute values only - same as in 
>XSLT. No evaluation in any other place - so in this case it is very simple.

I think I was too terse to make myself understand.  With "in-text replacement"
I meant

    <h1>Hello {username}</h1>

as shortcut for

    <h1>Hello <xsp:expr>username</xsp:expr></h1>

I am against that because it risks to break too many existing XSP containing 
curlies for whatever reason in text nodes.  I am also -1 on activating that
feature on a per-page.  Whilst I am all for improving XSPs I would want to
avoid creating a second dialect.  (Of course a temporary safeguard as in [1],
with the intention to make it the default later, is okay.)

>> Also for the src="{source}" shortcut I am sceptic.  It breaks when
>> you want to move your <img> content markup from XSP to logicsheet.
>Please elaborate, what breaks and why?

I was just thinking of XSP as staging ground for code which later might be
moved to a logicsheet.  One can move a sniplet like

     <xsp:attribute name="src"><xsp:expr>source</xsp:expr></xsp:attribute>

unchanged from XSP and logicsheet whilst <img src="{source}"/> needs to
be adaption.

But I had the misconception that there was the danger that in the logicsheet
it would silently generate <img src=""/>.  However, XSLT will signal "source" 
as invalid expression to catch the error at compile time.

So I changed my mind and now, I am in favor of it.

>> But I agree that the xsp:attribute markup is too verbose.  I'd rather
>> wish for the XSLT analogy:
>>   <xsp:attribute name="src" value="source"/>
>That can be trivially added - on top of what we have now. Not sure why it was 

Shall we add it then?
Here's my +1.

Cheers, Alfred.

This message is for the named person's use only. It may contain confidential, proprietary
or legally privileged information. No confidentiality or privilege is waived or lost by any
mistransmission. If you receive this message in error, please notify the sender urgently and
then immediately delete the message and any copies of it from your system. Please also immediately
destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the intended recipient.
The sender's company reserves the right to monitor all e-mail communications through their
networks. Any views expressed in this message are those of the individual sender, except where
the message states otherwise and the sender is authorised to state them to be the views of
the sender's company.

View raw message