----- Original Message ----- From: "Emmitt Dove" <[EMAIL PROTECTED]> To: "RBASE-L Mailing List" <[email protected]> Sent: Thursday, January 03, 2008 2:41 PM Subject: [RBASE-L] - RE: storing code in the database
> Larry, > > That said, a menu that profiles itself to the user is certainly achievable. > I've been having a debate with myself over whether to move in that > direction, or to go to EFFs for menus. Using EFFs, where do you get the > user security data? (One possible answer: a security database .) > I had such a front end DB in 4.5. I did work for a company that (old tech) photographed documents for storage on film and used the db for look by Roll and Frame number. Their work encompassed many different companies with different security requirements, so the Users logged into the Security DB and based on who you were, presented with disparate menus leading to the DBs for which you were approved, etc. > > So many features, so little time! > > > > Emmitt Dove > > Manager, DairyPak Business Systems > > Blue Ridge Paper Products, Inc. > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > (203) 643-8022 > > > > From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Lawrence > Lustig > Sent: Thursday, January 03, 2008 1:14 PM > To: RBASE-L Mailing List > Subject: [RBASE-L] - RE: storing code in the database > > > > << > > - Process name (PK) > > - Disk filename (for auto loading and unloading) > > - d/t created > > - author > > - d/t last revised > > - revised by > > - version number > > - comment > > - code column (varchar datatype) > >>> > > > Emmitt: > > I originally requested the RUN SELECT functionality way, way, way back in > RBDos days when there was no way at all of storing code in the database > (short of sticking it in a NOTE field and unloading it yourself preparatory > to running it). My goal was to build my own menu / permissions system in > which I only had to update the rows in the code table and some accompanying > access control lists and then use a common, unchanging piece of code to > present that data to the user as an application. > > In my opinion the need for RUN SELECT has been eliminated for almost all > cases by all the new features of R:Base. However, it sounds like you want > to take things further than R:Base currently does by essentially turning > your RUN SELECT system into a version control management system (you could > even keep older versions of each procedure on line if you wanted to). > > My original idea was to use CHOOSE to display menus to the user showing only > the commands that the user was permitted to see. With the new R:Base > functionality to create objects at runtime, I imagine you could easily have > each form create a customized version of a menu or group bar from data in > the procedures table based on the current user login and other information. > That would be very cool -- menus and forms that automatically adjusted > themselves to the user's identity! > > If you go this route, it would be _very_ nice if you submitted an > enhancement request for a new kind of rich text editing control -- one that > would act exactly like RBEDIT. Then you could _really_ build a version > control system on top of R:Base. > > > -- > Larry > >
