Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] two attribute framework notes

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] two attribute framework notes

Chronological Thread 
  • From: Tom Zeller <>
  • To: Chris Hyzer <>
  • Cc: "" <>
  • Subject: Re: [grouper-dev] two attribute framework notes
  • Date: Mon, 28 Sep 2009 11:40:29 -0500
  • Domainkey-signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=vfTbqXQ962tIvRqSrerWEldjUyTdqngY/lDDPkm7UHNe4obFLpcd68oZUaIQfJqPxm RIHfyEz8K1cp0l3XajklOpDjU9JAsiManaT5E+6f85KkQ4Ybim/mFMC7CYlEcd2deYSz Yco+9peS9fcSDnkyiW0TmHI1wQUVErixYhU3k=


To make sure I understand, are you saying that instead of :

group.grantPriv(attrDef, subject);

the API will be

attributeDef.grantPriv(subject, group);

? And that this way, the group object will have less (new) methods ?


> ## API delegates to organize API
> One of the concerns with the attribute framework and privilege management
> was that it would bloat the API.  I think the current strategy the API uses
> for one-to-many methods in the API (just add all methods to the "one"
> object), is the cause for the bloat.  The Group object currently has
> thousands of lines of code, and hundreds of methods.  However, if we
> organized the methods by one-to-many (or other means), then it would be a
> lot easier to use / maintain / test / etc.  i.e. look at the privilege
> assignment above:
> attributeDef.getPrivilegeDelegate().grantPriv(SubjectTestHelper.SUBJ0,
> AttributeDefPrivilege.ATTR_ADMIN, false);
> In the Group object (and note I am not changing existing API here, this is
> for new stuff), all the privilege methods are in the group object.  
> However, above you see that I am putting them in another class which exists
> to delegate logic from the "one" class, to the "many" class (in this case
> privileges).  I will use this technique for attributes and permission
> management as well, and we will not see any bloat.  You will notice that
> the resulting API object model does not mirror the data model... oh well.

Archive powered by MHonArc 2.6.16.

Top of Page