You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Torsten Curdt <tc...@dff.st> on 2002/01/10 20:24:44 UTC

XSP bug?

Shouldn't the following construct work?

 ...
 <tag>
    <xsp:logic>
       try {

         <ns:list>
           Collection list = ...

           for (Iterator iterator = list.iterator(); iterator.hasNext();) {
             MyObj o = (MyObj) iterator.next();

             <ns:MyObj>
               <ns:name>o.getName()</ns:name>
             </ns:MyObj>

           }
         </ns:list>

       }
       catch(Exception e) {
         <xsp:content>Error: <xsp:expr>String.valueOf(e)</xsp:expr></xsp:content>
       }
    </xsp:logic>
 </tag>
 ...

Referring to some old C1 documentation http://xml.apache.org/cocoon1/xsp.html
(paragraph "logic tags") this should work.
And I think this should work the same way in C2!

One could use <xsp:element> (like e.g. esql does) to work around this.
But that's a not quite nice sollution. Can we aggree that this should
work?

Unfortunately the current implementation will treat any java code
within a tag inside the xsp logic tag as text nodes - not as java.

If we can aggree that this behaviour is wrong I'd like to change
the xsp.xsl accordingly.
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: XSP bug?

Posted by Torsten Curdt <tc...@dff.st>.
> >If you look at the provided C1 docs this was different before.
> >
> How is this different ? The examples do not embed markup as far as your
> example, but they state that " the |<xsp:logic>| element allows for the
> arbitrary nesting of other markup without the need to "prematurely"
> close it"
>
> And the example below this sentence clearly shows that text nodes in
> embedded markup aren't Java code :
>
> <table>
>   <xsp:logic>
>     for (int i = 0; i &lt; countries.length; i++) {
>       <tr>
>         <td>
>           <xsp:expr>countries[i].getName()</xsp:expr>
>         </td>
>         <td>
>           <xsp:expr>countries[i].getCurrency()</xsp:expr>
>         </td>
>       </tr>
>     }
>   </xsp:logic>
> </table>
>
> Notice the <xsp:expr> inside the <td> : if they weren't present,
> "countries[i]..." wouldn't be considered as Java code and thus inserted
> as is in the produced document.
>
> And this is what makes XSP more XML-ish than other dynamic page
> languages : in the XML tree, the <tr> in the above sample are _inside_
> the <xsp:logic>, which is more in accordance with the page logic than
> what you would do with JSP, where there would be 2 java code blocs _at
> the same level_ as the <tr>.

Hm... damn - you are right ;)

I recalled it differently...

> >3) what's the more desired behaviour
> >
> IMO the desired behaviour is the one we have today : as soon as you put
> markup in an <xsp:logic>, you leave Java code to go back to XML content.

Ok, I will shut up then ;)
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: XSP bug?

Posted by Vadim Gritsenko <va...@verizon.net>.
Torsten,

I here fully agree with Sylvain, and I was trying to tell you same as
Sylvain, may be just not so clear... If you read examples from C1
(reference in my other email), you will see that after XML tag nested in
<xsp:logic>, C1 *is* switching to content mode, ending scope of Java.

Vadim

> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> 
> Torsten Curdt wrote:
> 
> >>>Referring to some old C1 documentation
> http://xml.apache.org/cocoon1/xsp.html
> >>>(paragraph "logic tags") this should work.
> >>>And I think this should work the same way in C2!
> >>>
> >>You need to open a new <xsp:logic> inside <ns:list> : the scope of
Java
> >>code in <xsp:logic> is limited to text nodes that are its _direct_
> >> children. Also, "o.getName()" should be enclosed by an <xsp:expr>.
So
> >>the above snippet should be written as follows :
> >>
> >
> >[snip]
> >
> >Right.
> >
> >>So I'm not sure there is a wrong behaviour in the engine.
> >>Sylvain
> >>
> >If you look at the provided C1 docs this was different before.
> >
> How is this different ? The examples do not embed markup as far as
your
> example, but they state that " the |<xsp:logic>| element allows for
the
> arbitrary nesting of other markup without the need to "prematurely"
> close it"
> 
> And the example below this sentence clearly shows that text nodes in
> embedded markup aren't Java code :
> 
> <table>
>   <xsp:logic>
>     for (int i = 0; i &lt; countries.length; i++) {
>       <tr>
>         <td>
>           <xsp:expr>countries[i].getName()</xsp:expr>
>         </td>
>         <td>
>           <xsp:expr>countries[i].getCurrency()</xsp:expr>
>         </td>
>       </tr>
>     }
>   </xsp:logic>
> </table>
> 
> Notice the <xsp:expr> inside the <td> : if they weren't present,
> "countries[i]..." wouldn't be considered as Java code and thus
inserted
> as is in the produced document.
> 
> And this is what makes XSP more XML-ish than other dynamic page
> languages : in the XML tree, the <tr> in the above sample are _inside_
> the <xsp:logic>, which is more in accordance with the page logic than
> what you would do with JSP, where there would be 2 java code blocs _at
> the same level_ as the <tr>.
> 
> >
> >So question is:
> >
> >1) is this still C1 behaviour or is the docu outdate (well, always ;)
> >
> This both C1 & C2 behaviour, and docu is up to date (well, at least on
> this point ;)
> 
> >
> >2) what says the xsp spec (is there one?)
> >
> There's a 2-year old working draft at
> http://xml.apache.org/cocoon1/wd-xsp.html
> The before-last chapter "Page readability" explains just the same as
> above on JSP.
> 
> >
> >3) what's the more desired behaviour
> >
> IMO the desired behaviour is the one we have today : as soon as you
put
> markup in an <xsp:logic>, you leave Java code to go back to XML
content.
> 
> >
> >4) what will break if we change it
> >
> Again, IMO nothing's wrong... or maybe our example ;-)
> 
> Sylvain


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: XSP bug?

Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Torsten Curdt wrote:

>>>Referring to some old C1 documentation http://xml.apache.org/cocoon1/xsp.html
>>>(paragraph "logic tags") this should work.
>>>And I think this should work the same way in C2!
>>>
>>You need to open a new <xsp:logic> inside <ns:list> : the scope of Java
>>code in <xsp:logic> is limited to text nodes that are its _direct_
>> children. Also, "o.getName()" should be enclosed by an <xsp:expr>. So
>>the above snippet should be written as follows :
>>
>
>[snip]
>
>Right.
>
>>So I'm not sure there is a wrong behaviour in the engine.
>>Sylvain
>>
>If you look at the provided C1 docs this was different before.
>
How is this different ? The examples do not embed markup as far as your 
example, but they state that " the |<xsp:logic>| element allows for the 
arbitrary nesting of other markup without the need to "prematurely" 
close it"

And the example below this sentence clearly shows that text nodes in 
embedded markup aren't Java code :

<table>
  <xsp:logic>
    for (int i = 0; i &lt; countries.length; i++) {
      <tr>
        <td>
          <xsp:expr>countries[i].getName()</xsp:expr>
        </td>
        <td>
          <xsp:expr>countries[i].getCurrency()</xsp:expr>
        </td>
      </tr>
    }
  </xsp:logic>
</table>

Notice the <xsp:expr> inside the <td> : if they weren't present, 
"countries[i]..." wouldn't be considered as Java code and thus inserted 
as is in the produced document.

And this is what makes XSP more XML-ish than other dynamic page 
languages : in the XML tree, the <tr> in the above sample are _inside_ 
the <xsp:logic>, which is more in accordance with the page logic than 
what you would do with JSP, where there would be 2 java code blocs _at 
the same level_ as the <tr>.

>
>So question is:
>
>1) is this still C1 behaviour or is the docu outdate (well, always ;)
>
This both C1 & C2 behaviour, and docu is up to date (well, at least on 
this point ;)

>
>2) what says the xsp spec (is there one?)
>
There's a 2-year old working draft at 
http://xml.apache.org/cocoon1/wd-xsp.html
The before-last chapter "Page readability" explains just the same as 
above on JSP.

>
>3) what's the more desired behaviour
>
IMO the desired behaviour is the one we have today : as soon as you put 
markup in an <xsp:logic>, you leave Java code to go back to XML content.

>
>4) what will break if we change it
>
Again, IMO nothing's wrong... or maybe our example ;-)

Sylvain




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: XSP bug?

Posted by Torsten Curdt <tc...@dff.st>.
> >Referring to some old C1 documentation http://xml.apache.org/cocoon1/xsp.html
> >(paragraph "logic tags") this should work.
> >And I think this should work the same way in C2!
> >
> You need to open a new <xsp:logic> inside <ns:list> : the scope of Java
> code in <xsp:logic> is limited to text nodes that are its _direct_
>  children. Also, "o.getName()" should be enclosed by an <xsp:expr>. So
> the above snippet should be written as follows :

