You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Bjarne Jensen <bh...@ruc.dk> on 2001/06/13 10:01:19 UTC
Maintaining Cocoon-layout in WYSIWYG-HTML-editor
I have read the article Style-free XSLT Style Sheets
(http://www.xml.com/pub/a/2000/07/26/xslt/xsltstyle.html) by Eric van der
Vlist and this is IMHO a really great article that told me how to splits the
XHTML and XSLT in to different layout-files. Does anyone think it would work
in real life, if the XHTML was maintained by a WYSIWYG editor like
dreamweaver with support for XHTML - anybody know such an editor? (if not
you can use Dreamweaver and Tidy). The XSLT-part of the layout would be
maintained by a programmer or a trained graphical designer. Anyone tried
this in real life I would really like to hear some opinions? My own
opinion is that I think this would work because the HTML would be made as
useual and the process of applying the new HTML to the
Cocoon-web-application could be done automatically without involving the
programmer - does anyone disagree or agree?
Thanks for any comments
/Bjarne
---------------------------------------------------------------------
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: SV: Maintaining Cocoon-layout in WYSIWYG-HTML-editor
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Bjarne Jensen a écrit :
>
> 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?
>
We've customized it with JavaScript. Some new menus are added to insert
these annotations. We've also added icons so that additional markup is
visible in edition mode. You can find docs about this in the "Extending
DreamWeaver" section of help.
> The text Paul and 33333 is deleted when the pages is generated right
> dynamically, right?
>
Yep. And replaced with real data.
> for-each=Person is in my opinion programming and not layout (XSLT is a
> real programming-language Turin-complete and so on, its not just layout).
> So havent you mixed programming and layout in your example? That was why I
> wrote <my:dynaimcContentName/> in stead of <xsl:value-of select=Name/>.
>
This is not XSL, even if we've borrowed some of its syntax. The
primitives are dedicated to data insertion (including iteration on
data). There are also many other features but I will not detail them
here.
> 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?
>
We're targetting mainly intranet webapps (not web sites or portals) and
this approach covers most of the needs, even if advanced features of our
products allow to use several XSL for different parts of the page.
> 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 doesnt get mixed up, right?.
.On top of the
> transforming logic there is some layout.
>
We did this component. It allows the application to access data as XML
conforming to an application data model whatever the underlying storage
system is.
> Thanks you very much 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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
SV: SV: Maintaining Cocoon-layout in WYSIWYG-HTML-editor
Posted by Bjarne Jensen <bh...@ruc.dk>.
Well it's my email-program. SV: is danish but means exactly the same as RE:
(reply) :-) Do not know if SV has another meaning also.
The best way to search in old mails is IMHO by using www.google.com and
typing "site:mailman.real-time.com" + "what you search for", like:
"site:mailman.real-time.com SV:", finds mails send to this list that
contains "SV:" + I got the tip by reading an old posted mail.
Hope that I am not disturbing the list IYHO.
/Bjarne
-----Oprindelig meddelelse-----
Fra: Daniel Pfuhl [mailto:pfuhli@yahoo.de]
Sendt: 13. juni 2001 14:50
Til: cocoon-users@xml.apache.org
Emne: Re: SV: Maintaining Cocoon-layout in WYSIWYG-HTML-editor
Hi
sorry for my lack of knowledge but
what means "SV" in front of the subject
of a mail?
where can I find such information so that
I don't have to disturb the list again searching
such answers.
thanks
daniel
=====
--------------------------------------------------------
Daniel Pfuhl
mailto:daniel@dphome.de
__________________________________________________________________
Do You Yahoo!?
Gesendet von Yahoo! Mail - http://mail.yahoo.de
---------------------------------------------------------------------
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
---------------------------------------------------------------------
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: SV: Maintaining Cocoon-layout in WYSIWYG-HTML-editor
Posted by Daniel Pfuhl <pf...@yahoo.de>.
Hi
sorry for my lack of knowledge but
what means "SV" in front of the subject
of a mail?
where can I find such information so that
I don't have to disturb the list again searching
such answers.
thanks
daniel
=====
--------------------------------------------------------
Daniel Pfuhl
mailto:daniel@dphome.de
__________________________________________________________________
Do You Yahoo!?
Gesendet von Yahoo! Mail - http://mail.yahoo.de
---------------------------------------------------------------------
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
SV: Maintaining Cocoon-layout in WYSIWYG-HTML-editor
Posted by Bjarne Jensen <bh...@ruc.dk>.
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, its not just layout).
So havent 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 doesnt 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:sylvain.wallez@anyware-tech.com]
Sendt: 13. juni 2001 13:39
Til: cocoon-users@xml.apache.org
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 doesnt 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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
---------------------------------------------------------------------
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Maintaining Cocoon-layout in WYSIWYG-HTML-editor
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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 doesnt 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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
SV: SV: Maintaining Cocoon-layout in WYSIWYG-HTML-editor
Posted by Bjarne Jensen <bh...@ruc.dk>.
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?
-----
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 doesnt it?
It is possible to have your own logicsheets in C1 so I really does not
understand the difference here?
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.
-----
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?
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?
Thank you ones again :-)
/Bjarne
-----Oprindelig meddelelse-----
Fra: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
Sendt: 13. juni 2001 11:56
Til: cocoon-users@xml.apache.org
Emne: Re: SV: Maintaining Cocoon-layout in WYSIWYG-HTML-editor
Bjarne Jensen a écrit :
>
> Well that sounds really interesting congratulations :-) So by
maintaining
> the website like this you have a separation between layout and content.
What
> about seperation between content and program-logic have you also
> accomplished this? Are there any need for that?
>
Content is generated by XSPs (which was the main way of doing it with
Cocoon1, but this changes with C2) which calls application logic Java
code either directly through <xsp:logic> or using specialized
logicsheets. We also have an XML persistence engine that hides
SQL/LDAP/files/Whatever for data access. This leads to true
presentation/logic/persistence separation.
> And then another question. What if you compute a table (so that you don't
> know how long it would be) is this also maintained in Dreamweaver or do
> you have the HTML that makes the TABLE inside the XSLT in that situation?
I
> cant figure out how to maintain a table like this in Dreamweaver only in
> XSLT.
>
Among our specialized tags, some are structure-oriented. The designer
just has to mark the table with the data collection he wants to display,
and this generates an <xsl:foreach> in the resulting XSL, adding rows as
necessary and feeding cells with live data (this works not only with
tables, but with any repetivite structure : lists, paragraphs, popups,
etc).
The main ideas behind all this are :
- web pages, even if dynamic, should be editable by a web designer (with
no programming skills)
- turning a static page into a dynamic one shouldn't be destructive : in
JSP/ASP/PHP, data access code replaces example data that the designer
has put in the page during the design. With our approach, markup
identifying the data surrounds (tags) or marks (attributes) the static
example data.
The benefits are that you can always show your dynamic pages as static
ones (just send a bunch of HTML files to your customer to show him what
his app looks like) and that a web designer can update the pages with
his favorite tool even if they're dynamic (easy maintenance).
> Thank you very much for your comment :-)
>
WYSIWYG editing is IMO the main feature that's missing for XML/XSL to
spread the whole web industry. That's what we're trying to do.
> /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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
---------------------------------------------------------------------
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: SV: Maintaining Cocoon-layout in WYSIWYG-HTML-editor
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Bjarne Jensen a écrit :
>
> Well that sounds really interesting congratulations :-) So by maintaining
> the website like this you have a separation between layout and content. What
> about seperation between content and program-logic have you also
> accomplished this? Are there any need for that?
>
Content is generated by XSPs (which was the main way of doing it with
Cocoon1, but this changes with C2) which calls application logic Java
code either directly through <xsp:logic> or using specialized
logicsheets. We also have an XML persistence engine that hides
SQL/LDAP/files/Whatever for data access. This leads to true
presentation/logic/persistence separation.
> And then another question. What if you compute a table (so that you don't
> know how long it would be) is this also maintained in Dreamweaver or do
> you have the HTML that makes the TABLE inside the XSLT in that situation? I
> cant figure out how to maintain a table like this in Dreamweaver only in
> XSLT.
>
Among our specialized tags, some are structure-oriented. The designer
just has to mark the table with the data collection he wants to display,
and this generates an <xsl:foreach> in the resulting XSL, adding rows as
necessary and feeding cells with live data (this works not only with
tables, but with any repetivite structure : lists, paragraphs, popups,
etc).
The main ideas behind all this are :
- web pages, even if dynamic, should be editable by a web designer (with
no programming skills)
- turning a static page into a dynamic one shouldn't be destructive : in
JSP/ASP/PHP, data access code replaces example data that the designer
has put in the page during the design. With our approach, markup
identifying the data surrounds (tags) or marks (attributes) the static
example data.
The benefits are that you can always show your dynamic pages as static
ones (just send a bunch of HTML files to your customer to show him what
his app looks like) and that a web designer can update the pages with
his favorite tool even if they're dynamic (easy maintenance).
> Thank you very much for your comment :-)
>
WYSIWYG editing is IMO the main feature that's missing for XML/XSL to
spread the whole web industry. That's what we're trying to do.
> /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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
SV: Maintaining Cocoon-layout in WYSIWYG-HTML-editor
Posted by Bjarne Jensen <bh...@ruc.dk>.
Well that sounds really interesting congratulations :-) So by maintaining
the website like this you have a separation between layout and content. What
about seperation between content and program-logic have you also
accomplished this? Are there any need for that?
And then another question. What if you compute a table (so that you don't
know how long it would be) is this also maintained in Dreamweaver or do
you have the HTML that makes the TABLE inside the XSLT in that situation? I
cant figure out how to maintain a table like this in Dreamweaver only in
XSLT.
Thank you very much for your comment :-)
/Bjarne
-----Oprindelig meddelelse-----
Fra: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
Sendt: 13. juni 2001 10:40
Til: cocoon-users@xml.apache.org
Emne: Re: Maintaining Cocoon-layout in WYSIWYG-HTML-editor
Bjarne Jensen a écrit :
>
> I have read the article Style-free XSLT Style Sheets
> (http://www.xml.com/pub/a/2000/07/26/xslt/xsltstyle.html) by Eric van der
> Vlist and this is IMHO a really great article that told me how to splits
the
> XHTML and XSLT in to different layout-files. Does anyone think it would
work
> in real life, if the XHTML was maintained by a WYSIWYG editor like
> dreamweaver with support for XHTML - anybody know such an editor? (if not
> you can use Dreamweaver and Tidy). The XSLT-part of the layout would be
> maintained by a programmer or a trained graphical designer. Anyone tried
> this in real life I would really like to hear some opinions? My own
> opinion is that I think this would work because the HTML would be made as
> useual and the process of applying the new HTML to the
> Cocoon-web-application could be done automatically without involving the
> programmer - does anyone disagree or agree?
>
> Thanks for any comments
> /Bjarne
>
We use a similar approach here : a regular HTML page built with a
WYSIWYG editor is augmented with specialized markup that identifies
variable parts of the page. This page is then "compiled" in an XSL that
merges presentation and data to produce dynamic pages.
To avoid HTML source code edition for adding our specialized markup, we
have extended DreamWeaver (it's easily customizable in JavaScript) so
that the web designer can do it all in WYSIWYG mode.
About Tidy, we had some problems with it because it doesn't like
non-HTML markup. So we derived the AElfred parser that's in SAXON
(originally written by David Megginson, author of SAX) so that it
accepts HTML (auto-closing tags, value-less attributes, etc) and our
markup.
And thus we obtain a true separation between presentation and logic, and
a kind of WYSIWYG XSL editor with DreamWeaver !
--
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
---------------------------------------------------------------------
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Maintaining Cocoon-layout in WYSIWYG-HTML-editor
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Bjarne Jensen a écrit :
>
> I have read the article Style-free XSLT Style Sheets
> (http://www.xml.com/pub/a/2000/07/26/xslt/xsltstyle.html) by Eric van der
> Vlist and this is IMHO a really great article that told me how to splits the
> XHTML and XSLT in to different layout-files. Does anyone think it would work
> in real life, if the XHTML was maintained by a WYSIWYG editor like
> dreamweaver with support for XHTML - anybody know such an editor? (if not
> you can use Dreamweaver and Tidy). The XSLT-part of the layout would be
> maintained by a programmer or a trained graphical designer. Anyone tried
> this in real life I would really like to hear some opinions? My own
> opinion is that I think this would work because the HTML would be made as
> useual and the process of applying the new HTML to the
> Cocoon-web-application could be done automatically without involving the
> programmer - does anyone disagree or agree?
>
> Thanks for any comments
> /Bjarne
>
We use a similar approach here : a regular HTML page built with a
WYSIWYG editor is augmented with specialized markup that identifies
variable parts of the page. This page is then "compiled" in an XSL that
merges presentation and data to produce dynamic pages.
To avoid HTML source code edition for adding our specialized markup, we
have extended DreamWeaver (it's easily customizable in JavaScript) so
that the web designer can do it all in WYSIWYG mode.
About Tidy, we had some problems with it because it doesn't like
non-HTML markup. So we derived the AElfred parser that's in SAXON
(originally written by David Megginson, author of SAX) so that it
accepts HTML (auto-closing tags, value-less attributes, etc) and our
markup.
And thus we obtain a true separation between presentation and logic, and
a kind of WYSIWYG XSL editor with DreamWeaver !
--
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>