[Bese-devel] ucw component api (design question)

[Marco Baringer]

[thinking out loud]

ucw is currently being used for a relativly simple document management
system, and it's working out nicely. however there is one issue i've
run into and it's what seaside calls "component threads."  let's take
the example of a simple document editing component embeded in a larger
document system app.

here's the use case i'm dealing with:

we have a menu style widget which displays a tree of options and
associate each item onthe menu with a particular action (save changes,
change state, view diffs, email alert, etc.) and the save changes 
action is implemented as something like this:

(defaction save-changes ((d document))
  (aif (verify-state d)
       (when (call 'confirm-save d)
         (update-document d)
         (call 'category-manager (document.category d)))
      (call 'document-invalid :bad-slots it)))

simple enough right? the "problem" (i'm not really sure it's a problem
yet) is that the calls to confirm-save and 'document-invalid replace
the entire "page" and not just the part of the page which was
dedicated to the document. you can see this effect when you inspect
the result of something in the admin repl.

what would be nice, for this particular situation, is that the calls
to CALL changed not the current component of the latest session-frame,
but only the component contained in the tabbed-pane which contains
this document (and the menu), ie i'd like the rest of the page to
remain the same (the tabbed pane should remain, as should the menu
both in their current state) and have the rendering of CONFIRM-SAVE to
appear only in the position of the page which previously contained the
DOCUMENT component.

what changes would this require? basically every component would need
to know one where, in the tree (or graph?) of components making up the
app's UI it was located. in this case we could rather simply change
the CALL macro to affect not the current-component but only the
call'ing component's place in this tree. however, this does not mean
we will never need the current "replace the entire UI with this
component" operation (so we'd end up with CALL and CALL* operators
which differed only in the graphical placing of the call'd component).

there are some issues:

1) as far as rendering goes we now need to distinguish components
   which are "embeddable" (and therefore don't produce an entire valid
   html doucment), with "root" components (which produce the html,
   head and body tags. it's simple enough to turn an embeddable
   component into a root component, so maybe this isn't as big an
   issue as it looks.

2) is a simple container/contained component relationship enough or
   do we something more general? 

3) am i just confusing the rendering of components (the graphical
   presentaton of a ui) with the control flow of an app? if so, hat
   would be a "good" solution to this?

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