[Bese-devel] UCW guidance
Jan Rychter
jan at rychter.com
Tue Aug 30 13:33:37 UTC 2005
I need some guidance on what is the best way to design UCW applications:
1. I needed to enclose some components within a TAL template page. There
is a menu/navigation bar and the main application area. I ended up
defining a window object subclassing window-component and
template-component. So far so good. But now I have two
simple-container slots, one for the menu and one for the body. Each
container slot in turn contains the menu component and the component
that is the current body. This extra level of indirection (the
simple-containers) seems unnecessary, but without it I couldn't
figure out how to switch the body component. Any advice?
2. I'm using (defmethod shared-initialize :after...) to add my
subcomponents to the main window-component (copied from the
examples). Surely there has to be a better way?
3. When you have a three-step-process (say, a shopping cart checkout),
would you rather implement three separate components that call each
other or one component with internal (backtracked) state, going
through the three states?
4. I believe this question is similar to the one posted earlier by Tim
Lavoie. I ended up writing the following piece of code:
(defaction switch-to ((component main-menu) new-label)
(setf (selected-item component) new-label)
(switch-component (main.body (ucw::parent (ucw::parent component))) new-label))
Needless to say, I find this to be rather ugly. There are two
ucw::parent calls because of the extra level of indirection that I had
to design in (see question 1), but even if it wasn't for that, I'd need
at least one ucw::parent call. There surely is a better way?
Also, I've just been bitten by the cps transformer -- I was trying to
generate an <ucw:action inside a loop clause. Took me a while to find
out that using dolist instead of loop solves my problem... (I guess this
is to be expected in the ucw_dev branch and will change with the cps
interpreter?)
Any advice would be much appreciated!
thanks,
--J.
More information about the bese-devel
mailing list