20 Oct
2007
20 Oct
'07
10:30 p.m.
Hello Lukas,
It appears that embedding a PRChildren component is broken. This is a
little tricky to explain.
At the point of visiting the embedded component visitInternalLinkEmbed:
anObject
the context's structure is correct, namely the parent structure being
displayed. ie. PRCurrentContext value structure.
By the time it obtains the structure from which to collect the
child-items, this structure may be something else entirely.
So it appears that the PRChildren component being used is one that was
cached, and this cached widget has itself cached the #context. I.e. the
old context that it had when it was origianlly cached, not the current
one in which it is being displayed.
I have posted my solution for this...
Name: Pier-Seaside-kph.213
Author: kph
Time: 20 October 2007, 9:24:28 pm
UUID: 75264720-7f4a-11dc-a343-000a95edb42a
Ancestors: Pier-Seaside-lr.212
- fixed typo 'Highlight' labels
- components obtained from a contexts componentDictionary cache have an
obsolete context cached in their #context
cheers
Keith
20 Oct
20 Oct
10:36 p.m.
New subject: Whats happening?
Could someone explain where we are going with this?
thanks
Keith
=====
Name: Pier-Seaside-tg.206
Author: tg
Time: 16 October 2007, 5:05:33 pm
UUID: 7f2eb12c-28b3-4c8c-b74d-269681e5345a
Ancestors: Pier-Seaside-lr.205
worked with lukas to get rid of the environment
21 Oct
21 Oct
9:05 a.m.
New subject: Whats happening?
Could someone explain where we are going with this?
We are working on making Pier easier, for example that a structure
has its own environment. A migration path will be provided. Don't
load this (yet).
Another goal is to let a structure have multiple documents, so that
you can for example edit a side-bar, etc.
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
1:54 p.m.
New subject: Whats happening?
Lukas Renggli wrote:
Ok... I am still stuggling to understand what this means.
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.
How will moving and copying work for these secondary-documents?
How about a rule along the lines of "if I contain an 'environment' use
it, otherwise use my parent's environment" ?
I also think that you we need a different environment for editing
environments. So can environments have environments? See below
I am also attempting to make pier easier to use and harder to break. The
scheme that I came up with looks like this.
welcome
admin
user
public
site
env
sidebar
header
footer
contents
dev
env
boxes
header
contents
Each of my top levels has different permissions. public and site are
viewable by those that are not logged in. The user area requires the
user to be logged in, and the admin and dev areas require you to be
logged in as an admin-user. The dev hierarchy can only be edited by the
superuser.
User/public, use the site-env, and admin/dev/site use the dev-env.
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.
I agree anything that help make things easy to use will be a good thing.
I do not think that the current permissions model is flexible enough for
any but the simpleset use cases. I think that if groups were to be able
to have groups as members that might help.
cheers
Keith
Could someone
explain where we are going with this?
We are working on making Pier easier, for example that a structure
has its own environment. A migration path will be provided. Don't
load this (yet).
Another goal is to let a structure have multiple documents, so that
you can for example edit a side-bar, etc.
Lukas
3:45 p.m.
New subject: Whats happening?
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
4:35 p.m.
New subject: Whats happening?
Hi,
You can achieve groups in groups by adding users in several groups.
For example, if you want all users from G1 to have access to what
users in G2 do, then make all users from G1 also belong to G2.
Cheers,
Doru
On Oct 21, 2007, at 3:45 PM, Lukas Renggli wrote:
--
www.iam.unibe.ch/~girba
www.iam.unibe.ch/~girba/blog/
"When people care, great things can happen."
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). 
4:56 p.m.
New subject: Whats happening?
On 10/21/07, Lukas Renggli <renggli(a)iam.unibe.ch> wrote:
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.
Well, on Unix at least, the problem with the POSIX model is not in how
it deals with users and groups, but rather how these can be applied to
resources (i.e. permissions for user, group and everyone else).
I don't recall anything about how ACL works in Pier. For me, I would
like a solution where I can put different groups on a given resource,
and then put people in those groups. As much as it pains me to say, I
think Windows has a better security model in this regard.
5:02 p.m.
New subject: Whats happening?
Lukas Renggli wrote:
Thanks for this case study, it is helpful.
As always I have difficulty understanding these things and I have a
simple system very similar to yours...
Yours: admins, assistants, students and public.
Mine: superuser, admins, agents, and public (other).
So they are not so very different. However your admin level, can be
handled by granting superuser status, giving you only assistants and
students to manage permissions for. For any component you can grant two
different permissions, to the owner and group. If the students access is
specified by the group permissions then surely only one assistant can be
allowed to edit any one exercise, by granting that assistant ownership
privileges.
I have simply admins which can edit the site, and agents which can use
the site.
So if I assign a component as owned by user admin, and with use
privileges by the group 'agents' this works.
Ok, thats fine until I want to give more than one person admin rights
(without giving them super-user status), since the item can only be
owned by a single user rather than a group.
My solution to this is that I use pier-users as "roles" and have an
externally defined table of users which log in as a role. e.g. keith,
bob and eric once authenticated all log in as pier user "role-admin". So
a page owned by "role-admin" can be edited by keith, bob or eric. The
usage is defined by the group 'agents', and 'role-agent' is a member of
that group.
Lets say... I want to introduce a layer in between. Say an
agent-supervisors, who has slightly more privileges than an agent for
accessing the same component. Since the ownership can only be one user,
and that is "role-admin" and the group can only be one group which is
"role-agent" I am stuck I think.
Perhaps I was wrong perhaps what is needed is not for a group to contain
other groups, but for the owner to be a group rather than an individual.
If my owner could be a group, then... group "editors" could include
users "role-admin" and "role-agent-supervisors".
This would allow me to assign editing rights to 'editor' and using
rights to group 'agents'.
...
I think this boils down to the number of different uses for one
component. If the uses are "admin", "use" , "view" then in
some cases
this maps into owner, (user) group, other (public). Private regions of
a site would have to map "admin", "use" and "view" into just
owner and
group, since other is disallowed, and this is where I have got into trouble.
Still I am very glad to see pier moving forward,
Keith
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.
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.
The difference between our approaches is that you have to manage the
permissions of each component individually. I found this quite difficult
to keep track of.
My approach gives permissions to each branch of the heirarchy, and so a
component inherits the permissions of the branch in which it is placed.
The advantage of this is visibility. I can know from the path of a
component what permissions it has.
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
20 Oct
20 Oct
11:11 p.m.
New subject: Whats happening? x2
Could someone explain where we are going with this?
Where are conditions going?
I thought that automatic validation was half of the point of magritte?
thanks
Keith
21 Oct
21 Oct
9:10 a.m.
New subject: Whats happening? x2
Where are conditions going?
I asked a couple of weeks ago in the mailing-list and removed them
because nobody opposed. The condition objects impose certain
portability problems to VisualWorks and GemStone. They added quite a
big deal of classes that I personally never used.
I thought that automatic validation was half of the
point of magritte?
Put a valuable object as condition, e.g. a block or your own
implementation of an Object that responds to #value:.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
9:13 a.m.
It appears that embedding a PRChildren component is
broken. This is a
little tricky to explain.
I guess that's not just the PRChildren component. Your fix makes
sense, I will merge it into the latest code as soon as possible.
Cheers,
Lukas
At the point of visiting the embedded component
visitInternalLinkEmbed:
anObject
the context's structure is correct, namely the parent structure being
displayed. ie. PRCurrentContext value structure.
By the time it obtains the structure from which to collect the
child-items, this structure may be something else entirely.
So it appears that the PRChildren component being used is one that was
cached, and this cached widget has itself cached the #context. I.e.
the
old context that it had when it was origianlly cached, not the current
one in which it is being displayed.
I have posted my solution for this...
Name: Pier-Seaside-kph.213
Author: kph
Time: 20 October 2007, 9:24:28 pm
UUID: 75264720-7f4a-11dc-a343-000a95edb42a
Ancestors: Pier-Seaside-lr.212
- fixed typo 'Highlight' labels
- components obtained from a contexts componentDictionary cache
have an
obsolete context cached in their #context
cheers
Keith
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Lukas Renggli
http://www.lukas-renggli.ch
6032
days inactive
6033
days old
10 comments
4 participants
participants (4)
-
Jason Johnson -
Keith Hodges -
Lukas Renggli -
Tudor Girba