You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Zvi <th...@ifrance.com> on 2000/05/02 02:57:04 UTC
Additions to XSP util:* taglib
Hi,
I wrote XSP taglib like <xsl:for-each>, <xsl:if>, <xsl:case>,
<xsl:when>, <xsl:oherwise>.
And I proposing to add them to Cocoon standard util:* taglib.
What do you think, guys?
Zvi
Re: Additions to XSP util:* taglib
Posted by Stefano Mazzocchi <st...@apache.org>.
Ulrich Mayring wrote:
> Plus, you have a whole slew of additional options by doing clever things
> with PIs. This point will hopefully be fixed by the Sitemap, but right
> now cocoon is too confusing for me. We should have more structure for
> document authors.
You're totally right and we are not hiding this.
I hope the sitemap will bring more structured vision of your site. This
is why I believe Cocoon2 will be far superior by design...
... but still not perfect.
We know that XSP overlaps with both JSP and XSLT. Some believe that XSP
is actually completely rewritable using XSLT with extentions.... but we
have to wait for XSLT 1.1 for that.
The future will tell how to integrate more.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: Additions to XSP util:* taglib
Posted by Ulrich Mayring <ul...@denic.de>.
Zvi wrote:
>
> 2. Much less verbose, than writing many times <xsp:logic> tags with
You are dead right. Of course the cleanest thing would be if we
integrated XSP and XSLT in a better way (I don't know how). But right
now we have three different documents, the XML, the XSP and the XSLT
document - and this leads to confusion at times, especially since an XSP
file can also be an XSLT stylesheet at the same time.
I'm not sure if you guys understand what I mean. The thing is that
syntactically everything the document authors write is XML. But
semantically there is:
- "plain XML", i.e. a document describing data and nothing else
- "XSPish XML", i.e. a document describing data and doing some
computation - perhaps altering/adding data or even doing things totally
unrelated to the data
- "XSLTish XML", i.e. a document transforming XML into whatever.
- "XSPish XSLT XML", i.e. a document containing data, doing some
computation and doing some XML transformation
Plus, you have a whole slew of additional options by doing clever things
with PIs. This point will hopefully be fixed by the Sitemap, but right
now cocoon is too confusing for me. We should have more structure for
document authors.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: Additions to XSP util:* taglib
Posted by Zvi <th...@ifrance.com>.
and my last argument:
I think we need to make XSP much more similar to XSLT, this will allow easy
migration from XSP to EXSLT in the future.
In fact some people think, that XSP is just compiled variant of XSLT Literal
Result Element ...
For example, I would like to have implemented {xxx} inside attributes in XSP,
instead of using <xsp:attribute> tag.
This will be much less verbose.
Ricardo, any hints how to implement this?
Zvi
Zvi wrote:
> Kevin,
>
> I like it for 2 reasons:
> 1. Target langauge independent (doesn't mutter Java/JS/C/C++/Perl/TCL
> etc...)
> For example: I can write:
>
> <util:case>
> <util:when test="a!=b">
> A!=B
> </util:when>
> <util:otherwise>
> A==B
> </util:otherwise>
> </util:case>
>
> and then XSP will compile it to Java
> then if I'll want to switch to JavaScript or C++ :), then I need only to
> write new logicsheet ...
>
> 2. Much less verbose, than writing many times <xsp:logic> tags with
> <[CDATA[ ... ]]> inside :)
> compare between:
>
> <util:if test="a > b">
> <h1>A greater than B!</h1>
> </util:if>
>
> and
>
> <xsp:logic>
> <[CDATA[
> if(a>b){
> ]]>
> </xsp:logic>
> <h1>A greater than B!</h1>
> <xsp:logic>
> }
> </xsp:logic>
>
> Zvi
>
> "Kevin A. Burton" wrote:
>
> > Zvi wrote:
> > >
> > > Hi,
> > >
> > > I wrote XSP taglib like <xsl:for-each>, <xsl:if>, <xsl:case>,
> > > <xsl:when>, <xsl:oherwise>.
> > > And I proposing to add them to Cocoon standard util:* taglib.
> >
> > I would say -0.
> >
> > Although I am sure it is awesome code. The XSL <xsl:for-each> etc code
> > is really only added because there is no XSL native language. With XSP
> > we can use Java/JavaScript/etc. So it seems like this might just be
> > redundant.
> >
> > KEvin
> >
> > --
> > Kevin A Burton (burton@apache.org)
> > http://relativity.yi.org
> > Message to SUN: "Please Open Source Java!"
> > "For evil to win is for good men to do nothing."
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> > For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: Additions to XSP util:* taglib
Posted by Zvi <th...@ifrance.com>.
Kevin,
I like it for 2 reasons:
1. Target langauge independent (doesn't mutter Java/JS/C/C++/Perl/TCL
etc...)
For example: I can write:
<util:case>
<util:when test="a!=b">
A!=B
</util:when>
<util:otherwise>
A==B
</util:otherwise>
</util:case>
and then XSP will compile it to Java
then if I'll want to switch to JavaScript or C++ :), then I need only to
write new logicsheet ...
2. Much less verbose, than writing many times <xsp:logic> tags with
<[CDATA[ ... ]]> inside :)
compare between:
<util:if test="a > b">
<h1>A greater than B!</h1>
</util:if>
and
<xsp:logic>
<[CDATA[
if(a>b){
]]>
</xsp:logic>
<h1>A greater than B!</h1>
<xsp:logic>
}
</xsp:logic>
Zvi
"Kevin A. Burton" wrote:
> Zvi wrote:
> >
> > Hi,
> >
> > I wrote XSP taglib like <xsl:for-each>, <xsl:if>, <xsl:case>,
> > <xsl:when>, <xsl:oherwise>.
> > And I proposing to add them to Cocoon standard util:* taglib.
>
> I would say -0.
>
> Although I am sure it is awesome code. The XSL <xsl:for-each> etc code
> is really only added because there is no XSL native language. With XSP
> we can use Java/JavaScript/etc. So it seems like this might just be
> redundant.
>
> KEvin
>
> --
> Kevin A Burton (burton@apache.org)
> http://relativity.yi.org
> Message to SUN: "Please Open Source Java!"
> "For evil to win is for good men to do nothing."
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
Re: Additions to XSP util:* taglib
Posted by "Kevin A. Burton" <bu...@relativity.yi.org>.
Zvi wrote:
>
> Hi,
>
> I wrote XSP taglib like <xsl:for-each>, <xsl:if>, <xsl:case>,
> <xsl:when>, <xsl:oherwise>.
> And I proposing to add them to Cocoon standard util:* taglib.
I would say -0.
Although I am sure it is awesome code. The XSL <xsl:for-each> etc code
is really only added because there is no XSL native language. With XSP
we can use Java/JavaScript/etc. So it seems like this might just be
redundant.
KEvin
--
Kevin A Burton (burton@apache.org)
http://relativity.yi.org
Message to SUN: "Please Open Source Java!"
"For evil to win is for good men to do nothing."
Re: Integration with BEA WebLogic application server
Posted by Niclas Hedhman <ni...@localbar.com>.
Joshua Van Buren wrote:
> I am currently integrating Cocoon 1.7.2 with Weblogic 5.1 on Windows 2k. I
> am running into a couple of problems with ClassCircularityError exceptions.
> It seems to be breaking at the cl.ClassLoader call in
> cocoon.framework.manager.java
>
> Has anyone seen this before?
public class A extends B
{}
public class B extends A
{}
will give you this result. That however, should be captured by the compiler,
and not in runtime unless the class hierarchy has changed between compiles of
different classes. I would believe you have naming interference between
classes, and/or versioning problems.
Niclas
Integration with BEA WebLogic application server
Posted by Joshua Van Buren <jv...@vanteon.com>.
I am currently integrating Cocoon 1.7.2 with Weblogic 5.1 on Windows 2k. I
am running into a couple of problems with ClassCircularityError exceptions.
It seems to be breaking at the cl.ClassLoader call in
cocoon.framework.manager.java
Has anyone seen this before?
Thanks,
Josh
Integration with BEA WebLogic application server
Posted by Joshua Van Buren <jv...@vanteon.com>.
I am currently integrating Cocoon 1.7.2 with Weblogic 5.1 on Windows 2k. I
am running into a couple of problems with ClassCircularityError exceptions.
It seems to be breaking at the cl.ClassLoader call in
cocoon.framework.manager.java
Has anyone seen this before?
Thanks,
Josh