SitePoint Sponsor

User Tag List

Page 10 of 11 FirstFirst ... 67891011 LastLast
Results 226 to 250 of 267
  1. #226
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    I think needed objects should be created as needed, and orphans removed automatically, otherwise the interface will treble in size.
    I don't get it. I'm totally lost. How can you both create objects "as needed" and give error messages about non-existent objects?

    In testCanAssignOnlyTo AnExistingRole(), how does the Administrator object know that the role "pleb" already exists? Has it been created somehow, and if so, where?

    Alternatively, if assign() automatically creates roles, how can it ever generate an error about a non-existent role?
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  2. #227
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by dagfinn
    How can you both create objects "as needed" and give error messages about non-existent objects?
    The one exception was adding an access key without a role. The role would have been created by the permit() call. Because permissions and roles are administered together, they can be automatic. The access keys stick out a little bit when interfacing to roles. I am trying to come up with a solution which does as much as possible, but yes, a further contradiction may emerge that forces a broader interface. If we try to keep it minimal for as long as possible though, I think we are in with a chance of something quite clean

    Quote Originally Posted by dagfinn
    In testCanAssignOnlyTo AnExistingRole(), how does the Administrator object know that the role "pleb" already exists? Has it been created somehow, and if so, where?
    By the permit() call.

    Quote Originally Posted by dagfinn
    Alternatively, if assign() automatically creates roles, how can it ever generate an error about a non-existent role?
    The ideas is it automatically creates access keys, not roles. The code does not currently do that (it needs refactoring in light of the new interfaces). This should also prevent roles that don't have permissions. Looks like the role is a kingpin that cannot be removed without careful thought.

    This was all prompted by thoughts over how it would be used in practice. Perhaps I should trot out some possible scenarios so that we can thrash them out.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  3. #228
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    OK, I don't understand what you're doing, but if you can figure out how to make it work, that's OK by me. To me the insurmountable problem seems to be this: if you create any object implicitly by naming it in a call that creates a relationship between two objects, you can create a new one, when you actually intended an existing one, simply by misspelling.

    Also, the solution has to be compatible with authorization. So there must be a password stored as well.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  4. #229
    SitePoint Zealot sike's Avatar
    Join Date
    Oct 2002
    Posts
    174
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    this is my understanding (and questions of course (; ) from just looking at the RbacAdministratorTest testcases and the last few comments :

    permit(role, action)
    - transparently creates roles
    - fails only if persistence reports a error ?
    - how do we drop actions from a role ?
    - what if we drop all actions from a role ?

    assign(access, role)
    - transparently creates access
    - fails if role doesnt exist

    dropRole(role)
    - drops role and all assigned actions
    - fails if there are accesses (?) which only have this role permitted

    dropAccess(access)
    - drops access and removes all its role assignments

    one comment on the testcase:
    i would rename testCanAssignOnlyToAnExistingRole() to testCanAssignToExistingRole() as it only tests this.

    cheers,
    Sike

    ps. the term "access" is a hard one for conversation (maybe its just me )..

  5. #230
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by sike
    permit(role, action)
    - transparently creates roles
    - fails only if persistence reports a error ?
    - how do we drop actions from a role ?
    - what if we drop all actions from a role ?
    In order: Yes, yes, deny($role, $action) ?, I think this is the same as dropRole().

    Quote Originally Posted by sike
    assign(access, role)
    - transparently creates access
    - fails if role doesnt exist
    That is my current best guess.

    Quote Originally Posted by sike
    dropRole(role)
    - drops role and all assigned actions
    - fails if there are accesses (?) which only have this role permitted
    That pretty well sums things up. This is definitely a tricky case though.

    Quote Originally Posted by sike
    dropAccess(access)
    - drops access and removes all its role assignments
    Yes.
    Quote Originally Posted by sike
    one comment on the testcase:
    i would rename testCanAssignOnlyToAnExistingRole() to testCanAssignToExistingRole() as it only tests this.
    Agreed.

    Quote Originally Posted by sike
    ps. the term "access" is a hard one for conversation (maybe its just me )..
    It was my stupid idea and even I have come to hate it. I still like "Usage" (but noone else does). Maybe "AccessKey" or "UserId"?

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  6. #231
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by dagfinn
    OK, I don't understand what you're doing, but if you can figure out how to make it work, that's OK by me.
    If you cannot figure it out then it is a sign that I am on the wrong track. Either case we should carry on discussing it until it is clear.

    Quote Originally Posted by dagfinn
    To me the insurmountable problem seems to be this: if you create any object implicitly by naming it in a call that creates a relationship between two objects, you can create a new one, when you actually intended an existing one, simply by misspelling.
    Well, you can get a coding error anywhere. If this is likely an issue then using define()'d constants in the code would mitigate against this. We have still left this option pen, even though we haven't made use of it in the test cases.

    Quote Originally Posted by dagfinn
    Also, the solution has to be compatible with authorization. So there must be a password stored as well.
    I think this is a trap we don't want to fall into. At the moment we are only storing a relation of an external key to the roles. What we call "access" could in fact be a foreign key value within an authorisation schema. That is, the link table falls within our remit, but not the external table it links to.

    I should say, I am not 100% sure where I am going with the test case. It really does need to be either proved with code or argued out. The main aim was to cut down on orphans and the size of the interface, but it is likely wrong in detail.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  7. #232
    SitePoint Zealot sike's Avatar
    Join Date
    Oct 2002
    Posts
    174
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    i think we should strip out that "if empty delete it". if we say
    that you can not delete anything if it is referenced it would become
    a bit cleaner imho. this "magic" deletion is really only a small function
    using the methods we already have :

    PHP Code:
        removeRole(role)
        {
            
    $accessList this->getAccessListForRole(role);
            foreach(
    $accesList as $access)
            {
                 
    $access->dropRole($role);
            }
            
    $actionList this->getActionListForRole(role);
             foreach(
    $actionList as $action)
             {
                  
    $action->dropRole($role);
             }
             
    $this->dropRole($role);
        } 
    i havent looked up the proper method names but you get the idea hopefully.

    Sike

  8. #233
    SitePoint Zealot sike's Avatar
    Join Date
    Oct 2002
    Posts
    174
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    It was my stupid idea and even I have come to hate it. I still like "Usage" (but noone else does). Maybe "AccessKey" or "UserId"?
    i would'nt call it stupid, but as i was writing the post i had problems with it
    personaly i typed "user" and the realized its called access. but user is the same stupid idea i think (;

    Sike

  9. #234
    SitePoint Zealot
    Join Date
    Jun 2003
    Location
    Elsewhere
    Posts
    107
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    It was my stupid idea and even I have come to hate it. I still like "Usage" (but noone else does). Maybe "AccessKey" or "UserId"?
    Sorry for the pathetically short post, but:

    'Identity' ?

    'Client' ?

    **Azmo fades into the background again....


  10. #235
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Well, you can get a coding error anywhere. If this is likely an issue then using define()'d constants in the code would mitigate against this.
    I'm afraid we're not communicating effectively. I thought we had agreed on this when you told me my analysis was "spot on".

    I don't think we can proceed without discussing our process.

    As you said on May 14:
    Quote Originally Posted by lastcraft
    ...the two big time suckers are usually requirements and bugs.
    I agree completely, and I I'm pretty certain we're being bitten by the requirements.

    What we lack are real use cases (or user stories, if you prefer). I mean use cases describing how this will be used by real users. I know we're making something that has no user interface, but without making some assumptions about the user interface, we're lost in space.

    I thought we could get away with what we were doing, but we can't. When I say misspelling, you say coding error, but I'm thinking about a name being mistyped into a user interface. That's either a lack or a mismatch of requirements.

    I think the problem is exacerbated by the nature of the implementation we're discussing. Your last implementation was minimal on design, and I think that's a potentially good starting point and it would be interesting to discover what kind of design could emerge from refactoring. But it demands a relatively exact knowledge of what the thing we're building is supposed to do. I think a domain-model type of design is probably less sensitive to vague requirements because it's inherently more flexible and has more built-in assumptions to guide us.

    From that point of view, seratonin's April 14 implementation is more in the right direction.
    So I would either:
    • get some real use cases, or
    • implement from a domain-driven design; or
    • do something else instead.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  11. #236
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Post #100 and #106 are my attempt to understand the problem in it's simplest form. I wanted to "get back to basics". Post #100 is the interaction between the client and the Authentication and Authorization interface and post #106 was pseudocode from the client's perspective. Maybe we can derive some use cases from these types of interactions and go from there. I really feel like we are spinning our wheels. Why was the first implementation off track? What can we improve by refactoring it?

    Thanks,

    JT

  12. #237
    SitePoint Zealot sleepeasy's Avatar
    Join Date
    Sep 2003
    Location
    Bristol, UK
    Posts
    145
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    What we lack are real use cases (or user stories, if you prefer). I mean use cases describing how this will be used by real users. I know we're making something that has no user interface, but without making some assumptions about the user interface, we're lost in space.
    Off Topic:

    Use-cases aren't restricted to systems that have a user interface. Granted, most use case models define how a (human) user interacts with a system, through a GUI. However, it is perfectly "legal" if the actors in a use-case model are other systems, or as is the case here, a different module.

    So I think you should definately get the use cases down.

    Define the behaviour of the system - the main use-cases. And then examine each one and define their extension points: what happens if a pre-condition isn't met, what if we try to add a user that already exists, what data is input into the system...

    Something like sike's post would be good, but with an increased level of detail otherwise when you start trying to identify candidate classes you're going to have many grey areas (even if you don't see them at first), and in the long run you will find your design to have low cohesion.

    Use cases will also help the collaborators understand the behaviour of the system a lot better. Dagfinn could ask lastcraft "So how are we going to implement use case X"... and lastcraft will immediately know what Dagfinn is talking about, so development is immediately focused.

    I realise some of you may have your own approaches to design/development and/or may be 70year-old Software Engineers and know all that I've just said, so please excuse me if I seem to be lecturing you, but I do mean well, honest

    Anyway, I hope this helps.
    Always open to question or ridicule

  13. #238
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by dagfinn
    I thought we had agreed on this when you told me my analysis was "spot on".
    You pointed out that domain objects were bieng created on the fly by the actions and that was spot on. I consider that a good thing as it keeps the interface cleaner. I am just trying to stick to that style as much as I can.

    Quote Originally Posted by dagfinn
    I don't think we can proceed without discussing our process.
    Uh oh...

    Quote Originally Posted by dagfinn
    What we lack are real use cases
    How about we add just one use case per iteration, rather than trying to solve the whole thing in one go? How about you write that use case. I did one earlier with act of getting permissions and I think we are agreed on that interface. The first test case has had little controversy, it seems to be the administration side that is thrashing.

    Quote Originally Posted by dagfinn
    I thought we could get away with what we were doing, but we can't.
    It's not so bad .

    Quote Originally Posted by dagfinn
    When I say misspelling, you say coding error, but I'm thinking about a name being mistyped into a user interface. That's either a lack or a mismatch of requirements.
    It is not a requirement that will be handled by us. If someone wants to put a user interface on then they will do the validation also. For example they would likely use drop downs when assigning for example. I think this issue is a red herring.

    Quote Originally Posted by dagfinn
    I think a domain-model type of design is probably less sensitive to vague requirements because it's inherently more flexible and has more built-in assumptions to guide us.
    Domain models are emergent. Trying to come up with one at this stage will lead to a heck of a lot of thrashing. Also it is just about impossible to derive one without some degree of coverage by use cases. We don't have this situation yet. I don't think this is the best course right now.

    An alternative approach is simply to code (minimally) one piece of functionality at a time as we have been. The code is not fixed in stone and can be tried one way and then rolled back and tried another. Without face to face contact the airy discussions will take time, but code settles things pretty quick. The main thing is to do one feature at a time and code it at each stage.

    Quote Originally Posted by dagfinn
    From that point of view, seratonin's April 14 implementation is more in the right direction.
    That is an implementation, we are still trying to finalise the next test case. I didn't disagree with Seratonin's implementation, except for the level of complexity, and we nearly got something running. I think we all thought that, but could not agree how to trim it down. As we have something running right now, what aspects of Seratonin's do you wish to import?

    Quote Originally Posted by dagfinn
    So I would either:
    • get some real use cases, or
    • implement from a domain-driven design; or
    • do something else instead.
    Let's do number one (one only).

    As a next post I can make some minor changes and repost just the first test case, and the first solution with a separate connection class. That small advancement we can all agree on, yes? That will benchmark it ready for the next piece of functionality.

    If somebody writes a single use case for just one action that an administrator could do, we could refine that use case and add it as a test case.

    Some gut feelings about such a use case...
    1) The administration action chosen should affect the behaviour of the system (e.g. Authorisation by someone produces a different set of permissions after this change). That way it ties in directly with the existing code.
    2) I think we should do everything we can to avoid orphans as long as it doesn't lead to any contradictions (which it probably will).
    3) Keep it confined to just authorisation (I think we have got the hang of this).

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  14. #239
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    You pointed out that domain objects were bieng created on the fly by the actions and that was spot on. I consider that a good thing as it keeps the interface cleaner.
    No wonder we're misunderstanding each other. I thought we had concluded it wasn't.
    Quote Originally Posted by lastcraft
    How about we add just one use case per iteration, rather than trying to solve the whole thing in one go? How about you write that use case. I did one earlier with act of getting permissions and I think we are agreed on that interface. The first test case has had little controversy, it seems to be the administration side that is thrashing.
    You're right, we have more or less gotten the authorization part out of the way. So we definitely have made progress. I'm just saying we're not making progress right now on the administration part.
    Quote Originally Posted by lastcraft
    It is not a requirement that will be handled by us. If someone wants to put a user interface on...
    It's not hypothetical except for the fact that what we're implementing may never be used at all. Applications that use an RBAC implementation will have a user interface. If you disagree, give me counterexamples.
    Quote Originally Posted by lastcraft
    ...then they will do the validation also. For example they would likely use drop downs when assigning for example. I think this issue is a red herring.
    When you say that you want to create objects implicitly, it has clear implications for the administrative user interface. It means that the administrative user will never have the opportunity to create the objects explicitly. (Unless the application writer engages in some really ugly hacking). But maybe the user wants to create them explicitly, and that's why we have to think about it first. Implicit vs. explicit object creation is not a technical issue. It comes down to user requirements.

    I'll leave it at that for now and not discuss the other stuff yet. Better to concentrate on one point until that clears up.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  15. #240
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by dagfinn
    If you disagree, give me counterexamples.
    The permissions structure is coded in a file generated by the developer. That whole structure is shipped with the application and is then read only.

    A remote authentication server receives permission changes via SOAP as an XML update.

    The system is slaved to another system (say an Oracle server) and the whole permission set is updated in one go.

    These are all digressions however.

    Quote Originally Posted by dagfinn
    When you say that you want to create objects implicitly, it has clear implications for the administrative user interface. It means that the administrative user will never have the opportunity to create the objects explicitly.
    Yes that is right and a good summing up. It is our job to decide the API and whatever decisions we make will have implications on how it is managed. This is very much in our domain and a fundamental decision on the character of the library - you are right to flag it.

    Quote Originally Posted by dagfinn
    But maybe the user wants to create them explicitly, and that's why we have to think about it first. Implicit vs. explicit object creation is not a technical issue. It comes down to user requirements.
    Yes, and it is also an opportunity to "do it right" and actually one of the things that makes this little project interesting. We cannot do both explicit and implicit creation at the same time as they have fundamentally different trade offs. That is why I put the orphans issue into the gut feelings section, rather than running off writing my own use case (although that is what I have surreptitiously done with the test case so slapped wrist for me).

    The "case in favour"...

    I am not tied to the implicit approach, but I think it is an excellent avenue to try out. It is all too easy to invent bogus requirements because of concentrating too hard on management of structures and not actually thinking about the task to be done. We want to save people effort, not inflict it on them. It also fits in with "do the simplest thing that could work". That is it should be easier to refactor our way out of this because less code will have been created.

    Quote Originally Posted by dagfinn
    I'll leave it at that for now and not discuss the other stuff yet. Better to concentrate on one point until that clears up.
    Agreed. At this point we get down to the philosophy of the library, something that is very important. It is what really distinguishes one tool from another and one of the reasons why there is no "best" library.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  16. #241
    SitePoint Enthusiast daveah's Avatar
    Join Date
    Jan 2004
    Location
    chester
    Posts
    51
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Whats happend to the rest of this thread... ??

  17. #242
    Non-Member
    Join Date
    Jan 2004
    Location
    Planet Earth
    Posts
    1,764
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Hello, what do you mean by the rest of it ?? As far as I know, this discussion is still on going

    Just that folks have not really got back to it for a while, that's all.

    Off Topic:


    Shame Site Point doesn't provide a means to export a given forum thread, ie This one for example, so we can pretty much do what we like with the discussion, off - line

  18. #243
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Widow Maker
    Hello, what do you mean by the rest of it ?? As far as I know, this discussion is still on going

    Just that folks have not really got back to it for a while, that's all.

    Off Topic:


    Shame Site Point doesn't provide a means to export a given forum thread, ie This one for example, so we can pretty much do what we like with the discussion, off - line
    I would like to get back to this thread. Although, it has gotten quite long and has grown some hair, I do think it contains some useful information. Lastcraft, Dagfinn, where do we stand with the last test case/implementation. I will implement one of the test cases to get the ball rolling again.

    Thanks,

    JT

  19. #244
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by seratonin
    I would like to get back to this thread.
    Me too. I didn't want to post next as I felt I was dominating the thread a bit too much.

    Quote Originally Posted by seratonin
    Lastcraft, Dagfinn, where do we stand with the last test case/implementation. I will implement one of the test cases to get the ball rolling again.
    In the last two test cases posted, tey both fail. The second doesn't have any code behind it, but the interface is currently in discussion anyway so I probably wouldn't touch that. The first test case worked before, but had a slight change to the interface (wrapping the connection in our own class). If you could make the small changes to the code to get that test working that I think would be an easy step to establish a benchmark.

    The real problem is how much of the database structure and low level administration do we want to expose to the administration interface? Any comments are welcome. Personally I favour a smart interface if possible, but I'll go with the flow.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  20. #245
    SitePoint Zealot sike's Avatar
    Join Date
    Oct 2002
    Posts
    174
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Hi...
    The real problem is how much of the database structure and low level administration do we want to expose to the administration interface? Any comments are welcome. Personally I favour a smart interface if possible, but I'll go with the flow.
    i think we should leave the type of the datasource used to persist the permissions and stuff completly out. a more abstract persistance mechanism would get us started and i think it gives the user enough room to incoporate rbac easily into their applications. that would mean a rather low level api for the administration api with a "deluxe" layer build on top of it where all that "magic" auto creation and deletion happens. i am not advocating a complete datasource abstraction but rather a rbac specific abstract container which is easily adaptable to the users favourite abstraction layer (eg Pear, Adodb, homegrown stuff or xml).

    Sike

  21. #246
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by sike
    that would mean a rather low level api for the administration api with a "deluxe" layer build on top of it where all that "magic" auto creation and deletion happens.
    I am just talking about interfaces for now (the implementation is likely to be easy). I think we should start simple by having just one interface for now. The problem is what does it look like in use? If people can back it up with stories/use cases that would be better.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  22. #247
    SitePoint Zealot sike's Avatar
    Join Date
    Oct 2002
    Posts
    174
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    I am just talking about interfaces for now (the implementation is likely to be easy). I think we should start simple by having just one interface for now. The problem is what does it look like in use? If people can back it up with stories/use cases that would be better.
    ACK.

    heres my first kind of use case :

    - 3 user classes : User, Project Manager (PM), Administrator
    - User : login, use messaging system, fill out surveys
    - PM : login, review surveys, view statistics
    - Admin : login, use extended messaging system, admin surveys, admin users
    - authentication done via sessions
    - page is built from components

    PHP Code:
     <?
      
    # left out authentication of users and all page related setup
      
    ....
      
    # user logged in?
      
    if ($User != false)
      {
        
    $Authoriser = &new Authoriser(new RbacConnection(RBAC_CONNECTION);
        
    $Permissions = &$Authoriser->getPermissions($User->id); 
        
    # user allowed to see surveys?
        
    if ($Permissions::can('view survey')
        {
           
    //Add Right Column (floats right with a width of 300px)
           
    $columnSurveys = &$columnsMain->addColumn('columnSurvey','300px');
           
    //Add Surveys list to column
           
    $listSurveys = &$columnSurveys->newComponent('cSurveysList');
           ....
        }
      }
      ....
      
    # left out page rendering
     
    ?>

    hmm i am not shure if this really is a use case

    Sike

  23. #248
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by sike
    hmm i am not shure if this really is a use case
    I get the idea anyway . We have kind of solved the permissions side of things I hope, it is the administration that needs the discussion. Any ideas?

    yours, Marcus

    p.s. You don't need the branch in the code above. The authenticator could just return a public user if authentication fails as even the public user will likely be able to do something. With that trick (kind of NullValue pattern) the other code behaves just fine.
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  24. #249
    SitePoint Evangelist
    Join Date
    Dec 2003
    Location
    Arizona
    Posts
    411
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Hi...
    We have kind of solved the permissions side of things I hope, it is the administration that needs the discussion. Any ideas?
    Do we really need anything more than a couple of gateway objects to solve the administration problem?

    JT

  25. #250
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi...

    Quote Originally Posted by seratonin
    Do we really need anything more than a couple of gateway objects to solve the administration problem?
    It's the interface that's causing grief, in particular should you be able to create orphans and then link them. Basically, what does the code look like when you add a role, a user and permission? It is possible to just add the linkages and have the items come into existence and disappear automatically. If it's possible then I think we should do it (but you may disagree). Is there a use case that requires adding the connected "things"? Should that degree of automation be the "style" of the library or should we make every creation explicit and refuse to connect non-existent "things"?

    Really, what does the administration test case look like? It could come down to a simple vote.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •