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