Stephen Compall <[email protected]> writes:
> On Jan 13, 5:09 am, Jan Rychter <[email protected]> wrote:
>> 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.
>
> This description makes get/set-children-of-type sound like a harder-to-
> use solution to the same problem that map-subwidgets solves. Does it
> solve any problems other than child/subwidget list composition?
Well, you can't really compare the two, because as I understand it,
map-subwidgets serves a single purpose: enumerating subwidgets and
mapping a function onto them. The whole {get|set}-children-of-type
implementation does a bit more than that.
There are three reasons why I chose to go this way:
1. Debuggability: It is much easier to debug and understand variables
than method combinations. This means that you can easily insert a
(break) somewhere in your code and just inspect what this particular
widget's children are. You can't easily do that using the map-subwidgets
approach.
2. Rendering order control: I have cases where I want to control
rendering order of all children precisely, in one place. I do not want
to juggle :before, :after and :around methods on render-widget-body and
render-widget-children, I just want to override one method and render
all children. As an example, I have an "event-story" widget that
inherits from a number of other widgets, each providing children
(commentable is one of them). It is natural to render everything in the
proper order in one place.
3. Children storage and flows: This approach solves the children storage
problem for everyone, and provides a default make-widget-place-writer
method. This means that you will very rarely need to write your own,
unless you do something strange.
I think map-subwidgets is more elegant, but less practical.
Also, I would be interested to know what it is you find hard to use
about {get|set}-children-of-type?
--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
-~----------~----~----~----~------~----~------~--~---
