A ToolBuilderSpec having a name,
so it is easy to associate a widget with it. But what is a big disappointment to me, that name is not used anywhere outside the builder (when you built the morphs). Some of the this there is a bit odd.. I don't want to use a #widgetAt: , right after issuing #buildOn: to access morphs , because at this stage its not really interesting. The most interesting is to be able to talk with widget when user interacting with your model. It would be nice to have a toolbuilder to set some key in morph's extension attributes to carry its spec's name. Then i could simply check the morph spec name in appropriate places and could do very powerful things with morph, without referencing/keeping it in a model persistently. What i'm actually want to achieve with it, having a good parallel to HTML - first you defining the document structure declaratively, you don't have actual object yet - then when page is loaded you able to use javascript and its very easy to manipulate with elements which having a predefined ids. -- Best regards, Igor Stasenko AKA sig. |
Hi Igor -
I just made a small change that allows you to do that. If a widget spec has an ID the external name of the morph is being set to the same name. This allows you to do things like: open window := ToolBuilder open: self. sysCatList := window submorphNamed: 'systemCategoryList'. (submorphNamed: queries the external name which is assumed to be set in the above) Do note that this is inherently non-portable across frameworks; that's why ToolBuilder has the widget registry to have a common protocol across the various frameworks. However, if you know what you're doing, this can of course be quite useful. Cheers, - Andreas Igor Stasenko wrote: > A ToolBuilderSpec having a name, > so it is easy to associate a widget with it. > But what is a big disappointment to me, that name is not used anywhere > outside the builder (when you built the morphs). > Some of the this there is a bit odd.. > I don't want to use a #widgetAt: , right after issuing #buildOn: to > access morphs , because at this stage its not really interesting. > The most interesting is to be able to talk with widget when user > interacting with your model. > > It would be nice to have a toolbuilder to set some key in morph's > extension attributes to carry its spec's name. > Then i could simply check the morph spec name in appropriate places > and could do very powerful things > with morph, without referencing/keeping it in a model persistently. > > What i'm actually want to achieve with it, having a good parallel to HTML > - first you defining the document structure declaratively, you don't > have actual object yet > - then when page is loaded you able to use javascript and its very > easy to manipulate with elements which having a predefined ids. > > > |
2009/9/6 Andreas Raab <[hidden email]>:
> Hi Igor - > > I just made a small change that allows you to do that. If a widget spec has > an ID the external name of the morph is being set to the same name. This > allows you to do things like: > > open > window := ToolBuilder open: self. > sysCatList := window submorphNamed: 'systemCategoryList'. > > (submorphNamed: queries the external name which is assumed to be set in the > above) > > Do note that this is inherently non-portable across frameworks; that's why > ToolBuilder has the widget registry to have a common protocol across the > various frameworks. However, if you know what you're doing, this can of > course be quite useful. > I seen your commit. It was just a single line of code! Great. Thank you Andreas. The code i'm currently working on is DSDeltaInspector and i have to do the following in the #buildWith: method: window := builder build: spec. rightPane := builder widgetAt: #rightPane. ^window the rightPane is an instance variable, which i using later to replace its submorphs with different submorphs: ... rightPane removeAllMorphs. self buildRightPane. ... buildRightPane | change builder | builder := ToolBuilder default. change := self currentChange. change ifNotNil: [ builder buildAll: (DSDeltaChangeViewer new buildViewOf: change using: builder) in: rightPane ] as you can see, i'm using the toolbuilder for replacing a part of the window with different content. Now , after your changes i don't need to reference the rightPane, but reference the window instead. Which currently doesn't makes any difference so far (because you still have to keep it in ivar), but when its going to manipulate with multiple widgets, identified by a name it will be really helpful. Concerning portability.. well, i had to use a #removeAllMorphs message which can be found in Morphic only. But i am sure that its easy to have some common protocol in all frameworks which using toolbuilder, like: widget replaceContentBy: (builder buildAll: here is set of widgets which built using builder in: widget) or even better, we could add a message to builder, like: builder replaceContentOf: someWidget byBuildingAll: (specsCollection) and, for convenience even add something like following: builder replaceContentOfWidgetsNamed: #foobar inWidget: arootWidget byBuildingAll: (specsCollection) > Cheers, > - Andreas > > Igor Stasenko wrote: >> >> A ToolBuilderSpec having a name, >> so it is easy to associate a widget with it. >> But what is a big disappointment to me, that name is not used anywhere >> outside the builder (when you built the morphs). >> Some of the this there is a bit odd.. >> I don't want to use a #widgetAt: , right after issuing #buildOn: to >> access morphs , because at this stage its not really interesting. >> The most interesting is to be able to talk with widget when user >> interacting with your model. >> >> It would be nice to have a toolbuilder to set some key in morph's >> extension attributes to carry its spec's name. >> Then i could simply check the morph spec name in appropriate places >> and could do very powerful things >> with morph, without referencing/keeping it in a model persistently. >> >> What i'm actually want to achieve with it, having a good parallel to HTML >> - first you defining the document structure declaratively, you don't >> have actual object yet >> - then when page is loaded you able to use javascript and its very >> easy to manipulate with elements which having a predefined ids. >> >> >> > > > -- Best regards, Igor Stasenko AKA sig. |
Free forum by Nabble | Edit this page |