cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Flow wishlist :)
Date Mon, 25 Nov 2002 20:04:41 GMT
Hunsberger, Peter wrote:
>>>hmmmm, hmmmm, hmmmm, I have FS alarms ringing all over the place in my
>>>head, but I have several great examples of where having that would rock 
>>>the planet.... but still, I'm afraid of people going back adding 
>>>programmatical logic to the sitemap....
>>>
>>>... but it would be *so* cool to have a Workflow definition language
>>>created as markup and then having a pipeline that generates the 
>>>flowscript by XSLT transformation!
>>
>>
>>I've been exploring the ability to define flow via XSLT and parsed 
>>markup for some time now. I've a conceptual design in my head so far, 
>>but it is very different from what exists in Cocoon so far, and 
>>different from generating flowscript:  it seems to me that the 
>>essential requirement here is just to be able to drive Cocoon via XSLT 
>>parsing of the current context (request, session, etc. as the user 
>>sees fit).  As such, you're talking about a pluggable replacement for 
>>the entire sitemap handler it's really a very different processing model
> 
> from the current sitemap.
> 
>>I think another way to understand it is as though one was adding the 
>>equivalent of XSLT chaining to the XSLT language:  process this 
>>DOM/SAX stream up to this point; make a decision on what to chain in 
>>next and hand the whole thing over to some subsequent 
>>transform/serialization process that inherits the processed stream as 
>>it's starting point.  This is different from included XSLT templates 
>>since each sequence of chained transforms begins as though it was 
>>starting fresh from the other (no name collision). It's different from 
>>the current Cocoon sitemap (but functionally equivalent) since it 
>>allows an XSLT to make the decisions instead of the Sitemap.  The 
>>appeal to me is that such a design is consistent with the functional 
>>programming model of XML/XSLT...
>>
>>
>>
>>>>I know, I know, it smells of FS all around, but this would make it 
>>>>*so*
>>>>easy to be able to connect cocoon to existing workflow editing systems.
>>>>
>>>>Gosh, I have to think about that.
>>>>
>>>>What do you people think?
>>>
>>>
>>>This is an important piece to the future of Cocoon. My personal 
>>>functional requirements are to stay within the XML/XSLT processing 
>>>model as much as possible and not design a new language (a Sitemap 
>>>language), and not require the use of compiled code (Java).  I don't 
>>>know if others would think these are reasonable requirements or not, 
>>>but if you see the value of such then I think it seems to suggest a 
>>>very different Cocoon model then the current sitemap.  As such, I 
>>>think it might be worth exploring what happens if you throw the 
>>>current model up in the air and do some design work from scratch: if 
>>>we didn't have site maps, knowing what we know now, how would we get 
>>>all this functionality?  If that matches up with sitemaps, flow, etc. 
>>>fine then add in the new syntax to support it.  However, if it's a new 
>>>way of doing things then it at least has to wait for blocks to be 
>>>implemented, and more likely it's a Cocoon 2.5 or 3.0 type of thing...
>>
>>Ok, we'll keep this on the stack of 'possible wild proposals', ok? :)
>>
>>No, seriously, I'm very happy when people think about radically 
>>different approaches to solve the same problems because that's how 
>>innovation takes place.
> 
> 
> Well, perhaps not wild or radical, just different...
> 
> 
>>At the same time, everybody considered the sitemap one of the core 
>>features of Cocoon and, for sure, this isn't going to go away any time 
>>soon (not even for Cocoon 3.0). this doesn't mean we can't innovate or 
>>propose alternative solutions to cohexist, but for now, I'd concentrate 
>>on keeping our design focus on what we have.
> 
> 
> I certainly wouldn't expect sitemap to go away, even if the capability I
> suggest was implemented.  In particular, one might want to use both
> capabilities, directing only some URIs to the router type XSLT that I'm
> looking at.  Depending on how it was implemented one might also want to use
> the sitemap to specify how the context for the router XSLT was built up
> (aggregation patterns).
> 
> The whole point of jumping in here wasn't so much to propose anything new or
> radical as to suggest that   one way of answering your query of whether the
> additions to the sitemap that are being discussed are FS or not (or
> something not appropriate at the moment even if not FS) would be to step
> back and do a clean design for the capabilities that would implement them.
> If you find that the real way to implement such capabilities is using
> something not like the sitemap (IE, something more like what I suggest) then
> clearly, one shouldn't be trying to build these new capabilities into the
> sitemap independent of the semantics and syntax discussions.
> On-the-other-hand, if you find that -- even after starting from a clean
> slate -- you have a good match for the current sitemap implementation, then
> it is reasonable to continue to try and answer the semantics and syntax
> questions about how the capabilities get implemented.

Ah, sorry, didn't get that.

To be entirely honest with you, I already did this redesign in my head 
when I was thinking about how to separate the flow logic from the 
sitemap and trying to get rid of actions. I started to think about wild 
alternatives, but couldn't find any.

Then Ovidiu's proposal about the flowscript made perfect sense and still 
does, even with the new functionality that we are talking about.

> Personally, I find the sitemap a pretty complex beast that attempts to do a
> awful lot of independent things; separation of flow is a step towards
> breaking this out, but the discussion seems to be centering on how to
> implement two languages simultaneously within the sitemap just so one can
> cleanly separate the business logic from the flow logic.

?? sorry, I don't get this. The business logic should reside in java 
objects that you write or reuse from the external, I see it like this

   resource production logic -> sitemap (declarative)
   flow logic -> flowscript (procedural)
   business logic -> custom java objects (procedural)

and I think this is very clean.

> This suggests to
> me that perhaps what is needed is two different concepts -- the sitemap and
> something else -- each performing separate tasks.

Absolutely. The sitemap should be considered just a way to produce 
resources (thus being read-only on data stores) and pass control to the 
business object level for all the data manipulation that involves 
writing. The flow will keep control of moving from one state to another, 
but it should be read-only as well (the writing part should be always 
done by invoqued java objects).

   Whether, in general, that
> something else is something close to what I propose I don't know, but, I do
> know that for us, it would allow a very clean separation of business logic
> mapping and web flow mapping.

both flow logic and business logic are procedural (or better described 
so), I think the mapping between the two might be even as simple as the 
Avalon component manager.

But I really don't see any need to go back and refactor the 
sitemap+flowscript concept which is, IMO, great.

-- 
Stefano Mazzocchi                               <stefano@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