Re: Use Cases [was Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)]

[Ovidiu Predescu <ov...@apache.org>]

Diana,

On 6/25/02 6:52 AM, "Diana Shannon" <sh...@apache.org> wrote:

> 
> On Sunday, June 23, 2002, at 12:25  PM, Daniel Fagerstrom wrote:
> 
> <snip />
> 
>> So what use cases do we have?
>> 
>> * It should definitely be easy to write wizards in a flow description
>> language.
>> I believe this is the case for flowscripts (see
>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102052662705449&w=2,
>> for
>> details), but on the other hand this could be done in a much smaller and
>> more specialized language. Ivelin and Torsten listed some requirements
>> for
>> wizards, IIRC.
>> 
>> * Shopping carts? This will be possible when Ovidiu (or someone else)
>> have
>> added variables that are accessible across different flowscript
>> invocations.
>> 
>> * Anything more?
> 
> I'm trying to imagine what it would be like to use the same sitemap
> (view) and same content (model) with different flowscripts. Here's some
> *very* preliminary thoughts on how I might apply flowscripts to a real
> world need (based on an even more preliminary understanding of what
> might be possible).
> 
> Use Case Idea 1
> what: games, simulations, decision support webapps
> 
> model: e.g., simulation model of an ecosystem
> - view: sitemap pipelines, presenting useful views of ecosystem (status,
> history, impacts, etc.)
> - controller: flowscripts
> - flowscript variations -> different webapps
>  (a) single-user simulation game (users interact with model over a
> period of time)
>  (b) multi-user game, similar to (a) but different players (characters
> with different roles) had different flow scripts
>  (c) simulation tool (not a game) which shows results of policies over
> time
>  (d) decision support tool with feedback about policy decisions
> (flowscripts could be even be granularized based a a field of concern,
> e.g. a farmer may want different advice than a logger)
>  ...
> 
> Note: I know you're probably thinking, these all could use different
> views (sitemaps) as well. While this may be true, in my experience,
> there is a lot of "view overlap" among these seemingly different
> applications.
> 
> Use Case Idea 2:
> what: learning tools
> 
> model: learning content
> view: document pages, quiz pages, feedback pages, report pages, etc.
> controller: flowscripts -> same tools, different audiences and users
> with varying learning levels
>  (a) basic, intermediate, advanced flowscripts (or grade-level,
> professional concern) for different levels of ability  (Some learners
> need reinforcement when they struggle with concepts, other don't.) This
> could be dynamically generated, of course.
>  (b) different flowscripts based on context of use (how much time
> available, professional needs, etc.)
>  (c) different flowscripts (for future continuations) generated
> dynamically (or by a teacher, e.g.) based on a student's past
> performance.
> 
> On the other hand, once you have a great set of flowscripts, you could
> use them with different sitemaps and different models as well. With SoC,
> the possibilities seems almost unlimited for extremely valuable reuse.
> 
> Is this overkill for a flowscript?

I think these are all great use cases, which can show the potential of flow
scripts! I can definitely see how flowscripts would help the development of
such tools.

I started working on a simple documentation system which allows
documentation to be published, and give user the ability to add notes to
each page. I said this in the past too, I really like the way the PHP
documentation system is setup. For an example check out:

http://www.php.net/manual/en/language.constants.php

I want to implement a similar system using Cocoon, flow scripts and Castor
as a mapping tool between a relational database and Java objects. This is a
non-trivial example which I hope shows how the separation of concerns is
enforced in this design.

Regards,
-- 
Ovidiu Predescu <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)



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