I've taken this approach in the past. I've found that it involves heavy (or at least essential) use of the document() function. This approach has been documented in a couple articles on XML.com.
http://www.xml.com/pub/a/2000/07/26/xslt/xsltstyle.html http://www.xml.com/pub/a/2002/03/27/templatexslt.html But I learned there are apparently problems with use of the document() function in Cocoon, given current limitations with respect to caching. http://xml.apache.org/cocoon/faq/faq-xslt.html#faq-6 I was pleased to find Leigh Dodds' note on the Cocoon Wiki for "metastylesheets". http://outerthought.net/wiki/Wiki.jsp?page=MetaStylesheets I'm now successfully using this approach in my current project to implement custom tag libraries in Cocoon without needing to use the document() function. However, I am wondering how much this approach really scales. I guess I will find out. I believe that putting XSLT into the hands of graphic designers and average Web developers does *not* achieve separation of concerns. Custom tag libraries is the way to go. XSP addresses that. But Cocoon appears yet to directly address the problem of implementing tag libraries *in XSLT*. Perhaps "metastylesheets" is the way to go. Or perhaps the document() function is the way to go, and the caching problems just need to get addressed. Or perhaps there is another approach that I haven't considered. In any case, this needs to be addressed, IMHO. It's also quite possible that this has been fully addressed and I just haven't seen it. In that case, I would appreciate a link to that discussion :-) Evan > -----Original Message----- > From: Luca Morandini [mailto:spectrum.morandini@;ipzs.it] > Sent: Tuesday, November 12, 2002 5:35 AM > To: [EMAIL PROTECTED] > Subject: R: Separation of concerns? > > 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]> --------------------------------------------------------------------- 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]>
