xml-xsp-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fo...@neonics.com
Subject Re: XSP outside of Cocoon
Date Tue, 12 Mar 2002 22:09:05 GMT

> [...]
> 
> Hey, thanks a lot for the pointers.

np ;) like to help..

> > You can easily implement it yourself, as I did. I use it for two things:
> > 1) a lightweight Cocoon called NeoServ which only has the features I need,
> > consisting of only 7 java files.
> 
> It does not happen to be available under some kind of OpenSource
> license? :)

I'm not sure yet ;) I need to write a lot of documentation (unless people
are smart enough to learn by example) before I can release it ;)
Just check www.neonics.com in a while. Still working on it.. it runs on
NeoServ.

If you're interested I can give you a simple example site, running
(almost)
out of the box ;)

(need to build it first though ;))

> > <xsl:template match="*">
> > 
> >   <!-- the next line processes attributes first. You also
> >        need to define a template matching attributes -->
> >   <xsl:apply-templates select="@*"/>
> > 
> >   contenthandler.startElement(
> >       "<xsl:value-of select="namespace-uri(.)"/>",
> >       "<xsl:value-of select="local-name(.)"/>",
> >       "<xsl:value-of select="name(.)"/>,
> >       xspattr
> >   );
> 
> This looks a bit weird, a stylesheet where you mix XML and Java without
> surrounding tags?

Yes, it does, doesn't it? ;)  

This stylesheet does not generate XML, but plaintext (java sourcecode).
You should find the xsp.xsl in your cocoon source distribution (or unjar
the jar) and look at it. (very ugly but it works ;))

The above is not an example of an xsp page, but the final xml-to-java
stylesheet.

So it generates a pure text file. In fact, a complete java class..

> > This generates java code that creates SAX events for each node it finds.
> > Easy huh?
> 
> Yeah, looks easy enough, only that I don't understand who can process
> such a mixture of XSLT and Java.

Hope this issue is resolved now..

Let me give you one more example:

1) INPUT XML:

<?xml version="1.0"?>

  <xsp:page>
     <mytag> Hello there </mytag>
     <paragraph> It is now <mytaglib:time-of-day/>. </paragraph>
  </xsp:page>


2: XSP LOGICSHEET

<!-- blah blah default <?xml header and <xsl:stylesheet -->

  <xsl:template match="xsp:page">
    <xsp:page>
      <xsp:structure> <!-- defined this myself (identical to cocoon) to
				give the programmer a place for include's
		        -->

         <xsp:include>my.package.*</xsp:include>
      </xsp:structure>

      <xsp:logic>
          String getTimeOfDay() {
            // some java code that returns a string like HH:MM
          }
      </xsp:logic>

      <xsl:apply-templates/>  <!-- preserve/copy the rest of the content
				   below the 'xsp:page' tag in the source
				   XML document -->

   </xsp:page>
 </xsl:template>

<!-- the above just takes the original xml document, and replaces the
     xsp:page tag with the above, and adding the original content.
     So it just adds the xsp:structure and xsp:logic (with the
     getTimeOfDay() method) to the original document.
-->

 <xsl:template match="mylib:time-of-day">
   <xsp:expr>getTimeOfDay()</xsp:expr>
 </xsl:template>


<!-- and some more templates, like the identity operator (copy the rest
     of the nodes/attributes -->

</xsl:transformation>


-------------

If we would run the stylesheet in step 2 on the document in step 1
we would get the following result:

3)

<xsp:page>
  <xsp:structure>
    <xsp:include>my.lib.*</xsp:include>
  </xsp:structure>

  <xsp:logic>
    String getTimeOfDay() {
        // ...
    }
  </xsp:logic>


  <mytag> Hello there </mytag>
  <paragraph> It's now <xsp:expr>getTimeOfDay()</xsp:expr>.</paragraph>
</xsp:page>


Got it till this far?

