cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Muly Oved" <mulyo...@hotmail.com>
Subject Re: Component approach to web development using Cocoon
Date Thu, 06 Jan 2000 10:02:04 GMT
Thanks for the details answers. I will try to clear a few things.

>> HTML1+HTML2+XSL -> HTML3

>what does "html1 + html2" mean? what do you use to go from html1 to
>html2?

1) To enable parsing the html need to be converted to XHTML (which is a
valid XML document).
2) The + is a very limited operation in this context, all it does is taking
xhtml1 and replace one of it's section with section from xhtml2, the
sections are identified by the ID attribute.
3) XSL can't control more then 1 document at a time. So XSL is not the
proper tool to do the merge of the documents.


>>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:
This is exactly the motivation for that operation.
There are many technologies to create web pages. Many of those can be
represented as a static file on the server ready to be delivered to the
client. HTML, DHTML, JavaScript, Applet, XML+XSL, JSP, (JSP is included and
Servlet is not included)

What I suggest is a way to automate the management of using those different
technologies, and in a way that is orthogonal to those technologies, it is
not conflicting with Cocoon XML framework.

For example (not a good one)
The static page will include
<DIV ID="date">6-Jan-2000</DIV>

The component page can include
<DIV ID="date">
<SCRIPT LANGUAGE="JavaScript">
..
</SCRIPT>
</DIV>

Or
<DIV ID="date">
<%= currentDate%>
</DIV>
(In this case xhtml1+jsp2=jsp3 so the result is jsp which is still just a
valid xml document)

When thinking what will be the best approach to implement this it seem to me
that yet another xml language need to be designed to provide the
instructions, it can use the XPath spec to specify the parts but still need
to include new commands.

Do you think there is any value in such approach for organizing the
development of a web site?
Do you think it has a place in the Cocoon framework?

Regards,

Muly.


----- Original Message -----
From: Berin Loritsch <bloritsch@infoplanning.com>
To: <cocoon-users@xml.apache.org>
Sent: Wednesday, January 05, 2000 6:48 PM
Subject: FW: Component approach to web development using Cocoon


> 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
>
>
> ---------------------------------------------------------------------
> 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