Re: LDAP and Enterprise Objects
Re: LDAP and Enterprise Objects
- Subject: Re: LDAP and Enterprise Objects
- From: Chuck Hill <email@hidden>
- Date: Fri, 21 Jan 2005 15:52:14 -0800
It is the Generation Gap pattern. One thing you might want to consider
is to add some meta-data to the model and use this to control code
generation. If you inspect an attribute there is a "book" pane
(probably meant to be a dictionary...) where you can set key-value
pairs. You could put something in there (e.g LDAPMultiValue=true) and
check for this when generating your templates. Or you could use a
special EOPrototype for this purpose. You will have to dig into how
the templates generate code and do some research and experiments to
figure out what needs to be in the templates.
Chuck
On Jan 21, 2005, at 1:34 PM, William Norris wrote:
yes, i had considered modifying _User, but this kinda defeats the
purpose of this kind of design... I can't remember what it's called,
but Chuck talks about it in his book. The next time I modify my model
and rerun WOGen (or EOGenerator as the case may be), any changes I
made will be written over.
On Fri, 21 Jan 2005 15:07:29 -0600, Albert Jagnow
<email@hidden> wrote:
I have also run into this problem. I don't know if this is the best
example or solution, but I have an application that checks authority
based on a users group, the "memberOf" attribute in an Active
Directory
LDAP directory. What I did was to have public class User extends
_User, but then I commented out the generated methods for "memberOf"
in _User that had this problem and rewrote other methods in my User
class. For example (this is a simplified version of my code):
public boolean userHasAuthority(){
NSArray groupListArray =
(NSArray)user.valueForKey("memberOf");
if(groupListArray != null){
Enumeration en = groupListArray.objectEnumerator();
while(en.hasMoreElements()){
String group = (String)en.nextElement();
if(group != null && group.equals(
restrictAccessToGroup() )){
return true;
}
}
}
return false;
}
--Albert
On Jan 21, 2005, at 2:51 PM, William Norris wrote:
so you changed
public class User extends _User
to
public class User extends EOGenericRecord
or did you change your EOModel to have a classtype of EOGenericRecord
instead of User (or whatever class it is)?
On Fri, 21 Jan 2005 12:42:48 -0800, Chuck Hill
<email@hidden> wrote:
Yes, I've run into this. I left the base class as an EOGenericRecord
and wrote my own cover methods as you note below. Otherwise, you
will
need to create new methods names as Java does not allow overloading
based on return type.
Chuck
On Jan 21, 2005, at 12:36 PM, William Norris wrote:
I use WOGen to create my EO Classes. The method signature for the
mail accessor is "public String mail()". I could override this
method
and put the above custom logic in it, except that it would have to
have an identical signature -- returning a String. the only other
thing i could think to do is create a new method "mailArray" that
ignores the auto-generated mail() method altogether.
Has anyone else run into this? What did you do?
--
Practical WebObjects - a book for intermediate WebObjects developers
who want to increase their overall knowledge of WebObjects, or those
who are trying to solve specific application development problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
This e-mail (including any attachments) is covered by the Electronic
Communications Privacy Act, 18 USC. 2510-2521. It is confidential and
may be legally privileged. If you are not the intended recipient, you
are hereby notified that any retention, dissemination, distribution,
or
copying of this communication is strictly prohibited. Please reply to
the sender that you have received the message in error, and then
delete
it. Thank you.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
village.net
This email sent to email@hidden
--
Practical WebObjects - a book for intermediate WebObjects developers
who want to increase their overall knowledge of WebObjects, or those
who are trying to solve specific application development problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden