cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: [C2] Fw: actions
Date Thu, 25 Jan 2001 08:34:50 GMT
Allan Erskine wrote:
> > 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)

Go ahead and send your proposals to this list. There are alot of people here 
to discuss your thought about any theme.

Giacomo

>
> - Allan
>
> > - donald
> >
> >
> > ---------------------------------------------------------------------
> > 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