4) THE xsp.xsl WHICH TRANSFORMS THE DOCUMENT IN STEP 3 TO JAVA CODE

  just look at the example code i gave you in my previous mail.. or
look at the xsp.xsl from cocoon.


5) THE RESULT AFTER STYLESHEET 4 WAS RUN ON INTERMEDIATE RESULT 3

  import my.package.*;

  String getTimeOfDay() {
    // some code
  }

  contenthandler.startElement("mytag");
  contenthandler.charachters(" Hello there ");
  contenthandler.endElement("mytag");

  contenthandler.startElement("paragraph");
  contenthandler.characters("It's now ");
  parent.xspExpr( getTimeOfDay() );   // parses the output from the
				      // function as xml and calls
				      // contenthandler.characters(...)
  contenthandler.characters(".");
  contenthandler.endElement("paragraph");


--------

This is nowhere near complete, since this is not a valid java sourcecode.


In step 4, the xsp.xsl, there are a few things:

a) a template that just copies the content from xsp:logic tags, thereby
   removing the xsp:logic.
b) replaces <xsp:expr>SOMETHING</xsp:expr>  with  xspExpr(SOMETHING);
   where xspExpr is a method in the parent class (the current class
   is the java class we're generating, which extends some default
   class).
c) a template to change <xsp:include>SOMETHING</xsp:include> into
   import SOMETHING;
d) a template that converts all other (non- xsp:) tags to
   contenthandler.startElement(....) and .endElement code.
e) a template that matches the root tag (in our case always xsp:page)
   that has a default class body, something like:

    <xsl:template match="xsp:page">
      // xsl code to run the template on the xsp:include tags
   
      public class {CLASS} extends ParentClass {

	// xsl template-call that runs the xsp:page.xsp:logic[1] 
	// (the first xsp:logic in xsp:page)
	//as to generate the method's like getTimeOfDay()

	public void parse() {
          // xsl-code to apply all other templates (to replace
          // xsp:logic/xsp:expr/other tags as described above)
        }        

      }
    </xsl:template>



phew.. way to much typing again ;)


> > Hope this info is enough to get you started.
> > 
> > And... you don't need cocoon to do this!
> > in fact, I suggest you don't ;)
> 
> Well, that is my plan. In our company we are presently having somewhat
> of a strategic discussion on how we want to build frontends (for the
> backends we already made the decision for Avalon/Phoenix). Presently we
> have several Swing GUIs out there and several HTML GUIs served by
> Cocoon1 and both GUIs do very similar things. I found that the largest
> benefit of Cocoon1 is that I can develop new applications and new
> features for old applications much faster, whereas a real Java
> application with a Swing GUI is easier to use and debug. If the
> strategic decision goes in favor of web applications, then maybe I can
> develop the thing we're talking about on company time :)

hehe :)

Well, you can also generate the Swing components if you want to. You
then need to edit the final xsl, to not produce SAX events (since you
cannot runtime edit sax events into swing-java-code (at least not very
fast), but to generate a java file that is your final goal.

For that, you need to know what the dynamic content is.. I've been
thinking
about this too for a while, so I can easily generate sourcecode for java
or for windows, using the same input files..

 
> Cocoon2 moves into a direction, where it tries to do more and more, the
> developer loses some freedom and gains some power, but the power tends
> to have an adverse effect on usability and maintainability. So I am
> thinking to go from Cocoon1 not to Cocoon2, but to Cocoon0 ;-)

Indeed ;)

However, cocoon 2 is a lot faster, since it uses the SAX events as I
described above. It uses a complete different core, also removing the
stylesheet-directives from the xml files and moving it into a 'sitemap',
which defines what needs to be done when some url is requested.

Just read my section on www.neonics.com (click on projects, then on
NeoServ). THe site doesn't work completely (the downloads are broken), but
the summary of each project should have enough information about
the global functionality..

> Again, thanks for your help,

again, np ;)




Mime
View raw message