On Sat, 16 Mar 2002, Fisher, James wrote:
> It seems they export a functional interface. Do we then lose the benefits
> of OO programming? Or do I have to write my whole object model and make it
> available to my web app via wrapper taglibs?
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.
I've built up the belief over the last year that XML systems just aren't
object-oriented, and aren't terribly compatible with the paradigm. The
funny thing is that relational DB's aren't object-oriented either. This
means that your OO middleware ends up being in the wonderful position of
having an impedance mismatch problem in *both* directions: DB<->libraries
and libraries<->XSP.
Take a look at Cocoon's solution to this problem: Taglibs in Cocoon are
actually "logicsheets", which are implemented as XSLT files that transform
taglib "calls" into literal java that instantiates objects, calls commands
on them, etc. Now Cocoon developers have muddy their pristine OO design
with various layers:
- special query and/or persistence code for their relational<->object
mapping, in areas of their code where performance matters
- logicsheets, to switch OO land to functional land (and have to be
maintained separately from their OO libraries)
- XSP files, to make the functional calls
- XSLT files...that are declarative and therefore sorta functional in
nature
...whereas AxKit-style taglibs need neither the first nor the second
sources of "muddiness".
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
mismatch problems because procedural interfaces (Taglibs) link quite well
with functional programs (XSP), and thankfully our existing "pure"
libraries can be exported as taglibs by the simple addition of some lines
to the top of the module.
I actually think it's a pretty interesting issue, myself, because it's
occurred to me that pages are pretty nicely object oriented: they keep
data and related functionality together and they can be abstract; and with
a smart sitemap system, they can be polymorphic and support inheritance.
My own feeling is that maybe it's much less important that web systems be
OO internally because they're already pretty OO at superficial levels and
this gives us enough of the benefits to not require internal rework. My
experience so far seems to support this.
> Does this illustrate a weekness with a functional symbol heavy interface
> performance issue regarding tablibs. Maybe not for a small site, but with
> any kind of usage it would seem it your site is "taglib heavy" this could be
> an issue. A better implementation of taglibs would be an OO interface?!
The section you quote actually refers to exported symbols using @EXPORT
and the Exporter module. Taglibs actually work through direct function
calls using ModuleName::function syntax, so as a result you don't actually
have to export anything anywhere.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
