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]>
