cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Russ White" <russw...@earthlink.net>
Subject RE: complex site design issues (long)
Date Fri, 15 Sep 2000 20:02:16 GMT
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
>
>


Mime
View raw message