Menu
▾
▴
Re: [Bobs-devel] Rewrite classes
|
From: Joe z. <jz...@at...> - 2002-08-15 04:29:19
|
I don't understand. I was thinking a plugin would be something that gets passed pre-defined parameters and returns pre-defined parameters, whether it be a call to an API or a class based on a pre-defined base plugin class. The details of how the plugin works should be of no concern to bobs - except for any pre-defined constraints there may be. I haven't tried to figure out how you're using plugins, because I've got my head buried in the admin config. I don't have any experience with pc based plugins either. And I don't understand what the "data layer" would be. So, I guess that's no help. Joe Rene wrote: >I'm still trying to decide whether I think an API interface would be a >good idea or if "plugins" should be selfcontained. > >I'm trying to seperate as much as possible to a form a base >functionality. Then plugins can use that and add to it as needed. > >What bothers me is that plugins cannot extend each other. This to is the >key problem. Do I just say "fine, so be it" or do I restructure the >whole thing until I find a way? >In the current state a plugin would need to provide an API to be usefull >to other plugins. > >Taking the fast path now would be easy, but later on it might prove more >work if things need to change. > >There are 3 layers of separation in what we've done so far. >-- Admin layer > configuration/login >-- Base layer > common functionality >-- Plugin layer > specific functionality > >If another layer should be added it would probably be a data layer >between plugins and base. That would enable plugins to use each others >functionality better. But it would also require extensive work to define >how data is passed and what type of data are passed. > >How do you feel about this? I don't really have the experience required >to define the data layer and its inner workings. >If you are experienced in that area we could work together on it. > >-Rene > > > > > >On Mon, 2002-08-12 at 08:25, Joe zacky wrote: > > >>Rene wrote: >> >> >> >>>This looks fine to me. >>>The way I think of it is that config/admin classes end up passing an >>>array to the "base" class which contains all configuration settings of >>>the active server. >>> >>> >>> >>I'm trying to think of the "objects" involved. Site configuration >>(config object), server configuration (server object), List of servers >>(serverlist class), administrator login (admin object), user logins >>(user, group, and access classes), and screen functions like html output >>(gui class). >> >> >> >>>I hardcoded the config in the example I put up. I just need to fit in >>>the real stuff you've been working on. >>> >>> >>> >>> >>I think my stuff's ready enough for you to use now. I have half a dozen >>more small changes to make and some code review/cleanup before another >>checkin. The class reorganization will take more time. I've been using >>SourceNavigator as my editor. It has a nice 'grep' function that >>searches all the source code in the project. >> >> >> >>>So in the end the only communication between admin/config/login and the >>>rest of bobs is an array with the configuration settings. >>> >>> >>> >>> >>The array(s) and functions in the "server" object will be basically what >>the "config" class is now. >> >>Joe >> >> >> >>>-Rene >>> >>>On Sun, 2002-08-11 at 22:15, Joe zacky wrote: >>> >>> >>> >>> >>>>Now that I've gotten familiar with the admin interface and config class, >>>>I feel like you - I want to rewrite the classes. I've been reading a lot >>>>in the php manual and examples and I think a single server definition >>>>should be an object (class). A serverlist class could extend the server >>>>class. All the classes could be based on a simple config class that just >>>>basically stores the siteroot and server directory. >>>> >>>>Here's my proposed class structure. Please let me know what you think. >>>> >>>>------------------------------------------------------ >>>>BOBS proposed class structure >>>> >>>>CLASS VARIABLES CLASS FUNCTIONS >>>> >>>> config >>>>siteroot config (constructor) >>>>serverdir >>>> admin extends config >>>>admin_ok check_admin >>>>admin_pwd >>>> server extends config >>>> server (constructor) - inits >>>>as new server >>>>server_defs[] get_ini - get .ini file into >>>>config >>>>login_ok check_active >>>>new check_day >>>>config login >>>> commit_changes >>>> serverlist extends server >>>>servers[] set_config >>>>current_server set_current >>>> get_current >>>>------------------------------------------------------ >>>> >>>>I think the check_rules and parsing should be in a class too, but I'm >>>>not sure how to fit it in yet. Maybe an edit class and a GUI class that >>>>extend server? >>>> >>>>Joe >>>> >>>>P.S. I could finish the functionality the way it is if you want to get a >>>>working version out there before rewriting the classes. Just let me know. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >> >>------------------------------------------------------- >>This sf.net email is sponsored by:ThinkGeek >>Welcome to geek heaven. >>http://thinkgeek.com/sf >>_______________________________________________ >>Bobs-devel mailing list >>Bob...@li... >>https://lists.sourceforge.net/lists/listinfo/bobs-devel >> >> > > > > >------------------------------------------------------- >This sf.net email is sponsored by:ThinkGeek >Welcome to geek heaven. >http://thinkgeek.com/sf >_______________________________________________ >Bobs-devel mailing list >Bob...@li... >https://lists.sourceforge.net/lists/listinfo/bobs-devel > > > |
