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

[Stefano Mazzocchi <st...@apache.org>]

Diana Shannon 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?

No Diana, you hit the target! With the introduction of flowscript, it is
possible to have a clear view of the logic that controls the flow your
web application, thus the 'glue' that connects your data (business
logic) with the presentation (pipelines).

You are totally right when you say that there is a lot of overlap in the
flow of very different web applications. For example, both a CMS and an
e-learning system share much of the same logic for audit trails of
content publication. But they have totally different flows from the
user-level.

Anyway, you touched the point describing not simple stuff like
'data-entry wizards', but the flows of the entire application realm.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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