Jan Rychter <[email protected]> writes:
> Thanks for your comments. As I understand it, the only purpose of the
> container is to keep a list of children, e.g. maintain tree structure
> for non-leaf nodes. If you remove it, where do you keep the list of
> children? Do we make all widgets keep that list?
It is not quite the same. Non-containers can have and render children;
this is what MWPW is for. From a refactoring I did yesterday (uses
SERIES, note this is in a project with a completely different
`walk-widgets' interface):
(defwidget pseudo-composite ()
()
(:documentation "Instead of leaving things in a list, put them in
slots and define a method on pseudo-composite-slot-names."))
(defgeneric pseudo-composite-slot-names (pc)
(:method-combination append)
(:documentation "Calculate the slots that hold widgets. When
unbound or nil, they are assumed to be nonexistent."))
(defun scan-pc-slot-names (pc)
(declare (optimizable-series-function))
(scan 'list (pseudo-composite-slot-names pc)))
(defun scan-pc-children (pc)
"Answer a series of child widgets to be rendered."
(declare (optimizable-series-function))
(choose (mapping ((slot (scan-pc-slot-names pc)))
(slot-get pc slot))))
(defmethod walk-widgets progn (proc (self pseudo-composite))
(iterate ((subwij (scan-pc-children self)))
(walk-widgets proc subwij)))
(defmethod weblocks:render-widget-body ((self pseudo-composite) &key
&allow-other-keys)
"Render each pc-child in order."
(iterate ((subwij (scan-pc-children self)))
(weblocks:render-widget subwij)))
(defmethod weblocks:make-widget-place-writer ((container pseudo-composite)
subwidget)
"Linear search among subwidgets."
(find-for-widget-place-writer
container subwidget
(mapping ((slot (scan-pc-slot-names container)))
(make-slot-widget-place container slot))))
Pseudo-composite is probably a terrible name for this :)
> If we make all widgets keep a list of children, I'm all for removing the
> container. I just wasn't sure whether we want to carry that baggage
> around.
One of the things I do is rename `container-children' to
`widget-children'. However, the intention is not that all children must
be answered from that method; that is what `generate-subwidgets' is
for. Instead, `widget-children' is *only* for a settable list of such
children, and has no backing slot on widget; all container still
provides is a slot with :accessor and an MWPW method.
> I really wanted to get rid of the selector class, but could not. In fact
> it was gone at one point, but came back, because of
> container-update-direct-children. It represents an interface between
> widget tree updating and the get-widget-for-tokens method, and that
> interface is common to all selectors.
Which I do differently, without CUC and CUDC, with the help of widget
tree walking.
>> * Question: Is a selector required to render its selected widget?
>
> I *think* the answer is "yes", as both selectors in that case
> will render their widgets (one is a menu and the other is the
> content).
Actually, I think this makes the answer "no", because the menu one
*doesn't* render the selected widget.
Anyway, if the answer is yes, I think the cache ought to mve back into
selector, since for all selectors there is the notion of a selected and
to-be-rendered widget.
--
I write stuff at http://failex.blogspot.com/ now. But the post
formatter and themes are terrible for sharing code, the primary
content, so it might go away sooner or later.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"weblocks" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/weblocks?hl=en
-~----------~----~----~----~------~----~------~--~---
