You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Torsten Curdt <tc...@dff.st> on 2000/09/15 22:00:53 UTC
complex site design issues (long)
ok, guys, somehow I feel up to now
everybody is doing his own thing when it
comes to a complex site design.
I would really like to start a constructive
thread on finding "THE concept" (I know there
is not THE one - but let us share some thought)
I've been working with Cocoon1 for a few months
now. It was my first time really using XML/XSLT
and of courese XSP. So my lack of knowledge
shall be forgiven ;)
We are building a dynamic site which needs to be
* secured: we need to have a form where known
users can login. After that all connetions
are done via https
* multi-lingual: user may choose his preferred
language to see the site
* multi-media: user may choose to see the site
with his browser as well as WAP or PDF
* easy to maintain: a clean separation of design,
content and logic is desired
* paging: paging through a database generated
list via "page 1 2 3 4" and "next" "prev"
Our first approach was to have one XML file which
represents all data that is needed in one process.
(language specific, media independent)
Depending on the media there were 2 to 5 stylesheets
to display parts of it: (simplified...)
x = displayed
| = not displayed
stylesheet 1 2 3
<order> | | |
<info>Please fill out the fields</info> x x x
<form> | | |
<input> | | |
<text>your name here:</text> x | |
<lineedit> x | |
</input> | | |
<input> | | |
<text>your address here:</text> | x |
<lineedit> | x |
</input> | | |
<input> | | |
<image href="images/textasimage.gif/> | | x
<combo name="state"/> | | x
</input> | | |
</form> | | |
</order> | | |
Since the XML file is media independent defining
subsets does not make much sense... How can you
know if the subsets fit on every media!?
So we let the stylesheet grab the stuff by itself.
We had URLs like:
http://host/de/order.xml?page=1
http://host/de/order.xml?page=2
So what you can see on page=3 depends heavily
on the media.
To separate the logic from the content and the
design we used the concept of the clean-page
example.
We had one XSP file for the logic which grabs
the data from a database and then enriches the XML
tree. So our combos got filled for example.
(We made even another step of separation and
created JavaBeans that provide the data from
the database. So we didn't have to put the sql
strings inside the code.)
This approach had some design flaws because we
tried to put all texts into the XML file so that
every stylesheet (HTML or WAP) can access it.
But what's up when you need media specific texts.
(What about showing a simple welcome text over 3
WML card which is one page in HTML?)
And sometimes you really had to make some real quirks
to show a simple text in your XSL!
Number two: My XSP fills the XML from the database.
It always fills in ALL the dynamic content but only a
fraction is needed! => SLOW!!
(All combos of a process are filled on any page
request!!Large DOM trees!)
What really rocked was the way you were able to
implement a new media type. Just create ONE new XSL
set and that's it... got it for any language...
Unfortunately it was definitly too slow...
For our level based user authentification system
we used two special attributes and an exception tag.
One of these attributes defined the needed authorisation
level for that specific tag and all it's childs.
If a redirect attribute was given, an insufficient
userlevel leeds to -well- a page redirect or otherwise
the exception tag.
These authentification definitions can also be nested.
We improved this approach a bit more and removed the
need of the exception tag.
<page>
<welcome userlevel="0">Hello<username userlevel="1-"/>,
welcome to our site
</welcome>
<text userlevel="0">
Sorry, you need to log in to see this text
</text>
<text userlevel="1-">
Some text
</text>
</page>
<page>
<settings userlevel="1-3,5" redirect="/error.xml">
<name/>
<street/>
</settings>
</page>
All checking is done in the corresponding XSP file.
--
Our second approach was meant to reduce the DOM trees
to a minimum and only create what is shown.
We started more to use include techniques. So we
have a default XSP file which is include by any XSP
file. A default navigation XML which holds the standard
site navigation an per page navigation which both
gets included into the content XML files...
It's a very complex directory structure probably to
much at this time...
We realized it too complex to maintain or at least
not so useable as we expected...
And it got faster but is still too slow though... :(
(300ms on a Pentium III-750 for a static page is much
to slow! [Tomcat3.1+Cocoon1.75])
--
We 're now re-thinking all of these structures to
gain higher performance and maintainability.
First of all we're thinking of changing from the
clean-page based way to a combination of taglib
and beans. Something like:
<page>
<order>
text
<combo><beans:get method="getAll" path="com.dff.orders"/></combo>
</order>
</page>
The parameter committal has to be considered... But still
there is the question of media independence... What do you guys
think... should a XML be media independent (I thought so)
or is it just a more structured way of creating HTML sites...
Sorry, for the long post. Still there is much more to say
and discuss.
...let this be the beginning.
--
Torsten
RE: complex site design issues
Posted by Torsten Curdt <tc...@dff.st>.
> The combination of Struts, Cocoon, a good servlet/jsp container
> like Resin,
> and an EJB container like Inrpise Application Server (Among many)
> will give
> you a great basis to build your own solution. I currently use this
> combination to serve up Internationalized WAP/HTML/PDF sites for
> my clients.
>
> Sorry man but no one technology is going to solve all of your plroblems.
I know... that's why I want to discuss some options, hear some experiences,
discuss the pros and cons and see how they integrate into cocoon1 and
cocoon2!!
Here are so many people trying to start a site with cocoon...
Trying with some pages is one thing but if it comes to complex
site there are several design issues to be thought of. (maybe
you can share some thought on my original message or tell from
the benefits of your sollution?)
--
Torsten
RE: complex site design issues
Posted by Russ White <ru...@earthlink.net>.
The combination of Struts, Cocoon, a good servlet/jsp container like Resin,
and an EJB container like Inrpise Application Server (Among many) will give
you a great basis to build your own solution. I currently use this
combination to serve up Internationalized WAP/HTML/PDF sites for my clients.
Sorry man but no one technology is going to solve all of your plroblems.
-----Original Message-----
From: Torsten Curdt [mailto:tcurdt@dff.st]
Sent: Saturday, September 16, 2000 8:28 AM
To: cocoon-users@xml.apache.org
Subject: RE: complex site design issues
Asking for the url of struts doesn't mean
there shouldn't be any discussion at all...
I don't think struts will really solve all our problems!
--
Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
RE: complex site design issues
Posted by Torsten Curdt <tc...@dff.st>.
Asking for the url of struts doesn't mean
there shouldn't be any discussion at all...
I don't think struts will really solve all our problems!
--
Torsten
RE: complex site design issues (long)
Posted by Torsten Curdt <tc...@dff.st>.
Can anyone provide an example that show how
it integrates into Cocoon?
--
Torsten
> -----Original Message-----
> From: David Ramsey [mailto:dramsey@neosoft.com]
> Sent: Friday, September 15, 2000 10:15 PM
> To: cocoon-users@xml.apache.org
> Subject: Re: complex site design issues (long)
>
>
> http://jakarta.apache.org/struts/index.html
>
> It's an Apache Jakarta project.
>
> David Ramsey
> ==============================================================
> "Always listen to experts. They'll tell you what can't be
> done, and why. Then do it."
> -- Lazarus Long, in Robert Heinlein's Time Enough for Love
> ==============================================================
>
> ----- Original Message -----
> From: "Torsten Curdt" <tc...@dff.st>
> To: <co...@xml.apache.org>
> Sent: Friday, September 15, 2000 3:08 PM
> Subject: RE: complex site design issues (long)
>
>
> > ...can you give an url?
> >
> > > -----Original Message-----
> > > From: Russ White [mailto:russwyte@earthlink.net]
> > > Sent: Friday, September 15, 2000 10:02 PM
> > > To: cocoon-users@xml.apache.org
> > > Subject: RE: complex site design issues (long)
> > >
> > >
> > > You may have already done this, but check out STRUTS
> > > It rock for this kind of site, especially internationalization
> > > issues. Also
> > > sticky forms are handled nicely.
> > > It is a very cool framework. It also fits nicely with Cocoon
> and Resin.
>
Re: complex site design issues (long)
Posted by David Ramsey <dr...@neosoft.com>.
http://jakarta.apache.org/struts/index.html
It's an Apache Jakarta project.
David Ramsey
==============================================================
"Always listen to experts. They'll tell you what can't be
done, and why. Then do it."
-- Lazarus Long, in Robert Heinlein's Time Enough for Love
==============================================================
----- Original Message -----
From: "Torsten Curdt" <tc...@dff.st>
To: <co...@xml.apache.org>
Sent: Friday, September 15, 2000 3:08 PM
Subject: RE: complex site design issues (long)
> ...can you give an url?
>
> > -----Original Message-----
> > From: Russ White [mailto:russwyte@earthlink.net]
> > Sent: Friday, September 15, 2000 10:02 PM
> > To: cocoon-users@xml.apache.org
> > Subject: RE: complex site design issues (long)
> >
> >
> > You may have already done this, but check out STRUTS
> > It rock for this kind of site, especially internationalization
> > issues. Also
> > sticky forms are handled nicely.
> > It is a very cool framework. It also fits nicely with Cocoon and Resin.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
RE: complex site design issues (long)
Posted by Torsten Curdt <tc...@dff.st>.
...can you give an url?
> -----Original Message-----
> From: Russ White [mailto:russwyte@earthlink.net]
> Sent: Friday, September 15, 2000 10:02 PM
> To: cocoon-users@xml.apache.org
> Subject: RE: complex site design issues (long)
>
>
> You may have already done this, but check out STRUTS
> It rock for this kind of site, especially internationalization
> issues. Also
> sticky forms are handled nicely.
> It is a very cool framework. It also fits nicely with Cocoon and Resin.
RE: complex site design issues (long)
Posted by Russ White <ru...@earthlink.net>.
You may have already done this, but check out STRUTS
It rock for this kind of site, especially internationalization issues. Also
sticky forms are handled nicely.
It is a very cool framework. It also fits nicely with Cocoon and Resin.
> -----Original Message-----
> From: Torsten Curdt [mailto:tcurdt@dff.st]
> Sent: Friday, September 15, 2000 4:01 PM
> To: Cocoon-Users
> Subject: complex site design issues (long)
>
>
> ok, guys, somehow I feel up to now
> everybody is doing his own thing when it
> comes to a complex site design.
> I would really like to start a constructive
> thread on finding "THE concept" (I know there
> is not THE one - but let us share some thought)
>
> I've been working with Cocoon1 for a few months
> now. It was my first time really using XML/XSLT
> and of courese XSP. So my lack of knowledge
> shall be forgiven ;)
>
> We are building a dynamic site which needs to be
> * secured: we need to have a form where known
> users can login. After that all connetions
> are done via https
> * multi-lingual: user may choose his preferred
> language to see the site
> * multi-media: user may choose to see the site
> with his browser as well as WAP or PDF
> * easy to maintain: a clean separation of design,
> content and logic is desired
> * paging: paging through a database generated
> list via "page 1 2 3 4" and "next" "prev"
>
> Our first approach was to have one XML file which
> represents all data that is needed in one process.
> (language specific, media independent)
> Depending on the media there were 2 to 5 stylesheets
> to display parts of it: (simplified...)
>
> x = displayed
> | = not displayed
> stylesheet 1 2 3
> <order> | | |
> <info>Please fill out the fields</info> x x x
> <form> | | |
> <input> | | |
> <text>your name here:</text> x | |
> <lineedit> x | |
> </input> | | |
> <input> | | |
> <text>your address here:</text> | x |
> <lineedit> | x |
> </input> | | |
> <input> | | |
> <image href="images/textasimage.gif/> | | x
> <combo name="state"/> | | x
> </input> | | |
> </form> | | |
> </order> | | |
>
> Since the XML file is media independent defining
> subsets does not make much sense... How can you
> know if the subsets fit on every media!?
> So we let the stylesheet grab the stuff by itself.
>
> We had URLs like:
> http://host/de/order.xml?page=1
> http://host/de/order.xml?page=2
>
> So what you can see on page=3 depends heavily
> on the media.
>
> To separate the logic from the content and the
> design we used the concept of the clean-page
> example.
> We had one XSP file for the logic which grabs
> the data from a database and then enriches the XML
> tree. So our combos got filled for example.
>
> (We made even another step of separation and
> created JavaBeans that provide the data from
> the database. So we didn't have to put the sql
> strings inside the code.)
>
> This approach had some design flaws because we
> tried to put all texts into the XML file so that
> every stylesheet (HTML or WAP) can access it.
> But what's up when you need media specific texts.
> (What about showing a simple welcome text over 3
> WML card which is one page in HTML?)
> And sometimes you really had to make some real quirks
> to show a simple text in your XSL!
>
> Number two: My XSP fills the XML from the database.
> It always fills in ALL the dynamic content but only a
> fraction is needed! => SLOW!!
> (All combos of a process are filled on any page
> request!!Large DOM trees!)
>
> What really rocked was the way you were able to
> implement a new media type. Just create ONE new XSL
> set and that's it... got it for any language...
>
> Unfortunately it was definitly too slow...
>
> For our level based user authentification system
> we used two special attributes and an exception tag.
> One of these attributes defined the needed authorisation
> level for that specific tag and all it's childs.
> If a redirect attribute was given, an insufficient
> userlevel leeds to -well- a page redirect or otherwise
> the exception tag.
> These authentification definitions can also be nested.
>
> We improved this approach a bit more and removed the
> need of the exception tag.
>
> <page>
> <welcome userlevel="0">Hello<username userlevel="1-"/>,
> welcome to our site
> </welcome>
> <text userlevel="0">
> Sorry, you need to log in to see this text
> </text>
> <text userlevel="1-">
> Some text
> </text>
> </page>
>
> <page>
> <settings userlevel="1-3,5" redirect="/error.xml">
> <name/>
> <street/>
> </settings>
> </page>
>
> All checking is done in the corresponding XSP file.
>
> --
>
> Our second approach was meant to reduce the DOM trees
> to a minimum and only create what is shown.
> We started more to use include techniques. So we
> have a default XSP file which is include by any XSP
> file. A default navigation XML which holds the standard
> site navigation an per page navigation which both
> gets included into the content XML files...
>
> It's a very complex directory structure probably to
> much at this time...
>
> We realized it too complex to maintain or at least
> not so useable as we expected...
>
> And it got faster but is still too slow though... :(
> (300ms on a Pentium III-750 for a static page is much
> to slow! [Tomcat3.1+Cocoon1.75])
>
> --
>
> We 're now re-thinking all of these structures to
> gain higher performance and maintainability.
>
> First of all we're thinking of changing from the
> clean-page based way to a combination of taglib
> and beans. Something like:
>
> <page>
> <order>
> text
> <combo><beans:get method="getAll" path="com.dff.orders"/></combo>
> </order>
> </page>
>
> The parameter committal has to be considered... But still
> there is the question of media independence... What do you guys
> think... should a XML be media independent (I thought so)
> or is it just a more structured way of creating HTML sites...
>
> Sorry, for the long post. Still there is much more to say
> and discuss.
>
> ...let this be the beginning.
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>