Bjarne Jensen a écrit :
>
> Is this correctly understood?
>
> ------
> Dreamweaver creates HTML like this:
>
> <table cellspacing=”2”>
> <tr><td><my:dynaimcContentName/></td><td><my:dynaimcContentPhone/></td></tr>
> </table>
>
> And your XSLT render this to something like:
>
> <table cellspacing=”2”>
> <tr><td>Paul</td><td>33333333</td></tr>
> <tr><td>Ann</td><td>33333332</td></tr>
> …
> ..
> </table>
>
> How do you do that? Gets the parents and so I XSLT?
>
In your example, static example data is replaced by dynamic markup,
which is precisely what we wanted to avoid. The augmented html rather
looks like this (the datamodel namespace identifies markup related to
the application data model).
<table>
<tr datamodel:for-each="Person">
<td><datamodel:value-of select="Name">Paul</datamodel:value-of></td>
<td><datamodel:value-of
select="Phone">33333"</datamodel:value-of></td>
</tr>
</table>
Put this in a web browser, and it will be rendered correctly with
example data, even if it's in fact a dynamic page !
> -----
>
> You wrote:
>
> ”..but this changes with C2) which calls application logic Java
> code either directly through <xsp:logic> or using specialized
> logicsheets. “
>
> C1 calls application logic in Java directly doesn’t it?
> It is possible to have your own logicsheets in C1 so I really does not
> understand the difference here?
>
No actual difference since a logicsheet always finally gets translated
to Java code. We use logicsheets for commonly used features while
<xsp:logic> is used in non-reusable specific needs.
> I know the sitemap can centralize Processing Instructions (PI) in C2 and
> that is not possible in C1 and that can give a better separation. But that
> has nothing to do with what your are writing.
>
Well, it has in a certain way : in C1, the fact that an XSP decides
(through PI's) how it is to be rendered is mixing of concerns. With C2's
sitemap, you can use a single XSP file to produce content that gets
rendered differently (html, wml, pdf, excel, svg, etc) depending on the
sitemap-defined context.
> -----
>
> You also wrote:
> “We also have an XML persistence engine that hides
> SQL/LDAP/files/Whatever for data access.”
>
> What is an XML persistence engine?
>
A component that allows XML data to be read/write/queried in any target
persitence mechanism for which we have written an implementation (files,
SQL db, LDAP directories, etc). The application doesn't have to know
_how_ data is stored.
> Hides the filename in the URL, or?
>
> Well please tell more about this
>
> PS: I really like hearing how you made the separation. The reason why I am
> so interested in the separation is that I am writing the last paper in my
> education and the subject is separation between layers in webapplications. 3
> years ago I worked in a webfirm that mixed the layers and that was a big
> problem then. I think the problem still remains in a lot of companyes you
> are the only one I have ever head about that seems to have accomplished
> this. I agree (se below) to you why the layers should be separate. Another
> reason for having the layers separate is that you can substitute one or two
> layers and you have a new application that should suits a new customer. Are
> you doing that?
>
Yep, separation is a big win in that domain. Some real-life examples :
- during the development of a project, the customer (which was providing
the database structure) decided to switch from SQLServer to Oracle and
change the database model to correct some design flaws of the initial DB
(information redundancy, unnecessary join tables and the like). Since we
had designed a datamodel according to the application needs and not as a
copy of the DB structure, switching to the new DB structure was just a
matter of rewriting the datamodel/SQL mapping (a few days), without
touching a single line in application code and presentation.
- we've built some generic applications in the area of human resources
and project management. Just as in the previous example, these are built
according an application data model, and not a DB model. Adapting the
application to the customer environment is just a matter of persistance
configuration (fetch user information from LDAP/Files/SQL tables/...,
store data in Oracle/Informix/Access/...) and graphic layout to adapt to
the customer's graphic standard. No application change.
> Thank you ones again :-)
> /Bjarne
>
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
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: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
