21 Oct
2007
21 Oct
'07
3:45 p.m.
I thought that structures already have their own
environments. Are you
saying that a structure, having multiple documents, can have an
environment as one of those.
Yes, we would like to make the environment part of the page itself,
not only a reference to a different structure as it was before. Of
course you can still do that by embedding a different page.
How will moving and copying work for these
secondary-documents?
Copying and moving is possible on the level of structures only. So
when you move a structure, its environment will be moved as well.
That's exactly the same behavior as before.
How about a rule along the lines of "if I contain
an 'environment' use
it, otherwise use my parent's environment" ?
That will be the same.
I also think that you we need a different environment
for editing
environments. So can environments have environments? See below
You can stil do that. Exactly the same way you did before.
I am also attempting to make pier easier to use and
harder to
break. The
scheme that I came up with looks like this.
[...]
This allows the admin users to edit the site-env the environment of
the
overall site. While the admin and site areas themselves use the dev-
env
for display. This prevents admin users from breaking their working
environment dev-env while changing the site-env. It works pretty well.
Personally I find it a bit hard to understand ... ;-)
Anyway, it is (and also should) remain flexible enough so that people
can configure and setup their sites the way they like.
Personally, I am using a very different model:
(contents of the website)
system
(location of the management widgets)
components
(location of reusable components)
parts
(location of reusable layout parts)
designs
(location of full layout templates)
I use this model for my web-site, the Seaside web-site and a couple
of other Pier instances.
I do not think that the current permissions model is
flexible
enough for
any but the simpleset use cases.
I assume that you are using the Unix Security framework? What you
have there is a (mostly) POSIX compliant security model.
I am successfully this model in quite complicated setup right now. I
am using it in an university course about software engineering:
admins (myself), assistants (myself and some other assistants), and
students. Furthermore, each student belongs to a group together with
one of the assistants. Permissions are set so that only assistants
can edit exercises. Each student can only edit his personal page and
the pages of his team. Each team has private pages (that only the
team can see) and public pages.
Of course there is always a discussion between what is the best
security model. There is also an ACL based security model available
in Pier. People have always been discussion what is a better
approach. Having tried both, I find the traditional POSIX permission
model easier to understand an manage, but that's certainly a personal
preference.
I think that if groups were to be able
to have groups as members that might help.
Such a model would not be more powerful than the existing one. If
that is requested, I guess, it could be easily feasible to implement
(probably by removing a simple check).
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch