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 Re: [C2] Fw: actions
Date Wed, 24 Jan 2001 15:17:24 GMT
> On Tue, 23 Jan 2001, Allan Erskine wrote:
>
> > But given that a sitemap author may conceivably want to match/select/act
on
> > any state from authentication to session state, from application to
database
> > state to the state of the last action executed, wouldn't an explicit
unified
> > notion of state in the sitemap be helpul?
> >
> > And while this newbie is in the game of bandying lofty ideas around (or
> > lofting bandy ideas maybe), what if any aspect of a declared state could
be
> > accessed on the fly as SAX events?  Then matching on anything from
browser
> > type to whatever could be done with an XPath matcher, thus making Bob
our
> > collective uncle...surely...
> >
> > If someone can tell me why I'm being daft, I'll don my pinny and write
some
> > docs for you all...
>
> i had this thought back in the early days of the sitemap, when this was
> all wishful thinking and nary a line of code had been written. stefano
> argued against it, but i'm still not sure i agree with his argument. my
> thinking was that you could interpret request-time state as a virtual XML
> document, and you could allow sitemap authors to write match patterns
> using XPath expressions.

phew!  I'm glad my question didn't seem too daft...

> i think his argument was thus:

I'm sure the sitemap has come on a long way since this argument, so I'm
going to stick my neck out here....

> 1. the cost of creating the virtual XML object was prohibitive

That would be up to the object in question...a virtual XML representation of
say, a database table would be out the question for an omni-present sitemap
entity, although there would be nothing to stop you keeping this
representation implicit (ie implicit in some mechanism, eg an sql -> xml
query extractor).  Objects such as session, form, authentication, request
and response would typically be of small size, and keeping valid SAX
representations of them around (it would be good to scope these within areas
of sitemap aggregation!) wouldn't be too expensive in my opinion

> 2. the cost of interpreting XPath expressions was also prohibitive

Agreed.  But people aren't going to be so interested in XPath queries such
as "//roles/*" since in the context of matching on states of objects it
doesn't really make sense not to care what class of object you're matching
on.  Given that most matches are then going to be of the form
"/application/authentication/roles/*" or
"/application/forms/last_submitted[verified="true"]" (I'd even consider
restricting XPath matches to this kind of thing only) you could interpret
(or compile once, then execute) your XPath expressions quicker than you can
say index.

> 3. sitemap authors wouldn't be programmers (the infamous girlfriend test)
> and they should have programmers write matchers for them rather than do it
> themselves using complex XPath expressions

At the moment there's no choice for us hapless programmers but to do things
the hard way, witness recent email from Mats Noren (Sitemap + Action +
Abstract Sitemap).  Programmers have to write matchers for any object class
they need to create...and selectors.  It's as if us programmers are being
excluded from all the wonderful processes that the sitemap is starting to
enable for content publishers.  I have more to say on this but I'll save it
for now, suffice to say XPath macthing has the potential to offer sitemaps a
declarative flow-control style that I've heard people hankering for (usually
when trying to avoid if-then like constructs sneaking into the sitemap) -
and sitemap authors might even like the restricted XPath matching once they
got used to it; ....then they could have girlfriends too!

> 4. that i was trying to use the XPath hammer to pound the sitemap screw

XPath hammer is one thing...implementing classes + associated
selectors/matchers then getting them compiled and subsequently trying to
make state-based choices on them is like using your head - to hammer sitemap
screws into brick walls!

> (this is, naturally, a one-sided remembrance - i'm sure others will
> correct me if i put words in stefano's mouth)
>
> personally, i'd be delighted to see someone try to implement this sort of
> thing and see how well it works. i think one could hook it onto the
> current c2 sitemap engine without having to affect the engine core. not
> that i've the time, mind you...

I'd happily give it a bat, but I am a bit of a newbie (just been lurking for
a couple of months + small scale dabbling)...

If somebody thought there was really any mileage in it, I'd be happy to try
and implement something (I have a proposal which I'll send if anyone's
interested)

- Allan

> - donald
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


Mime
View raw message