cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Curdt" <>
Subject complex site design issues (long)
Date Fri, 15 Sep 2000 20:00:53 GMT
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:

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

  <welcome userlevel="0">Hello<username userlevel="1-"/>,
   welcome to our site
  <text userlevel="0">
    Sorry, you need to log in to see this text
  <text userlevel="1-">
    Some text

  <settings userlevel="1-3,5" redirect="/error.xml">

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:

      <combo><beans:get method="getAll" path="com.dff.orders"/></combo>

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.

View raw message