cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: XSP and sitemap objectModel
Date Fri, 18 May 2001 11:50:41 GMT

On Thu, 17 May 2001, Jason Foster wrote:

> One thing that's clear to me is that I'm pretty confised about all of the
> various places that a component can hide information.  If you could
> comment on or add to the following summary that would be great!
> Place                        Purpose
> ---------------------------------------------------------------------
> Request parameters                --> hold form info from client

Or other parameter put in URLs like

here foo is a http parameter

> Request attributes                --> ???

Used to attribute your request with information used elsewhere. There
seems to be implementations of servlet engines which communicates to
servlets using request attributes.

> Session attributes                --> hold persistent client info


> Action/Matcher objectModel        --> allow flow control

No, not Action/Matcher objectModel (such thing doesn't exist).
Environment objectModel. It is used to pass important environmental
objects to sitemap components. It is created by the concrete Environment
implementation and it is used by sitemap components to get to those
objects. the sitemap only passes it along to the components but doesn't
use it at all.

> Action parameters

Also here. No explicit Action parameters. I was talking about the
element <parameter> in the sitemap syntax to parameterize sitemap
components with request information (as opposed to configuration
information which is passed only at instantiation time during startup of
the sitemap engine)

> You mentioned "sitemap parameter elements" but I'm not entirely sure what
> you mean by that.  I think that you are referring to both the Action
> parameters and the param available to a selector.

Again. The parameter element in the sitemap is a general method to
parameterize sitemap component during request processing.

> I think I'm most confused by the difference between an Action parameter
> and an Action objectModel.

You're look at it from a different angle :) Have a deeper look into the
sample sitemap that is in the C2 webapp directory and read the
xdocs/drafts/sitemap-working-draft.xmap document first which explains
most of the initial intension of the elements in the sitemap (even if it
is not accurate ATM)

> This all came from my desire to pass information from an Action to an XSP
> page.  For example if I have an action that adds "previous-result=fail" to
> its objectMap, how can my XSP page read from that to find out what to
> extract from the database?

Instead using the objectModel use the request object in the
objectsModel and put your stuff into the Attributes.

> I get the impression that I could use a selector to accomplish some of
> this but somehow that doesn't feel right.  What I wouldn't give for some
> sitemap design heuristics!
> > You are mistaken :) the discussion is if Matchers and Selector should have
> > access to sitemap parameter elements.
> OK, so to me a valid question is whether or not an XSP page should also
> have access to the sitemap parameters.

They already have, look:

   <map:generate type="serverpages" src="my.xsp">
     <parameter name="foo" value="bar"/>

The XSP page is able to get the value as


> Conversely shouldn't everything
> have access to the environment?

If you mean the Environment object than no. It was made for exclusive
use by the sitemap engine.

> If this isn't that case then it's pretty
> difficult for actions to control things, isn't it?  Something like the
> following looks pretty straightforward:
> <map:act type="PickWhatToDoNext" />
> <map:select type="objectModel" name="DoThisNext">
>   <map:when test="login" />
>   <msp:when test="logout" />
> </map:select>

I don't know what you'd like to acomplish here.


Please check that your question has not already been answered in the
FAQ before posting. <>

To unsubscribe, e-mail: <>
For additional commands, e-mail: <>

View raw message