22 Oct
2007
22 Oct
'07
3:59 a.m.
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
<merlyn(a)stonehenge.com> <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!
22 Oct
22 Oct
9:52 p.m.
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.
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
10:39 p.m.
>>>> "Lukas" == Lukas Renggli
<renggli(a)iam.unibe.ch> 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
<merlyn(a)stonehenge.com> <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!
23 Oct
23 Oct
7:33 a.m.
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 <merlyn(a)stonehenge.com> wrote:
>>>> "Lukas" == Lukas Renggli <renggli(a)iam.unibe.ch> 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
<merlyn(a)stonehenge.com> <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
4:46 p.m.
>>>> "Jason" == Jason Johnson
<jason.johnson.081(a)gmail.com> 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
<merlyn(a)stonehenge.com> <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!
6030
days inactive
6031
days old
4 comments
3 participants
participants (3)
-
Jason Johnson -
Lukas Renggli -
merlyn＠stonehenge.com