cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: Separation of logic/content (Was: XSP Best Practise Question)
Date Fri, 23 Aug 2002 14:36:40 GMT
Good post. This topic is starting to look like it may belong on dev, but I
haven't joined dev due to the extra volume, so a somewhat long response
follows...

> Mapping MVC to web applications is, in my mind, a priori,
> a mess, due to the fact that the requests (events) the
> web application receives must ultimately be encoded as links 
> and form actions in the HTML presented to the user. Thus 
> some mixing of view and control is required. In a sense, 
> we are trying to make the best of a bad situation.

No argument that HTTP is less than perfect for tracking state! However, you
can use logical link names that are mapped to physical implementations.
Cocoon pipelines are one way to do this, but this means that you may have to
change a mapping in multiple spots.  Some form of dynamic lookup from a
database makes more sense; in our case, for the Cocoon portion of the
handling, we use a two part scheme for all page names such as "x.y" where
"x" is the physical page name and "y" is a logical type.  The pipeline only
specifies how to handle types (every matcher is wild carded in the form
*.y).  The specifics of how to manage a particular page can then be based on
page type.  As an example, in our case pages types include such things as
search pages, results lists, menus, "grids", "questionnaires", and half a
dozen forms of administrative types.

> A typical web application the links can be divided into 
> the following categories:

Not sure these are useful abstractions? I think they are too general, I
prefer higher level abstractions that tell me more about the semantics I
expect for a given event associated with a given page.

> Goto Considered Harmful, Come-From is Fine

Yes, Cocoon should lead you to event handling semantics and MVC enforces
this...

> How to implement the controller? Actions seem a reasonable 
> choice. 

Can't imagine any other!

> This would require having
> the 'master pipeline' described above.

Not sure I see the connection here: if you're writing a generic pipeline
then by definition you really can have only a single mapping, since logical
links connected to generic actions will be automatically defined to cover
your entire "namespace" used for your links.  However, I don't believe this
enforces a single pipeline?  Having said that, in this case, I can't see why
you'd want multiple pipelines except for multiple application support.  IE;
additional prefixes (or suffixes) map different applications to different
pipelines, which in turn implement their own mappings of logical types to
controllers as needed.

> The Controller could be implemented as a generic class
> implementing Action, which could read an XML config file 
> (called the flowmap or FSM-config). The config file would 
> contain, in some form, the matrix of applictaion states and 
> events and their mappings to the 'action pipelines'. 

I prefer to do the mapping in a database so that it can be changed at run
time using administration screens...  I also don't want a single action, my
action handlers are based on page type. For the most part, "all" they do
update context, which means mapping physical parameter names back to logical
names and storing the parameters in the correct context as needed for the
next pass through the system, but each type of page has different semantics
and thus different parameters that need to be mapped in different ways.  In
our case, the real action handlers are the XSLTs that get invoked (or not
invoked) by the actions.  However, I should note that updating context may
include updating a database and that may include calls to EJB's and one heck
of a lot of code; "all" is a relative term....

> It might be possible to encode the controller configuration 
> directly in the pipeline portion of the sitemap, but I'm not 
> sure that you want to include all that 'application code', 
> (which is what this information really is, in the sitemap.

Yes, this is a maintenance issues (see above), beside having the issue of
not being dynamic.

> When responding to a request I'd like to use one pipeline
> composed of XSP logicsheets to perform the event processing 
> and then be able to switch to another pipeline to generate 
> the next page. 

This sounds slightly similar to the proposal I threw out yesterday to build
a way of processing the pipeline as a XML config file consumed by an XSLT.
(I wouldn't limit this to just being in response to an action.)  The basic
requirements are that actions are based on context, and context is updated
in response to state changes. Thus, context data needs to be available for a
transformation that can "transform" it's understanding of the current
context (logical state) into the specification for the next physical state.

> Is this even possible in Cocoon? Are redirects an answer? 

Cocoon provides good ways to track context and things like the request
generator already dump them back out in the required form.  A more
generalized session generator would probably be required to fill in some of
the pieces (we built one that is application specific).  I don't see a need
for redirects, except as a way to handle the fact that Cocoon doesn't
currently have ways of doing this kind of dynamic link construction so you
end up pointing page processing back at generic processing with state
changes added in between.


---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>


Mime
View raw message