You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Dave Jarvis <da...@joot.com> on 2001/11/16 08:39:59 UTC

BOX: Business-Oriented XML

Hello,

Using Tomcat, Xalan, Xerces, and Java-based technologies, I have
developed a system that completely decouples presentation from business
logic.  I would like to discuss the system and the possibility of adding
it to the technologies offered by the Apache Foundation.  Please find a
brief architectural overview of the system online at the following
address:

	http://www.joot.com/box/

For a more technical system description, please read the following page:

	http://www.joot.com/dave/writings/articles/bsp/

I look forward to your comments, critiques, and questions.

Sincerely,
Dave Jarvis

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: BOX: Business-Oriented XML

Posted by Peter Donald <do...@apache.org>.
Hi,

You should read 

http://jakarta.apache.org/site/newproject.html

Essentially your project needs to have a community of developers already 
associated with it and ideally it should have a PMC member who is willing to 
champion the project. While projects can flourish under jakarta it is epected 
that the project would be a success outside of jakarta aswell. 

It doesn't seem like this project satisfies the basic requirements. You may 
want to see if there is any interest in developing it under commons project. 


Another idea would be to make contact with members of Cocoon project at 
xml.apache.org because it seems that in many ways your architecture is 
similar to theirs.

On Fri, 16 Nov 2001 18:39, Dave Jarvis wrote:
> Hello,
>
> Using Tomcat, Xalan, Xerces, and Java-based technologies, I have
> developed a system that completely decouples presentation from business
> logic.  I would like to discuss the system and the possibility of adding
> it to the technologies offered by the Apache Foundation.  Please find a
> brief architectural overview of the system online at the following
> address:
>
> 	http://www.joot.com/box/
>
> For a more technical system description, please read the following page:
>
> 	http://www.joot.com/dave/writings/articles/bsp/
>
> I look forward to your comments, critiques, and questions.
>
> Sincerely,
> Dave Jarvis

-- 
Cheers,

Pete

----------------------------------------------------------
Which is worse: Ignorance or Apathy? Who knows? Who cares?
----------------------------------------------------------

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Business-Oriented XML

Posted by Davanum Srinivas <di...@yahoo.com>.
Dave,

Please move this discussion over to cocoon-dev mailing list if you really want good feedback. You
will find that the people over there are quite ready to accept new concepts, criticism, patches,
contributions etc :)

Thanks,
dims

--- Jeff Turner <je...@socialchange.net.au> wrote:
> On Fri, Nov 16, 2001 at 08:58:06PM -0800, Dave Jarvis wrote:
> > Hello, again.
> > 
> > Neeme Praks wrote:
> > > Have you ever had a look at Apache Cocoon project? That achieves all the
> > 
> > Yes.
> > 
> > > benefits you outlined in your paper plus more.
> > 
> > Here are a few items BOX addresses that Cocoon does not (as far as I can
> > discern; please correct my errors):
> > 
> > 	o doesn't provide an inherent state-based architecture (it's an aside,
> > not focus)
> 
> Nope, they threw out the "reactor" (state machine) pattern as being too
> hard to manage.
> 
> > 	o doesn't automatically apply a different view of logic based on the
> > domain
> 
> Certainly can :) Have a look at Cocoon 2's class
> org.apache.cocoon.selection.HostSelector.
> 
> > 	o extremely complex; it mixes multiple languages and odd syntax (e.g.,
> > &connectDatabase)
> 
> That's just your particular XSP, which uses an XML entity
> "&connectDatabase;" to pull in other XSP. If you put your logic in
> logicsheets as intended, then your XSP pages are pure XML.
> 
> > 	o makes it easy to couple presentation and logic (see below)
> 
> Actually, XSP makes it easy to mix *content* and logic (presentation is
> in XSLs).
> 
> > 	o lacks an integrated expression parser
> > 	o doesn't expose a consistent syntax for doing tasks such as:
> > 		- file I/O
> > 		- sending XML to remote servers
> 
> Have a look at Cocoon 2's xscript SOAP demo (xscript being an XSP
> equivalent of James Strachan's xtags taglib).
> 
> > 		- calling native code (Java, C, Perl, etc.)
> > 		- SQL statements
> > 	o cookies, FORM parameters, and URL encoded variables are not treated
> > uniformly
> > 	o doesn't use plain XML (i.e., embeds other language source directly)
> 
> Anyway, if you've got time, hop on cocoon-dev.. I'm sure there's much
> mutual learning to be had (it's a fun place to lurk anyway). Cocoon 2
> has a very generic architecture, and I've no doubt that your code could
> be integrated as an XSP alternative.
> 
> 
> --Jeff
> 
> ---------------------------------------------------------------------
> In case of troubles, e-mail:     webmaster@xml.apache.org
> To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org
> 


=====
Davanum Srinivas - http://jguru.com/dims/

__________________________________________________
Do You Yahoo!?
Find the one for you at Yahoo! Personals
http://personals.yahoo.com

---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org


Re: Business-Oriented XML

Posted by Davanum Srinivas <di...@yahoo.com>.
Dave,

Please move this discussion over to cocoon-dev mailing list if you really want good feedback. You
will find that the people over there are quite ready to accept new concepts, criticism, patches,
contributions etc :)

