You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xsp-dev@xml.apache.org by Robin Green <gr...@hotmail.com> on 2001/01/09 20:01:59 UTC

Re: [C2] xsp:logic tag behaviour

Firstly, changes to XSP should be discussed on xsp-dev since Cocoon is not 
the only product that uses XSP.

Secondly, a -100 from me since some logicsheets, including esql, will break. 
They rely on the ability to create variables which continue after the 
xsp:logic tag ends - one of the few technical advantages which XSP has over 
plain Java.

"Vadim Gritsenko" <vg...@hns.com> wrote:
>I noticed that <xsp:logic> tag behaves a little bit different than I 
>thought
>it should after reading http://xml.apache.org/cocoon/wd-xsp.html, 
>especially
>part "Page Readability".
>
>In short: I thought that local variable visibility should be limited by
>corresponding <xsp:logic> tag, but now it implemented such way that local
>variables are visible across all page - and this breaks page readability.

You misunderstand what they mean by page readability (which is a HIGHLY 
subjective concept anyway). (Actually local variables are not visible all 
over the page, only in the document populate method, as is normal in Java.) 
They are talking about merely and simply reducing verbosity by allowing 
mixing of code and data (although it must be said, in Cocoon you are not 
entirely free to mix code and data in this way, because of the need to 
distinguish code from CDATA, i.e. literal XML text.)

>
>Consider simple example:
>
><page>
>   <xsp:logic>
>     int i = 5;
>   </xsp:logic>
>   The value of i is: <xsp:expr>i</xsp:expr>
></page>
>
>This example works now, and I think that this is reducing readability of 
>XSP
>and this XSP code is no different from jsp:
>
><page>
>   <jsp:scriptlet>
>     int i = 5;
>   </jsp:scriptlet>
>   The value of i is: <jsp:expression>i</xsp:expression>
></page>
>
>So, example from "Page Readability" chapter of WD can be fully rewritten
>using "JSP coding style"...

Yes, Cocoon gives you the freedom to be more or less verbose (up to a 
point).




_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.


RE: [C2] xsp:logic tag behaviour

Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 9 Jan 2001, Vadim Gritsenko wrote:

> Sorry to hear this... But - correct me if I don't understand this -
> it is possible to re-write logicsheet so it uses variables only
> inside scope of <xsp:logic> tag, example:
> ------------- existing code --------------
>       <xsp:logic>
>         Stack esqlSessions = new Stack();
>         EsqlSession esqlSession = null;
>       </xsp:logic>
>       <xsl:apply-templates/>
> -------------- replace by ----------------
>       <xsp:logic>
>         Stack esqlSessions = new Stack();
>         EsqlSession esqlSession = null;
>         <xsp:content>
>           <xsl:apply-templates/>
>         </xsp:content>
>       </xsp:logic>
> ------------------------------------------
>
> And the code will be a little bit clearer (at least, you can see
> variable scope - so you know where this variable may be used) - of
> course, this is objective.

no. some variables declared in an xsp:logic element may be used in
expressions which are used outside of the xsp:logic element. if you want
your variables to lose scope after your xsp:logic element ends, put curly
braces inside your xsp:logic element (<xsp:logic>{ ... }</xsp:logic>).

> > They rely on the ability to create variables which continue after the
> > xsp:logic tag ends - one of the few technical advantages which
> > XSP has over plain Java.
>
> But now, if your tag declares variable - you can not use this tag again in
> same jsp - or you must do some sort of variable name generation.

that's why well-behaved logicsheets, e.g. esql, mail, smtp, put a prefix
(_esql_) on variables they declare. yeah, i can see some rationale for an
xsp:variable element so that this process is automatic, but others have
disagreed so far.

- donald


RE: [C2] xsp:logic tag behaviour

Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 9 Jan 2001, Vadim Gritsenko wrote:

> Sorry to hear this... But - correct me if I don't understand this -
> it is possible to re-write logicsheet so it uses variables only
> inside scope of <xsp:logic> tag, example:
> ------------- existing code --------------
>       <xsp:logic>
>         Stack esqlSessions = new Stack();
>         EsqlSession esqlSession = null;
>       </xsp:logic>
>       <xsl:apply-templates/>
> -------------- replace by ----------------
>       <xsp:logic>
>         Stack esqlSessions = new Stack();
>         EsqlSession esqlSession = null;
>         <xsp:content>
>           <xsl:apply-templates/>
>         </xsp:content>
>       </xsp:logic>
> ------------------------------------------
>
> And the code will be a little bit clearer (at least, you can see
> variable scope - so you know where this variable may be used) - of
> course, this is objective.

no. some variables declared in an xsp:logic element may be used in
expressions which are used outside of the xsp:logic element. if you want
your variables to lose scope after your xsp:logic element ends, put curly
braces inside your xsp:logic element (<xsp:logic>{ ... }</xsp:logic>).

> > They rely on the ability to create variables which continue after the
> > xsp:logic tag ends - one of the few technical advantages which
> > XSP has over plain Java.
>
> But now, if your tag declares variable - you can not use this tag again in
> same jsp - or you must do some sort of variable name generation.

that's why well-behaved logicsheets, e.g. esql, mail, smtp, put a prefix
(_esql_) on variables they declare. yeah, i can see some rationale for an
xsp:variable element so that this process is automatic, but others have
disagreed so far.

- donald


RE: [C2] xsp:logic tag behaviour

Posted by Vadim Gritsenko <vg...@hns.com>.
> -----Original Message-----
> From: Robin Green [mailto:greenrd@hotmail.com]
> Sent: Tuesday, January 09, 2001 14:02
> To: cocoon-dev@xml.apache.org
> Cc: xsp-dev@xml.apache.org
> Subject: Re: [C2] xsp:logic tag behaviour
>
>
> Firstly, changes to XSP should be discussed on xsp-dev since
> Cocoon is not the only product that uses XSP.

