I would delegate to that class (include it as a field in our User class) rather than inheriting. You should not use inheritance unless you expect to be able to use the child class wherever the base class is accepted. In this case, it is not ever going to be necessary to pass our MUGLE User object to somewhere that expects a GAE User object.
Moreover, delegating to a class makes it an implementation detail; we can always change to a different implementation later, or provide several (for example, we could provide a Unimelb login which does not use the GAE user system at all). Inheriting from a class makes the connection an explicit part of the public interface, so there is a lot of coupling between the two. Do you know if it's possible to include a reference to a GAE User class inside a JDO class such as ours? If so, go ahead and add the GAE User class as a field of MUGLE User. In other words, we should end up with a User table with a column which links the MUGLE User to a Google user ID. If it doesn't serialise properly, we can just have a "Google User ID" field instead, which implicitly links to the GAE User. That's what I think I've done in the past (in Python). -- You received this bug notification because you are a member of MUGLE Developers, which is subscribed to MUGLE. https://bugs.launchpad.net/bugs/727767 Title: Extending the User class from GAE Status in Melbourne University Game-based Learning Environment: Opinion Bug description: I noticed that GAE provides its own User class that actually includes an authorized user (takes care of logins). http://code.google.com/appengine/docs/java/javadoc/com/google/appengine/api/users/User.html Would it be a good idea to extend our own User from that class? I personally prefer that could come in handy for other reasons in future too. -- Mailing list: https://launchpad.net/~mugle-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~mugle-dev More help : https://help.launchpad.net/ListHelp
