cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@infoplanning.com>
Subject FW: Component approach to web development using Cocoon
Date Wed, 05 Jan 2000 16:48:12 GMT
You can use DCP objects (part of the cocoon framework) to generate embedded
XML (or in your case XHTML--the formatting of HTML to look like XML).  If you
need a completely dynamic solution, i.e. a generated page including generated
embedded XML, then you would create a producer to do it.  Both of these abilities
are currently part of Cocoon.

Regarding the list of technologies you are listing as alternatives, they are used for
different realms of responsibility.  Here is a breakdown of what they address:

DHTML: This is merely the combination of DOM enabled JavaScript, CSS, and
             HTML.  It does not access any server resources, and lives completely
             within the client.  Because Cocoon generates HTML, you can still use
             this with the Cocoon publishing framework.

JavaScript: This either lives completely within the client, or completely within
                  the server.  In fact, if you install the FESI package, you can use
                  JavaScript as a DCP object (see the docs for more info).  It can
                  also be used to talk to a Java applet.

Applets:  This is a small embedded Java application included in the page.
              The advantages of this solution are that you may obtain an HTTP
              connection with the server (only the server it came from), to
              dynamically obtain more information from the server.  The
              two major disadvantages are that it greatly increases download
              time, and not every Java Virtual Machine that is shipped with
              a browser is equal--you must test it on every target platform.
              Web Browser Java Virtual Machines are getting better, and are
              conforming more closely witht the Java Standard.

JSP:  Java Server Pages embed java code within the HTML.  As a result,
         the pages must be compiled.  The disadvantage to this result is that
         logic, content, and style are all lumped together in one file (unless
         you explicitly embed another page).  One solution to this delimna
         is the use of Java Beans which encapsulate the data and logic in
         a resident object, and is only referenced by the JSP.

Cocoon: Probably the most direct competition to any technology you listed
             would be Java Server Pages.  Cocoon is a servlet (a technology
             you failed to mention), and is a truly powerful architecture.  The
             idea of XML/XSL is to separate the content from the presentation.
             Cocoon adds some further functionality so that you can also
             properly separate out logic into another resource.

The following details regard the different components of Cocoon, showing
what it can and cannot do:

XML: Specifies content and meta data.  This is the perfect area for business
         analysts or columnists (if its a news site).  If your site ever incorporates
         a search function, you will be able to return more accurate results if
         you use a standard schema for your site.  While you can use XHTML,
         it won't help you with the search functions.  The DocBook schema,
         although officially it is SGML, is a very good basis to use for a site.

XSL: Specifies presentation.  This is the perfect area for graphics designers.
        You can incorporate DHTML in this layer, and it won't confuse the people
        who write the content.  This layer is actually not needed if you use XHTML
        as your schema (because that is what you are transforming the XML to),
        but that defeats the most powerful and compelling reason
        (at least to me) for using cocoon in the first place.

DCP:  Specifies the logic.  This is the perfect area for programmers.  You can
          incorporate business logic, and encapsulate dynamic information without
          cluttering the XML page too much.  All that is required is a couple
          processing instructions in the XML to reference the object.  Methods
          performed on the object can return XML to embed.  It is analogous to
          Java Beans (although you are not stuck with Java).

Producers: Another location for specifying logic, and producing dynamic content
                 is by writing a producer.  A producer can have all the priveledges that
                 Cocoon has.  One advantage to making producers is that you are
                 placing all of your information directly into the DOM.  There is no extra
                 parsing step to convert your XML to a DOM.  This is a very powerful
                 feature.

SQL:  This is a stock producer that will allow you to access any database with a
          JDBC driver.  You have some control over the names used for the tags.
          It is an excellent resource if you don't have to manipulate the output alot.

XSP:  This is not acutally written yet, but it will be very much like JSP--only using
          XML.  I do not have all the information on what this is purposed to be in
          its entirety.

So, depending on what you want to do (which it sounds like can be accomplished
with simple Server Side Includes), Cocoon can be the publishing platform to beat.
It is easier to maintain a web site using this technology in the long term than many
other solutions (Perl, PHP, JSP).  Because of the inherent separation of content
and presentation, you will be able to update the look and feel of your site in hours
instead of days or weeks.  Many talented programmers (like the people at
themes.org), have created themeable web sites, but I am sure the code is not as
clean and easily understood.  Despite the problems that some people (including
me) have encountered during installation and set up,  and despite the fact that the
learning curve is a little longer than Cold Fusion, the long term payoffs are worth
the effort.

-----Original Message-----
From:	Muly Oved [SMTP:mulyoved@hotmail.com]
Sent:	Tuesday, January 04, 2000 10:03 AM
To:	cocoon-users@xml.apache.org
Subject:	Component approach to web development using Cocoon

Hi

I am new to Cocoon and I wonder if Cocoon can do that:

To enable paralleled development of web sites using multiple tools and
methodologies I want to be able to develop the HTML pages using normal tools
and then combine several common fragments to one HTML. The fragments and the
place to put them can be identified by the html ID.

I can see I can use Cocoon for
XML+XSL -> HTML
Where the
XML has data
XSL mix presentation information and data pooling instruction.

What I need is
HTML1+HTML2+XSL -> HTML3
Where HTML3 is based on HTML1 with some of the sections of HTML1 replaced
with sections from HTML2, the instruction what to do is placed in the XSL
(Or other XML base language)

This enable to:
- Develop HTML1 as a purely static HTML document and just give some of the
DIV an ID.
- Develop HTML2 by other methodology by other people, which more suitable
for this part (DHTML/JavaScript/Applets/JSP/Cocoon).

And then in a sort of a build process combine the parts from HTML1 with
parts of HTML2 generating HTML3 ready for production.

The idea can be seen as a component approach to web development.

Does something like that exist (maybe with different terminology), planed or
make any sense?

Regards,

Muly.

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


Mime
View raw message