cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcelo F. Ochoa" <moc...@ieee.org>
Subject RE: XP taglib and new cocoon site
Date Wed, 12 Jul 2000 15:30:22 GMT


Ulrich Mayring <ulim@denic.de> wrote:
>Robin Green wrote:
> >
> > Then why don't you do what I suggested?
> >
> > E.g.:
> > view.xml contains the code (XSP).
> > archive.xml contains the archive overview.
> >
> > Use view.xml?get=archive.xml and use <xsp:include-file>. 
><xsp:include-file>
> > does not suffer from the 64K restriction.
>
><xsp:include-file> is new to me. Perhaps you mean <util:include-file>?

Yes, sorry, I meant <util:include-file>

>Or the XInclude Processor?
>
>Anyway, XSP pages are always compiled. If you include XML before or
>during an XSP pass, then that XML is compiled along with it. If you
>include XML after an XSP pass, then you avoid that problem. The only
>option to do that would be the XInclude processor, but that currently
>doesn't work after XSP, only before it.

No, you are mistaken. <util:include-file> includes the file after the 
compilation has completed. It is a Java include, not an XSL or XML include. 
So <util:include-file> does indeed avoid the 64K limit. You can verify this 
by looking at src/org/apache/cocoon/processor/xsp/library/java/util.xsl 
(IIRC)

>
> > Why do you need any XSP in the overview anyway, if it is all 
>pre-generated?
>
>There is no XSP anywhere in any of my pre-generated files, they are all
>straight XML. As soon as I include them into a XSP page, however, they
>get compiled along with the XSP page.
>
>Basically, my premises are these:
>
>a) all content in straight XML files, which are visible to the user
>b) all logic in XSP files, which are invisible to the user
>
>So, the user requests an XML file. All my XML files have a stylesheet
>called "/common.xsp", which generates a dynamic XSP page and executes
>it. The XSP page generates some dynamic content, puts it into tags and
>calls its stylesheet, which is called "/common.xsl". This stylesheet
>transforms the XML tags to HTML.
>
>As you can see there is no XSP file, which the user could request and
>which in turn could include something.

Well there should be - see below.

>Instead the user requests XML
>files, which will generate a dynamic XSP page, if logic needs to be
>done. This way I can give my straight XML files to anybody and have true
>seperation of logic and content.

I am in fact suggesting the same separation into logic and content!  Just a 
different way around. (Nitpick - your "straight XML files" probably include 
processing instructions - so they are not _pure_ content. In fact, my 
approach would use pure content XML files.) You currently have: (this 
diagram needs a fixed width font BTW)

              XSP logicsheet                      stylesheet
  Data (XML) ----------------->  XSP --> content -------------> HTML


whereas to solve your problem, you should just switch it around from a "data 
pulls logic" system into a "logic pulls data" system, like this:

    gets XML data
       |
       |                       stylesheet
  One XSP page --->  content --------------> HTML


Do you see what I mean? The one single XSP page does the job of your XSP 
sheet, without the overhead and the 64K limit.

I anticipate that you may have additional logic that cannot conveniently be 
subsumed into this approach. If so please could you give more details.

Incidentally, we are working on a "automatic include" system (part of a 
Content Management System like that described on the Oracle website), which 
is sort of a more complex elaboration of the "logic pulls data" approach - 
but the CMS level of complexity is probably not needed for this mail archive 
application!
[>]  Do you know DB Prism / Cocoon CMS, it is made with DB Centric Idea, similar to your
"logic pulls data" terms.

DB Prism generates XML in Database Stored Procedures writen in PLSQL or Java, with this approach
you could apply any manipulation of the XML before plug into Cocoon.
(Logic+XML) DB Prism Producer  -> Cocoon (presentation/xsl) -> browser

[>]  IMO this approach has many benefits, like low mantanaince, performance, security,
...
- Low maintenance: Any modificaction in the data structure is detected by tha Databases through
his dependency link. (If you modify the structure of the table your XSP never receive this
signal, in a big project humm..).
- Performance: An Stored Procedure runs closest to the data and then, get it faster than JDBC
calls, in an XSP pages with many SQL calls the JDBC round trips in the networks decrease the
performance of XSP pages.
- Security: You could apply any level of application security, plus Database Security. For
example in DB Prism CMS is possible to use row level security in order to check users access
to CMS/XML pages that exists in a same table.
- Debugging, with Java Stored procedures you could use for example Oracle Jdeveloper debugging
to debug your application, XSP at this moment don't have debugger and IMO is too hard to find
errors and run step by step.
...

Best regards, Marcelo.

[>]  PD: DB Prism/Cocoon CMS is at: http://www.plenix.com/dbprism/
--
Robin Green
i-tao Ltd.
4 Skyline Village
Limeharbour
London E14 9TS
United Kingdom
Phone +44 20 7537 2233  Fax +44 70 8081 5118
http://www.i-tao.com


________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org

or additional commands, e-mail: cocoon-users-help@xml.apache.org

Mime
View raw message