users/groups UI
Locked
 
|
a first attempt
Name: Pier-Security-kph.33 Author: kph Time: 22 June 2006, 2:03:14 am UUID: 4efb7bda-2fd7-b04d-8858-41ae19a61f37 Ancestors: Pier-Security-lr.32 Added Pier Widget for User/group management ___________________________________________________________ Try the all-new Yahoo! Mail. "The New Version is radically easier to use" The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
I did attempt a drag and drop version of the users and groups manager,
it is included in pier-security-widgets-wip.kph.34 if anyone wishes to get it working. Keith ___________________________________________________________ Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
In reply to this post by keith1y
> Name: Pier-Security-kph.33
> Author: kph > Time: 22 June 2006, 2:03:14 am > UUID: 4efb7bda-2fd7-b04d-8858-41ae19a61f37 > Ancestors: Pier-Security-lr.32 > > Added Pier Widget for User/group management Hey Keith, I am very interested in your changes. Where did you publish? Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
>> Added Pier Widget for User/group management >> > > Hey Keith, > > I am very interested in your changes. Where did you publish? > > Cheers, > Lukas > 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 _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
Dear Lukas,
I have now published to the repository. My aim is to put these tools in the improved environment which I was proposing. Keith ___________________________________________________________ All New Yahoo! Mail Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
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 _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
In reply to this post by keith1y
Hi Keith,
I am trying to merge all your changes, though I see some problems in Pier. For Magritte all your code should be merged in now. 1. Pier-Security-kph.40 - Pier-Security-kph.40 adds several cool widgets to Pier to add, create and edit users and groups. I do not properly understand why these are widgets and not commands? This means that I need a special place inside Pier where I add those widgets to be able to use them somewhere protected? Why not transform them into commands, so that they can also be properly logged with the persistency framework? Maybe provide a special Meta-Command that displays a special administrator interface to be able to trigger those commands without cluttering up the command interface with 10 new commands? 2. Your new persistency mechanisms looks cool. Does it work yet? How is the performance? I am especially interested into the Magma implementation. Your changes add a lot of external dependencies, why not put the new persistency mechanisms into their own packages? People could load then Pier-Magma if they want to use Magma or Pier- XML if they want XML persistency. Just my cents ;-) Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
Hi Lukas
> Hi Keith, > > I am trying to merge all your changes, cool, > though I see some problems in > Pier. For Magritte all your code should be merged in now. > Did I write any magritte code? > 1. Pier-Security-kph.40 - Pier-Security-kph.40 adds several cool > widgets to Pier to add, create and edit users and groups. I do not > properly understand why these are widgets and not commands? 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. > This > means that I need a special place inside Pier where I add those > widgets to be able to use them somewhere protected? Why not transform > them into commands, so that they can also be properly logged with the > persistency framework? Maybe provide a special Meta-Command that > displays a special administrator interface to be able to trigger > those commands without cluttering up the command interface with 10 > new commands? > > persistence would be transparent. > 2. Your new persistency mechanisms looks cool. Does it work yet? How > is the performance? I am especially interested into the Magma > implementation. Your changes add a lot of external dependencies, why > not put the new persistency mechanisms into their own packages? > 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 > People could load then Pier-Magma if they want to use Magma or Pier- > XML if they want XML persistency. > > Just my cents ;-) > > Cheers, > Lukas > > ___________________________________________________________ All New Yahoo! Mail Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
Hi Keith,
> Did I write any magritte code? mhh, sorry this was someone else. > 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, sounds like an interesting approach. Looking forward to see an implementation. > 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. Yes, this sounds reasonable, breaking the environment and looking yourself out of the system is too easy. Luckily there is always a working inspector ... > 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. Exactly and I think the ACL security of Philippe is doing that as well, at least this was one his of the initial requirements I defined ... >> 2. Your new persistency mechanisms looks cool. Does it work yet? How >> is the performance? I am especially interested into the Magma >> implementation. Your changes add a lot of external dependencies, >> why not put the new persistency mechanisms into their own packages? > > 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. Yes, we can discuss about that. If it is reliable working it might be a good thing in Squeak, though there were interests in porting it to other Smalltalk dialect and a strong dependency to Magma would make a port much harder. > 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. Why "Magma Seaside"? Isn't it possible to implement the Magma persistency so that it doesn't depend on Seaside, for example if only the OmniBrowser interface is loaded? Or maybe one using a different Web framework? > 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. Indeed ;-) Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
|
|
rking inspector ...
> > > 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. > > Exactly and I think the ACL security of Philippe is doing that as > well, at least this was one his of the initial requirements I > defined ... 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 _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki _______________________________________________ Smallwiki mailing list [hidden email] http://impara.de/mailman/listinfo/smallwiki |
«
Return to Magritte, Pier and Related Tools
|
1 view|%1 views
| Free forum by Nabble | Edit this page |