Return-Path: Delivered-To: apmail-jakarta-jetspeed-dev-archive@jakarta.apache.org Received: (qmail 270 invoked by uid 500); 30 Apr 2001 22:18:38 -0000 Mailing-List: contact jetspeed-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Post: List-Help: List-Unsubscribe: List-Subscribe: Reply-To: jetspeed-dev@jakarta.apache.org Delivered-To: mailing list jetspeed-dev@jakarta.apache.org Received: (qmail 99915 invoked from network); 30 Apr 2001 22:18:31 -0000 User-Agent: Microsoft-Entourage/9.0.1.3108 Date: Mon, 30 Apr 2001 15:18:34 -0700 Subject: Re: UpdateAccount Save Password Bug Fix From: Jon Stevens To: jetspeed-dev Message-ID: In-Reply-To: <9678C2B4D848D41187450090276D1FAE0C1449C6@FMSMSX32> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N on 4/30/01 2:29 PM, "Turpin, Jay" wrote: > Thanks for the additional information. However, maybe you can clear up some > confusion on our part. Why use: > > data.getUser().setPerm( org.apache.turbine.om.security.User.FIRST_NAME, > firstname ); > > instead of: > > data.getUser().setFirstName(firstname); Right, you suggest the right way to do things. However, in Jetspeed, the history is to pick the wrong way. :-) > Maybe this question comes from my general confusion about the design. Based > on reading the documentation about Peers on the Turbine web site, I thought > TurbineUserPeer is used for interacting with the underlying data repository, > in this case, the TURBINE_USER table in the database. However, in the code > below, it looks like it is being used as "User" object for the application. TurbineUser is the implementation of the User interface. > I have a difficult time understanding the purpose of many of the features in > the User interface, particularly get- and setPerm(). How do these functions > differ from using the accessor methods in the TurbineUser class? Repeat: The TurbineUser class is the default implementation of the User interface. > I think of the system working this way, please educate me if I am mistaken: > * The app should use the TurbineUserPeer class to fetch a TurbineUser object No! The app should use the TurbineSecurity class to fetch a User object. This object could be a TurbineUser object or any other object that implements the User interface. You should *never* directly reference a TurbineUser class...you should *always* use TurbineSecurity. > * Use the data in the TurbineUser object to populate a form and store > updates made by the user Potentially. > * If the data needs to be made permanent, create a Criteria object using the > data in TurbineUser and save it to the database using TurbineUserPeer Nope. User.save() > Is this viewpoint correct? Or am I missing something? Close...what you are missing is the level of abstraction that Turbine provides over the User/Role/Permission system. -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous --------------------------------------------------------------------- To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org