>From: Scott Eade [mailto:[EMAIL PROTECTED]] >Sent: Sunday, December 15, 2002 4:18 AM >To: turbine-dev >Subject: Re: More updates to the Extending Turbine User Howto > > >Quinton, > >Your update is coming along quite nicely, but I am not sure that you have >fully covered adding the columns to TURBINE_USER. For this to happen there >actually has to be a change to the TURBINE_USER schema somewhere along with >a regeneration of the OM layer for this table (as is done in the existing >howto).
If you are talking about a required modification to turbine-user.xml, I don't think that it is required any longer. The method that I described in the how-to is exactly how I modified it in my application using T2.2. I renamed my turbine-schema.xml to prevent torque from finding it. The existing how-to does talk about making a change to the turbine-schema.xml file. However, the change made will not cause TurbineUser to be regenerated. I am not sure why that change was required before. The Turbine* and BaseTurbine* objects generated in your OM layer under version 2.2, are not used at all. The version of these objects that is used can be found in org.apache.turbine.om.security.* and org.apache.turbine.om.security.peer.*. Since Torque will not be used to regenerate the TurbineUser and associated classes, we must create the adapter and map builder classes to additional database columns. >The discussion about optionally extending TurbineMapBuilder and providing >the adapter classes is a necessary convenience even when using the >OBJECTDATA solution - by making these changes you make the getTitle() and >setTitle() methods available (if you weren't going to do this then the howto >would read in its totality "To extend turbine_user, just use >set/getPerm()."). Actually, I mention that if you are going to use the OBJECTDATA solution, you should implement those methods in your ExtendedUser class. I did not make a big deal of it though. Perhaps I should go into some examples with code of doing it both ways. You could still create the adapter class for TurbineUser to add these methods when using the OBJECTDATA solution but does it really make a difference? I think that it would just add an unnecessary additional class to maintain. The adapter and map builder classes are only _REQUIRED_ when you are going to use additional columns. The purpose of those classes it map certain keys of the perm hashtable to the database columns. You must still use setPerm/getPerm in both solutions. The additional classes cause data in certain mapped keys to be removed from the hashtable immediately before it is written to the database and put into the mapped columns instead. The reverse is true for reading data from the database. I have not looked into the exact details on why it works like this. I am assuming that it is to allow for other implementations that database persistence. Either way, the existing how-to also uses getPerm/setPerm for all access. One thing on the OBJECTDATA solution that I do need to look into is if you need to reference the TurbineUser and TurbineUserPeer objects instead of the adapter classes. I think that you will have to do this. I have never implemented it this way though. > >As this solution currently stands, I think it still suffers from the three >drawbacks documented under the "Deciding how additional data in TURBINE_USER >will be stored" section. Am I wrong? Have you been able to do the three >things listed using this implementation? Yes. 1. I have tested the critieria option. 2. I have queuried the database and there is data in the additional columns. 3. I do rerference the primary key of TURBINE_USER tables in my project-schema.xml. I answering this question I have just realized that one problem that I things that I did say incorrectly is the ability to reference additional data in TURBINE_USER as foreign keys. You can only reference the primary key anyway (unless torque will allow you to reference a unique key). The OBJECTDATA solution really has nothing to do with being able to reference the primary key of TURBINE_USER from the tables defined in project-schema.xml. I will fix that. > >I am pretty sure the solution that actually adds the columns will, as did >the old howto, require a change to _a_ turbine-schema.xml file (I say "_a_" >because it may be a different one to the one that is renamed as part of your >document) and a subsequent regeneration of the security service OM layer. >What needs to be generated are the actual classes that are used (as opposed >to the ones you provide instructions for eliminating). [Aside: >Incidentally, if the classes generated by turbine-schema.xml are not used >then why is this file there in the first place?] The trick is that I >suspect that the classes that are used by the security system are generated >as part of building turbine rather than as part of building an application >(I hope I am wrong on this - I haven't looked into it). > No change is required to any turbine-schema.xml file. The reason is that it should _NOT_ be regenerated by Torque. Org.apache.turbine.om.security.TurbineUser implements the User interface in the same package. These additional methods would not be regenerated by Torque. This is why I originally made the mistake of saying that the setPerm/getPerm/setTemp/getTemp methods were no longer there. That information was from some of my old notes when I did not realize that the Turbine* objects generated by Torque were not used. The only reason that I can think of to modify turbine-schema.xml is the ant task that will create your database schema for you. Without this file, it will not happen. Modifying the file to include the additional column(s) would allow you to use Torque to recreate the database with the additional column(s) in place. I think I need to look into another way of preventing torque from generating objects from turbine-schema.xml besides renaming it. I think that perhaps the reason that I have just now thought about that problem is that I have never used torque to generate my database for me. I have not looked into the process of building Turbine and if the security package is rebuilt during this process. I can say that not having this file and rebuilding Turbine does not break anything. I think that I would rather keep the instructions as they are with the adapter classes even if rebuilding Turbine would add the additional fields. IMHO, it would be easier for the newcomer to Turbine to extend it this way that to be required to rebuild Turbine. This is just my opinion though. >As I said earlier, the update is developing nicely. Some additional work >may be required to get over this last hump. Perhaps one of the others that >was going to have a crack at this document can pitch in to get this last bit >happening (Rodney?). Thank you. I have certainly put some work into it an I would like to make it even better. I spent about a week trying to get this working when I migrated from 2.1 to 2.2. The mailing list archives were not of much help other than a few people reporting that the method describe in 2.1 could be used with some changes for the decoupled version of Torque. I did not want anyone else to have to go through that long process. If anyone else has any information of alternative methods or other implications, please let me know! > >BTW 1: You might like to add a comment in TurbineMapBuilderAdapter that goes >into a little more detail about the need for the dummy integer, even a >reference back to TurbineMapBuilder might make things clearer. Makes sense. > >BTW 2: Is there a reason why the document is generated wider than the >browser window? Compare the width of the existing howto to yours. > Honestly, I have no idea. I don't really understand how the xdocs are generated. I will look into this though. If anyone can offer some information how the width is determined, please let me know. I would rather not dig into that part of this. >Cheers, > >Scott >-- >Scott Eade >Backstage Technologies Pty. Ltd. >http://www.backstagetech.com.au >.Mac Chat/AIM: seade at mac dot com >> From: "Quinton McCombs" <[EMAIL PROTECTED]> >> Reply-To: "Turbine Developers List" <[EMAIL PROTECTED]> >> Date: Sat, 14 Dec 2002 22:06:42 -0600 >> To: "Turbine Developers List" <[EMAIL PROTECTED]> >> Subject: More updates to the Extending Turbine User Howto >> >> I have recently made more changes to the new version of the howto for >> extending Turbing User. Thank you to everyone who took the time to look >> it over and comment. This has allowed me to fix a few mistakes and go >> into more detail on sections that were not clear enough. The main >> changes that I made are listed below. >> - Fixed mistakes (of course) >> - It is now divided up into sections >> - I added a discussion on the issues with using OBJECTDATA for storage >> vs additional columns. >> - Added more specific instructions for renaming turbine-schema.xml and >> removing the objects that were generated from it. >> >> http://blaze.qdog.org/preview/howto/extend-user-howto.html -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
