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. > 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. This also shows why #1 isn't an issue. You can see these slots, and drill into the hash table. -- Sorry but you say Nibiru is a Hoax? Doesnt Exist? So maybe The Sumerian people doesnt exist also! --Anonymous by way of SkI --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
