Providing lookup environment for descriptions
Locked
Providing lookup environment for descriptions
 
|
I'm using some option descriptions. For resolving possible options of to be referenced objects I use something like
options: [ HRExampleObject instances ] magritteDynamicObject; Now I'm trying to avoid using globals. Especially when dealing with gemstone it is not advizable to have class side instances management. Is there a way to specify some lookup environment to lookup something like the above? Norbert _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: Providing lookup environment for descriptions
|
|
On 16.11.2010, at 21:22, Norbert Hartl wrote: > I'm using some option descriptions. For resolving possible options of to be referenced objects I use something like > > options: [ HRExampleObject instances ] magritteDynamicObject; > > Now I'm trying to avoid using globals. Especially when dealing with gemstone it is not advizable to have class side instances management. Is there a way to specify some lookup environment to lookup something like the above? > Well, the question was maybe too unspecific. At first I'm looking for a possibility to create options from the instance side while dealing with components. On my custom components I could do that easily by overwriting availableList. I'm just looking for a more generically applicable solution that does not force me to build a custom component for every case. thanks, Norbert _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: Providing lookup environment for descriptions
|
|
On 17/11/10 4:34 AM, Norbert Hartl wrote:
> > Well, the question was maybe too unspecific. At first I'm looking for > a possibility to create options from the instance side while dealing > with components. I don't fully understand what you're trying to achieve, but how about you override #description on the instance side. Something like: description | desc instanceSpecificDesc | desc := super description copy. "Copy, else per class cache altered" desc add: (instanceSpecificDesc := self descriptionInstanceSpecific). instanceSpecificDesc optionsAndLabels: self buildOptionsAndLabels. "instanceSpecificDesc options: self buildOptions." A variation, to have all the descriptions documented on the class side, is as follows: description | desc customizedDesc | desc := super description copy. customizedDesc := desc detect: [:each | each label = 'Customized']. customizedDesc options: self customOptions. ^ desc _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: Providing lookup environment for descriptions
|
|
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. -------------------- On 17 November 2010 13:56, Yanni Chiu <[hidden email]> wrote: > On 17/11/10 4:34 AM, Norbert Hartl wrote: >> >> Well, the question was maybe too unspecific. At first I'm looking for >> a possibility to create options from the instance side while dealing >> with components. > > I don't fully understand what you're trying to achieve, but how about you > override #description on the instance side. Something like: > > description > | desc instanceSpecificDesc | > desc := super description copy. "Copy, else per class cache altered" > desc add: (instanceSpecificDesc := self descriptionInstanceSpecific). > instanceSpecificDesc optionsAndLabels: self buildOptionsAndLabels. > "instanceSpecificDesc options: self buildOptions." > > A variation, to have all the descriptions documented on the class side, is > as follows: > > description > | desc customizedDesc | > desc := super description copy. > customizedDesc := desc detect: [:each | each label = 'Customized']. > customizedDesc options: self customOptions. > ^ desc > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
Hi Lukas,
This sounds really useful.
Since these changes are not backward compatible I'll try to provide I am using similar tricks to the ones Yanni indicated above to build instance specific instances - so it looks like your proposal would simplify that code considerably. I've also been bitten by the name clash with #description.
One specific annoyance I have is with class extension description methods that are installed by addons that I can't disable (I currently delete the methods). Specifically: PRCase>>descriptionDocumentTagCloud: aDescription ^ aDescription beTagCloud PRStructure>>descriptionNameTagCloud: aDescription
^ aDescription beTagCloud I use the TagCloud addon, but don't want the structure name to be included and instead of document I use plain text (arguably the plain text change might be more widely applicable, but probably the first is more specific to my use cases)
Perhaps it's overcomplicating to be able to disable class extension descriptions - without making the code incomprehensible. --- The other issue is with Magritte description caching and Gemstone. After I change a description in Gemstone I have to remember to flush the description cache. This seems to be due to a combination of Gemstone's classHistory and lack of support for weak collections(?). Is this on your radar?
---- I imagine your proposed changes will require some effort to rework Pier - as it uses Magritte extensively - I guess we can all pitch in to try to make it happen smoothly - perhaps we could organise a Camp Magritte/Pier??
---- Nick _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: Providing lookup environment for descriptions
|
|
In reply to this post by Yanni Chiu
On 17.11.2010, at 17:56, Yanni Chiu wrote: > On 17/11/10 4:34 AM, Norbert Hartl wrote: >> >> Well, the question was maybe too unspecific. At first I'm looking for >> a possibility to create options from the instance side while dealing >> with components. > > I don't fully understand what you're trying to achieve, but how about you override #description on the instance side. Something like: > > description > | desc instanceSpecificDesc | > desc := super description copy. "Copy, else per class cache altered" > desc add: (instanceSpecificDesc := self descriptionInstanceSpecific). > instanceSpecificDesc optionsAndLabels: self buildOptionsAndLabels. > "instanceSpecificDesc options: self buildOptions." > > A variation, to have all the descriptions documented on the class side, is as follows: > > description > | desc customizedDesc | > desc := super description copy. > customizedDesc := desc detect: [:each | each label = 'Customized']. > customizedDesc options: self customOptions. > ^ desc > this came to mind as well. I was asking if there is a better idea to achieve the same. Norbert _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: Providing lookup environment for descriptions
|
|
In reply to this post by Lukas Renggli
On 17/11/10 12:21 PM, Lukas Renggli wrote:
> > 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. I like the proposed changes. I've run into all those problems that would be fixed. The pragma usage is something I'll have to get used to. It's not clear whether your plan is to start with the Magritte2 code base, and create, say, a Magritte3. Or is it to make the changes directly to the Magritte2 code base. Changing Magritte2 directly would mean one less branch to be maintained. Either way is fine with me. _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
«
Return to Magritte, Pier and Related Tools
|
1 view|%1 views
| Free forum by Nabble | Edit this page |