[Moose-dev] Re: Mondrian vs Roassal: a conceptual comparison

In which way? Cheers, Doru On Mon, Oct 15, 2012 at 3:18 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: Well spotted. Version 1.165 of Roassal is now consistent. Cheers, Alexandre On Oct 14, 2012, at 4:49 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > On 14 Oct 2012, at 16:07, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >>> For example, take the text block of a label: >>> >>> textFor: aROElement >>> | v | >>> v := (text roValue: aROElement). >>> ... >>> >>> If the separation would be clear for everyone the roValue: would be evaluated against the model. >> >> We are now pointing at something interesting. ROAbstractLabel>>textFor: indeed contains " (text roValue: aROElement)", which is okay to me. > > The problem is that right now Roassal is not consistent. Either all transformation methods in shapes talk to the element, or they all talk to the model. Right now, we have 4 methods talking to the model and 3 talking to the element. > > Evaluate this to check: > methodsThatCallModel := OrderedCollection new. > methodsThatCallElement := OrderedCollection new. > ROShape withAllSubclasses flatCollect: [:cls | > | forMethods | > forMethods := cls methods select: [:each | each selector endsWith: 'For:']. > forMethods do: [:method | > method parseTree allChildren do: [:node | > (node isMessage and: [ node selector = #roValue: ]) > ifTrue: [ > (node children noneSatisfy: [:childNode | childNode isMessage ]) > ifTrue: [methodsThatCallModel add: method] > ifFalse: [methodsThatCallElement add: method] > ] > ] > ] > ]. > methodsThatCallModel explore. > methodsThatCallElement explore. > > >> Within the builder it can be otherwise... > > If all shapes work consistently with the element, we would have to build a parallel hierarchy for shape builders to make them talk with the model. It can be done, but the design should be consistent. > > Cheers, > Doru > > >> Alexandre >> >> >> >>> >>> >>>> - The builder should probably develop towards offering high-level patterns of animation that still preserve the transformation metaphor. >>> >>> Yes >>> >>>> - And perhaps we have to go beyond the current builder. For example, EyeSee is an example of another API and model that could probably be implemented on top of Roassal. >>> >>> That would be cool. >>> Some users of Roassal have expressed such a need... >>> >>> Alexandre >>> >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> >>>> On Oct 11, 2012, at 3:46 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> There were several posts that intrigued me lately related to the >>>>> difference between Mondrian and Roassal, and I did not know exactly >>>>> why. Now, I think the reason stems from the conceptual difference >>>>> between the two. So, here I go :) >>>>> - Roassal is a basic engine that provides a DOM-like graph object >>>>> model. Its main goal is to enable one to build and manipulate visual >>>>> objects. >>>>> - Mondrian is a high level transformation engine. Its main goal is to >>>>> enable one to transform an arbitrary subject model into a graph >>>>> visualization. >>>>> >>>>> Of course, Mondrian had a basic engine, too, inside, but it was not as >>>>> flexible as Roassal (especially in the animation part). However, the >>>>> main point of Mondrian was really to support the transformation. >>>>> >>>>> It is for this reason that all blocks in the Mondrian API take the >>>>> subject model as an input. The target is the developer that knows his >>>>> model and almost nothing about Mondrian (except for the simple >>>>> transformation predicates). This was a conscious decision, not a >>>>> mistake. It is clear that you miss flexibility (e.g., you cannot >>>>> manipulate the node within an action block), but you gain simplicity >>>>> for basic actions. >>>>> >>>>> Another choice in Mondrian was to focus on the graph model. It is >>>>> again clear that this decision excluded some classes of >>>>> visualizations, and as a result several visualizations misused the >>>>> high-level transformation engine for low level object placing. An >>>>> example of this is the DSM. It is precisely in this area (and of >>>>> course others that were not charted yet) that Roassal can play a very >>>>> important role. >>>>> >>>>> I think both points of view are important, and it would be cool to >>>>> look for solutions that marry both (1) the transformation engine level >>>>> that speaks mostly the "language" of the original objects, and (2) the >>>>> graphical engine that offers basic blocks for visual manipulation. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Every thing has its own flow" >>>>> _______________________________________________ >>>>> Moose-dev mailing list >>>>> Moose-dev(a)iam.unibe.ch >>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)iam.unibe.ch >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of problem understanding." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev(a)iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev