mugle-dev team mailing list archive

[Matt Giuca <727767@xxxxxxxxxxxxxxxxxx>]

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.