Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <601F6322AD71D5118D6C0003472515290660D085@sjmemexc1.stjude.org>
From: "Hunsberger, Peter" <Peter.Hunsberger@stjude.org>
To: "'cocoon-dev@xml.apache.org'" <cocoon-dev@xml.apache.org>
Subject: RE: Flow wishlist :)
Date: Mon, 25 Nov 2002 15:01:33 -0600
MIME-Version: 1.0
Content-Type: text/plain

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

Well, now you have one....  ;-)

<snip/>

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

Well, yes mostly it is, but we have a requirement for very dynamic business
logic and very dynamic flow logic.  As a result, I'd like to keep as much of
the logic declarative (specifically, coded in XSLT) as possible.  We really
need to mix and match business rules, business flow, presentation flow and
presentation logic on the fly according to a pretty complex set of rules.
Using XSLT allows us to stay much closer to a rules evaluation model and
avoid what would otherwise be very complex Java code.  

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

I'm not quite sure why you would see procedural logic as being "better"?
Again, we're coming at this from a rules based approach and as such XSLT
seems like a more natural fit...

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

Not having had a chance to get my hands dirty with it I can't comment on
that.  If I may, let me give two example problems that we have, one simple,
one not so simple and perhaps someone who has had a chance to play with this
more can explain how flowscript would work with them?

1) Presentation flow use case: user has a search screen, search presents a
list of results, user picks from a list of results and sees the details of a
given item.  In the case that the search produces only a single result you
want to jump directly to the details screen and skip the pick list. (Just
for argument lets say that the two presentation required is complex enough
that you really don't want to do all presentation from a single XSLT.)  

With an XSLT template style matcher this is a simple count() of the data
results picking the resultant presentation transform to apply.  I suspect
this is pretty trivial for the flowscript model also?

2) Work flow mapping use case:  item requisition document presented as a
fill in the blanks form.  User does a "Submit for approval".  Business rules
are such that if user is level X or above and request is for amount Y or
less it is automatically sent to purchasing, otherwise it is sent to users
boss for approval before being sent to purchasing. Boss and purchasing both
need to be presented with screens giving items waiting for approval and be
able to approve, not approve as appropriate and route documents on as
appropriate.

As described, this second is perhaps easier to code as procedural code.
However, it gets really interesting when the flow has to cross business
organization boundaries.  Process modeling languages such as BPEL4WS start
to come into play and one ends up wanting to have a general XML model for
describing the problem whether internal or extranet related.  This doesn't
force you into a XSLT processing mode (for the process modeling language) as
a result, but it seems natural to me?


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org