Thanks,
dims

--- Jeff Turner <je...@socialchange.net.au> wrote:
> On Fri, Nov 16, 2001 at 08:58:06PM -0800, Dave Jarvis wrote:
> > Hello, again.
> > 
> > Neeme Praks wrote:
> > > Have you ever had a look at Apache Cocoon project? That achieves all the
> > 
> > Yes.
> > 
> > > benefits you outlined in your paper plus more.
> > 
> > Here are a few items BOX addresses that Cocoon does not (as far as I can
> > discern; please correct my errors):
> > 
> > 	o doesn't provide an inherent state-based architecture (it's an aside,
> > not focus)
> 
> Nope, they threw out the "reactor" (state machine) pattern as being too
> hard to manage.
> 
> > 	o doesn't automatically apply a different view of logic based on the
> > domain
> 
> Certainly can :) Have a look at Cocoon 2's class
> org.apache.cocoon.selection.HostSelector.
> 
> > 	o extremely complex; it mixes multiple languages and odd syntax (e.g.,
> > &connectDatabase)
> 
> That's just your particular XSP, which uses an XML entity
> "&connectDatabase;" to pull in other XSP. If you put your logic in
> logicsheets as intended, then your XSP pages are pure XML.
> 
> > 	o makes it easy to couple presentation and logic (see below)
> 
> Actually, XSP makes it easy to mix *content* and logic (presentation is
> in XSLs).
> 
> > 	o lacks an integrated expression parser
> > 	o doesn't expose a consistent syntax for doing tasks such as:
> > 		- file I/O
> > 		- sending XML to remote servers
> 
> Have a look at Cocoon 2's xscript SOAP demo (xscript being an XSP
> equivalent of James Strachan's xtags taglib).
> 
> > 		- calling native code (Java, C, Perl, etc.)
> > 		- SQL statements
> > 	o cookies, FORM parameters, and URL encoded variables are not treated
> > uniformly
> > 	o doesn't use plain XML (i.e., embeds other language source directly)
> 
> Anyway, if you've got time, hop on cocoon-dev.. I'm sure there's much
> mutual learning to be had (it's a fun place to lurk anyway). Cocoon 2
> has a very generic architecture, and I've no doubt that your code could
> be integrated as an XSP alternative.
> 
> 
> --Jeff
> 
> ---------------------------------------------------------------------
> In case of troubles, e-mail:     webmaster@xml.apache.org
> To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org
> 


=====
Davanum Srinivas - http://jguru.com/dims/

__________________________________________________
Do You Yahoo!?
Find the one for you at Yahoo! Personals
http://personals.yahoo.com

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


Re: Business-Oriented XML

Posted by Davanum Srinivas <di...@yahoo.com>.
Dave,

Please move this discussion over to cocoon-dev mailing list if you really want good feedback. You
will find that the people over there are quite ready to accept new concepts, criticism, patches,
contributions etc :)

Thanks,
dims

