Hi,
I've built on Esteban's pragma work and all tests are again green - that is
the Magritte container and description extensions now work.
The code is in:
http://source.lukas-renggli.ch/magritte2unstable
If you want to try it out you'll have to ensure MAPragmaBuilder is used by
resetting the builder:
MADescriptionBuilder default: nil.
Currently the code is backwards compatible.
The next step appears to be to break backwards compatibility and move the
descriptions to the instance side.
Lukas mentioned that it might be possible to automate this breaking change
with an automated refactoring. I've had a quick look at some of the
existing refactorings and will need some support to build a reliable
refactoring, which should perform the following:
1) Add <magritte>, <magritte: #extensionMethod>, <magritteContainer>
for respectively descriptions, descriptions extensions and description
containers.
2) Move the descriptions to the instance-side
Perhaps more contentiously it could also:
3) put descriptions in category "magritte" or "magritte-descriptions" or
"meta-descriptions" rather than just "descriptions"
4) rename descriptions from: #descriptionPlace to #placeDescription.
Once descriptions are on the instance-side Magritte will require a little
more refactoring... Then Pier will need to be migrated...
Any thoughts on the above or pointers on how to tackle the automated the
refactoring?
Thanks
Nick
Lukas makes an excellent case for moving the Magritte descriptions to the
instance-side - in his original email below.
I'm happy to have a first pass at moving the descriptions to the
instance-side and adding description extensions.... unless someone else has
already dived-in with an implementation.
If I hear nothing I'll make a start tomorrow...
Nick
---------- Forwarded message ----------
> From: Lukas Renggli <renggli(a)gmail.com>
> Date: 17 November 2010 17:21
> Subject: Re: Providing lookup environment for descriptions
> To: "Magritte, Pier and Related Tools ..." <smallwiki(a)iam.unibe.ch>
>
>
> The way Magritte builds descriptions by default has become quite a
> nuisance. Of course you can always do your own thing as Yanni
> describes, but I think that at some point Magritte should be improved
> in that regard. I wrote a proposal this summer of want to proceed on
> that, 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 <magritte> to annotate the methods. And to extend and
> change existing descriptions use <magritte: 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
> <magritte>
>
> ^ MASingleOptionDescription new
> options: self possiblePlaces;
> label: 'Place of Item';
> accessor: #place;
> yourself
>
> Class extensions can modify a description using:
>
> Item>>placeDescriptionXmlStorage: aDescription
> <magritte: #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.
>
> --------------------
>
>
FYI
---------- Forwarded message ----------
From: Lukas Renggli <renggli(a)gmail.com>
Date: 17 November 2010 17:21
Subject: Re: Providing lookup environment for descriptions
To: "Magritte, Pier and Related Tools ..." <smallwiki(a)iam.unibe.ch>
The way Magritte builds descriptions by default has become quite a
nuisance. Of course you can always do your own thing as Yanni
describes, but I think that at some point Magritte should be improved
in that regard. I wrote a proposal this summer of want to proceed on
that, 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 <magritte> to annotate the methods. And to extend and
change existing descriptions use <magritte: 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
<magritte>
^ MASingleOptionDescription new
options: self possiblePlaces;
label: 'Place of Item';
accessor: #place;
yourself
Class extensions can modify a description using:
Item>>placeDescriptionXmlStorage: aDescription
<magritte: #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.
--------------------
Hi Esteban,
Great news!
> I made some minor changes to magritte2, to accomplish a
> few things you pointed as desirable:
Please send such mails to the list.
> 1) replace #description with #magritteDescription
Right, but that will break a lot of code. Especially with Pier, that
does a lot of fancy reflection on its structure and that is very hard
to fix (at least the last time I tried). What about doing that in a
second step?
> 2) Create a pragma-based builder, using <magritteDescription> and <magritteContainer> pragmas
Great.
- Did you consider moving the descriptions to the instance-side, so
that we have the descriptions together with the accessors and that we
can have instance- and class-side descriptions?
- Did you think about descriptions that get dynamically injected from the model?
- Did you consider getting rid of the description cache and replacing
it with a description selector cache? So that we can get the
descriptions quickly but they are built dynamically in the context of
the object?
- Did you think about the extensibility properties, i.e. with method
extensions: #descriptionFoo, #descriptionFooBarExt:,
#descriptionFooZorkExt:, ...
> 3) a small fix to make Magritte-Morphic work on Pharo 1.4 (a change on multiselect lists)
Just commit it, if it doesn't break Pharo 1.3.
> this is still not well tested (although all tests are green), but Nick wanted to start using it, so I wonder if there should be a new repository (magritte3, maybe, or "magritte2.1", whatever) to start working?
>
> what do you think, should I create it (in your repository)?
Feel free to commit it to the current repository, if it doesn't break
any builds. Otherwise we might want to submit it somewhere else before
merging into the head.
Lukas
>
> Cheers,
> Esteban
--
Lukas Renggli
www.lukas-renggli.ch
I'm playing with and already enjoying Magritte after the awesome talk Nick
and Esteban gave at ESUG this year.
How do I customize Magritte editors in Morphic? Specifically, for the
Address example from the Seaside book, I tried:
anAddress asMorph
addButtons;
addWindow;
openInWorld.
but the fields were really tiny and hid most of the text as you can see
below (on Nabble at least):
http://forum.world.st/file/n4251518/PharoScreenshot.2.png
Then I tried a standard Morphic approach:
| form window |
form := anAddress asMorph addButtons.
window := SystemWindow new addMorph: form fullFrame: (LayoutFrame
fractions: (0@0 corner: 1.0(a)1.0) offsets: (10@10 corner: 10@10)).
window openInWorld.
but I got "MessageNotUnderstood: MAContainerMorph>>layoutFrame:"
--
View this message in context: http://forum.world.st/Customizing-Magritte-Morphic-Forms-tp4251518p4251518.…
Sent from the Magritte, Pier and Related Tools mailing list archive at Nabble.com.
I'm having little success with this. Nick Ager's recent documentation
regarding Pier Admin has been very helpful in many other respects and
has inspired me to pursue Pier further, but embedding a Seaside
component or application seems to elude me.
If I create a small Seaside application, how do I reference it so that
it embeds in my blog? A small example sure would help.
Many thanks.
The Pier-JQueryMobile-Core package, along with the attached 3 changesets
(which override Pier/Magritte methods), need to be installed. Then run:
PRJQueryMobileDistribution new register
It's unfortunate that the changesets are needed. Maybe someone has a
better way.
Also attached are two screen shots of what you should see. You should
have a default jQueryMobile UI for Pier.
