Terence Yes, I think your situation is true for a lot of Cocooners; I have tended to use XSP because my "use cases" do not require specialised data generation (as yours seems to) - its mostly just pulling data from a DB (see the other thread on this topic). If I can avoid handcoded Java for this type of application, I will do so.
I agree XSLT works (I use and I like it) - but the point I picked from the article was the difficulty of working with a page designer who may know HTML and now wants to incorporate dynamic elements in the page - the argument goes that giving that person a whole language (be it XSLT or a full-blown JXT) is really overkill (and leads to mixing of view with model). I do think its good to bring in opinions from people outside of the "Cocoon bubble" - certainly Cocoon has always espoused SOC and we need to look at insights that suggest where there are "gaps" in the approach; not because we are academics [remember the article was written by someone with very solid experience in website design and maintenance ] but because we have an inherent drive to "make things better"! My 2c, anyway. >>> [EMAIL PROTECTED] 2004/05/04 03:02:54 AM >>> I'm new to cocoon and JXTs so what I know is only what I have read on the website and what I've done so far with a cocoon app I've taken over development of. I will make some general comments on the ideas you've raised. I wouldn't get bogged down in the whole "purity" thing with whether or not a template is a "true template". For me, the important thing is separation of concerns. As you point out, XSLT provides enough facilities in the specification to create the necessary contracts for separation of concerns. For me, it's the only templating system I need and I choose it because it is a widespread cross-technology standard. Being a cocoon newbie, I'm questioning the need to use XSPs because I see them as a way to loose many of the bonuses that come with OO in terms of using popular industrial tools like JavaDoc and Junit. Although I started my web development career with ColdFusion, I'm not a big fan of the tags and code mixture when it comes to creating a controller (in the MVC sense) or writing business logic. I'm thinking I'm probably gonna write all my apps using custom generator classes and just ignore XSPs. But that's just me. Some would argue that XSPs are easier and "more rapid" but I think they just create an extra layer of maintenance in your java application. I've just taken over development of an existing cocoon app here at work so it looks like I'll be writing XSPs in the short term, but they are not for me. Generally, as far as your discussion goes, I don't like using text-based templates anywhere near my business logic - ie, I don't like using the templating facilities of JSP, XSP, ASP, PHP, or ColdFusion. My experience is mainly with PHP, and I tend to write in an OO way - using the standards based DOM API to build up my content, and then I use an XSLT processor to orchestrate the view (with XSLT stylesheets). I think this concept in general is very simple but it is a scalable one with easy maintenance. (I've written a PHP framework (XML Application Objects) which is on hold while I learn cocoon http://xao-php.sf.net ). Maybe when I get more experience with cocoon, I will port XAO as a set of cocoon generators. As it stands, it's already easy for me to integrate XAO applications into coocoon as it is easy to pull untransformed content into the sitemap -- especially in the contenxt of aggregation. Same is true the other way around. XAO can easily "consume" XML from a cocoon app with one line. So yeah, all I need is the DOM standard for content generation, and the XSLT standard for formatting. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
