18 Feb
2003
18 Feb
'03
11:43 a.m.
Hi,
I'm not feeling very well, so I won't be able to come to the meeting
today. But of course I am reachable by e-mail.
I plan to do some heavy refactorings on the Structure hierarchy and
update the tests today. I don't know how far I will get.
What I plan to do is:
- find a good way to map title to urls
- include property management
- move the template, title, ... i-vars to properties
- create a management interface for properties
BTW, do we want to be able to access properties directly "structure
title" or only with special function calls like "structure propertyAt:
#title"?
Some further goals are (probably not for today):
- attach the security-model
- develop a more generic interface for storage
Sorry for yesterday's e-mail in german: I discussed with Hannes about
SIXX and how easy it is for a dump-out storage. As I already explained
the XML-Parser gets messed-up when parsing very long ByteArrays (used
to store resources). So I think the way to go is to store the
resource-data as external binary files. I don't know yet if this solves
the problems, but at least I hope so.
Cheers
Lukas
--
Lukas Renggli
http://renggli.freezope.org
18 Feb
18 Feb
2:35 p.m.
Hi,
I'm not feeling very well, so I won't be able to come to the meeting
today. But of course I am reachable by e-mail.
Ok
I plan to do some heavy refactorings on the Structure
hierarchy and
update the tests today. I don't know how far I will get.
What I plan to do is:
- find a good way to map title to urls
- include property management
- move the template, title, ... i-vars to properties
- create a management interface for properties
I'm thinking aloud: do we really want to have only properties?
The distinction between an ivars and a property is that a property is
optional?
I have the impression that the important structural elements should be
ivars.
What do you think about that?
BTW, do we want to be able to access properties directly "structure
title" or only with special function calls like "structure propertyAt:
#title"?
I would prefer to use method structure title
this way we do not see how they are encoded.
But this means that we should have some way of creating method when you
declare
a new property and I do not like that. I prefer a static approach.
So could we discuss before you change everything in the point 3 above
(move template, title, ivars to properties)?
Some further goals are (probably not for today):
- attach the security-model
- develop a more generic interface for storage
Sorry for yesterday's e-mail in german: I discussed with Hannes about
SIXX and how easy it is for a dump-out storage. As I already explained
the XML-Parser gets messed-up when parsing very long ByteArrays (used
to store resources). So I think the way to go is to store the
resource-data as external binary files. I don't know yet if this
solves the problems, but at least I hope so.
But you should ask the vwnc mailing-list
Cheers
Lukas
--
Lukas Renggli
http://renggli.freezope.org
Prof. Dr. Stéphane DUCASSE (ducasse(a)iam.unibe.ch)
http://www.iam.unibe.ch/~ducasse/
"if you knew today was your last day on earth, what would you do
different? ... especially if, by doing something different, today
might not be your last day on earth" Calvin&Hobbes
3:48 p.m.
I plan to do
some heavy refactorings on the Structure hierarchy and
update the tests today. I don't know how far I will get.
What I plan to do is:
- find a good way to map title to urls
- include property management
- move the template, title, ... i-vars to properties
- create a management interface for properties
I'm thinking aloud: do we really want to have only properties? The
distinction between an ivars and a property is that a property is
optional? I have the impression that the important structural
elements should be
ivars. What do you think about that?
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.
BTW, do we
want to be able to access properties directly "structure
title" or only with special function calls like "structure
propertyAt: #title"?
I would prefer to use method structure title this way we do not see
how they are encoded. But this means that we should have some way of
creating method when
you declare a new property and I do not like that. I prefer a static
approach.
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
So could we discuss before you change everything in
the point 3 above
(move template, title, ivars to properties)?
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
19 Feb
19 Feb
7:09 p.m.
Hi lukas
I hope that you are going better. My mailbox just got the wonderfull
idea to get desync from pop so I just got 6000 mails duplicated :)
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.
OK
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 did not really get it so you will explain us that.
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.
I'm not sure that title should not be a iv of page if page has to have
a title. There is a difference between an entity having a property and
all the entities.
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
I would prefer to avoid that and do not mix meta stuff with the rest.
But this means that we should have some way of
creating method when
you declare a new property and I do not like that. I prefer a static
approach.
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
Rest well. Computers can wait. I hope you will be ok to see ralph
johnson.
Stef
So could we discuss before you change everything
in the point 3 above
(move template, title, ivars to properties)?
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
Prof. Dr. Stéphane DUCASSE (ducasse(a)iam.unibe.ch)
http://www.iam.unibe.ch/~ducasse/
"if you knew today was your last day on earth, what would you do
different? ... especially if, by doing something different, today
might not be your last day on earth" Calvin&Hobbes
10:23 p.m.
I hope that you are going better.
Yep, a little bit.
My mailbox just got the wonderfull idea to get desync
from pop so I
just got 6000 mails duplicated :)
Arghhhh ...
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 did not really get it so you will explain us that. But this means that we should have some way of
creating method when
you declare a new property and I do not like that. I prefer a static
approach.
If we don't want the static approach, my idea would be doing it
highly dynamic ;-) So could we discuss before you change everything in
the point 3
above (move template, title, ivars to properties)?
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 :-) I hope you will be ok to see ralph johnson.
I hope so too. Do I have to prepare something?
Cheers
Lukas
--
Lukas Renggli
http://renggli.freezope.org
7976
days inactive
7977
days old
4 comments
2 participants
participants (2)
-
Lukas Renggli -
Stephane Ducasse