Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm
Message-ID: <20000106113258.65238.qmail@hotmail.com>
From: "Muly Oved" <mulyoved@hotmail.com>
To: <cocoon-users@xml.apache.org>
References: <6C923E7A49ACD311A64E0000D11C16371D9A8F@trc-tpaexch01.trcinc.com>
Subject: Re: Component approach to web development using Cocoon
Date: Thu, 6 Jan 2000 13:30:23 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

>I'm still not sure I follow this.  It sounds like you are saying that you
>want to take a static XML and overide specific nodes with a more dynamic
XML
>node.  If that is true, can you come up with a better example.  I don't yet
>see the need.
Override specific nodes, Yes this is the idea.
The motivation for this is to enable parallel development of the document
while develop in a more traditional approach then XML+XSLT.

The web designer will be able to work and maintain a fully static html
version of the site. The data on this site will be faked sample data. To do
this he can use any HTML editor and that will really keep him productive and
happy, (XSLT maybe just to complicate for those types of workers, yet).

The programmer is working on the dynamic parts of the document on a
different set of html and does not need to be concerned about every change
in the images, colors, style or static text.

All the web designer and the programmer need to coordinate between them is
the ID of the sections. Not that this is trivial, but comparing to other web
technologies can be done :).

This is just an example it does not have to be split between static and
dynamic, it can be split between different types of dynamic or different
type of static. It just a way to split the work, nothing more complicate
then that.

>I also disagree with:
>>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.

>XSL can load additional XML documents using the document() function.  And
>XML can load additional nodes from an external entity into the root node.
I will check this, thanks.

Muly.

----- Original Message -----
From: Steven Maring <Steven.Maring@trcinc.com>
To: <cocoon-users@xml.apache.org>
Sent: Thursday, January 06, 2000 12:36 PM
Subject: RE: Component approach to web development using Cocoon


> I'm still not sure I follow this.  It sounds like you are saying that you
> want to take a static XML and overide specific nodes with a more dynamic
XML
> node.  If that is true, can you come up with a better example.  I don't
yet
> see the need.
>
> I also disagree with:
> >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.
>
> XSL can load additional XML documents using the document() function.  And
> XML can load additional nodes from an external entity into the root node.
>
> Why don't you just stick with a single XML file and take advantage of
> Cocoon's ability to have a processing instruction in XML call out to a
> Servlet(or whatever) for dynamic processing?
>
> -Steve M.
> Tampa, FL
>
> -----Original Message-----
> From: Muly Oved [mailto:mulyoved@hotmail.com]
> Sent: Thursday, January 06, 2000 5:02 AM
> To: cocoon-users@xml.apache.org
> Subject: Re: Component approach to web development using Cocoon
>
>
> 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.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>