--- Jeff Turner <je...@socialchange.net.au> wrote:
> On Fri, Nov 16, 2001 at 08:58:06PM -0800, Dave Jarvis wrote:
> > Hello, again.
> > 
> > Neeme Praks wrote:
> > > Have you ever had a look at Apache Cocoon project? That achieves all the
> > 
> > Yes.
> > 
> > > benefits you outlined in your paper plus more.
> > 
> > Here are a few items BOX addresses that Cocoon does not (as far as I can
> > discern; please correct my errors):
> > 
> > 	o doesn't provide an inherent state-based architecture (it's an aside,
> > not focus)
> 
> Nope, they threw out the "reactor" (state machine) pattern as being too
> hard to manage.
> 
> > 	o doesn't automatically apply a different view of logic based on the
> > domain
> 
> Certainly can :) Have a look at Cocoon 2's class
> org.apache.cocoon.selection.HostSelector.
> 
> > 	o extremely complex; it mixes multiple languages and odd syntax (e.g.,
> > &connectDatabase)
> 
> That's just your particular XSP, which uses an XML entity
> "&connectDatabase;" to pull in other XSP. If you put your logic in
> logicsheets as intended, then your XSP pages are pure XML.
> 
> > 	o makes it easy to couple presentation and logic (see below)
> 
> Actually, XSP makes it easy to mix *content* and logic (presentation is
> in XSLs).
> 
> > 	o lacks an integrated expression parser
> > 	o doesn't expose a consistent syntax for doing tasks such as:
> > 		- file I/O
> > 		- sending XML to remote servers
> 
> Have a look at Cocoon 2's xscript SOAP demo (xscript being an XSP
> equivalent of James Strachan's xtags taglib).
> 
> > 		- calling native code (Java, C, Perl, etc.)
> > 		- SQL statements
> > 	o cookies, FORM parameters, and URL encoded variables are not treated
> > uniformly
> > 	o doesn't use plain XML (i.e., embeds other language source directly)
> 
> Anyway, if you've got time, hop on cocoon-dev.. I'm sure there's much
> mutual learning to be had (it's a fun place to lurk anyway). Cocoon 2
> has a very generic architecture, and I've no doubt that your code could
> be integrated as an XSP alternative.
> 
> 
> --Jeff
> 
> ---------------------------------------------------------------------
> In case of troubles, e-mail:     webmaster@xml.apache.org
> To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org
> 


=====
Davanum Srinivas - http://jguru.com/dims/

__________________________________________________
Do You Yahoo!?
Find the one for you at Yahoo! Personals
http://personals.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Business-Oriented XML

Posted by Jeff Turner <je...@socialchange.net.au>.
On Fri, Nov 16, 2001 at 08:58:06PM -0800, Dave Jarvis wrote:
> Hello, again.
> 
> Neeme Praks wrote:
> > Have you ever had a look at Apache Cocoon project? That achieves all the
> 
> Yes.
> 
> > benefits you outlined in your paper plus more.
> 
> Here are a few items BOX addresses that Cocoon does not (as far as I can
> discern; please correct my errors):
> 
> 	o doesn't provide an inherent state-based architecture (it's an aside,
> not focus)

Nope, they threw out the "reactor" (state machine) pattern as being too
hard to manage.

> 	o doesn't automatically apply a different view of logic based on the
> domain

Certainly can :) Have a look at Cocoon 2's class
org.apache.cocoon.selection.HostSelector.

> 	o extremely complex; it mixes multiple languages and odd syntax (e.g.,
> &connectDatabase)

That's just your particular XSP, which uses an XML entity
"&connectDatabase;" to pull in other XSP. If you put your logic in
logicsheets as intended, then your XSP pages are pure XML.

> 	o makes it easy to couple presentation and logic (see below)

Actually, XSP makes it easy to mix *content* and logic (presentation is
in XSLs).

> 	o lacks an integrated expression parser
> 	o doesn't expose a consistent syntax for doing tasks such as:
> 		- file I/O
> 		- sending XML to remote servers

Have a look at Cocoon 2's xscript SOAP demo (xscript being an XSP
equivalent of James Strachan's xtags taglib).

> 		- calling native code (Java, C, Perl, etc.)
> 		- SQL statements
> 	o cookies, FORM parameters, and URL encoded variables are not treated
> uniformly
> 	o doesn't use plain XML (i.e., embeds other language source directly)

Anyway, if you've got time, hop on cocoon-dev.. I'm sure there's much
mutual learning to be had (it's a fun place to lurk anyway). Cocoon 2
has a very generic architecture, and I've no doubt that your code could
be integrated as an XSP alternative.


--Jeff

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Business-Oriented XML

Posted by Jeff Turner <je...@socialchange.net.au>.
On Fri, Nov 16, 2001 at 08:58:06PM -0800, Dave Jarvis wrote:
> Hello, again.
> 
> Neeme Praks wrote:
> > Have you ever had a look at Apache Cocoon project? That achieves all the
> 
> Yes.
> 
> > benefits you outlined in your paper plus more.
> 
> Here are a few items BOX addresses that Cocoon does not (as far as I can
> discern; please correct my errors):
> 
> 	o doesn't provide an inherent state-based architecture (it's an aside,
> not focus)

Nope, they threw out the "reactor" (state machine) pattern as being too
hard to manage.

> 	o doesn't automatically apply a different view of logic based on the
> domain

Certainly can :) Have a look at Cocoon 2's class
org.apache.cocoon.selection.HostSelector.

> 	o extremely complex; it mixes multiple languages and odd syntax (e.g.,
> &connectDatabase)

That's just your particular XSP, which uses an XML entity
"&connectDatabase;" to pull in other XSP. If you put your logic in
logicsheets as intended, then your XSP pages are pure XML.

> 	o makes it easy to couple presentation and logic (see below)

Actually, XSP makes it easy to mix *content* and logic (presentation is
in XSLs).

> 	o lacks an integrated expression parser
> 	o doesn't expose a consistent syntax for doing tasks such as:
> 		- file I/O
> 		- sending XML to remote servers

Have a look at Cocoon 2's xscript SOAP demo (xscript being an XSP
equivalent of James Strachan's xtags taglib).

