cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [C2] XSP and apects (was: log performance penalties)
Date Tue, 27 Feb 2001 14:59:28 GMT
Giacomo Pati wrote:
> 
> Berin Loritsch wrote:
> > Giacomo Pati wrote:
> > >  Stefano Mazzocchi wrote:
> > > > ----- Original Message -----
> > > > From: "Allan Erskine" <a.erskine@cs.ucl.ac.uk>
> > > > To: <cocoon-dev@xml.apache.org>
> > > > Sent: Friday, February 23, 2001 5:05 AM
> > > > Subject: [C2] XSP and apects (was: log performance penalties)
> > > >
> > > > > ----- Original Message -----
> > >
> > > <snip/>
> > >
> > > > > thing for different forms, longing for XSP actions, feeling locked
in
> > > > > by proprietary sitemap.  Just the usual $0.02 worth in other words).
> > > >
> > > > I don't follow cocoon-users and I believe that placing a rant on
> > > > cocoon-users is totally meaningless.
> > > >
> > > > Cocoon was not designed with webapps in mind, admittely, not even
> > > > Cocoon2 so far and the 'action proposal' is not enough thought out to
> > > > represent a clear design (even Giacomo agrees with me on this).
> > >
> > > Unfortunetly, yes, I do agree :/
> > > I haven't come to a better solution and all other proposals (thanks for
> > > them all) will polute the sitemap with too much semantics IMHO. Semantics
> > > which is too much programatic to make it into the sitemap (for now).
> > > That's why I haven't agreed (most silently) with the proposers of
> > > additional stuff on the action proposal. We still have a lot to think
> > > about it. As proposer (and implementor) of the Action proposal into C2 I
> > > use it for web apps and I've seen that you can come up with easy
> > > solutions but you'll need additional layers which supports your Action
> > > coding (ie. access layers like Castor).
> >
> > I am still working out the bugs, but the new Actions I committed today
> > (which when they are debugged will replace the XXXEmployeeAction actions)
> > will load a configuration file (an XML file) to set the parameters needed
> > for the actions. This lets you set parameters and other things that are
> > completely orthagonal to the sitemap.
> 
> Yes, I probably think is might be the solution. But still, I don't know if we
> need Actions? Can't a Matcher or a Selector take its place? Can't a Matcher
> instead of matching URIs match on events? Or be configured with a separate
> file as you proposed? Or even have it's own namespace to be configured (I
> know this would clutter up the sitemap but it is still separated by
> namespace).

That's what I was talking about.  Using an external file to configure these
things, or match on events.  An Event matcher would really be cool.  Basically,
we could set in motion a Future (a value that is specified now, but evaluated
in the future--usually in a separate thread), and you could check on the result
after the EvaluationComplete event is sent.  (However that is not directly related
to the thread at hand).

Either separate by namespace, or use an external file.  Too many things in the
sitemap make it a development tool, and not an administration tool.  That is
not the stated purpose of the Sitemap.

> 
> Giacomo
> 
> > This approach would work for configuring aggregation and other aspects
> > without cluttering the sitemap with too many semantics.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

Mime
View raw message