tag:blogger.com,1999:blog-7515306875906042828.post3381698822129561291..comments2024-02-05T11:56:11.174-08:00Comments on Objology: Sounding Out the View TreeTravis Griggshttp://www.blogger.com/profile/01599271142862167244noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-7515306875906042828.post-78741039906626403392011-10-18T03:45:09.540-07:002011-10-18T03:45:09.540-07:00This comment has been removed by a blog administrator.get a facebook fan pagehttp://www.socialcubix.com/services/branded-page-design-and-developmentnoreply@blogger.comtag:blogger.com,1999:blog-7515306875906042828.post-55365983984688337062011-10-13T07:53:35.073-07:002011-10-13T07:53:35.073-07:00The key is the primary object that is to be resolv...The key is the primary object that is to be resolved from a context. Consider starting with the key as the receiver and use double-dispatch to resolve from a context.<br /><br />Instead of:<br />(self ? (Query tag: #dialogAnswer)) enable<br /><br />use:<br />(#dialogAnswer ? self) enable<br /><br />Symbol>>? anObject<br /> ^Query tag: self in: anObject<br /><br />or:<br /><br />(#dialogAnswer tagIn: self) enable<br /><br />Symbol>>tagIn: anObject<br /> ^Query tag: self in: anObject<br /><br />The Query class methods would be a general interface for resolving for context.<br /><br />In general though, I'm not convinced that the added cost of instance creation is worth the benefit of code expressiveness. It is easy to extend ApplicationModel with helper methods that are efficient and still expressive.<br /><br />I use query objects for logical operations on separately maintained database collections. There is significant benefit for that purpose.Paul Baumannhttps://www.blogger.com/profile/09535202244914473312noreply@blogger.comtag:blogger.com,1999:blog-7515306875906042828.post-17242293427562954902011-10-10T17:00:27.507-07:002011-10-10T17:00:27.507-07:00Nice idea. A couple of nits.
ViewTreeSet doesn...Nice idea. A couple of nits.<br /><br />ViewTreeSet doesn't appear to be a set, and doesn't appear to require a tree of views -- just a tree of nodes such that each node has #parent and #children. Might call 'em TreeWalkers. Might say to yourself #parents or #offspring when you mean one or the other of these collection facades. And you might say that sending them #select: a1block is a lot like sending #query: (Query block: a1block). Hmmmm... #selectId:, #selectTag:, #selectType:... almost useful enough as shorthand to be pushed up into Collection. Although #withId:, #withTag:, and #withType: seem easier to read. YMMV of course. Binary selectors aren't quite as necessary in this form, which is good, because using #? to produce a collection facade merely sucks swamp gas. Whereas using double #?? to get another that now runs in reverse? Blows chunks. <br /><br />So -- nice idea.cstbnoreply@blogger.comtag:blogger.com,1999:blog-7515306875906042828.post-61937236228464251492011-10-07T20:23:14.109-07:002011-10-07T20:23:14.109-07:00I like the basic approach. One aspect I don't...I like the basic approach. One aspect I don't care for is the requirement for the developer to know that SpecWrapper is what implements #show, for example. I just want to send #show to the widget and have it figure out that it needs to go to the SpecWrapper. What if the ? returned a widget traversal object instead of the final widget. It would know that #show is to be sent to the SpecWrapper and #layout is to be sent to the BorderedWrapper. Then, the user doesn't have to specify the wrapper class he wants to talk to.David Buckhttps://www.blogger.com/profile/14309364915707457568noreply@blogger.comtag:blogger.com,1999:blog-7515306875906042828.post-80268861434950785322011-10-07T07:00:38.754-07:002011-10-07T07:00:38.754-07:00I agree with Ralph. On any mature VW project, a t...I agree with Ralph. On any mature VW project, a ton of time is spent hunting down builders in subcanvases (and tracing containers) in order to make what a user calls "a simple UI change". This approach looks like it could make that a whole lot easier to think about.James Robertsonhttp://www.jarober.comnoreply@blogger.comtag:blogger.com,1999:blog-7515306875906042828.post-32756260271712332042011-10-07T04:51:10.955-07:002011-10-07T04:51:10.955-07:00I spend most of my day in Seaside and javascript. ...I spend most of my day in Seaside and javascript. jQuery does a very good job of allowing you to skip DOM details. I can see how this approach would work well with VW UI code. I agree with Ralph: keep working on it!Bob Nemechttps://www.blogger.com/profile/09778957926861701906noreply@blogger.comtag:blogger.com,1999:blog-7515306875906042828.post-79149465425553575532011-10-07T04:09:30.632-07:002011-10-07T04:09:30.632-07:00But making it easier to change wrapper order, or t...But making it easier to change wrapper order, or to get rid of wrappers, is a big deal.<br /><br />I think this shows a lot of promise. Keep on working on it!Ralph Johnsonhttps://www.blogger.com/profile/04679750650357730843noreply@blogger.comtag:blogger.com,1999:blog-7515306875906042828.post-3349004977665877352011-10-07T00:40:41.361-07:002011-10-07T00:40:41.361-07:00I don't mind running around in other objects t...I don't mind running around in other objects that much.<br />What I object is where you have to look makes no sense to me whatsoever.<br />Visibility? Better fetch the SpecWrapper.<br />Changing layout? BoundedWrapper, here we go!<br /><br />Huh????<br /><br />Other than making it easier to potentially change wrapper order, I don't really see how writing myElement ?? SpecWrapper instead of myWidget container container container makes it easier to write and understand the code when what you want to do is make the widget visible or not...CmdDothttps://www.blogger.com/profile/17314894420874752547noreply@blogger.comtag:blogger.com,1999:blog-7515306875906042828.post-24292757452199392702011-10-07T00:39:30.276-07:002011-10-07T00:39:30.276-07:00This comment has been removed by the author.CmdDothttps://www.blogger.com/profile/17314894420874752547noreply@blogger.com