[Bese-devel] UCW guidance

[Marco Baringer]

Jan Rychter <jan at rychter.com> writes:

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

why make the navbar a container? could something like the component in
the other mail (the one i just sent to Tim Lavoie) work? the body
component you pass to navbar need not even be a contianer, all it
needs is a switch-component method.

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

the example-window should be written like this:

(defcomponent example-window (simple-window-component)
  ((body :component
         (simple-container
          :current-component-name 'example-welcome
          :contents
          `((example-welcome .     ,(make-instance 'example-welcome))
            (counter .             ,(make-instance 'counter))
            (transaction-example . ,(make-instance 'transaction-example))
            (example-form .        ,(make-instance 'example-form))
            (sum .                 ,(make-instance 'sum))
            (presentations-example . ,(make-instance 'presentations-example))
            (file-upload-example . ,(make-instance 'file-upload-example))))
         :accessor example-window.body)))

no, i don't know why it's not already done that way and yes, this
could be improved on.

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

personally i prefer the former (three components) especially since
people (like those pesky clients) keep changing the order of things
and it's easier for me to move three seperate component around in a
single action than change the state handling in a single component.

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

i'd do it like so:

(defaction switch-to ((menu main-menu) new-label)
  (setf (selected-item menu) new-label
        (container.current-component-name (controlled-component menu)) label))

setting up the controlled-component slot should be done in the
shared-initialize method of the component which contains the navbar
(and presumably the 'content' component).

if this seems like a good idea (at the very least better than the
nothing we have now) i'll implement it in the example app.

> 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?)

no, the 'fresh-binding' vs. 'one-binding+modification' is a buch
deeper issue i can't really "fix." as odd as it may seem the current
effect is what is supposed to happen.

> Any advice would be much appreciated!

i hope this helps. the more info (doubts, questions, other
possiblities) the better i can help and the more ideas we can bounce
around.

i think i've said this in the past but i'll repeat it here just in
case. component based continuation enabled web frameworks (libraries,
platform whatever the hell they're called today) are young (ucw
especially so). i do not know what the 'right' answer to these
questions could be: never ever believe that i know what i'm talking
about.

-- 
-Marco
Ring the bells that still can ring.
Forget the perfect offering.
There is a crack in everything.
That's how the light gets in.
	-Leonard Cohen