[Seaside] Magritte 3

[Germán Arduino]

Very interesting, Magritte is one of the more useful frameworks here,
thanks by your work! Thanks also to Esteban.

I'm interested not only in the web UI but also in the Morphic UI, and when
tried the example of MagritteMagic didn't worked:

(MMConference new location: 'Informatics forum'; talks: MMTalk all;
asMorph) addWindow; callInWorld

This is targeted to some specific Pharo version? I can't found #addWindow
nor #callInWorld even when the latest may be replaced by #openInWorld I
think.

Cheers.



2012/2/19 Nick Ager <nick.ager at gmail.com>

> Hi,
>
> I'm pleased to announce a new version of Magritte  - Magritte 3. The
> rational for Magritte 3 is eloquently described by Lukas in his mail below.
> The work on Magritte 3 was started by Esteban and completed by myself.
>
> I've created a screen-cast which describes:
>
>    -  the rational for Magritte 3
>    -  the refactorings available to ease the transition from Magritte 1
>    or 2 to Magritte 3
>    -  A walk-through of updating a sample from Magritte 2 to Magritte 3.
>
> The screen-cast is on vimeo at:
> http://vimeo.com/37032840
>
> The sample used in screen-cast can be downloaded as:
>
> Gofer it
>>  url: 'http://ss3.gemstone.com/ss/MagritteMagic';
>> package: 'ConfigurationOfMagritteMagic';
>>  load.
>>
>> (Smalltalk at: #ConfigurationOfMagritteMagic) load.
>
>
> The slides used in the screen-case can be viewed on slideshare at:
>
> http://www.slideshare.net/nickager/magritte3
>
> Enjoy
>
> Nick
>
>
> ---------- Forwarded message ----------
> From: Lukas Renggli <renggli at gmail.com>
> Date: 17 November 2010 17:21
> Subject: Re: Providing lookup environment for descriptions
> To: "Magritte, Pier and Related Tools ..." <smallwiki at iam.unibe.ch>
>
>
> The way Magritte builds descriptions by default has become quite a
> nuisance. I think that at some point Magritte should be improved
> in that regard. I wrote a proposal this summer for how to proceed,
> but of course I had to finish my writing and never actually
> found the time to implement it:
>
> --------------------
>
> I propose to perform the following (non-backward compatible) changes
> in the Magritte 2 code-base to resolve some major annoyances and
> issues that keep on reoccurring:
>
> - Move descriptions from class-side to instance-side. This resolves
> various issues such as cache-invalidation, instance specific
> descriptions, dynamic descriptions, context dependent descriptions,
> etc. Furthermore the descriptions will be closer to the code they
> describe and it will be possible to describe class- and instance-side
> of an object, not just the instance-side.
>
> - Rename the method #description as the default entry point into
> Magritte to #magritteDescription. This avoids common problems where
> the domain model already defines such a method.
>
> - Instead of using a naming convention for description methods, use a
> pragma called <magritteDescription> to annotate the methods. And to extend
> and
> change existing descriptions use <magritteDescription: aSelector>. Finally
> all
> Smalltalk implementation reached a consensus of pragmas that can be
> safely used cross-platform.
>
> All in all the "new" Magritte would look like in the following
> example. Imagine a shop item with the accessor #place:
>
>   Item>>place
>       ^ place
>
>   Item>>place: aString
>       place := aString
>
> The meta-description is defined on the instance-side and annotated. It
> can refer to itself for the possible places:
>
>   Item>>placeDescription
>        <magritteDescription>
>
>       ^ MASingleOptionDescription new
>           options: self possiblePlaces;
>           label: 'Place of Item';
>           accessor: #place;
>           yourself
>
> Class extensions can modify a description using:
>
>   Item>>placeDescriptionXmlStorage: aDescription
>       <magritteDescription: #placeDescription>
>
>       ^ placeDescription xmlTag: 'xname'
>
> Since these changes are not backward compatible I'll try to provide
> automatic refactorings for most parts. Moving existing code to the new
> codebase will certainly cause some problems, but in the long run I
> believe this to be a much better approach than the current one. If
> people have any feedback, concerns or other changes that would be
> important in the same run I am happy to hear them.
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20120224/16b836ec/attachment-0001.htm