[snip]

Right.

> So I'm not sure there is a wrong behaviour in the engine.
> Sylvain

If you look at the provided C1 docs this was different before.

So question is:

1) is this still C1 behaviour or is the docu outdate (well, always ;)
2) what says the xsp spec (is there one?)
3) what's the more desired behaviour
4) what will break if we change it

--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: XSP bug?

Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Torsten Curdt wrote:

>Shouldn't the following construct work?
>
> ...
> <tag>
>    <xsp:logic>
>       try {
>
>         <ns:list>
>           Collection list = ...
>
>           for (Iterator iterator = list.iterator(); iterator.hasNext();) {
>             MyObj o = (MyObj) iterator.next();
>
>             <ns:MyObj>
>               <ns:name>o.getName()</ns:name>
>             </ns:MyObj>
>
>           }
>         </ns:list>
>
>       }
>       catch(Exception e) {
>         <xsp:content>Error: <xsp:expr>String.valueOf(e)</xsp:expr></xsp:content>
>       }
>    </xsp:logic>
> </tag>
> ...
>
>Referring to some old C1 documentation http://xml.apache.org/cocoon1/xsp.html
>(paragraph "logic tags") this should work.
>And I think this should work the same way in C2!
>
You need to open a new <xsp:logic> inside <ns:list> : the scope of Java 
code in <xsp:logic> is limited to text nodes that are its _direct_ 
 children. Also, "o.getName()" should be enclosed by an <xsp:expr>. So 
the above snippet should be written as follows :

<tag>
  <xsp:logic>
    try {
      <ns:list>
        <xsp:logic>
          Collection list = ...
          for (Iterator iterator = list.iterator(); iterator.hasNext();) {
            MyObj o = (MyObj) iterator.next();
              <ns:MyObj>
                <ns:name><xsp:expr>o.getName()</xsp:expr></ns:name>
              </ns:MyObj>
          }
        </xsp:logic>
      </ns:list>
    }
    catch(Exception e) {
      <xsp:content>Error: 
<xsp:expr>String.valueOf(e)</xsp:expr></xsp:content>
    }
  </xsp:logic>
</tag>

So I'm not sure there is a wrong behaviour in the engine.
Sylvain

>
>One could use <xsp:element> (like e.g. esql does) to work around this.
>But that's a not quite nice sollution. Can we aggree that this should
>work?
>
>Unfortunately the current implementation will treat any java code
>within a tag inside the xsp logic tag as text nodes - not as java.
>
>If we can aggree that this behaviour is wrong I'd like to change
>the xsp.xsl accordingly.
>--
>Torsten
>



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: XSP bug?

Posted by Torsten Curdt <tc...@dff.st>.
On Thu, 10 Jan 2002, Vadim Gritsenko wrote:

> > From: Torsten Curdt [mailto:tcurdt@dff.st]
> >
> > > <xsp:logic>
> > >    Enumeration e = request.getHeaderNames();
> > >    if ((e != null) && (e.hasMoreElements())) {
> > >     <p>Here are the request headers...
> > >
> > > There is no escaping here! XSP automagically switches from Java to
> > > content once any tag or <xsp:content> is found.
> >
> > Yes... but in C2 only for the first tag! Already found the
> > caveat in the xsp.xsl!
>
> You lost me here! Do you mean second <p> would require <xsp:content>
> inside?

On my way home I realized I did not make myself clear. Too late,
too much work ;) Let's give another try:

The current implementation shows the following behaviour for
text nodes:

  ...
  <p>
    <xsp:logic>
    text nodes are java code - OK
      <p>
        text nodes are copied as text nodes - WRONG?
        in order to write java here you have open
        another xsp:logic tag. (AFAIR that's not how it
        was in C1 - look at the C1 docs)
        <xsp:logic>
          text nodes are java code - OK
        </xsp:logic>
     </p>
   </xsp:logic>
  </p>
  ...

You will get these problems only if you create tags inside
a xsp:logic section and want to write more nested java code. Clear?
So is this behaviour correct or not?

(You might also look at the esql.xsl)

I'd like to have only *ONE* xsp:logic tag meaning all descending text
nodes are java. If you want to switch back to normal processing you have
to use xsp:content to be back in copy mode.

