cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lorenzo De Sio <l.de...@w4b.it>
Subject R: Separation of concerns?
Date Tue, 12 Nov 2002 11:34:40 GMT
I think you pointed out quite a big issue, though from my point of view this
is not such a problematic one.

I currently work in a co-founded small company. We are 1 programmer, 1
HTML/graphic designer, 1 HTML/Flash developer, 1 junior developer which has
no actual programming skills, but quickly learned HTML and XSL.

You could ask: why Cocoon in such a small team? The answer is XSL itself.

Currently, our application development work in the past few years (we are
focused on small-medium businesses) has been mainly on e-commerce,
data-driven, customer-updatable sites and, later, content management for
small-to-medium publishing needs.

We ended up in producing many, many times the same mini-applications,
branding them differently each time. This led us (even on the ASP platform
we were, and still mainly are, working on) to XSL. ASP already (no .NET) has
a few underlooked features (XML serialization of a Recordset object to a
Stream object, for example, which is quite fast and can support XSL
transformation) which allowed us to separate the presentation layer from the
content/logic one. This actually allowed me to totally drop the production
of such applications to the junior programmer. He also benefits from the
separation, by actually reusing 99% of the code (we embedded database write
logic in a single "library" .asp file, the only required code changes are
for changing SELECT queries), and by being able to personalize the look by
only changing one XSL template file.

This simple implementation of a XML/XSL separation, much simpler but similar
to Cocoon's approach, already gave us these benefits.

The next step, which we are experiencing in the development of quite a large
e-learning site (with Cocoon), is to directly let the designers access the
XSLs, by giving them the basic XSL skills required to do the job.

I find that The XSL skills required are not really heavy. Heavy XSL skills
are, in my opinion, required in working on complex structure transformations
that come *before* the final, presentation-aimed XSL transformation. Our
experience is that, instead, the final transformation deals 99% of the time
with: a) a container with many rows of data (a master, which can be easily
handled even with a simple <xsl:for-each/>; b) an item of data with many
fiels (a detail). Such XSL-drive HTML renderings are done mostly using
<xsl:value-of/> inserted into traditional HTML markup and I found that even
the HTML designer and the Flash developer are comfortable with them.

Of course you need designers who know HTML. But even this requirement could
fade in the future, since tools like Dreamweaver already support XHTML
conformance, and they could easily be scripted to allow insertion of XSL
value elements and for-each loops.


L.


-----Messaggio originale-----
Da: Andrew Watt [mailto:andrew@andrewwatt.com]
Inviato: martedì 12 novembre 2002 10.47
A: cocoon-users@xml.apache.org
Oggetto: Separation of concerns?


I have a (multi-part) question about the suggested "separation of concerns" 
that it is proposed that Cocoon achieves.

I would like to ask how Cocoon is being used in a production environment, 
specifically how does separation of roles work out. Does it actually work 
in practice? How easy is it in production settings to find "graphics 
designers" who are also fluent in XSLT?

Aren't such bi-skilled people essential to achieve the implementation of 
the "style" concern? Or, in practice, are "real" designers and "real" XSLT 
coders working together on the XSLT stylesheets?

I guess that the suspicion that is lurking at the back of my mind is that 
the "confusion of concerns" (to coin a phrase) is, to some extent, being 
shuffled off into the "style" box. Of course, that may be a signficant 
improvement over other workflows.

I can see pretty clearly the cleanness of the current approach for 
programmers/administrators ... designers don't touch the content nor the 
sitemaps ... but I do have slight doubts about the cleanness of the style 
concern. Or maybe my doubt is about the realisticness of finding graphics 
designers comfortable to code in XSLT.

I notice, too, that style is little mentioned in the online documentation 
and doesn't appear as a term in the index of the Langham/Ziegeler book. 
That makes me wonder if others either have doubts too about the style 
concern or, perhaps, haven't looked (yet?) in a detailed way at how this 
will work.

I wonder if what has mostly been happening up to now is XSLT-coders 
dabbling with design? :)

I would be interested in any stories about the reactions of "pure" graphics 
designers in a production setting when first faced with the Cocoon approach 
and how they and, I suspect, XSLT-programmer colleagues actually worked out 
a practical workflow.

Andrew Watt


---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>

---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

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