PRChildren broken

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

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

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

 

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

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


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> 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


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> 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


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> 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




--
Lukas Renggli
http://www.lukas-renggli.ch


_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

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









   



_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

> 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.

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

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

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:

>> 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).

--
www.iam.unibe.ch/~girba
www.iam.unibe.ch/~girba/blog/

"When people care, great things can happen."



_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

On 10/21/07, Lukas Renggli <[hidden email]> 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.

_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

Lukas Renggli wrote: Thanks for this case study, it is helpful. 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.
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










_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki