Re: Meeting Today

We will still have the following basic i-vars. These hold objects that need to be there in a valid object: Structure: id, parent, properties Chapter: children Page: document Resource: data, mimetype I think properties should be optional and be inherited on the instance side, e.g. if a component does not define a template or a storage the one from the parent will be taken or the default one if nothing is specified. In the current code the implementation of this behavior is duplicated several times. Another issue is the relation between the id and title. The id is used to the url from. Currently the title is generating a new id automatically whenever it changes. This has got the advantage that the url is always reflecting the page title, but there are also major drawbacks: - changing the title breaks your bookmarks to the page - titles have to be checked for validity (the id must be unique within a chapter) - special characters in titles make it hard to create links to that pags, as they could be used in wiki *Title>Page*. I completely agree, the things that are needed to represent a page, a chapter or a resource are still in i-vars. I don't think that every component needs a title, so I would put this into the properties. Yes I think we could write some simple accessors for the most often used properties like Structure>>title Structure>>storage Structure>>template ... and for the rest we would need to use Structure>>propertyAt: aSymbol If we don't want the static approach, my idea would be doing it highly dynamic ;-) Structure>>doesNotUnderstand: aMessage (aMessage args size = 0) ifTrue: [ ^self propertyAt: aMessage selector ] (aMessage args size = 1) ifTrue: [ ^self propertyAt: aMessage selector put: aMessage args first ] ^super doesNotUnderstand I promised too much this morning: My headache has become worse and I cannot work on the computer such a long time. So we will have some more time to discuss and evaluate the possibilities :-) -- Lukas Renggli http://renggli.freezope.org