magritte - multiple dynamic views for information gathered on multipage form

I have a traditional "gather information over 10 pages" app in Perl that I'm
rewriting using Seaside and Magritte.  The current app stashes everything in a
giant Perl hash (saving and loading from hidden vars) at each step.
Sometimes, the presence or absence of (or even repetitions of) a field depends
on previous questions answered on previous pages.  When I started to model
this with Magaritte, I quickly hit some roadblocks trying to implement the
dynamic "descriptionFoo" since these are (a) cached and (b) have no access to
"self" since they are class-side.  So I've managed to come up with something
that sorta works instance-side, but I'm not very happy with it, as I wonder
for example how many times "myModel description" will be called during a
render, and whether I should try to cache that.  I also am ending up with a
series of subclasses of a parent class that holds the entire collected values,
but has only the items of interest.  None of this seems very clean, and it
seems like I'm reinventing some wheels.

Does anyone have some examples of how to do things like a basic "gather info
from a multipage query, some of which depends on earlier answers" task would
work and look like?

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

It is perfectly fine to override #description on the instance-side  
and return a dynamically composed object depending on the state of  
self (or the current context, whatever).

While rendering the component keeps a reference onto the returned  
description, so #description should only be called once. However  
calling #description is usually not a bottleneck, only when  
traversing a huge graph of thousands of objects you will find a  
measurable speedup when using the cached descriptions.

> Does anyone have some examples of how to do things like a basic  
> "gather info
> from a multipage query, some of which depends on earlier answers"  
> task would
> work and look like?

Sounds like an interesting design problem.

Do you need the model to be adaptive, so that end users can define  
questions and model the flow on the fly? Or are the questions and  
flow hard-coded?

Cheers,
Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

>>>>> "Lukas" == Lukas Renggli <[hidden email]> writes:

Lukas> Do you need the model to be adaptive, so that end users can define  
Lukas> questions and model the flow on the fly? Or are the questions and  
Lukas> flow hard-coded?

Questions and flow are hard-coded.

Basically, I'm replacing the "booking engine" at geekcruises.com.  Go to any
cruise, pick "book now", check the check box, and submit.

You'll be in the Perl code that I'm replacing after that.  It's safe to paw
through there, all the way to the end, because nothing gets recorded until the
last "book it" hit.

The cabin types depend on the cruise number from the initial request.  The
number of detailed passenger infos depends on the number of people given
earlier.  And so on.  So, the views have to be somewhat dynamic based on
previous questions, and I'm also hitting the database for a few of the things
so I don't want to have to do that repeatedly for the same web hit for the
same query.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Isn't there some kind of component that breaks things into different
pages?  If not, then this page has some good information:
http://onsmalltalk.com/programming/smalltalk/using-magritte-with-seaside/

I am making a series of sites right now that all view the same domain
objects, so I can't use the defaults from Magritte because the
"description" will depend on who is looking.

In Magritte we can customize as high up as we want.  My plan right now
is simply not use #asComponent for display, but instead have a
asAComponent for one site and asBComponent for another.  Each one
would select a different set of descriptions as described in the link
above.

Another option would be to make a custom component (or perhaps
renderer is better, I haven't looked deeply at this part) that has a
"page" member to show what page is displaying, calls the object side
descriptions but caches the results (it may already work this way) and
so on.

I'm sure others know other tricks, I'm just starting with Magritte.

On 10/22/07, Randal L. Schwartz <[hidden email]> wrote:
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

>>>>> "Jason" == Jason Johnson <[hidden email]> writes:

Jason> Isn't there some kind of component that breaks things into different
Jason> pages?  If not, then this page has some good information:
Jason> http://onsmalltalk.com/programming/smalltalk/using-magritte-with-seaside/

Oooh... I may have stumbled on that already, but I ended up recreating
parts of it for what seems to be working now.  The MAAccessor info looks
like it'll help solve the next problem I have though.  Yeay.

Jason> In Magritte we can customize as high up as we want.  My plan right now
Jason> is simply not use #asComponent for display, but instead have a
Jason> asAComponent for one site and asBComponent for another.  Each one
Jason> would select a different set of descriptions as described in the link
Jason> above.

Yeah, here's what I came up with in my WATask'ish thing:

MyTask>>go
  self call: self page1Component.
  self call: self page2Component

MyTask>>page1Component
  | result |
  result := model asPage1Component.
  "tweak description for this view"
  result description componentRenderer: MACssRenderer.
  result description attributes addClass: 'specialclass'.
  "tweak view"
  result
    addValidatedForm;
    addDecoration: (WAMessageDecoration new message: 'page 1'; yourself).
  ^result

(page2 component is similar)

MyModel>>asPage1Component
  ^MAContainer new
    add: self descriptionField1;
    asComponentOn: self

MyModel>>asPage2Component
  ^MAContainer new
    add: self descriptionField2;
    addAll: self descriptionsField3; "might return 0..n items"
    add: self descriptionField4;
    asComponentOn: self


I'm trying to keep the "view" tweaks in the Task, because I think the task
should own how the container is rendered, although I think the subcontainers
will probably define their own viewish flavors without help.  I may rethink
this later. :)

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki