This is something I was thinking about from the beginning. It can be done by keeping
reference to the session in identity model classes. The main problem I see is the mix of
two approaches:
- most management methods in the model objects (Identity/Group/Role)
- all management methods in manager objects connected to the session (the only reason to
have 4 separate managers is to not end up with 100 methods in IdentitySession)
Now to mix - some methods in Identity/Group/Role and some in managers
Most of the search/find/resolve methods need to remain in managers anyway. Now if you
think about the assignments you can place methods you mentioned in the Identity/Group but
those operating on the collections will need to remain in the managers:
public void associateGroups(Collection<Group> parents, Collection<Group>
members) throws IdentityException
Also you can have
group.findAssociatedGroups(GroupType groupType, boolean parent, boolean inherited, ... )
but then you still need to keep few of findXXX methods in the manager as they don't
belong to one model object... What I'm afraid of is the confusion of users where to
look for certain methods. That's why I decided to put all all methods in the
managers.
I'm not totally against the approach you suggested but I'm simply not sure if it
can be done without making API a bit messy. We can discuss about possible solutions. One
idea would be to simply duplicate some methods to have them in both places.
"jeff.yuchang" wrote : Firstly, I think the API and SPI is very good. It is very
flexible. ;-).
|
| However, I had a thought when I saw the OrganizationTest class.
|
| | session.getRelationshipManager().associateGroups(rhOrg, jbossDivision);
| | session.getRelationshipManager().associateGroups(rhOrg, rhelDivision);
| |
|
| I was thinking it would be easier to see the relationship if we do as following in the
API level.
|
|
| | rhOrg.addGroup(jbossDivision);
| | rhOrg.addGroup(rhelDivision);
| |
|
| I know the latter one might add complexity in the implementation. But it seems to me
more clearer from the API perspective. I don't know which way to better to go. Just
bring about this thought, see what you guys are thinking of this.
|
| Thanks
| Jeff
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184745#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...