[squeak-dev] A little ToolBuilder nitpick

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] A little ToolBuilder nitpick

Igor Stasenko
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.

Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: A little ToolBuilder nitpick

Andreas.Raab
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.
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: A little ToolBuilder nitpick

Igor Stasenko
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.