Lorenzo,
to ease the burden on your graphic designers, you could even build a sort of
"taglib" with XML elements to be expanded by an appropriate XSL.
I've done a lib which allows me to specify "smart" HTML without the need of
XSL (well, it works behind the scenes)... here's an example:
<img src="{insert-request-parameter:images-home}/blank.gif" border="0"
width="4"/>
I hope you got the idea :)
Best regards,
Luca Morandini
[EMAIL PROTECTED]
> -----Messaggio originale-----
> Da: Lorenzo De Sio [mailto:l.desio@;w4b.it]
> Inviato: marted́ 12 novembre 2002 12.35
> A: '[EMAIL PROTECTED]'
> Oggetto: R: Separation of concerns?
>
>
> 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: [EMAIL PROTECTED]
> 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: <[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/faq/index.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
>
We are protected from the virus by Norton Antivirus Corporate Edition
---------------------------------------------------------------------
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: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
