Vyacheslav Akhmechet <[email protected]> writes:
> On Mon, Feb 16, 2009 at 3:13 PM, Jan Rychter <[email protected]> wrote:
>> There is one widget-children slot -- how do you combine the various
>> children that each of your parent widgets has?
> Errr, I see. I thought the word 'inheritance' referred to parent-child
> relationship in the widget tree, not the actual Lisp type inheritance.
> That's what threw me off into the abyss of bewilderment :) Everything
> is clear now, thank you.
>
> My vote then goes towards the append method combination for some
> get-widget-children method. It seems to fit into this near perfectly,
> is easy to manipulate, and if I saw it I would immediately understand
> what it's for, while your solution was actually more confusing :) I
> don't think newbie-friendliness is a good argument not to use advanced
> CL features - if that were the goal you might as well write weblocks
> in Java. I also don't think method combinations are very difficult to
> debug (you can just print the return value of the function). These are
> my two cents.
I am not particularly attached to my solution, in fact I would gladly
trade it for something which is nicer and works better. It just needs to
do all that is required.
As for debugging, I disagree: to print the return value you need to have
a full environment (session, etc) set up and you have to instrument your
code. Then you have to track method ordering, and that isn't
obvious. I'd much rather just inspect a slot and see what's there. But
that point isn't that important.
Please remember that we also want these children to be ready to
participate in flows, so storing them in different ways isn't a good
idea unless one wants to write multiple make-widget-place-writer
functions. In particular, I found that storing widgets in slots and
ad-hoc lists really isn't such a great idea.
Also, an append method combination fixes the ordering, which in my case
is a no-no.
>> No, the goal was for you to override render-widget-children.
> Ok. I think that in most cases people will want to interleave child
> widgets with their own markup so it makes more sense to render child
> widgets in the specialization of render-widget-body for widget, and
> let people render them on their own when they specialize
> render-widget-body. It seems like this would be optimizing for a more
> common case.
I try to be careful in using words like "most cases" -- I found out that
people have wildly different use cases. Let's take the "commentable"
mixin example. Here's its render-widget-children method (it does not
provide a render-widget body method):
(defmethod render-widget-children ((obj commentable) &rest args)
(declare (ignore args))
(when (show-comment-bar-p obj)
(apply #'render-widget (get-children-of-type obj :comment-bar)))
(when (show-comments-p obj)
(call-next-method)))
Note that comment-bar participates in flows (it gets replaced by a rich
text editor).
Now, call-next-method will call pageable-list's render-widget-children,
which will render the pagination widget and the current list of comments
(which will vary depending on pagination).
The nice thing about this is that all I have to do to use this is to
make, say a news-item widget "commentable". That's pretty much it --
render-widget-children kicks in and things Just Work. However, should I
want to override the rendering order, I can easily do that by overriding
render-widget-children and doing all the work myself,
get-children-of-type being my only interface to actually get at
appropriate widgets.
I don't really want to defend my approach, as I myself am not that happy
with it, but I'd like everyone to understand the motivation behind, so
that we (I?) don't lose functionality.
--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
-~----------~----~----~----~------~----~------~--~---