> 		- calling native code (Java, C, Perl, etc.)
> 		- SQL statements
> 	o cookies, FORM parameters, and URL encoded variables are not treated
> uniformly
> 	o doesn't use plain XML (i.e., embeds other language source directly)

Anyway, if you've got time, hop on cocoon-dev.. I'm sure there's much
mutual learning to be had (it's a fun place to lurk anyway). Cocoon 2
has a very generic architecture, and I've no doubt that your code could
be integrated as an XSP alternative.


--Jeff

---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org


Re: Business-Oriented XML

Posted by Dave Jarvis <da...@joot.com>.
Hi, Jon.

> Why the heck would you want to do this anyway? You have to be nuts to write

To begin with, it is a very simple stepping stone for moving old systems
that don't scale well (e.g., FoxPro) to one that does.  The system I'm
working with has hundreds of tables, some with tens of thousands of
rows, others with over thirty million; not hand-coding the SQL is out of
the question.

> SQL by hand anymore and why would you want to embed it into your code
> anyway?

Embedding the SQL in this fashion creates a tight modular unit that
performs one piece of the entire site's functionality.  For example,
consider logging in: a relatively simple task.  The user enters their
e-mail address and password using an HTML form.  To verify that they got
it correct, one would write:

[File: /logic/Login/main.xml]
<?xml version="1.0"?>
<businessLogic>
<main>
<sql>
  <select>* FROM USERS WHERE EMAIL=? AND PASSWORD=?</select>
  <using>
    <value-of expr="$email"/>
    <value-of expr="$password"/>
  </using>
  <container name="results"/>
</sql>
<if test="!@results">
  <redirect expr="'http://www.yahoo.com'"/>
</if>
</main>
</businessLogic>

In this fashion, no other part of the system needs to know how the login
functionality works.  Also, since the code is interpreted, you can
change the SQL as required while the system is running.

How would you write the following functionality:  A web page is
presented to the user with an HTML FORM composed of two TEXT INPUT boxes
(named email and password; with no hidden fields).  They fill in their
information and now the system must verify it -- simply, easily, and
quickly.  Please show me a simpler means to perform this task.  Once
that's done, please make the solution platform, language, and database
neutral.

> You guys have totally lost touch with simple concepts like 'MVC'...

The Database is the Model.
The Logic is the Controller.
The XSL is the View.

I fail to see what I'm missing.  Please enlighten me!

Sincerely,
Dave Jarvis

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Business-Oriented XML

Posted by Jon Stevens <jo...@latchkey.com>.
on 11/16/01 8:58 PM, "Dave Jarvis" <da...@joot.com> wrote:

>   <sql>
>     <select>
>       * FROM WIC.FOURNIS
>       WHERE COD_CLIENT=?
>       ORDER BY NOM_FOURNIS
>     </select>
>     <using>
>       <value-of expr="#WIC_CLIENT"/>
>     </using>
>     <container name="results"/>
>   </sql>

Why the heck would you want to do this anyway? You have to be nuts to write
SQL by hand anymore and why would you want to embed it into your code
anyway?

You guys have totally lost touch with simple concepts like 'MVC'...

Ewww...

-jon


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Business-Oriented XML

Posted by Dave Jarvis <da...@joot.com>.
Hello, again.

Neeme Praks wrote:
> Have you ever had a look at Apache Cocoon project? That achieves all the

Yes.

> benefits you outlined in your paper plus more.

Here are a few items BOX addresses that Cocoon does not (as far as I can
discern; please correct my errors):

	o doesn't provide an inherent state-based architecture (it's an aside,
not focus)
	o doesn't automatically apply a different view of logic based on the
domain
	o extremely complex; it mixes multiple languages and odd syntax (e.g.,
&connectDatabase)
	o makes it easy to couple presentation and logic (see below)
	o lacks an integrated expression parser
	o doesn't expose a consistent syntax for doing tasks such as:
		- file I/O
		- sending XML to remote servers
		- calling native code (Java, C, Perl, etc.)
		- SQL statements
	o cookies, FORM parameters, and URL encoded variables are not treated
uniformly
	o doesn't use plain XML (i.e., embeds other language source directly)

If there's interest, I would be more than happy to illustrate a full
cycle of data acquisition (via HTML FORM) to SQL deposit, retrieval, and
final HTML page.  For those who enjoy gory details, I've made a brief
comparison of Cocoon and BOX for two very simple examples.  The first is
a little counter program, the second shows how to do SQL in both
tongues.

Sincerely,
Dave Jarvis

-=( First Example )=-

 ]] Cocoon's Logic (18 lines of code; tied to Java) [[
 <?xml version="1.0"?>
 <?cocoon-process type="xsp"?>
 <?cocoon-process type="xslt"?>
 <?xml-stylesheet href="page-html.xsl" type="text/xsl"?>

 <xsp:page language="java"
