cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allan Erskine <>
Subject [C2] Fw: actions
Date Tue, 23 Jan 2001 05:07:58 GMT
Further to my previous email (which may have involved some erroneous tree
barking), in /cocoon/docs/sitemap.html, in the first section on the sitemap
design engineering constraints, point no 10 is:

"resources must be matched with all possible state variables, not only with
URI (http parameters, enviornment variables, server parameters, time,
etc...). "

Could anyone flesh out what the author was intending here?  I've seen the
small number of selectors and matchers in sitemap-working-draft.xmap...fair
enough, if you go and write some Java, you can match/select/act on anything
to your heart's content...

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...

    <map:selector name="state-java-interface"
        <param map:value="state-set-name"/>

<map:matchers default="wildcard">
    <map:matcher name="xpath"
        <param map:value="generator"/>
        <param map:value="xpath"/>

<!-- possible wrong tree barking -->
<!-- insert sci-fi way of describing various classes of state entity here,
complete with interface(s) to state (e.g. SAX interface, or java class
interface) -->


    <map:match type="xpath" xpath="//authentication/authenticated">
    <map:match type="state-xpath" xpath="//authentication/roles/*">
        <map:generate src="forms/role/{1}/yesplease.xml"/>

- Allan

----- Original Message -----
From: Allan Erskine
Sent: Monday, January 22, 2001 4:08 PM
Subject: actions


I've been through the all the action proposal threads, and checked the code
in the latest cvs; I'd like to use actions in my webapps, but I'm still left
wondering where the whole malarky is headed.

If someone could help me with some niggles, then perhaps I could contribute
in whatever way...

I realise the action classes e.g. org.apache.cocoon.acting.AddEmployeeAction
are just a taster of how things _may_ be, but is anyone working on something
slightly more generic (the org.apache.cocoon.acting.DBAddingAction from
sitemap-working-draft.xmap perhaps)?

Secondly, is there a good reason why all the action discussion has been so
quiet on the subject of state?  People have been requesting mechanisms for
conditional actions depending on the states of forms, session or
authentication details, and for updating databases.  Would it not make sense
to have an abstract means of describing these state components at sitemap
level?  The sitemap could then be factored into regions of state context,
and the components/applications that act upon that state e.g.

    <map:state-set name="employee-data">
        <schema src="./employee.xml">
            <type value="db"/>  <!-- other types could be EJB, CRUDLET
etc -->
            <schema-transform src="./postgresql-imp.xsl">

<map:action name="add-employee">
        <schema src="./employee.xml">
            <type value="db"/>
            <schema-transform src="./postgresql-insert.xsl">

<map:match pattern="forms/employee">
    <map:state set="employee-data"/>
    <map:state set="application-session-state"/>
    <map:act set="employee"/>

Should I go on thinking along these lines, or are there reasons that state
description hasn't been made more explicit so far?


View raw message