Re: Business-Oriented XML
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] = 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: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Business-Oriented XML
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dave Jarvis Sent: Friday, November 16, 2001 9:40 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] 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: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Business-Oriented XML
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
pI've been requested xsp:exprcount()/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
pI'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
count0/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
PI'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-elementFOURNISSEURS/sql:doc-element
sql:row-elementFOURNISSEUR/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
Re: Business-Oriented XML
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: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