xmlns:xsp="http://www.apache.org/1999/XSP/Core">
 <xsp:logic>
 static private int counter = 0;

 private synchronized int count() {
 return counter++;
 }
 </xsp:logic>

 <page>
 <p>I've been requested <xsp:expr>count()</xsp:expr> times.</p>
 </page>
 </xsp:page>

 ]] Cocoon's XSP (6 lines of generated code) [[
 <?xml version="1.0"?>
 <?cocoon-process type="xslt"?>
 <?xml-stylesheet href="page-html.xsl" type="text/xsl"?>
 <page>
 <p>I've been requested 0 times.</p>
 </page>

 ]] Cocoon's XSL (10 lines of code) [[
 <?xml version="1.0"?>
 <xsl:stylesheet>
 <xsl:output method="html" encoding="US-ASCII"/>

 <xsl:template match="page">
   <xsl:apply-templates/>
 </xsl:template>

 <xsl:template match="p">
   <xsl:apply-templates/>
 </xsl:template>
 </xsl:stylesheet>

BOX code, in my opinion, is much simpler and straightforward, as there
is no intermediary XSP page:

 ]] BOX's Logic (7 lines of code; tied to XML) [[
 <?xml version="1.0"?>
 <businessLogic>
   <main>
     <session name="count" expr="#count + 1"/>
     <tag name="count" expr="#count"/>
   </main>
 </businessLogic>

 ]] BOX's XML (4 lines of generated code) [[
 <?xml version="1.0"?>
 <document>
   <count>0</count>
 </document>

 ]] BOX's XSL (7 lines of code) [[
 <?xml version="1.0"?>
 <xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 <xsl:output method="html" encoding="US-ASCII"/>

 <xsl:template match="document">
   <P>I've been requested <xsl:value-of select="count"/> times.</P>
 </xsl:template>

 </xsl:stylesheet>

By adding "<babel>" tags around the English text, you automatically get
a stylesheet that is in the viewer's language (based on their browser's
Accept-Language).  This is part of the architecture; no extra futzing is
required.  BOX makes it difficult to couple logic and presentation.  For
example, to write a "<p>" tag with logic, you must write <tag
name="p"/>.  XSL is where the <p> tag belongs; not snuggled in with
logic.

Let's look at a slightly more complex example, involving SQL.  First
Cocoon, then BOX.

-=( Second Example )=-

]] Cocoon Logic (20 lines of code) [[
<?xml version="1.0" encoding='ISO-8859-1' standalone="no"?>
<?xml-stylesheet href="../xsl/wic_fournisseursListe.xsl"
type="text/xsl"?>
<?cocoon-process type="xsp"?>
<?cocoon-process type="xslt"?>
<!DOCTYPE page SYSTEM "./librairies/entity.dtd">
<xsp:page
   language="java"
   xmlns:xsp="http://www.apache.org/1999/XSP/Core"
   xmlns:session="http://www.apache.org/1999/XSP/Session"
   xmlns:request="http://www.apache.org/1999/XSP/Request"
   xmlns:response="http://www.apache.org/1999/XSP/Response"
   xmlns:sql="http://www.apache.org/1999/SQL"
   xmlns:log="http://www.arctis.com/2000/XSP/Log"
   create-session="true">
<page title="Liste des fournisseurs">
<xsp:logic>
  try {
    <sql:execute-query>
    &connectDatabase;
    <sql:doc-element>FOURNISSEURS</sql:doc-element>
    <sql:row-element>FOURNISSEUR</sql:row-element>
    <sql:query>
      SELECT * FROM WIC.FOURNIS
      WHERE COD_CLIENT = '<session:get-value> name="WIC_CLIENT"/>'
      ORDER BY NOM_FOURNIS
    </sql:query>
    </sql:execute-query>
  }
  catch (Exception e) {
    <response:send-redirect location="wic_erreur.xml?Langue=FR"/>
  }
</xsp:logic>
</page>
</xsp:page>

]] Cocoon XSL (43 lines of code) [[
 <?xml version="1.0" encoding='ISO-8859-1'?>
 <?cocoon-format type="text/xsl"?>
 <xsl:stylesheet version="1.0"
                 xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                 xmlns="http://www.w3.org/TR/xhtml1/strict">
 <xsl:import href="./librairies/mainhtml.xsl"/>
 <xsl:import href="./librairies/lib_listes.xsl"/>

 <xsl:template match="/">
   <xsl:call-template name="main"/>
 </xsl:template>

 <xsl:template match="page">
   <xsl:apply-templates select="@title"/>
   <P align="center">
   <xsl:call-template name="tableauFournisseurs">
   <xsl:with-param name="actions">true</xsl:with-param>
   </xsl:call-template>
   </P>
 </xsl:template>

 <xsl:template name="tableauFournisseurs">
   <table border="1" width="100%" align ="center">
   <tr align="center">
     <th>Nom</th>
     <th>Adresse</th>
     <th>Banque</th>
   <xsl:apply-templates select=".//FOURNISSEUR">
   <xsl:with-param name="actions"><xsl:value-of
select="$actions"/></xsl:with-param>
   </xsl:apply-templates>
   </table>
 </xsl:template>

 <xsl:template match="FOURNISSEUR">
 <tr align="left">
   <td>
     <xsl:apply-templates select="NOM_FOURNIS"/>
   </td>
   <td>
     <xsl:apply-templates select="ADR_FOURNIS_1"/><BR/>
     <xsl:apply-templates select="ADR_FOURNIS_2"/><BR/>
     <xsl:apply-templates select="ADR_FOURNIS_3"/>
    </td>
    <td>
     <xsl:apply-templates select="BQE_FOURNIS"/>
    </td>
 </tr>
 </xsl:template>
 </xsl:stylesheet>

]] BOX Logic (28 lines of code) [[
<?xml version="1.0"?>
<businessLogic>
  <main>
    <var name="title" expr="'Liste des fournisseurs'"/>

    <sql>
      <select>
        * FROM WIC.FOURNIS
        WHERE COD_CLIENT=?
        ORDER BY NOM_FOURNIS
      </select>
      <using>
        <value-of expr="#WIC_CLIENT"/>
      </using>
      <container name="results"/>
    </sql>

    <if test="!$RowCount">
      <var name="Phase" expr="'erreur'"/>
      <stop/>
    </if>

    <enumerate container="@results">
      <tag name="fournis"/>
      <tag name="cod_client" expr="@results.cod_client"/>
      <tag name="nom_fournis" expr="@results.nom_fournis"/>
      <tag name="adr_fournis_1" expr="@results.adr_fournis_1"/>
      <tag name="adr_fournis_2" expr="@results.adr_fournis_2"/>
      <tag name="adr_fournis_3" expr="@results.adr_fournis_3"/>
      <tag name="bqe_fournis" expr="@results.bqe_fournis"/>
      <tag name="/fournis"/>
    </enumerate>
  </main>
</businessLogic>

]] BOX XSL (29 lines of code) [[
<?xml version="1.0" encoding='ISO-8859-1'?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:import href="/common/header.xsl"/>

<xsl:template name="content">
  <table border="1" width="100%" align ="center">
  <tr align="center">
     <th>Nom</th>
     <th>Adresse</th>
     <th>Banque</th>
  </tr>
  <xsl:apply-templates/>
  </table>
</xsl:template>

<xsl:template match="fournis">
<tr align="left">
  <td>
    <xsl:apply-templates select="nom_fournis"/>
  </td>
  <td>
    <xsl:apply-templates select="adr_fournis_1"/><BR/>
    <xsl:apply-templates select="adr_fournis_2"/><BR/>
    <xsl:apply-templates select="adr_fournis_3"/>
  </td>
  <td>
    <xsl:apply-templates select="bqe_fournis"/>
  </td>
</tr>
</xsl:template>

</xsl:stylesheet>

-fin-

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Business-Oriented XML

Posted by Dave Jarvis <da...@joot.com>.
Hello, again.

Neeme Praks wrote:
> Have you ever had a look at Apache Cocoon project? That achieves all the

Yes.

> benefits you outlined in your paper plus more.

Here are a few items BOX addresses that Cocoon does not (as far as I can
discern; please correct my errors):

	o doesn't provide an inherent state-based architecture (it's an aside,
not focus)
	o doesn't automatically apply a different view of logic based on the
domain
	o extremely complex; it mixes multiple languages and odd syntax (e.g.,
&connectDatabase)
	o makes it easy to couple presentation and logic (see below)
	o lacks an integrated expression parser
	o doesn't expose a consistent syntax for doing tasks such as:
		- file I/O
		- sending XML to remote servers
		- calling native code (Java, C, Perl, etc.)
		- SQL statements
	o cookies, FORM parameters, and URL encoded variables are not treated
uniformly
	o doesn't use plain XML (i.e., embeds other language source directly)

If there's interest, I would be more than happy to illustrate a full
cycle of data acquisition (via HTML FORM) to SQL deposit, retrieval, and
final HTML page.  For those who enjoy gory details, I've made a brief
comparison of Cocoon and BOX for two very simple examples.  The first is
a little counter program, the second shows how to do SQL in both
tongues.

Sincerely,
Dave Jarvis

-=( First Example )=-

 ]] Cocoon's Logic (18 lines of code; tied to Java) [[
 <?xml version="1.0"?>
 <?cocoon-process type="xsp"?>
 <?cocoon-process type="xslt"?>
 <?xml-stylesheet href="page-html.xsl" type="text/xsl"?>

 <xsp:page language="java"
