Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 12141 invoked by uid 500); 25 Jun 2002 16:12:01 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 12121 invoked from network); 25 Jun 2002 16:12:01 -0000 User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Tue, 25 Jun 2002 09:11:57 -0700 Subject: Re: Use Cases [was Re: [RT] SpitScript - B-Logic that doesn't suck ( Re: [RT] Flowmaps)] From: Ovidiu Predescu To: CC: Message-ID: In-Reply-To: Mime-version: 1.0 X-url: http://www.geocities.com/SilliconValley/Monitor/7464/ Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Diana, On 6/25/02 6:52 AM, "Diana Shannon" wrote: > > On Sunday, June 23, 2002, at 12:25 PM, Daniel Fagerstrom wrote: > > > >> 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 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