9 Jan
2006
9 Jan
'06
1:32 p.m.
I may be totally wrong but I think that we (maybe
including myself
is a bit premature) could develop a kind of mini-ERP in Pier/
seaside... based on component... for small companies...
If we can do that then no doubt that will a good smalltalk global
interest revival...
does it seem possible to you ? or naive ;)
Sure, something like that should be possible. Give it a try :-)
To me, what makes Pier hard to understand is probably
Magritte and
seaside. To "fully" understand Pier I think one have to understand
Magritte first and it's hard not to blend all concepts (visitor in
magritte, visitor in pier, a renderer is a visitor for Pier,
renderer in Seaside...) - at least for me...
Also, and maybe worst, Seaside main concepts has to be known too...
I think maybe to introduce Pier, it would be good to have a seaside
and magritte overview first... what it is and what it is not...
Yes, it is a requirement to understand Seaside first. The basics of
Magritte (what are descriptions, how are they built and collected,
how is a ui built, ...) can be learned within a few minutes. To
extend and deeply understand it a lot more time is required of
course, after all it is a meta-framework ... something similar (but
simpler) to the object/class/meta-class thing in Smalltalk.
>> What
could I do to make it clearer, despite the lack of missing
>> documentation? Would more method comments help? Are the existing
>> ones useful?
yes personnaly I like method comment... :). Especially in a
framework I like to have information on methods that should or
should'nt be modified... One of my problem is that I always change
code in place where I shouldn't... I also agree that tests are a good doc... would it be
possible to
have access to the tests when browsing a class ? maybe dynamically
copy the test code in the related tested class comment pane ?
Most classes MAFoo have an associated test-class called MAFooTest.
For pier the pattern looks like PRBar has an associated test-class
PRBarTest. You might also browse the references of classes to
understand its use.
I still don't understand well how MAMemento works
(I know it's a
kind of proxy but I cannot see him while exploring objects except
in some fatal error due to bad manipulations...).
The mementos are used to cache the state of described objects while
they are being edited. So the editors work on the mementos instead of
the real objects to be able to 'cancel' edit operations. Since every
read and write access of Magritte is dispatched trough #readUsing:/
#write:using: (implemented in Object and some subclasses) we are able
to capture and delay read/writes to the model by using the mementos.
somethink also what should be good is the steps needed
to add a new
magritte structure... (define the structure and the different
visitors.... I see that you (Lukas) create your defaults visitors
with a class method... is it something reproductible ?)
Well, this class method was just used to create the initial
structure. I guess, that if you add a new structure class you also
add a new visit class at the same time. Yeah, this is certainly
something you might forget, but this is not doable in an clean
automatic way.
So when creating a new structure add the following code and
everything should work (it is not even necessary, when you don't want
to distinguish your visitors from their superclass).
NewStructure>>accept: aVisitor
aVisitor visitNewStructure: self.
PRVisitor>>visitNewStructure: anObject
self visitStructure: anObject.
also MAgritte first reflex is to associate a
description to each
object attributes that need beeing edited and viewed. But what's
look very powerful to is the dynamic construction of
descriptions... but I just have no idea on how to proceed (what I'm
authorized to do and what I'm not).
You are afraid to add new descriptions to existing classes trough
method-extensions? Go ahead, this is exactly made for that ;-)
Does the prevelence orientation makes traditionnal
persistency
mechanisms (relationnal or object databases) irrelevant or
complementary ?
You could use any of those with that prevalence persistency
mechanism. It is just a way of how the history is kept (by keeping a
log of all the commands). Right now I just use simple reference
streams, but anything else could work as well.
Last Point I'm lost with PRQueryVisitor :)
It is partly broken. Sorry. Browse its tests and other references.
and what are the binary visitor ? related to
persistency ?
Yes, this is part of Magritte to be able to serialize described objects.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch