An introduction to Magritte 3, describing the rational for Magritte 3, the refactoring support available and porting guideline for upgrading to Magritte 3. How to download a Magritte 3 sample
3. Magritte: Describe once,
get everywhere
Introspection Object persistency
Re鍖ection
Object indexing
Documentation
Object setup
Viewer building
Object veri鍖cation
Form/Editor building
Object adaption
Report building
Data validation Object customization
Query processing and much more
4. Why Magritte 3 All in all the "new" Magritte would look like in the following
From: Lukas Renggli example. Imagine a shop item with the accessor #place:
November 2010 Item>>place
^ place
I wrote a proposal this summer of want to proceed on Item>>place: aString
that, but of course I had to finish my writing and never actually place := aString
found the time to implement it:
The meta-description is defined on the instance-side and annotated. It
-------------------- can refer to itself for the possible places:
I propose to perform the following (non-backward compatible) changes Item>>placeDescription
in the Magritte 2 code-base to resolve some major annoyances and <magritte>
issues that keep on reoccurring:
^ MASingleOptionDescription new
- Move descriptions from class-side to instance-side. This resolves options: self possiblePlaces;
various issues such as cache-invalidation, instance specific label: 'Place of Item';
descriptions, dynamic descriptions, context dependent descriptions, accessor: #place;
etc. Furthermore the descriptions will be closer to the code they yourself
describe and it will be possible to describe class- and instance-side
of an object, not just the instance-side. Class extensions can modify a description using:
- Rename the method #description as the default entry point into Item>>placeDescriptionXmlStorage: aDescription
Magritte to #magritteDescription. This avoids common problems where <magritte: #placeDescription>
the domain model already defines such a method.
^ placeDescription xmlTag: 'xname'
- Instead of using a naming convention for description methods, use a
pragma called <magritte> to annotate the methods. And to extend and Since these changes are not backward compatible I'll try to provide
change existing descriptions use <magritte: aSelector>. Finally all automatic refactorings for most parts. Moving existing code to the new
Smalltalk implementation reached a consensus of pragmas that can be codebase will certainly cause some problems, but in the long run I
safely used cross-platform. 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.
5. Issues with Magritte2
Name collision with #description
class-side description:
Cache-invalidation
dynamic descriptions
instance speci鍖c descriptions
context dependent descriptions
8. Magritte 3
Descriptions move from class to instance.
Use <magritteDescription> pragmas
rather than naming convention.
9. Magritte 3
Descriptions move from class to instance.
Use <magritteDescription> pragmas
rather than naming convention.
All descriptions are dynamically generated.
10. Magritte 3
Descriptions move from class to instance.
Use <magritteDescription> pragmas
rather than naming convention.
All descriptions are dynamically generated.
Rename #description to
#magritteDescription
11. Magritte 3
Descriptions move from class to instance.
Use <magritteDescription> pragmas
rather than naming convention.
All descriptions are dynamically generated.
Rename #description to
#magritteDescription
Non-backward compatible
16. MMAttendee class>>#descriptionBookingDate
^ MADateDescription new
priority: 30;
label: 'Booking date';
tooltip: 'When the attendee booked';
accessor: #bookingDate;
default: [ Date today ] magritteDynamicObject;
yourself
17. MMAttendee class>>#descriptionBookingDate
^ MADateDescription new
priority: 30;
label: 'Booking date';
tooltip: 'When the attendee booked';
accessor: #bookingDate;
default: [ Date today ] magritteDynamicObject;
yourself
MMAttendee>>#descriptionBookingDate
^ MADateDescription new
priority: 30;
label: 'Booking date';
tooltip: 'When the attendee booked';
accessor: #bookingDate;
default: [ Date today ] magritteDynamicObject;
yourself
18. MMAttendee class>>#descriptionBookingDate
^ MADateDescription new
priority: 30;
label: 'Booking date';
tooltip: 'When the attendee booked';
accessor: #bookingDate;
default: [ Date today ] magritteDynamicObject;
yourself
MMAttendee>>#descriptionBookingDate
<magritteDescription>
^ MADateDescription new
priority: 30;
label: 'Booking date';
tooltip: 'When the attendee booked';
accessor: #bookingDate;
default: [ Date today ] magritteDynamicObject;
yourself
19. MMAttendee class>>#descriptionBookingDate
^ MADateDescription new
priority: 30;
label: 'Booking date';
tooltip: 'When the attendee booked';
accessor: #bookingDate;
default: [ Date today ] magritteDynamicObject;
yourself
MMAttendee>>#descriptionBookingDate
<magritteDescription>
^ MADateDescription new
priority: 30;
label: 'Booking date';
tooltip: 'When the attendee booked';
accessor: #bookingDate;
default: Date today;
yourself
20. Refactoring
Move class-side descriptions to instance-
side
add <magritteDescription>
Works for description extensions.
Operates at a method, class or package
level
Battle-tested in translating Pier
21. Refactoring will not
remove empty class-side categories
convert class-side message sends within
descriptions to add class
convert calls from #description to
#magritteDescription
Simplify Magritte 1 or 2 dynamic description work-
arounds
Remove #magritteDynamicObject and its associated
block
22. Porting guidelines
1. Use the refactoring support to move class-side
descriptions to instance side descriptions with pragmas -
making sure that any accessors to class side methods are
either pre鍖xed with class or moved to the instance side.
2. remove #magritteDynamic and remove the block around
the method.
3. search for all senders and implementors of #description
in your code, if they are magritte descriptions rename the
selector from #description to #magritteDescription
4. Remove any empty categories on the class side.
23. Status
All tests green.
Although the API changes appear signi鍖cant the code
changes within Magritte are less signi鍖cant and mainly
localised to MAPragmaBuilder
Pier has been ported to Magritte 3 (Pier 3) and is stable.
Magritte-Json and Magritte-XMLBinding ported
Other Magritte add-ons such Magritte-JQuery un-ported
No performance testing - descriptions are no longer
cached. Is this signi鍖cant in the context of an application?
24. Next steps
Install:
Gofer it
squeaksource: 'MetacelloRepository';
package: 'ConfigurationOfMagritte3';
load.
ConfigurationOfMagritte3 project stableVersion load:'Seaside'.
Gofer it
squeaksource: 'MetacelloRepository';
package: 'ConfigurationOfMagritte3AddOns';
load.
ConfigurationOfMagritte3 project stableVersion load.
Use the refactoring tools to move to Magritte 3.
Pro鍖le performance within your application.
26. Further information
Seaside Book:
http://book.seaside.st/book/advanced/magritte
Lukas's site:
http://www.lukas-renggli.ch/smalltalk/magritte
Magritte/Pier mail list:
<smallwiki@iam.unibe.ch>
Editor's Notes
#2: Although I&#x2019;m saying Magritte 2 this equally applies to Magritte 1 - the only difference between Magritte 1 and 2 was some changes for Seaside 30 compatibility\n
#3: Although I&#x2019;m saying Magritte 2 this equally applies to Magritte 1 - the only difference between Magritte 1 and 2 was some changes for Seaside 30 compatibility\n
#4: Although I&#x2019;m saying Magritte 2 this equally applies to Magritte 1 - the only difference between Magritte 1 and 2 was some changes for Seaside 30 compatibility\n
#5: Although I&#x2019;m saying Magritte 2 this equally applies to Magritte 1 - the only difference between Magritte 1 and 2 was some changes for Seaside 30 compatibility\n
#6: Magritte is a meta-description framework - it allows you to add meta-data descriptions to your domain objects which can then be used to automatically generate reports, editors but not just that I&#x2019;m finding it increasingly useful for serialising into other industry standard formats such as Json, XML then materialising the domain objects back from those formats.\n