Stephen Compall <[email protected]> writes: > Jan Rychter <[email protected]> writes: >> 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. > > Okay, but see response to #3 below. > >> 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. > > As seen with HFSBO services-and-pricing, where rendering subwidgets is > intermixed with rendering object views, this only hinders you when doing > anything but the most basic one-widget-after-another rendering. It > would be less-than-ideal to require inheritors of this widget to > reimplement its particular rendering logic.
I disagree -- but I think we have different use cases, so it is difficult for us to understand each other's motivation. In the "commentable" widget case for example, inheritors do not have to do anything. They can rely on the built-in render-widget-body and render-widget-children methods and their combinations, which will usually get things right. However, if they need to, they may override the methods and compose things differently, having a uniform interface to the children of each type (and there may be multiple types per superclass). I don't see my solution hindering anything, but I do see it being helpful in a number of cases in my current application. >> 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. > > It doesn't when storing children in lists is inconvenient. In my case, > I frequently store children in separate slots, or in the case of > services-and-pricing, in a fast-changing hash table. There are *no* > cases where I've defined a widget that stores children in lists; it's > never been the proper representation for me. But then you have to provide a make-widget-place-writer method, right? If you do not, your widgets aren't future-proof -- they aren't ready to deal with flows. I like the fact that I can store my children anywhere I want, then call set-children-of-type and know that any of them can now be replaced in flows, if only my render methods stick to using get-children-of-type. I've found this to be very useful. > This also shows why #1 isn't an issue. You can see these slots, and > drill into the hash table. Yes, I also store widgets in slots sometimes. However, I found that sometimes I use slots (comment-bar), sometimes slots with lists (comments), and providing make-widget-place-writer methods in appropriate places was rapidly becoming cumbersome. And really, you don't even have to notice that set-children-of-type deals with lists, because it also accepts a single widget. So think of it as a storage location, not necessarily a list. As for debugging, I realize it's subjective. I find it very helpful to be able to see at a glance what ALL the children of a particular widget are. --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 -~----------~----~----~----~------~----~------~--~---
