On Mar 15, 2008, at 12:07 PM, Gustavo Pizano wrote:
these methots are in the session.java... is it good idea to have
them there?
The scope of the Application object is the entire application
including all Sessions and their WOComponents. So the Application
object is a good location for any resource that needs to be accessible
from any Session. There usually aren't too many of these. If you run
your app with concurrent request handling, these shared resources in
Application need to be thread-safe.
The scope of the Session object is all WOComponents used in each
Session. So the Session object is a good location for any resource
that needs to be accessible from more than one WOComponent. However,
each Session object is archived at the end and unarchived at the
beginning of each request-response cycle which is a reason to limit
the number of Session instance variables. So a common pattern is to
pass resources from one WOComponent to the next WOComponent, i.e., the
next "page", rather than placing these shared resources in the Session
object.
The scope of each WOComponent is that WOComponent itself. So any
resource that only that WOComponent needs to access should be in the
WOComponent.
Any logic and resources that don't depend on WOComponents, Sessions,
etc., should be in Model classes (as in the Model-Controller-View
paradigm). Enterprise Objects (i.e., those classes that represent
database entities) are common examples of Model classes.
So if you organize your WO apps and frameworks with such concepts in
mind, life will generally be better.
adn second, I know that the names in the tables of a db can be in
plural, but not the name of a java class, nto becuase of errors but
because of convention,
so what can I do there,?? make another class cales Usuario who
extends from Usuarios? (thats my thinking)
The Java class name does not have to be the same as the database
table name, so if a table in your database is named "Usuarios", you
could set its Java class name to be "Usuario". There's no need to
define a subclass just to make this happen.
and second
dunno understand this line very well..
((Session)session()).setCurrentUser(person);
its not a session method ...
what to do with that methog, I understand is to assing the session
to that User.
The user associated with a Session is usually needed by multiple
WOComponents, so defining the user in the Session object makes sense.
You need to define setCurrentUser()/currentUser() in your Session
object which extends WOSession. Because setCurrentUser() isn't
defined in WOSession is why session() must be cast to Session.
Aloha,
Art
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
