|
New User Object Model Describes how user and session objects should be handled by Helma. Implemented. Separating the user from the session. Current situation:The object "user" currently is a mix-up between the session object and the user data stored in the database. This is a proposal for a distinction between these two concepts to achieve a cleaner implementation of Helma's user model. It is aimed to reduce the user object to a standard HopObject and put everything session-related into a separate session object. The browser session should be represented by a global object "session" without prototype. This session object contains the standard methods of the transient "user" object in the current model (ie. onSince(), lastActive() etc.). In case of an authenticated session (ie. user is logged in) the corresponding HopObject of prototype user is mapped to a property of "session" called "user" (ie. session.user). In addition, a user's sessions can be accessed using the global function getUserSessions(). The current handler "user" is replaced by "session". The default URL mapping of the user object to /user and the mapping of the collection of all users to /users become obsolete. Instead, application developers are responsible for an appropriate mapping / mountpoint of the users' collection (eg. /members or /people). Example: root's type.properties members = mountpoint(membermgr) membermgr's type.properties _children = collection(user) _children.foreign = ID _children.accessName = NAME http://localhost:8080/members > membermgr/main.hac http://localhost:8080/members/username > user/main.hac in main.hac, "this" refers to the HopObject "username" of the user prototype. countUsers() is obsolete because root.members.size() does the job. Same with getAllUsers() > root.members.list(); ie. replacements by standard HopObject functions. session no prototype, global object available to all requests from http HopObject* session.user String session._id (ie. cookie value) String session.message (res.message becomes obsolete) date session.onSince() date session.lastActive() void session.touch() HopObject* session.login() void session.logout()*prototype user user prototype user, db-mapping Standard HopObject global session createSession(cookie) HopObject* registerUser (username, password) int countSessions() session getSession(sessioncookie) HopObject* getUser(username) user[] getActiveUsers() user[] getRegisteredUsers() sessions[] getSessions() sessions[] getUserSessions(username | HopObject* [or both?])*prototype user
... comment
stefanp,
Wednesday, 10. April 2002, 18:11
a few cents
I'm with most of it, here are some remarks:
More functions are added to the global object, which I don't appreciate for these reasons: * functions can easily be overwritten by the application programmer from the javascript environment, especially as the global functions in helma don't really follow a namespace. * the context of global object is the whole application which is also true for the app-object, but there's more logic to the latter when it comes to user- and session handling. apart from that, the app-object can't be scripted so the above problem could be eased by moving global functions to the app-object. * the built in global functions should stick to utility functions like format() or encode(). Everything else should be bundled like in the Math-prototype in core javascript, eg add xml-functionality as Xml.getDocument() and not as getXmlDocument() etc etc. so I'd suggest: app.getSession(cookievalue) app.getSessions() app.countSessions() app.createSession(cookievalue) which *could* be replaced by wrapping the sessions hashtable as a property: app.sessions app.sessions.count() app.sessions.get(cookievalue) app.sessions.add(cookievalue) .. create a new session. this definitly has to be wrapped so that it creates the sessionobject first. and: app.getUser(username) app.registerUser(username, password) app.getUserSessions(username | userobject) Btw, I'd suggest renaming getUserSessions() to getSessionsForUser(). Do we drop user.onLogout()? Do we drop the current global function isActive(userobject)? Should it be replaced by a function like user.isActive() or is app.getUserSessions(username)!=null enough? Replacing res.message with session.message poses a problem: the res.message-property is "forgotten" after it's been printed, simply because the response-object ceases to exist when the request is closed. The session.message-property would have to be reset manually. Making session.message a "special" property that is deleted after it has been read doesn't sound too nice. So if we wanted to move res.message to session.message I'd suggest using methods like session.setMessage()/.addMessage()/.getMessage(). But how is this used in skins? And a definite ++ to separating user and session. ... link ... comment
hns,
Thursday, 11. April 2002, 16:15
Looks very good to me
I think separating session and user objects as described in this RFC is a good idea.
One minor point, I think this line in the type.properties is not really needed: _children.foreign = ID I agree with StefanP that moving the global session functions to the app object is cleaner than the current approach. Are there more global functions that should/could move to the app object? ... link ... comment
grob,
Friday, 12. April 2002, 15:54
i'd say the following global functions should also be moved to app:
- authenticate() - getProperty() regarding user.onLogout(): i'm against dropping it, but shouldn't it be a function of session? and +1 for renaming getUserSessions() to getSessionsForUser() ... link ... comment
stefanp,
Friday, 17. May 2002, 20:34
first implementation
the first implementation has the following changes to the original proposal:
all global functions are implemented as methods of app-object, except: getRegisteredUsers() is dropped. getUserSessions() is called app.getSessionsForUser() session.message currently is not supported. ... link ... comment
stefanp,
Friday, 31. May 2002, 16:48
other changes
- properties can only be assigned freely to the session.data-property
- session.lastActive() and session.onSince() have been replaced by readonly-properties (session.lastActive and session.onSince). ... link ... comment
matthias,
Monday, 3. June 2002, 17:49
Do we drop user.onLogout()?
Do we drop user.onLogout()?
-1 even the user-prototype is not the right place for this funtion ... link ... comment |
navigation
Download
Community
Weblog
Mailing Lists
IRC Channel
Documentation
Introductions
Tools
Reference
Project
Roadmap
Bug Reporting
Source
Wiki
Tags
Updates
Related Projects
search
|
||||