Hi,
I'd like to create a repository for Pier using Magritte with pragmas (shall
we call it Magritte 3?). Can you (Lukas) create a new repository for Pier
(Pier3/ Pierunstable?) on source.lukas-renggli.ch
Thanks
Nick
Just when it was all going so well.... I started trying to port Pier to
use Magritte with pragmas and hit some issues:
Pier structures are instantiated with snippets of code thus:
addChild: ((PRComponent named: 'children')
componentClass: PRChildrenWidget;
write: 1 using: PRChildrenWidget descriptionLevel;
yourself);
the description is no longer defined on the class side so the above doesn't
work. Superficially a quick solution might be modify the code thus:
addChild: ((PRComponent named: 'children')
componentClass: PRChildrenWidget;
write: 1 using: (PRChildrenWidget *new*) descriptionLevel;
yourself);
However within PRComponent the method PRComponent>>#componentDescription
currently uses the componentClass to generate the descriptions. Again this
could be modified to create an instance and retrieve the descriptions from
the instance. However I started to wonder if there is a better way, rather
than creating numerous temporary instances for extracting the descriptions.
My initial idea is to pass a prototypical instance instance to PRComponent
with the default values set, this would then eliminate the need to create
multiple instances for description retrieval - the descriptions can be
retrieved directly from the prototypical instance. The above code would
then be something like:
addChild: ((PRComponent named: 'children')
prototypeInstance: ((PRChildrenWidget *new*) descriptionLevel: 1; yourself);
yourself);
Then I run into more issues as PRChildrenWidget doesn't currently have
write accessors for described properties (nor do any objects derived from
PRWidget), clearly that could be fixed ... but I'm starting to wonder if
I'm going down a sensible path and the modifications required simply fall
out of having instance-side descriptions or if I'm heading completely in
the wrong direction.
Thoughts?
Nick
Hi,
I've removed Magritte's description caching in the latest version so that
descriptions are now created dynamically on demand. Without the cache I
found I needed to guard against recursive descriptions and ended up using a
dynamic-variable as a temporary cache to break the recursion.
I had to modify one test to avoid a failure:
MADescriptionBuilderTest>>testRecursive
self assert: self magritteDescription children first reference = self
magritteDescription
The failure was caused by the child descriptions both having null accessors
which use random UUIDs so will never be equal. I fixed this by specify an
accessor: "accessor: MADictionaryAccessor new;"
I've created a Magritte-Deprecated package which contains:
MADescriptionBuilder
MANamedBuilder
MAProxyObject
MADynamicObject
MADynamicObjectTest
Also the following package extension methods have been placed in deprecated:
Object>>#description
Object class>>#description
BlockClosure>>#magritteDynamicObject
BlockContext>>#magritteDynamicObject
and I've removed all references to #magritteDynamicObject and the
associated block in the core Magritte packages.
Nick
Hello all.
Short history, what is the better manner to load jquery libraries for get
working a PQCyclerWidget?
Long...
I wanted to add a slideshow to a Pier site and I saw that already exists a
PRWidget for JQCycle, and I say great! Quickly I got to show the images
that I added to a structure, but without the effect... After a some
experimentation (I'm newbe in Pier) I saw this error in the browser
console: "Uncaught exception: ReferenceError: Undefined variable: jQuery".
Then I understood that the jquery library was not loaded, and I go to the
implementation of PQCyclerWidget and saw this:
PQCyclerWidget>>updateRoot: anHtmlRoot
super updateRoot: anHtmlRoot.
"assume that jQuery libraries are already loaded"
anHtmlRoot javascript url: JQWidgetBoxDeploymentLibrary / #jquerycycleallJs
then, I add this (before the existing line) and now the slideshow works
fine:
anHtmlRoot javascript url: '
https://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js'.
which is surely not the right way to load jquery in pier.
About instalation of this widget, I just load JQWidgetBox-Core and
JQWidgetBox-Cycle-Core in a Pier2 image (no dev packages), it is correct?
Regards
Hi,
In Lukas's proposal for moving to instance-side descriptions there are
various benefits mentioned such as:
- 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.
>
I'm not sure I understand the cache-invalidation issue. MAPragmaBuilder is
derived from MADescriptionBuilder and uses MADescriptionBuilder
*cache*instance variable which is invalidated in the same way as
before, so
currently the two implementations are equivalent. Was something different
envisaged?
Did you envisage any change to the use of #magritteDynamicObject?
Cheers
Nick
Highlights:
* Magritte descriptions now work on the instance side
* /magritte/editor works with instance side descriptions
* Refactoring support to move descriptions to instance side
Details:
* All code is in the repository:
http://source.lukas-renggli.ch/magritte2unstable
* Taking feedback from previous mail pragmas are now named: <*
magritteDescription*>, <*magritteDescription:* #extensionMethod>,
<magritteContainer> respectively for descriptions, descriptions extensions
and description containers (description containers extensions do exist,
they use the same pragma <magritteContainer> but take the container as a
parameter).
* All tests are green, and the /magritte/editor works.
* The refactoring supports works at the method, class and
class-category/package level. It adds the appropriate pragma for
descriptions, description extensions and container descriptions. The
methods keep the same category (this is to avoid package extensions methods
inadvertantly being reclassified). I attempted renaming #descriptionAddress
to #addressDescription but it complicated description extensions so I
decided to keep things simple. The refactoring support can be loaded from
Magritte-Tools. Before you try the refactoring, read the caveats below.
Caveats:
* I've ported but haven't tested the Morphic bindings. Be great if someone
who knows the Morphic bindings can test.
* The refactoring will not add 'class' for class-side selectors. For
example the following description:
> descriptionGroup
> ^ MAStringDescription new
> accessor: #group;
> default: self defaultGroup;
> label: 'Group';
> priority: 105;
> yourself
will be refactored to:
descriptionGroup
> <magritteDescription>
> ^ MAStringDescription new
> accessor: #group;
> default: self defaultGroup;
> label: 'Group';
> priority: 105;
> yourself
However you'll have to manually add a 'class' to 'self defaultGroup' to
make it 'self class defaultGroup' .... unless someone knows how to fix
this?...
* all instance side #description & #description: selectors within
MADescription and MAMemento hierarchy have been renamed to
#magritteDescription
& #magritteDescription: respectively. I've tried to catch all senders of
#description and change them to #magritteDescription. However instance
creation methods have kept their original naming for example MAMemento
class>>model:description:
Next Steps:
Attempt to refactor Pier and fix bugs based on feedback.... over to you....
Nick
In a fresh Pharo-1.3-13315 image, from Monticello Broswer I loaded ...
ConfigurationOfMagritte2-NickAger.34 from
'http://source.lukas-renggli.ch/magritte2'
ConfigurationOfMagritteAddOns2-NickAger.7 from
'http://source.lukas-renggli.ch/magritte2addons'
then executed each of ...
ConfigurationOfMagritte2 project stableVersion load.
ConfigurationOfMagritteAddOns2 load.
with the second producing the following dependency error...
This package depends on the following classes:
WAObject
JSJsonParser
You must resolve these dependencies before you will be able to load
these definitions:
MJJsonParser
MJJsonParser classSide>>onStream:description:
MJJsonParser classSide>>parse:using:
MJJsonParser>>addProperty:to:
MJJsonParser>>createObject
MJJsonParser>>descriptionFor:of:
MJJsonParser>>initializeOnStream:description:
MJJsonParser>>parseProperty
MJJsonParser>>pushDescription:during:
MJObject
MJObject classSide>>descriptionContainer
I have resolved this loading ConfigurationOfSeaside30-dkh.352 and then
executing...
ConfigurationOfSeaside30 load
cheers, Ben
I am just about to dip my toe into trying out Magritte to implement a
UML model and would like to clarify how bidirection relationships work.
Section 2.6.1 of [1] says... "A relationship is always defined from the
described object to the referenced object.
To describe a two-way relationship the developer has to define a
relationship description at both ends of the association."
I haven't seen a specific Magritte example of that, but I assume it is
similar to the Phosyden example [2]
> personEntity hasOne: #Pet as: #myPet.
> petEntity hasOne: #Person as: #owner.
That makes sense where there is only a single relation between two
classes. However where there are two relations between two classes as
shown in attached image, how are relations (1a,1b) paired together and
(2a,2b) pair together. Or would this pairing generally be of no
consequence?
I would naively assume these four definitions...
1a. topologicalNodeEntity hasOne: #TopologicalIsland as: #topologicalIsland.
1b. topologicalIslandEntity hasMany: #TopologicalNode as: #topologicalNodes.
2a. topologicalNodeEntity hasOne: #TopologicalIsland as:
#angleRefTopologicalIsland.
2b. topologicalIslandEntity hasOne: #TopologicalNode as:
#angleRefTopologicalNode.
cheers, Ben
[1] http://www.iam.unibe.ch/~scg/Archive/Diploma/Reng06a.pdf
[2]
http://dbxtalk.smallworks.com.ar/pier/Documentation/mission-4_-about-relati…