Sorry, I thought that this is an implementation issue...


> Secondly, a -100 from me since some logicsheets, including esql,
> will break.

Sorry to hear this... But - correct me if I don't understand this -
it is possible to re-write logicsheet so it uses variables only
inside scope of <xsp:logic> tag, example:
------------- existing code --------------
      <xsp:logic>
        Stack esqlSessions = new Stack();
        EsqlSession esqlSession = null;
      </xsp:logic>
      <xsl:apply-templates/>
-------------- replace by ----------------
      <xsp:logic>
        Stack esqlSessions = new Stack();
        EsqlSession esqlSession = null;
        <xsp:content>
          <xsl:apply-templates/>
        </xsp:content>
      </xsp:logic>
------------------------------------------

And the code will be a little bit clearer (at least, you can see
variable scope - so you know where this variable may be used) - of
course, this is objective.


> They rely on the ability to create variables which continue after the
> xsp:logic tag ends - one of the few technical advantages which
> XSP has over plain Java.

But now, if your tag declares variable - you can not use this tag again in
same jsp - or you must do some sort of variable name generation.


> "Vadim Gritsenko" <vg...@hns.com> wrote:
> >I noticed that <xsp:logic> tag behaves a little bit different than I
> >thought
> >it should after reading http://xml.apache.org/cocoon/wd-xsp.html,
> >especially part "Page Readability".
> >
> >In short: I thought that local variable visibility should be limited by
> >corresponding <xsp:logic> tag, but now it implemented such way that local
> >variables are visible across all page - and this breaks page readability.
>
> You misunderstand what they mean by page readability (which is a HIGHLY
> subjective concept anyway).

May be...

> (Actually local variables are not visible all
> over the page, only in the document populate method, as is normal
> in Java.)

I meant this. Visible across whole method.


> They are talking about merely and simply reducing verbosity by allowing
> mixing of code and data (although it must be said, in Cocoon you are not
> entirely free to mix code and data in this way, because of the need to
> distinguish code from CDATA, i.e. literal XML text.)

This interleaving of code and data - is really cool feature, I agree with
this.

<snip/>

> >So, example from "Page Readability" chapter of WD can be fully rewritten
> >using "JSP coding style"...
>
> Yes, Cocoon gives you the freedom to be more or less verbose (up to a
> point).

The result of this freedom is that there is a gap between XSP/XML document
structure (XML tags tree) and Java program structure (Java blocks tree). I
was
suggesting to link them together.


Vadim


RE: [C2] xsp:logic tag behaviour

Posted by Vadim Gritsenko <vg...@hns.com>.
> -----Original Message-----
> From: Robin Green [mailto:greenrd@hotmail.com]
> Sent: Tuesday, January 09, 2001 14:02
> To: cocoon-dev@xml.apache.org
> Cc: xsp-dev@xml.apache.org
> Subject: Re: [C2] xsp:logic tag behaviour
>
>
> Firstly, changes to XSP should be discussed on xsp-dev since
> Cocoon is not the only product that uses XSP.

Sorry, I thought that this is an implementation issue...


> Secondly, a -100 from me since some logicsheets, including esql,
> will break.

Sorry to hear this... But - correct me if I don't understand this -
it is possible to re-write logicsheet so it uses variables only
inside scope of <xsp:logic> tag, example:
------------- existing code --------------
      <xsp:logic>
        Stack esqlSessions = new Stack();
        EsqlSession esqlSession = null;
      </xsp:logic>
      <xsl:apply-templates/>
-------------- replace by ----------------
      <xsp:logic>
        Stack esqlSessions = new Stack();
        EsqlSession esqlSession = null;
        <xsp:content>
          <xsl:apply-templates/>
        </xsp:content>
      </xsp:logic>
------------------------------------------

And the code will be a little bit clearer (at least, you can see
variable scope - so you know where this variable may be used) - of
course, this is objective.


> They rely on the ability to create variables which continue after the
> xsp:logic tag ends - one of the few technical advantages which
> XSP has over plain Java.

But now, if your tag declares variable - you can not use this tag again in
same jsp - or you must do some sort of variable name generation.


> "Vadim Gritsenko" <vg...@hns.com> wrote:
> >I noticed that <xsp:logic> tag behaves a little bit different than I
> >thought
> >it should after reading http://xml.apache.org/cocoon/wd-xsp.html,
> >especially part "Page Readability".
> >
> >In short: I thought that local variable visibility should be limited by
> >corresponding <xsp:logic> tag, but now it implemented such way that local
> >variables are visible across all page - and this breaks page readability.
>
> You misunderstand what they mean by page readability (which is a HIGHLY
> subjective concept anyway).

May be...

> (Actually local variables are not visible all
> over the page, only in the document populate method, as is normal
> in Java.)

I meant this. Visible across whole method.


> They are talking about merely and simply reducing verbosity by allowing
> mixing of code and data (although it must be said, in Cocoon you are not
> entirely free to mix code and data in this way, because of the need to
> distinguish code from CDATA, i.e. literal XML text.)

This interleaving of code and data - is really cool feature, I agree with
this.

<snip/>

> >So, example from "Page Readability" chapter of WD can be fully rewritten
> >using "JSP coding style"...
>
> Yes, Cocoon gives you the freedom to be more or less verbose (up to a
> point).

The result of this freedom is that there is a gap between XSP/XML document
structure (XML tags tree) and Java program structure (Java blocks tree). I
was
suggesting to link them together.


Vadim