cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Comments on XSP 1.1 (long)
Date Wed, 01 Nov 2000 15:26:22 GMT
Matt Sergeant wrote:
> 
> On Tue, 31 Oct 2000, Stefano Mazzocchi wrote:
> 
> > True, logicsheets are written by programmers, but how many programmers
> > are confortable with inlining code into XSLT stylesheets? how many
> > programmers like to write their own SAX filter to create code that is
> > futher compiled?
> >
> > SLL glues markup and OO code. If you think you don't need it for Perl,
> > well, no problem, but are you sure all your joe perl programmers are
> > able to handle nested taglibs with no hassle?
> >
> > If so, well, I can't wait for Perl 6 to come out so that I can compile
> > it on a JVM and use it inside my XSP :)
> >
> > But, for now, I believe SiLLy (despite its name) is a very clever
> > approach for markup-java logic connection.
> 
> I think though that there's a better middle ground to be struck here. I
> don't know what it is or where it is, but SiLLy seems too verbose at the
> moment. I wish I could say more about what I think that middle ground is
> or should be, but I can't - I'm really just saying that I personally
> wouldn't be happy working at a company writing logic sheets using the
> lingo supplied in the example. It seems to make things easier for *Cocoon*
> (or AxKit or whatever), but not for the developer...

Ok, the fact that you wouldn't like to work for a such company is a
serious concern.

Let's try to come up with an example:

1) you are asked to write a taglib that has to be nested with a number
of taglibs that are not written by you.

2) suppose these other taglibs are written in XSLT+Java (no SLL or
anything), and you don't have documentation for them (like it is today)

What do you do?

Like many people here can guarantee, you try to see what the rest of the
taglibs do and try to come up with a resonable way to inline code that
works.... after a few hundred attempts, it does what you want and you
are happy.

Then, the taglib grows and it has to be refactored.. new people work on
it, people that are not used to XSLT+Java, neither to your own vision of
"how to make a taglib". The code is refactored, rewritten, it costs more
to refactor it than to write a new taglib from scratch.

Result: costs grow more than linearly and saturation happens. You can't
have more than N taglibs developped by your team and after a few years
they become black boxes... it's easy to throw them away than to see what
they do and how.

Perl people normally don't care about code management costs: they just
want to get their job done and it's not their fault if nobody else will
ever be able to manage it.

But everyone knows that software management costs are *much* more than
the costs of creating the software at the beginning. SLL also tries to
provide hooks to reduce taglib management costs in the long run.

If you don't care for it, then you should use it, but like OOP teaches
you, every moment you spend in designing an elegant and solid
architecture is a moment you save in the future.

Larry Wall doesn't understand why europeans care so much about code
elegance... but he never wrote an operating system in Perl :)
 
> PS: Don't hold your breath for Perl6 :-)

I know, but it's good to know integration will be easier when it comes
:)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


Mime
View raw message