I have to agree with JW on the point that OO or any other paradigm is just a tool. IMHO OO is a very powerful paradigm for building API's, but at the top level modern computer systems just really aren't object oriented. The MVC design pattern is fine for something that basically looks like a text editor, but web apps generally don't. Procedural or perhaps declarative systems seem to make better "glue". Its always been one reason I've used perl and before that FORTH heavily, both languages live happily in either mode. I think Java is too brittle, being OO all the way, and when you look at the twists that Cocoon has to go through to provide a glue layer that starts to become clear.
On the other hand there ARE some good things about Cocoon's architecture. SILLY has its benefits for instance. On Sunday 17 March 2002 09:41, J�rg Walter wrote: > On Sunday, 17. March 2002 08:11, Steve Willer wrote: > > This might not be a very PR-friendly response, but I would have to say > > yes, it's functional, and no you don't get to use OO paradigms in your > > taglib interfaces. > > It all depends on how you write them. I think you can put a great deal of > OO-ness in your XSP, if you want to. Take ESQL for example. You can view > the <connection> wrapper as the object, while the <execute-query> tags are > method calls. This is far from complete, but it shows that there is a way - > if anyone would want to. > > Then again, taglibs. You get inheritance via perl's inheritance, which > works just like normal if you are using SimpleTaglib.pm. Combining the > object wrapper above with this inheritance you already have a fair deal of > OO - if you want to. > > Finally, I wouldn't want to. The core functionality is much better left in > a generic module which has nothing to do with XSP. Take my Session plugin, > it uses OO quite thoroughly, although it is a bit mixed up, as $r functions > as the 'object'. Nevertheless, it is generic, it works without any XSP > page, it even works without AxKit and it doesn't depend on any perl code at > all in the web server except itself. The taglibs for the plugin are just > another interface to this object. They define alternate accessors to the > functionality provided by the generic class. And this maximizes code > reusability: the hard work is done in a way I can reuse it in a shell > script or in a static html+cgi environment, or wherever. ESQL does the same > (it uses DBI for the hard work). > > From a practical point of view, you get as much OO as you like in an > environment you know best (regular perl module programming), with the added > benefit that this is still the best place to implement the hard work. See > taglibs as alternate interface to your objects, and XSP as part of your > control. Not Model, not view. (see other part of this thread) > > > - special query and/or persistence code for their relational<->object > > mapping, in areas of their code where performance matters > > The use of an XML DB would go a long way to render relational DBs obsolete. > Having clever indexing, speed wouldn't be an issue, and having XPath and/or > XQeury querys and XUpdate for modifications, you get all the power you need > - but stay in XML space. > > > - logicsheets, to switch OO land to functional land (and have to be > > maintained separately from their OO libraries) > > Which is an advantage, IMHO, but for the separate maintenance. But a clever > guy could write something to make automatic taglibs from any module - after > all, this is perl, everything is possible in perl (well, mostly :-) - > should you want that. With the design strategy laid out previously, you > wouldn't want to put application code into XSP and hence you wouldn't have > the need for this. > > > - XSLT files...that are declarative and therefore sorta functional in > > nature > > XSLT is not 'just' declarative. If you want to, you can view XSLT as the > program code associated with the object, and the to be styled XML as the > object itself. Inheritance is via <xsl:import> and polymorphy is inherent > to XML. But again, it is doubtful if the OO nature is of any use here. > > > Because of all this complexity, I elected for our internal systems to > > skip the whole OO thing and stay procedural. We don't have any impedance > > That's it. It simply doesn't pay off to be radical OO here. Any programming > paradigm is just a tool. Unless all the implications of the new tools that > are emerging around XMl are well known, no one can say which is the best > way, and it pays off to keep it simple. > > > I'd be curious what an OO taglib would look like...presumably there would > > have to be a way in XSP to instantiate an object and reference it later > > on (without using <xsp:expr> and similar tags). Sometimes I'm actually > > surprised the Cocoon folks didn't put such things into the XSP spec, and > > left it as a functional language that required those ugly logicsheets. > > Look at ESQL - it is not a perfect example, but you instantiate objects > there and call methods on it. It just feels and works differently than your > usual OO programming. Compare that to XSLT variables. If you view them as > being extremely limited objects, you get a feeling for how differently > objects will be used in an XML environment. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