xmlns:xsp="http://www.apache.org/1999/XSP/Core">
 <xsp:logic>
 static private int counter = 0;

 private synchronized int count() {
 return counter++;
 }
 </xsp:logic>

 <page>
 <p>I've been requested <xsp:expr>count()</xsp:expr> times.</p>
 </page>
 </xsp:page>

 ]] Cocoon's XSP (6 lines of generated code) [[
 <?xml version="1.0"?>
 <?cocoon-process type="xslt"?>
 <?xml-stylesheet href="page-html.xsl" type="text/xsl"?>
 <page>
 <p>I've been requested 0 times.</p>
 </page>

 ]] Cocoon's XSL (10 lines of code) [[
 <?xml version="1.0"?>
 <xsl:stylesheet>
 <xsl:output method="html" encoding="US-ASCII"/>

 <xsl:template match="page">
   <xsl:apply-templates/>
 </xsl:template>

 <xsl:template match="p">
   <xsl:apply-templates/>
 </xsl:template>
 </xsl:stylesheet>

BOX code, in my opinion, is much simpler and straightforward, as there
is no intermediary XSP page:

 ]] BOX's Logic (7 lines of code; tied to XML) [[
 <?xml version="1.0"?>
 <businessLogic>
   <main>
     <session name="count" expr="#count + 1"/>
     <tag name="count" expr="#count"/>
   </main>
 </businessLogic>

 ]] BOX's XML (4 lines of generated code) [[
 <?xml version="1.0"?>
 <document>
   <count>0</count>
 </document>

 ]] BOX's XSL (7 lines of code) [[
 <?xml version="1.0"?>
 <xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 <xsl:output method="html" encoding="US-ASCII"/>

 <xsl:template match="document">
   <P>I've been requested <xsl:value-of select="count"/> times.</P>
 </xsl:template>

 </xsl:stylesheet>

By adding "<babel>" tags around the English text, you automatically get
a stylesheet that is in the viewer's language (based on their browser's
Accept-Language).  This is part of the architecture; no extra futzing is
required.  BOX makes it difficult to couple logic and presentation.  For
example, to write a "<p>" tag with logic, you must write <tag
name="p"/>.  XSL is where the <p> tag belongs; not snuggled in with
logic.

Let's look at a slightly more complex example, involving SQL.  First
Cocoon, then BOX.

