14 Apr
2009
14 Apr
'09
11:19 p.m.
Hi Lukas!
On Tue, Apr 14, 2009 at 3:42 PM, Lukas Renggli <renggli(a)gmail.com> wrote:
I understand you point, but it is rare for me to see "label" and
"priority"
in the descriptions that are use only to create the view (at least that is
what I saw so far...). That is what I meant by "coupling with the view".
But the block is still coupled with some implementation...
I was thinking about something more similar to a desktop app, where you
create the view and then you set the objects you want to show. For example:
addressView := AddressView new.
addressView cantons: self cantonsSubsystem contents.
addressView open.
I agree, but I don't see how to access the right customer manager from the
seaside component...
yes, I saw that, it is great!
1) Has anybody
defined the descriptions in other class but the model
class?
It seems to me that defining the descriptions as
class methods in the
model
class creates a coupling between the model and
the view that I would like
to
avoid. Part of that coupling is because of some
view's "attributes" like
label, priority, beSorted, readOnly, etc. It also couples the model with
Magritte, which avoids me to use the model in an environment without
Magritte.
Magritte is not the "View". Magritte is model as well, the meta-model.
If you would like to keep descriptions separate, that can be easily
done using extension methods. So one could imagine having the
descriptions in a separate package, other than the actual model.
Furthermore different other packages could modify these descriptions,
or add their own.
Foo class>>descriptionBar (in model package)
^ MAStringdescription new
accessor: #bar;
yourself
Foo class>>descrptionBarView: aDescription (adds the label in view package)
^ aDescription label: 'Bar'
Personally I keep the descriptions all in the model, unless there is a
good reason not to do so.
That's a good idea. I don't like extensions too much but it sounds
reasonable for this case.
Anyway, I'm still thinking about using another object to have the
descriptions... I'll let you know how it worked out
2) The description "descriptionCanton"
of the tutorial, is another
example
of why I want to decouple descriptions from the
model class. In the
tutorial
the cantons are hard coded in the method, but
that is not possible in a
"real" app. Cantons should be taken from another object, lets say the
"Cantons" object. But if I keep the "descriptionCanton" in Address
and
use
"Cantons" from there, I will be
coupling Address with Cantons, which will
prevent me from using Address in another context or with provinces or
states
instead of cantons. Does anybody has a suggestion
for doing this?
See above and <http://www.lukas-renggli.ch/smalltalk/magritte/faq>.
3) To keep the
objects that are created, the tutorial suggests to use a
class variable, but that is an option that does not scale. For instance,
what happens if I want to host the same app several times with different
data? (we are planning to use GLASS) Using the tutorial classes, I would
like to have an instance of MAPersonManager for one of our customers,
another instance of MAPersonManager for other customer, and so on. Also,
using a class variable keeps us from writing tests for that class because
that variable is shared among all the objects (tests, the real app, etc).
I
think this is more a SeaSide question...
I would make the customers part of the model and store a
MACustomerManager in some "persistent root". Tests get their own
MACustomerManager instance. 3) I see that Magritte always needs an object to
edit it. I mean, an
instance of Address to edit an address, an instance of Person to edit a
person, and so on.
No. Descriptions can always be used on any object, as long as the
object can handle them. MAMemento is such a power-object. It can
essentially handle any set of descriptions. It simply keeps a
dictionary from descriptions to their current values.
These mementos are used during edit operations. To Magritte a memento
object looks like the real object, but it can be edited and changed so
that it is temporarily in an invalid state without affecting the real
object and thus other concurrent users. Some memento subclasses can
even detect and merge conflicts. The real object is only changed when
all validation conditions are satisfied.
yes, but if I want to validate the object creation and use the
#syncronizeWith: idea I have to do something more I guess...
We need also to keep the changes that are made to an object, so directly
changing the object will not do it...
Keep the questions rolling.
Thanks for the answer!
Bye,
Hernan
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki