You wrote:
>“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 !”
I have tried this in my IE 5.5 it looks like a normal table. So IE5.5 does
not care about the extra attributes in the <TR> :-) Netscape 4.7 does not
show anything :-( so to use this approach the designers has to use IE5.5 (or
similar). My question is: how do you put the extra attributes in
Dreamweaver? (I have version 3). Are the designer typing them manually – or
are you using a Javascript or? How does it look like? How do I configure my
Dreamweaver?
The text “Paul” and “33333” is deleted when the pages is generated right
dynamically, right?
“for-each=”Person”” is in my opinion programming and not layout (XSLT is a
real programming-language Turin-complete and so on, it’s not just layout).
So haven’t you mixed programming and layout in your example? That was why I
wrote <my:dynaimcContentName/> in stead of <xsl:value-of select=”Name”/>.
In the Article (Style-free XSLT) the XSLT is split in two different files
but the layout gets calculated run-time. Is this the same with your
appliaction?
You also wrote:
> 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.
Is this component made by you or another vendor? This is some kind of
interface-program-logic between the data-model and the transforming logic
that guarantees the data doesn’t get mixed up, right?. ….On top of the
transforming logic there is some layout.
Thanks you very much again :-)
/Bjarne
-----Oprindelig meddelelse-----
Fra: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
Sendt: 13. juni 2001 13:39
Til: [EMAIL PROTECTED]
Emne: Re: Maintaining Cocoon-layout in WYSIWYG-HTML-editor
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]>
---------------------------------------------------------------------
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]>
