> Very nice, I'm looking forward to its integration into -dev.
>
> My notes:
>
>> [composite gone]
> We should provide a simple compatibility interface for the old
> composite.
> Not sure about the others with live projects here, but my code is
> littered
> with references to composites and I'd like to migrate gradually.
Well, what I did with my code was almost a search-replace, you basically
need to:
-- replace (root-composite) with (root-widget)
-- replace (make-instance 'composite :children XXX) with (make-instance
'widget :children XXX)
-- replace (setf (widget-children XXX) YYY) with (set-children-of-type XXX
YYY :your-type)
-- replace (composite-widgets XXX) with (get-children-of-type XXX :your-type)
it isn't that hard. I don't think a compatibility interface is possible,
because you simply can't (setf widget-children) anymore without breaking
things.
What I initially wanted was to have a (setf (my-children x) children)
and (my-children x) thing, which would automatically determine the type
of x and use it as a key. It might be possible to do and it would make
the interface somewhat nicer -- but I'd still want to keep the
{get|set}-children-of-type methods, because I have widgets that maintain
two or three lists of children. As an example, a "commentable" mixin
widget maintains a comment bar with a comment count and an action link
and a pageable list of comments. The comment bar is on a
:commentable-comment-bar list -- so that it can be replaced by an editor
when a "comment this" action is initiated. That's just immensely
useful. Same for rendering, it is much easier to lay things out without
having a big bag of all children all mixed up.
>> -- you can render navigation content separately from the menu (teleport
>> hack)
>
> It's a hack?
Yes, I consider it a hack, but I don't see a way to do it any
better. The problem is that the source containing widget has to know
that it isn't supposed to render its contents and that you're basically
cheating the tree structure -- if you have multiple navigation widgets
this might be a problem.
This solves my immediate problem, but one could certainly implement a
real split navigation where one part would influence another. I just
couldn't justify the effort involved.
>> -- you can't (setf widget-children) anymore, see set-children-of-type
>
> Looks more complicated that it needs to be. Why not a mandatory
> type argument to (setf widget-children) ?
You can supply arguments to (setf) functions?
>> -- anyone who uses set-children-of-type can participate in flows as a parent
> How does this relate to make-widget-place-writer?
There is one make-widget-place-writer which will work for everyone that
maintains their children using set-children-of-type. If you don't stick
you children there, you're on your own and you need your own
make-widget-place-writer. But I don't see why you'd want to do that
anymore.
--J.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