Like this:

  ...
  <p>
    <xsp:logic>
     if (request.getParameter("test")) {
       <p>
         String test = request.getParameter("test");
         <param><xsp:expr>test</xsp:expr></param>

         <xsp:content>
           <info>info text</info>
         </xsp:content>

         // or

         <info><xsp:content>info text</xsp:content></info>

       </p>
     }
    </xsp:logic>

What do you think?


BTW:
I realize that there is also a xsp:text. Can someone please
explain the difference between xsp:text and xsp:content. AFAICS it's
only used inside xsp:attribute. Maybe this supposed to be xsp:content,
too?
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: XSP bug?

Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Torsten Curdt [mailto:tcurdt@dff.st]
> 
> > <xsp:logic>
> >    Enumeration e = request.getHeaderNames();
> >    if ((e != null) && (e.hasMoreElements())) {
> >     <p>Here are the request headers...
> >
> > There is no escaping here! XSP automagically switches from Java to
> > content once any tag or <xsp:content> is found.
> 
> Yes... but in C2 only for the first tag! Already found the
> caveat in the xsp.xsl!

You lost me here! Do you mean second <p> would require <xsp:content>
inside?

Vadim


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: XSP bug?

Posted by Torsten Curdt <tc...@dff.st>.
On Thu, 10 Jan 2002, Vadim Gritsenko wrote:

> > From: Torsten Curdt [mailto:tcurdt@dff.st]
> >
> > On Thu, 10 Jan 2002, Vadim Gritsenko wrote:
> > > >  ...
> > > IIRC, this works.
> >
> > Well, it should... but seems not to...
>
> No, it works.

...only partially

> <snip/>
>
> >  <xsp:logic>
> >    try {
> >      <para>
> >        <xsp:content>This is not a java code, but the document
> > content.</xsp:content>
> >        <xsp:expr>new Date()</xsp:expr>
> >      </para>
> >    ...
> >  </xsp:logic>
> >
> > IIRC that's how it was in the old days?!;)
>
> Please, give me a break! I did not write lots of XSP those days, but I
> do remember that it was not this way. Check this out:
> http://cvs.apache.org/viewcvs.cgi/xml-cocoon/samples/xsp/page.xml?rev=1.
> 5&content-type=text/vnd.viewcvs-markup:
>
> <xsp:logic>
>    Enumeration e = request.getHeaderNames();
>    if ((e != null) && (e.hasMoreElements())) {
>     <p>Here are the request headers...
>
> There is no escaping here! XSP automagically switches from Java to
> content once any tag or <xsp:content> is found.

Yes... but in C2 only for the first tag! Already found the
caveat in the xsp.xsl!

>     </p>
>     <list title="Request Headers">
>
> And that's exactly the reason why xsp:logic is required again to switch
> from content to Java:
>
>      <xsp:logic>
>       while (e.hasMoreElements()) { ... }
>      </xsp:logic>
>     </list>
>    }
>   </xsp:logic>
>
> That's how it was 2 years ago ;P
> (Revision 1.5 , Sat Jan 8 07:19:41 2000 UTC (24 months ago) by Ricardo)
>
>
> > > > If we can aggree that this behaviour is wrong I'd like to change
> > > > the xsp.xsl accordingly.
> > >
> > > I can't right now. May be I just do not get what you are proposing.
> >
> > Hope it is clearer now
>
> Yep. Do you want to patch Cocoon 1 also? ;)

No, I'm comparing C2 to C1. In C1 I remember it was working... (IIRC)
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: XSP bug?

Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Torsten Curdt [mailto:tcurdt@dff.st]
> 
> On Thu, 10 Jan 2002, Vadim Gritsenko wrote:
> > >  ...
> > IIRC, this works.
> 
> Well, it should... but seems not to...

No, it works.

<snip/>

>  <xsp:logic>
>    try {
>      <para>
>        <xsp:content>This is not a java code, but the document
> content.</xsp:content>
>        <xsp:expr>new Date()</xsp:expr>
>      </para>
>    ...
>  </xsp:logic>
> 
> IIRC that's how it was in the old days?!;)

Please, give me a break! I did not write lots of XSP those days, but I
do remember that it was not this way. Check this out:
http://cvs.apache.org/viewcvs.cgi/xml-cocoon/samples/xsp/page.xml?rev=1.
5&content-type=text/vnd.viewcvs-markup:

<xsp:logic>
   Enumeration e = request.getHeaderNames(); 
   if ((e != null) && (e.hasMoreElements())) {
    <p>Here are the request headers...

There is no escaping here! XSP automagically switches from Java to
content once any tag or <xsp:content> is found.

    </p>
    <list title="Request Headers">

And that's exactly the reason why xsp:logic is required again to switch
from content to Java:

     <xsp:logic>
      while (e.hasMoreElements()) { ... }
     </xsp:logic>
    </list>
   }
  </xsp:logic>

That's how it was 2 years ago ;P
(Revision 1.5 , Sat Jan 8 07:19:41 2000 UTC (24 months ago) by Ricardo)


> > > If we can aggree that this behaviour is wrong I'd like to change
> > > the xsp.xsl accordingly.
> >
> > I can't right now. May be I just do not get what you are proposing.
> 
> Hope it is clearer now

Yep. Do you want to patch Cocoon 1 also? ;)

Vadim



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: XSP bug?

Posted by Torsten Curdt <tc...@dff.st>.
On Thu, 10 Jan 2002, Vadim Gritsenko wrote:
> >  ...
> >  <tag>
> >     <xsp:logic>
> >        try {
> >
> >          <ns:list>
>              <xsp:logic>
> >            Collection list = ...
> >
> >            for (Iterator iterator = list.iterator();
> iterator.hasNext();) {
> >              MyObj o = (MyObj) iterator.next();
> >
> >              <ns:MyObj>
>                  <ns:name><xsp:expr>o.getName()</xsp:expr></ns:name>
> >              </ns:MyObj>
> >
> >            }
>              </xsp:logic>
> >          </ns:list>
> >
> >        }
> >        catch(Exception e) {
> >          <xsp:content>Error:
> > <xsp:expr>String.valueOf(e)</xsp:expr></xsp:content>
> >        }
> >     </xsp:logic>
> >  </tag>
> >  ...
>
> IIRC, this works.

Well, it should... but seems not to...

>
>
> > Unfortunately the current implementation will treat any java code
> > within a tag inside the xsp logic tag as text nodes - not as java.
>
> How you propose to rewrite this example:
>
> <xsp:logic>
>   try {
>     <para>
>       This is not a java code, but the document content.
>       <xsp:expr>new Date()</xsp:expr>
>     </para>
>   ...
> </xsp:logic>

 <xsp:logic>
   try {
     <para>
       <xsp:content>This is not a java code, but the document content.</xsp:content>
       <xsp:expr>new Date()</xsp:expr>
     </para>
   ...
 </xsp:logic>

IIRC that's how it was in the old days?!;)

> > If we can aggree that this behaviour is wrong I'd like to change
> > the xsp.xsl accordingly.
>
> I can't right now. May be I just do not get what you are proposing.

Hope it is clearer now
--
Torsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: XSP bug?

Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Torsten Curdt [mailto:tcurdt@dff.st]
> 
> Shouldn't the following construct work?

Do you mean this:

>  ...
>  <tag>
>     <xsp:logic>
>        try {
> 
>          <ns:list>
             <xsp:logic>
>            Collection list = ...
> 
>            for (Iterator iterator = list.iterator();
iterator.hasNext();) {
>              MyObj o = (MyObj) iterator.next();
> 
>              <ns:MyObj>
                 <ns:name><xsp:expr>o.getName()</xsp:expr></ns:name>
>              </ns:MyObj>
> 
>            }
             </xsp:logic>
>          </ns:list>
> 
>        }
>        catch(Exception e) {
>          <xsp:content>Error:
> <xsp:expr>String.valueOf(e)</xsp:expr></xsp:content>
>        }
>     </xsp:logic>
>  </tag>
>  ...

IIRC, this works.


> Unfortunately the current implementation will treat any java code
> within a tag inside the xsp logic tag as text nodes - not as java.

How you propose to rewrite this example:

<xsp:logic>
  try {
    <para>
      This is not a java code, but the document content.
      <xsp:expr>new Date()</xsp:expr>
    </para>
  ...
</xsp:logic>

 
> If we can aggree that this behaviour is wrong I'd like to change
> the xsp.xsl accordingly.

I can't right now. May be I just do not get what you are proposing.

Regards,
Vadim


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org