You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Bjarne Jensen <bh...@ruc.dk> on 2001/05/17 13:55:03 UTC
SV: Is it possible to have a clean separation of 'document content', 'style' and'logic' in Cocoon?
About clean separation of the tree layers when using forms:
Thanks very much for the reply :-) I like the way Ulric Mayring think about
it as an abstract layer, and it gets us closer to the clean separation
between content, style and logic. But the way I see it, that is really not a
clean separation. Basically is it (very much) better that the content writer
writes
<mytaglib:form url=foo.xml> than <form url=foo.xml>?
Ideally it would be best (I think) that the content-writer, just writes
something like:
<searchFunctionality enable=true/>
In the XSP taglib I could handle the parameters and name them correctly. But
one problem remains, the graphics designer decides the names of the
formfields that the XSP programmer uses! Ideally the XSP programmer should
take care of everything regarding parsing of parameters. That is not done
this way. The string "<input type="hidden" name="actnr"
value="{$current}"/>" could be calculated in the XSP, but the graphics
designer still has to take care of the string gets inserted on the correct
place in the form.
In the stylesheet we cant use XSP. If we could it would be preferred that
the graphic designer writes something like <searchFunctionForm size=30/> -
or would it? That way we would limit the freedom of the graphics designer.
Maybe this is really a problem with form? Forms includes layout AND
functionality regarding parsing of parameters. So what is the solution of
the clean seperation? To split forms in part? maybe that makes it harder to
maintain. When the HTML of a form is maintained in all the tree different
layers. What do you think?
I also have another point: When trying to have a clean separation of the
tree layers, I have made some code that I have pasted below. The code parses
the value of at formfield to itself. The text in the formfield remains after
submit. So this is basically just a simple example of parsing parameters. I
have tried to implement it the way Ulric Mayering wrote. It is close to a
clean seperation (se above), but this is not the point here. If this should
work in a professional environment. I think everybody has to know a lot of
what happens with forms, and especially to know a lot XSL! So what has we
accomplished by the separation? I know it is provocative to say but we have
made everyone to a programmer!. But do you see my point? Any help or
comments of practical use of this would make me very glad :-)
Thanks in advance for your help
-Bjarne
Content file:
<myutil:form url="indhold.xml">
<myutil:input-parameter source="fieldName" target="username"/>
</myutil:form>
Logic file (XSP taglib):
<xsl:template match="myutil:form">
<form url="{@url}">
<inputfield size="30" param="{//@target}" source="{//@source}"/>
</form>
<searchQ><request:get-parameter name="fieldName"/></searchQ>
</xsl:template>
Layout file:
<xsl:param name="qText" select="searchQ"/>
<xsl:value-of select="$qText"></xsl:value-of>
<form method="GET" action="{form/@url}">
<input size="{form/inputfield/@size}" type="text"
name="{form/inputfield/@source}" value="{$qText}"></input>
<input type="submit" value="Søg"/>
</form>
-----Oprindelig meddelelse-----
Fra: ulim@denic.de [mailto:ulim@denic.de]
Sendt: 16. maj 2001 11:37
Til: cocoon-users@xml.apache.org
Emne: Re: Is it possible to have a clean separation of 'document
content', 'style' and'logic' in Cocoon?
Bjarne Jensen wrote:
>
> If that is the case the seperation of
> the 3 layers is not of so much use as it could be. When using forms (get
or
> post - to deliver my query text) it gets even worse. In the Style.xsl I
have
> to have hidden fields like "<input type="hidden" name="actnr"
> value="{$current}"/>" calculated in Style.xsl to pass parameters. In
short
> the Style.xsl gets very complicated.
You're right, this is not a clean seperation of content and logic. The
stylesheet should just transform XML into HTML or PDF or whatever you
need as output, but it should not make logical decisions, this should be
done in an XSP taglib.
It's kind of hard to explain how to do this right, but you have to think
of an abstract layer that sits on top of HTML forms and request
parameters, for example. Your content writers will only use this
abstract layer and your XSP taglib will translate it into suitable XML
and the stylesheet will translate this into suitable HTML. For example,
your content writer writes:
<mytaglib:form url="foo.xml">
<mytaglib:input-parameter source="inputfield" target="username"/>
</mytaglib:form>
In your XSP taglib you translate this to:
<form url="foo.xml">
<inputfield size="30" param="username"/>
</form>
The size="30" attribute may have been calculated by the taglib
beforehand using xsp:logic
Your stylesheet translates this into HTML:
<form method="POST" action"foo.xml">
<input type="text" ...>
</form>
All the decisions are made in the XSP taglib, your stylesheet has no
logic in this way. It just matches certain XML tags, which have been
generated by the taglib.
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: SV: SV: SV: SV: Is it possible to have a clean separation of
'document content', 'style' and'logic' in Cocoon?
Posted by Ulrich Mayring <ul...@denic.de>.
Bjarne Jensen wrote:
>
> 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).
In that case you decouple the information again and depend on a specific
context. I don't think it makes much of a difference whether you write
.htaccess files in XML or Apache syntax (which is kind of like XML
anyway).
> 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.
This comes back to my original point: are you writing a static website?
Then you have content writers writing (more or less) static content. Are
you writing a data-driven application? Then you have a programmer
writing the content (the content of an application is its logic). The
goal "seperation of content, logic and style" has a precondition that in
my experience is often not met, namely that it has actually been defined
what exactly constitutes the content, logic and style in this project.
> 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?
I've never done this, but I think there's an entry in the FAQ about
dynamically selecting stylesheets.
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
SV: SV: SV: SV: Is it possible to have a clean separation of 'document content', 'style' and'logic' in Cocoon?
Posted by Bjarne Jensen <bh...@ruc.dk>.
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: SV: SV: SV: Is it possible to have a clean separation of 'document
content', 'style' and'logic' in Cocoon?
Posted by Ulrich Mayring <ul...@denic.de>.
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
SV: SV: SV: Is it possible to have a clean separation of 'document content', 'style' and'logic' in Cocoon?
Posted by Bjarne Jensen <bh...@ruc.dk>.
Thank you ones again Ulrich - this is great :-)
but my working environment
does still not have tree separate layers. In the top of all by content page
I has this:
<?xml version="1.0" encoding="iso-8859-1"?>
<?cocoon-process type="xsp"?>
<?xml-logicsheet href="funktionalitet.xsl"?>
<?xml-stylesheet href="layout.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:xinclude="http://www.w3.org/1999/XML/xinclude" title="A Poem"
xmlns:request="http://www.apache.org/1999/XSP/Request">
(This describes the order of processing this document through XSP and XSL
(Logic and Style). Besides it defines the namespace that is useable inside
this page. So the content writer (as an example) just writes
<bhjutil:curTime/>, and the current time gets dynamic calculated.)
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.
Information regarding the order of processing of the document should not be
controlled by the content writer but by the programmer. Moreover it would be
nice to have this in a single file. So if the programmer wants to change the
stylesheet, add a new namespace or something like that he/she would not have
to make the changes in every file used on the site! Not before this is done
we have a truly separation between content and logic. How should this be
done?
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?
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 (thats how I has
done it). 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).
Thanks in advance for your help
-Bjarne
-----Oprindelig meddelelse-----
Fra: ulim@denic.de [mailto:ulim@denic.de]
Sendt: 17. maj 2001 17:01
Til: cocoon-users@xml.apache.org
Emne: Re: SV: SV: Is it possible to have a clean separation of 'document
content', 'style' and'logic' in Cocoon?
Bjarne Jensen wrote:
>
> About separation of the tree layers and roles:
>
> Thank you ones again :-) I thought it was the graphic designer that
creates
> the stylesheet, but as you think of it: It?s the XSP programmer (or one
with
> similar skils). So the layers are ?only? a designpattern for the
programmer
> (a great one - what so ever). It is not intended that a graphics designer
> makes the style file, the programmer makes the logic file and the content
> writer makes the content file. The programmer has to make changes in all
> files, to get it all to work. Is this right, or are anyone doing something
> different?
No, the content writer is seperate, but not the stylesheet writer.
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: SV: SV: Is it possible to have a clean separation of 'document
content', 'style' and'logic' in Cocoon?
Posted by Ulrich Mayring <ul...@denic.de>.
Bjarne Jensen wrote:
>
> About separation of the tree layers and roles:
>
> Thank you ones again :-) I thought it was the graphic designer that creates
> the stylesheet, but as you think of it: It?s the XSP programmer (or one with
> similar skils). So the layers are ?only? a designpattern for the programmer
> (a great one - what so ever). It is not intended that a graphics designer
> makes the style file, the programmer makes the logic file and the content
> writer makes the content file. The programmer has to make changes in all
> files, to get it all to work. Is this right, or are anyone doing something
> different?
No, the content writer is seperate, but not the stylesheet writer.
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
SV: SV: Is it possible to have a clean separation of 'document content', 'style' and'logic' in Cocoon?
Posted by Bjarne Jensen <bh...@ruc.dk>.
About separation of the tree layers and roles:
Thank you ones again :-) I thought it was the graphic designer that creates
the stylesheet, but as you think of it: Its the XSP programmer (or one with
similar skils). So the layers are only a designpattern for the programmer
(a great one what so ever). It is not intended that a graphics designer
makes the style file, the programmer makes the logic file and the content
writer makes the content file. The programmer has to make changes in all
files, to get it all to work. Is this right, or are anyone doing something
different?
Thanks in advance for your help
-Bjarne
-----Oprindelig meddelelse-----
Fra: ulim@denic.de [mailto:ulim@denic.de]
Sendt: 17. maj 2001 14:50
Til: cocoon-users@xml.apache.org
Emne: Re: SV: Is it possible to have a clean separation of 'document
content', 'style' and'logic' in Cocoon?
Bjarne Jensen wrote:
>
> About clean separation of the tree layers when using forms:
> Thanks very much for the reply :-) I like the way Ulric Mayring think
about
> it as an abstract layer, and it gets us closer to the clean separation
> between content, style and logic. But the way I see it, that is really not
a
> clean separation. Basically is it (very much) better that the content
writer
> writes
>
> <mytaglib:form url=?foo.xml?> than ?<form url=?foo.xml?>??
No, this was just a very simple example. You can get as high-level as
you like, if you don't want your content writers to deal with forms.
> Ideally it would be best (I think) that the content-writer, just writes
> something like:
>
> ?<searchFunctionality enable=?true?/>
Sure, this is more work for you, but it'll work.
> In the XSP taglib I could handle the parameters and name them correctly.
But
> one problem remains, the graphics designer decides the names of the
> formfields that the XSP programmer uses! Ideally the XSP programmer should
> take care of everything regarding parsing of parameters. That is not done
> this way. The string "<input type="hidden" name="actnr"
> value="{$current}"/>" could be calculated in the XSP, but the graphics
> designer still has to take care of the string gets inserted on the correct
> place in the form.
The graphics designer doesn't have much to do with it, this is the job
of the stylesheet writer. Your designer gives you some HTML code and
you, the developer, write a stylesheet from it.
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: SV: Is it possible to have a clean separation of 'document content',
'style' and'logic' in Cocoon?
Posted by Ulrich Mayring <ul...@denic.de>.
Bjarne Jensen wrote:
>
> About clean separation of the tree layers when using forms:
> Thanks very much for the reply :-) I like the way Ulric Mayring think about
> it as an abstract layer, and it gets us closer to the clean separation
> between content, style and logic. But the way I see it, that is really not a
> clean separation. Basically is it (very much) better that the content writer
> writes
>
> <mytaglib:form url=?foo.xml?> than ?<form url=?foo.xml?>??
No, this was just a very simple example. You can get as high-level as
you like, if you don't want your content writers to deal with forms.
> Ideally it would be best (I think) that the content-writer, just writes
> something like:
>
> ?<searchFunctionality enable=?true?/>
Sure, this is more work for you, but it'll work.
> In the XSP taglib I could handle the parameters and name them correctly. But
> one problem remains, the graphics designer decides the names of the
> formfields that the XSP programmer uses! Ideally the XSP programmer should
> take care of everything regarding parsing of parameters. That is not done
> this way. The string "<input type="hidden" name="actnr"
> value="{$current}"/>" could be calculated in the XSP, but the graphics
> designer still has to take care of the string gets inserted on the correct
> place in the form.
The graphics designer doesn't have much to do with it, this is the job
of the stylesheet writer. Your designer gives you some HTML code and
you, the developer, write a stylesheet from it.
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>