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.
--
CU
Joerg
PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc
PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
