cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bjarne Jensen" <...@ruc.dk>
Subject SV: SV: SV: SV: Is it possible to have a clean separation of 'document content', 'style' and'logic' in Cocoon?
Date Fri, 18 May 2001 11:09:58 GMT
Thanks again :-) The code below separate the PI from the content file (I am
using 1.8.2 on tomcat). But you say that is not a good way to do it? I
believe the file gets cached because it is not slow. I agree with you that
to have the PI in the content file is best in some situations and not in
others. In the situation with the authorization then it should be in the
content file if the content writer decides who are allowed to se the
content. To make it wok on different platforms. It would be good to have the
authorization in the content file OR a separate authorization file (in XML
of course). Moreover the system should be flexible the people using it
should restrain it. It also depends on your have 100 files or one with the
content of the 100 files. In the last situation it would be hard to put it
in all files. But basically it think authorization it is NOT the job of the
content writer. This is the job of the programmer or an administrator. So in
most working environments it would be best to have a central file with all
PI for different XML-files. I should then also be possible to make a PI that
is used by many files (the programmer select which ones). And that is what
the Cocoon 2 stylesheet is all about, right?

<?xml version="1.0" encoding="iso-8859-1"?>
<?cocoon-process type="xsp"?>
<?xml-logicsheet href="funktionalitet.xsl"?>
<?xml-stylesheet href="layoutHTMl.xsl" type="text/xsl"?>
<?cocoon-process type="xinclude"?>
<?cocoon-process type="xslt"?>
<xsp:page xmlns:xsp="http://www.apache.org/1999/XSP/Core"
xmlns:bhjutil="http://www.ruc.dk/~bhj/bhjutil"
xmlns:fp="http://apache.org/cocoon/XSP/FP/1.0"
xmlns:xinclude="http://www.w3.org/1999/XML/xinclude" title="A Poem"
xmlns:request="http://www.apache.org/1999/XSP/Request">
	<book>
		<!-Includes external file -->
		<include xinclude:parse="xml"
xinclude:href="data/realContent.xml#xpointer(//PLAY)"/>
	</book>
</xsp:page>

This is regarding the same subject somehow. How do I make the same file
available in PDF and HTML? Well I create to different stylesheets (already
done). But then I also has to make to different content files one with the
line <?xml-stylesheet href="layoutHTMl.xsl" type="text/xsl"?> and another
one with the line <?xml-stylesheet href="layoutFO.xsl" type="text/xsl"?>. Is
that the proper way to do it? Or is the solution to this problem also the
Cocoon 2 stylesheet?

Thanks in advance for your help
-Bjarne

-----Oprindelig meddelelse-----
Fra: ulim@denic.de [mailto:ulim@denic.de]
Sendt: 18. maj 2001 10:34
Til: cocoon-users@xml.apache.org
Emne: Re: SV: SV: SV: Is it possible to have a clean separation of
'document content', 'style' and'logic' in Cocoon?


Bjarne Jensen wrote:
>
> Is it possible to have this code (or some of it) placed in another file?
The
> reason for this is that in a truly separation between logic and content.

Ok, you are touching upon the IMHO most fundamental philosophical
problem of the Cocoon platform ;-)

Your content writers can use an XML editor that doesn't allow
modification of the PIs. It's not clever to centralize the PIs in
another file, if you want to do something like that you should use
Cocoon2. The big difference between Cocoon1 and Cocoon2 in this regard
is that Cocoon2 centralizes this in the sitemap file, whereas Cocoon1
allows you to write self-contained XML files. There is a big argument
between me and (it seems ;-) the rest of the community which way is
better - I think both ways are useful, it depends on your actual
project. For example, if you have data-driven applications, then
self-contained XML files are better, whereas large, static websites gain
much from a centralized sitemap.

To fully understand this difference in philosophy, consider another
case, authentication. You can have central authentication, like using
.htaccess files with Apache. These are files, which really have nothing
to do with your XML files and only work in a web context and with a
specific server platform. But it's easy to manage these central files,
of course. On the other hand, if you use my Auth taglib, you put the
authentication information in the XML files themselves, so they become
self-contained. This means they can, for example, be moved around
without losing their authentication information - they do not depend on
a specific server platform or request pattern.

This is why I call the Cocoon2 sitemap proprietary - much like the
.htaccess files. They depend on a specific platform and a specific usage
context. On the other hand these central files are powerful and in many
cases easier to maintain.

What is the solution? We need to find a third way, which is more general
and allows both patterns. In the case of authentication, this could mean
that we store our usernames/passwords/permissions in an LDAP directory.
Then it doesn't matter anymore if our webserver accesses this info via a
proprietary LDAP module or whether we are using the Auth taglib with its
LDAP authentication scheme.

> About the thing that the programmer has to be involved in the maintain of
> the stylesheet: Maybe this is done so because XSL is not as common as
HTML.
> And there are a lot of tools for creating HTML (Dreamweaver and FrontPage
> etc.), but I have not seen any tool like this for XSL (XML Spy is a great
> tool, but it is not so visual as many HTML-editors) - So in the future the
> programmer would only program the XSP? Is this realistic?

IMHO no. Have you ever seen the code produced by Dreamweaver et. al.?
This code sucks, but today people can get away with it, because it's
just HTML. Now imagine how XSL code produced by these programs would
look like.

> In the beginning of the Internet I think it was programmers that made HTML
> and this is not the case anymore. Now a days a HTML-specialist and/or
> graphic designer makes some HTML and some pics. The programmer then copy
> paste this in another file and add some dynamic content (that?s how I has
> done it).

That's the way it is and, IMHO, how it will be.

> This is ok - but I think there is one problem with that approach,
> when the site is up and running and minor changes in the HTML has to be
> made. The programmer has to do the changes (change margin, adjust position
> etc.). If we had a clean separation the HTML-specialist would do this. But
> if the HTML-specialist do this, the programmer has to re-do her or his
work
> of adding the XSL. As I understood what Ulrich writes the same approach is
> suggested with Cocoon. so the thing that is really separate is the
content.
> And if we use a database we would get pretty much the same separation. So
> what is it that makes the separation of the tree layers in Cocoon
different
> from an environment, where we use JSP or ASP and a database? Is it XSL?
That
> is also possible to use with JSP (by creating a extra VM).

I'm hoping for Cocoon3 ;-)

But in any case it's imperative to have your content in XML. Whether you
store that XML in the filesystem or in a database is up to you. In the
future it will also be imperative to have your data model and your logic
in XML - even though there are some shortcomings, only Cocoon can do
that.

Ulrich

--
Ulrich Mayring
DENIC eG, Systementwicklung

---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

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


---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

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