Storing WAComponent / WATask etc. in magma

Hi all,

I'm writing a seaside application in which I'm modeling the access a
logged in user has on various object as views / tasks on collections (or
subsets of collections) which are stored in magma.

e.g. in terms of a blog application: blog posts are stored in magma in a
collection. The master user has access to all posts but rather than
having an instance variable which holds a collection of blog posts the
user has an instance variable which holds a view on the blog posts to
which this user has access. This view is a subclass of WAComponent or in
case of editing / creating a new blog post a subclass of WATask. (Other
users have views which operate on different subsets of the blog posts
collection, but I can have a second master user simply by providing a
view on all posts). I hope this makes sense...

At first I stored these components / tasks in magma but it didn't work.

I changed the design and created a new class hierarchy subclassing
Object  and stored these objects in magma. These new classes essentially
store configuration data for the different views and provide a single
message which creates a new WAComponent (or task).

Later I noticed two thinks:

1) The reason why my application didn't work as expected probably hat
   nothing to do with storing the components in magma
2) I'm creating two class hierarchies which do essentially the same,
   there is one class to store the view in magma (subclassing Object)
   and another class subclassing WAComponent to create the view.

Before changing everything back (this will be a lot of work) and storing
WAComponents in magma I wanted to ask first if this will work? Do I have
to expect some strange behavior? Is this a good idea[tm]?

Thanks,

Florian
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2008/12/23 Florian Obser <[hidden email]>:
Don't do that. Components are session specific.

> At first I stored these components / tasks in magma but it didn't work.
>
> I changed the design and created a new class hierarchy subclassing
> Object  and stored these objects in magma. These new classes essentially
> store configuration data for the different views and provide a single
> message which creates a new WAComponent (or task).

That's the way to go. You don't necessarily have to use a class
hierarchy, you can use arbitrary configuration objects that hold on to
class names and other configuration values.

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> e.g. in terms of a blog application: blog posts are stored in
> magma in a collection.

Fine so far.

> The master user has access to all posts but rather than
> having an instance variable which holds a collection of blog posts the
> user has an instance variable which holds a view on the blog posts to
> which this user has access.

Not good.  You're creating a dependency in the model on the view, it should
be the other way around.  Models, i.e. your user, should not hold a
reference to the view that displays it, have the view hold a reference to
the model instead.  Your first instinct to have the user have a collection
of posts he has access to was more correct.

Try thinking like this... throw out the views altogether and just model your
domain all by itself.  Your objects are something like Blog, Post, User, and
Comment.  Get that all working first so you can grab a user in a workspace
and inspector and do stuff like "user posts" to see all the posts a user has
access to or "blog posts" to see all the posts in the blog, or maybe "blog
postsFor: user" to grab the posts a user can see.  Play around until you're
happy with the model and the persistence and have it all working without a
UI.

Don't start working on the views until you have the models all figured out.
The view is then nothing more than a layer that enables manipulation of the
persistent model.  Views are transient, not persistent, and should not be
stored.  Models should be unaware of the views that manipulate them.  Views
should have instance methods that represent the models they're manipulating.

> Thanks, Florian

Ramon Leon
http://onsmalltalk.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside