cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Allan Erskine" <a.ersk...@cs.ucl.ac.uk>
Subject [C2] XSP and apects (was: log performance penalties)
Date Fri, 23 Feb 2001 04:05:06 GMT
----- Original Message -----
From: "Stefano Mazzocchi" <stefano@apache.org>

> Of course, the real solution would be to use AspectJ to code Cocoon, but
> I'd rather wait until AspectJ stabilizes before moving to aspect
> oriented programming. [for those of you who don't know what I'm talking
> about, look at www.aspectj.org for more info on ASP for Java]
>

XSP seems nothing short of an aspect abstraction mechanism.  Aspects of
server processing can be abstracted by tags, and modularised by namespace
prefixing.  Even language and platform choice are aspects unders XSP's remit
(witness AxKit).  Surely too useful for just pages (which are becoming an
outmoded concept anyway).  Besides, being eXtensible conflicts with being
restricted to page serving...

IMHO, XSP's scope should be broadened to include server processes (sitemaps,
actions, ...), and XML fragment generation.  I truly believe this would be
powerful beyond belief (esp with recursive sitemap calling, and sub-pipeline
includes), and it could be done without breaking the current XSP.  In a
stroke, XSP's profile would be boosted, and C2 would be less proprietary
(becoming a framework for XSP publishing components).  C2's codebase would
also presumably shrink and be rationalised.

(conclusion reached after following Uli's application rant on cocoon-users,
and developing my own C2 web-app, writing action after action to do the same
thing for different forms, longing for XSP actions, feeling locked in by
proprietary sitemap.  Just the usual $0.02 worth in other words).

(and thanks to Paul Russel for the interesting reply to similar email on
cocoon users...hope for the same, to shut me up once and for all about
xsp sitemaps, or otherwise:)

----- Original Message -----
From: "Stefano Mazzocchi" <stefano@apache.org>
To: <cocoon-dev@xml.apache.org>
Sent: Monday, February 19, 2001 12:29 AM
Subject: Re: log performance penalties


> Tagunov Anthony wrote:
>
> > Sure, this approach is not universal..
> >
> > 1)
> > As for number of parameters:
> > i personally see no trouble in
> > having 9 .log methods with number of parameters from 1 to 9
respecitvely, if
> > it saves performance! And I beleive there's a sane limit that a regular
> > log request does not come over..
>
> The solution is to remove the code completely.
>
> I'm not sure how many of you know this but this Java code
>
>   final boolean LOG = false;
>   if (LOG && logger.debugIsActive()) logger.debug("this" + is + "a
> test");
>
> is compiled into
>
>   final boolean LOG = false;
>
> that's it! the code is gone! try it yourself with javap.
>
> This is the fastest solution available: no code executed no time lost.
>
> Of course, this requires a pretty good 'coding style' and coherence
> thruout the entire code and makes it more unreadable for those who are
> not aware of this java feature... but it's much better than having
> things like
>
> // #ifdef LOG
>  if (logger.debugIsActive()) logger.debug("this" + is + "a test");
> // #endif
>
> which must be preprocessed before generating the code.
>
> Of course, the real solution would be to use AspectJ to code Cocoon, but
> I'd rather wait until AspectJ stabilizes before moving to aspect
> oriented programming. [for those of you who don't know what I'm talking
> about, look at www.aspectj.org for more info on ASP for Java]
>
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <stefano@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>




Mime
View raw message