Doru
You know well that Glamour has a component model that it not plain smalltalk
model. So why are you telling me I do not know what?
Now you also know that Glamour overuse blocks with multiple optional block
arguments where the order is important.
So I do not undersand why you are saying that.
Stef
>
> Interesting comparison. It sounds to me as if this "component model" is a bad
> thing and that VW is a gold standard when it comes to describing user
> interfaces. Also, when you say DSL you refer to the way the Smalltalk API was
> design to read like sentences, which might sound like it goes against the
> tradition of Smalltalk. As for blocks, some would go as far as considering
> them to be plain Smalltalk :).
>
> I think a more detailed comparison would be more useful for newcomers. So,
> here is one.
>
> First, the block issue. The funny thing is that if you want to build a
> dynamic browser with Spec you have to rely on blocks, too. Take a look at an
> example from Ben:
>
> ---
> m := DynamicComposableModel new.
> m instantiateModels: #( button ButtonModel list ListModel).
> m list items: #(1 2 3 4 5).
> m button
> label: 'Plip';
> action: [ self halt ].
> m openWithSpecLayout: (SpecLayout composed
> newColumn: [: c | c add: #list ; add: #button height: 26 ];
> yourself).
> ---
>
> Glamour is actually written in plain Smalltalk, and you can simply use
> subclassing, too.
>
> For example, something like this:
> GLMCompositePresentation new
> with: [ :a |
> a list
> display: [ :input | 1 to: input ];
> act: [ :list | self halt ] entitled: 'Plip' ];
> openOn: 42
>
> Could be done like this:
>
>
> "Define a list presentation with an action in distinct classes to make blocks
> disappear"
> GLMGenericAction subclass: #MyPlipAction
> instanceVariableNames: ''
> classVariableNames: ''
> poolDictionaries: ''
> category: 'AAA'.
> GLMListPresentation subclass: #MyListPresentation
> instanceVariableNames: ''
> classVariableNames: ''
> poolDictionaries: ''
> category: 'AAA'.
> MyListPresentation compile:
> 'displayValue
> ^ 1 to: self entity'.
> MyListPresentation compile:
> 'actions
> ^ {MyPlipAction new}'.
> MyPlipAction compile:
> 'actOn: aPresentation
> self halt'.
> MyPlipAction compile:
> 'title
> ^ ''Plip'''.
>
> "Use the list"
> composite := GLMCompositePresentation new.
> composite add: (MyListPresentation new).
> composite openOn: 42.
>
>
> I doubt the blocks are an actual issue. Using blocks has the advantage of
> more compact code, but it is true that it comes with a price: when you store
> the block you cannot edit its code live while debugging (you actually can do
> that, too if you take care).
>
> The main difference between Spec and Glamour is actually conceptual: the
> application space. Spec addresses widgets: with Spec you place widgets on a
> "canvas" and handle the interaction. So, in a sense, this places Spec at the
> same level as Morphic. Glamour is at a higher level and it is specifically
> dedicated to supporting browsing workflows. In its current state, it is not
> useful for laying out widgets, but it can be very concise for expressing
> browsers.
>
> The way this works is via this "component model". Essentially, a browser can
> be described as a set of components that can pass data to each other. Glamour
> lets you model that.
>
> It so happens that the inspector and the debugger are browsers and can be
> expressed at that level. It also so happens that most user interfaces that
> programmers use can be expressed as browsers, too. And Glamour was actually
> validated for hundreds of various browsers (literally), so it seems it can
> support a large set of use cases.
>
> If you want to learn more about Glamour you can read the chapters from:
> - http://deepintopharo.org, or
> - http://www.themoosebook.org/book/internals/glamour
>
> If you want to see where Glamour fits within Moose, you can read this post:
> http://www.humane-assessment.com/blog/moose-custom-analyses-made-easy
>
> Doru
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
