|
From: Rene <re...@gr...> - 2002-08-12 07:44:48
|
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 |