First let me say, Magritte is great, and works well. But like all software systems, there is an opportunity for improvement.
We have added several of our own renderers, and so I have encountered some difficulties myself. And again, praise for Magritte because it does, in many places throughout the code, provide mechanisms for overriding default classes and behaviors. I like that the properties dict is readily accessible make it far more extensible than it would be without it. There is a LOT to like!
What Udo describes is a common problem when it comes to re-using libraries: the ability to substitute in your objects... is not always easy. This is not a Magritte-only issue, in fact, Magritte was prepared for this better than most classes I encounter. Over the years, I have encountered many libraries that require strict adherence to the class hierarchies provided within. And in many cases of using these libraries, one writes way too much code mapping between object types, and/or subclassing everything. (If my class satisfies the interface, why can't I substitute it for the native class? -- rhetorical, as there are always exceptions.)
Generally speaking, I believe we should rely less on rigid inheritance than on our ability to send any message to any object. This extreme polymorphism provided by Smalltalk is what makes so great. If we are going to require and design with strict inheritance requirements, we might as well be working in languages that support multiple inheritance.
-
Another catch, that is also a general problem in OO programming/code-organization: just because the programmer of a library defined a MagritteDescription set, doesn't mean she knows how the end application would want the tool rendered. In fact, a given application may wish to present the component in many different ways -- mine does.
Therefore I added methods like the following, to help present different ways in different contexts:
#magritteDescriptionSelecting: attributeNameListInOrder
#asHorizontalComponent
#asTableReportFor: aList magritteDescription: magDescr commandColumns: commandColumns
And numerous other, and permutations of, such convenience methods.
As noted by Udo: indeed, the weaving in of CSS makes problems like this even more complex.
-
One potential solution to the default class substitution problem, is to give users of libraries a way to specify the substitute classes in one neat table... but that 'view' of the world should be only one ... namespace-re-mapping, because, perhaps another piece of code in the same image (and even subsystem) does not want to make the same substitutions. [Which means all class refs must be compiled to be a lookup of the class by name in a thread specific namespace -- rather, namespace-override-dictionary. ... or something... better thought out!]
I am a big believer in registries. It is crazy to *believe* that in one location, one programmer can stuff all the information into an object (instance) that satisfies all the needs of all would-be users of the class; especially if this information is hard-coded into the class definition (instance side). Rather, the designer of an application, probably does know how they want certain things displayed; and when they don't, they use default behavior.
-
Again, my comments are very general. I love Magritte, it is a core tool that I use.
[And if this is all just off-topic silly blather ... please don't flame me!]
-Cam