-=( Second Example )=-

]] Cocoon Logic (20 lines of code) [[
<?xml version="1.0" encoding='ISO-8859-1' standalone="no"?>
<?xml-stylesheet href="../xsl/wic_fournisseursListe.xsl"
type="text/xsl"?>
<?cocoon-process type="xsp"?>
<?cocoon-process type="xslt"?>
<!DOCTYPE page SYSTEM "./librairies/entity.dtd">
<xsp:page
   language="java"
   xmlns:xsp="http://www.apache.org/1999/XSP/Core"
   xmlns:session="http://www.apache.org/1999/XSP/Session"
   xmlns:request="http://www.apache.org/1999/XSP/Request"
   xmlns:response="http://www.apache.org/1999/XSP/Response"
   xmlns:sql="http://www.apache.org/1999/SQL"
   xmlns:log="http://www.arctis.com/2000/XSP/Log"
   create-session="true">
<page title="Liste des fournisseurs">
<xsp:logic>
  try {
    <sql:execute-query>
    &connectDatabase;
    <sql:doc-element>FOURNISSEURS</sql:doc-element>
    <sql:row-element>FOURNISSEUR</sql:row-element>
    <sql:query>
      SELECT * FROM WIC.FOURNIS
      WHERE COD_CLIENT = '<session:get-value> name="WIC_CLIENT"/>'
      ORDER BY NOM_FOURNIS
    </sql:query>
    </sql:execute-query>
  }
  catch (Exception e) {
    <response:send-redirect location="wic_erreur.xml?Langue=FR"/>
  }
</xsp:logic>
</page>
</xsp:page>

]] Cocoon XSL (43 lines of code) [[
 <?xml version="1.0" encoding='ISO-8859-1'?>
 <?cocoon-format type="text/xsl"?>
 <xsl:stylesheet version="1.0"
                 xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                 xmlns="http://www.w3.org/TR/xhtml1/strict">
 <xsl:import href="./librairies/mainhtml.xsl"/>
 <xsl:import href="./librairies/lib_listes.xsl"/>

 <xsl:template match="/">
   <xsl:call-template name="main"/>
 </xsl:template>

 <xsl:template match="page">
   <xsl:apply-templates select="@title"/>
   <P align="center">
   <xsl:call-template name="tableauFournisseurs">
   <xsl:with-param name="actions">true</xsl:with-param>
   </xsl:call-template>
   </P>
 </xsl:template>

 <xsl:template name="tableauFournisseurs">
   <table border="1" width="100%" align ="center">
   <tr align="center">
     <th>Nom</th>
     <th>Adresse</th>
     <th>Banque</th>
   <xsl:apply-templates select=".//FOURNISSEUR">
   <xsl:with-param name="actions"><xsl:value-of
select="$actions"/></xsl:with-param>
   </xsl:apply-templates>
   </table>
 </xsl:template>

 <xsl:template match="FOURNISSEUR">
 <tr align="left">
   <td>
     <xsl:apply-templates select="NOM_FOURNIS"/>
   </td>
   <td>
     <xsl:apply-templates select="ADR_FOURNIS_1"/><BR/>
     <xsl:apply-templates select="ADR_FOURNIS_2"/><BR/>
     <xsl:apply-templates select="ADR_FOURNIS_3"/>
    </td>
    <td>
     <xsl:apply-templates select="BQE_FOURNIS"/>
    </td>
 </tr>
 </xsl:template>
 </xsl:stylesheet>

]] BOX Logic (28 lines of code) [[
<?xml version="1.0"?>
<businessLogic>
  <main>
    <var name="title" expr="'Liste des fournisseurs'"/>

    <sql>
      <select>
        * FROM WIC.FOURNIS
        WHERE COD_CLIENT=?
        ORDER BY NOM_FOURNIS
      </select>
      <using>
        <value-of expr="#WIC_CLIENT"/>
      </using>
      <container name="results"/>
    </sql>

    <if test="!$RowCount">
      <var name="Phase" expr="'erreur'"/>
      <stop/>
    </if>

    <enumerate container="@results">
      <tag name="fournis"/>
      <tag name="cod_client" expr="@results.cod_client"/>
      <tag name="nom_fournis" expr="@results.nom_fournis"/>
      <tag name="adr_fournis_1" expr="@results.adr_fournis_1"/>
      <tag name="adr_fournis_2" expr="@results.adr_fournis_2"/>
      <tag name="adr_fournis_3" expr="@results.adr_fournis_3"/>
      <tag name="bqe_fournis" expr="@results.bqe_fournis"/>
      <tag name="/fournis"/>
    </enumerate>
  </main>
</businessLogic>

]] BOX XSL (29 lines of code) [[
<?xml version="1.0" encoding='ISO-8859-1'?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:import href="/common/header.xsl"/>

<xsl:template name="content">
  <table border="1" width="100%" align ="center">
  <tr align="center">
     <th>Nom</th>
     <th>Adresse</th>
     <th>Banque</th>
  </tr>
  <xsl:apply-templates/>
  </table>
</xsl:template>

<xsl:template match="fournis">
<tr align="left">
  <td>
    <xsl:apply-templates select="nom_fournis"/>
  </td>
  <td>
    <xsl:apply-templates select="adr_fournis_1"/><BR/>
    <xsl:apply-templates select="adr_fournis_2"/><BR/>
    <xsl:apply-templates select="adr_fournis_3"/>
  </td>
  <td>
    <xsl:apply-templates select="bqe_fournis"/>
  </td>
</tr>
</xsl:template>

</xsl:stylesheet>

-fin-

---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org


RE: Business-Oriented XML

Posted by Neeme Praks <ne...@apache.org>.
Seems to me that here is some lack of homework...
Have you ever had a look at Apache Cocoon project? That achieves all the
benefits you outlined in your paper plus more.
Check out http://xml.apache.org/cocoon and http://xml.apache.org/cocoon2...

Rgds,
Neeme

> -----Original Message-----
> From: jarvisd@mail.one.lv [mailto:jarvisd@mail.one.lv]On Behalf
> Of Dave Jarvis
> Sent: Friday, November 16, 2001 9:40 AM
> To: general@jakarta.apache.org; general@xml.apache.org
> Subject: BOX: Business-Oriented XML
>
>
> Hello,
>
> Using Tomcat, Xalan, Xerces, and Java-based technologies, I have
> developed a system that completely decouples presentation from business
> logic.  I would like to discuss the system and the possibility of adding
> it to the technologies offered by the Apache Foundation.  Please find a
> brief architectural overview of the system online at the following
> address:
>
> 	http://www.joot.com/box/
>
> For a more technical system description, please read the following page:
>
> 	http://www.joot.com/dave/writings/articles/bsp/
>
> I look forward to your comments, critiques, and questions.
>
> Sincerely,
> Dave Jarvis
>
> ---------------------------------------------------------------------
> In case of troubles, e-mail:     webmaster@xml.apache.org
> To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
> For additional commands, e-mail: general-help@xml.apache.org
>


---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org