Hi Lukas cool, Did I write any magritte code? Firstly I admit it was a somewhat quick and dirty first attempt. Nevertheless, I do see them as tools associated with a particular task. The idea being that a page may be presented as a task document which may embed the tools for carrying out that task. In this case the page would be within the management area. Certainly I would expect to filter them out of the users widgets list fairly soon. I see commands as universal to their scope, i.e they apply to the universal task, and they lack their own context. For example users have edit view commands that universally apply within their scope and administrators have move/delete commands that are equally universal. What commands dont have is their own 'context', the context that I am calling a 'task'. The commands list provides a user interface to the current context with is the web page in front of you. Managing users and groups is more of an abstract concept and so I feel it needs to be presented within its own context. Hence the widget within a page paradigm. I think that it is simpler too. Just to let you know that I have zope in mind and so there is a fair bit of work to develop the Environment in this direction. I expect to work it so that the environment provides the style for its peers and their sub-trees, but I expect that the environment itself will have its own environment, so that a user editing their environment cant accidentally break the environment. User management may be a candidate for this kind of treatment, whereby a user having responsibility for a sub-tree may put a user manager in place for that subtree only. I beleive that xope does it this way too. Where I used to work they attached the user/groups manager to the global unix users/password server and managed everything globally. I had not thought of the logging issue, though with magma the persistence would be transparent. In theory Magma makes very little impact on the running application. I was hoping that magma persistence could make it into the main distribution and so although it may not look like it at this time I have been attempting to minimise those dependancies. If you look at PRMagmaPersistency all but one of the methods on the class side in the category "init repository", I am currently refactoring into the "Magma seaside" package as part of the magma control panel I am working on. This would leave only one real method (#doing:commit:) in PRMagmaPersistency (the others are stubs which could be fleshed out if needed). I suspect it would seem somewhat overkill to have a whole package for one class with one method. The class PRMagmaRoot is a work in progress and at the moment it is looking like it will be a component. I do not think that this will have any hard wired dependencies to the magma package. It will be responsible for managing the link between PRKernel-c-instances and the persisted instances in magmaSession root, i.e. itself. Performance, well I really havent had a chance to assess this yet. Magma has read strategies which could be easily configured to ensure that whole kernels are loaded into memory at once, and so in theory read performance would be uneffected particularly for small kernels. I am still learning stuff, particularly in the seaside domain. thanks for your input, I appreciate your support, I will let you know about magma in the next couple of days. Keith ___________________________________________________________ All New Yahoo! Mail – Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html

rking inspector ... Oh well, no, that's still not implemented yet ;). Yes it sounds compelling a first but we really couldn't come up with good semantics. Also there are no bit Pier installations deployed yet, so there's no imminent need for that. But once it's needed it should not be too hard to implement if you have come up with semantics first. One of the things I learned is "do it the Pier way". That means everything should be a structure, described by Magritte. Try to use as much of the Pier/Magritte infrastructure as possible. This has two advantages: - You have to change less code to remain compatible with the latest versions of Pier. Believe me, I've been doing this for over a year. - You are more compatible with the rest of the Pier stuff out there. Persistence, refactoring, .... So by continuing this, users should be normal structures, editing a user is just an edit command on a user, adding a user is just an add command. See the following example: http://spielverderber.seasidehosting.st/management/users (password for the root user is 'chamdoow') We had it otherwise before and it's really much better now. Less code, easier to maintain, ... you name it. Philippe

I probably published to the package-cache oops! Keith ___________________________________________________________ All New Yahoo! Mail – Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html

In this Users and Groups management tool I was thinking of granting all members of the admin group superuser status. Is that a good idea or not? Keith ___________________________________________________________ The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html