> Yeah, ok. So nevermind the pull request until the failing tests are > corrected (there are 3). 'detect-dirty-circularity' fails as you > might expect, since I'm now replacing the entire widget, not just its > children, but what's the best way to fix it? I'm trying to understand > what's really meant by 'circular' in this context,
The high-level explanation: dirty widgets get rendered and might mark other widgets dirty in this process. Now think of a cycle. :) > but I don't quite > follow this snippet: > > (setf (slot-value a 'other) b) > (setf d (list a b)) > (weblocks::render-dirty-widgets) > (ensure-null d) > > I see that setting a slot on one widget will cause it to be marked > dirty, but two questions: > > 1) why is 'd' supposed to be null Because *dirty-widgets* must be NIL when the dirty algorithm has finished. > 2) shouldn't only widget 'a' be dirty? No. Take a look at the preceding method: (defmethod render-widget-body ((wij dirtier) &key &allow-other-keys) (mark-dirty (slot-value wij 'other)) (princ 42 *weblocks-output-stream*)) It marks the other one as dirty. Plus both are stuffed into D/*DIRTY-WIDGETS*. So both are marked dirty and additionally one is also marked dirty by the other widget's rendering method. Got it? :) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
