Menu
▾
▴
phpwebsite-developers
|
From: Frits J. <FJ...@uv...> - 2001-03-30 15:48:35
|
I totally agree! This way the obvious danger of mess, interference and disagreements is avoided. It cannot be avoided that some want to make things different than others out of need, religion or whatever reason. Is everything in modules, forced to compatibility by standards set by the core program, set by Appalachian on input of everybody, hey - everybody is happy :) More product, less fuss. We can easily have two 'official' versions of a plugin, thus having creative and productive "arguments" (my plugin is more popular than yours) instead of stopping democracy - Join the force of your choice. Less chance of core problems! 'This plugin returns error' is better than 'This product returns error' Also it will reduce the betaversions, as the central core will be easier to produce, and then one may have to wait for plugins, but this must be better than to wait for the whole package.. Another obvious, and I should think extremely giving bonus, is that programmers will have more to show; "Plugin by:.." instead of "Contributors to the project, version this and that:..." The core should *never* sacrifice anything in order to be backwards-compatible between major releases. A plugin should have a number in its name, referring to which version of core it worked with, eg 'weather_plugin_7.php'. The reason for this is that this is free code, not expansive hardware - you can just upgrade everything if you want to move to next major release - This way we can get a head start, and move fast and flexible - not get stuck like some well known DOS-based OS, or as a large non-module-based project easily could be. The guys at Appalachian should kick back and decide which plugins they'd recognise, then put them on the official site after validating XTML, safe programming, etc. BTW; I am working on a proposal for CSS standards. Anyone read my (and Karstens) thoughts, and have comments? =) I think this whole community thing is way far out funny; Humanoids are moving from individuals to interacting cells in a large producing organism. Maybe if the right circumstances are there, life eventually will occur. Given the chance of communicating with ASCII in real-time on a global basis, coding eventually will occur. Hello fellow cells :) Forgive me for looking down.. Hail Todd. Frits. > -----Oprindelig meddelelse----- > Fra: Todd Owen [mailto:to...@da...] > Sendt: 30. marts 2001 16:39 > Til: php...@li... > Emne: Re: [Phpwebsite-developers] Roadmap > > > My proposal is that EVERYTHING should be a plug-in, including > much of what > is now "core" functionality, like the referrer tracking, > categories and > polls. I want to see phpWS as more of an erector site, with > just about > everything available a la carte. What does everyone think > about this? I > think it helps a user mentally organize phpWS and makes my > database scheme > ;) look more logical. > > Each plug-in module would have its own admin page too and it > would be the > perfect place to add access control. > > --Todd > > > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > |
|
From: Todd O. <to...@da...> - 2001-03-30 22:53:08
|
I think Brian will let us know the vote for database abstraction layer by Monday, if not before. This will allow those coding for the current structure to continue. I agree that development on the current phpWS should not be affected by the "redesign". This should work something like the Linux kernel. 2.2 continues as 2.3 is developing, then at some point 2.4 is magically complete. I like the idea of 80% design and 20% code. My degree is in electrical engineering and I have designed some very large buildings ($120 million range). A well thought out design is CRITICAL. When building my last prison, a change to the foundation would have been cripling to the entire project. That's why I think more dialog, like what we're having now, is very beneficial and shouldn't be cut off today. However, I do understand that some people want to code and we do need standards for that code. Things like database abstraction layer, code indention and naming (underscores) should be decided now and be used in both the "stable" and "development" versions. I propose we start using the odd and even version naming beginning with version 0.8 and the rewrite will be 1.0. Although I'm glued to every developer list email, I realize that lots of others are using the Sourceforge forums. Most of my work will be on the rewrite, but that's OK because we'll still work together as a group, whether you're primarily 0.8.x or 0.9.x. There appear to be lots of plug-in module programmers talking on the forums and they're ready to start coding. Others of us are ready to redesign. Am I making any sense? Am I the only one over here or not? --Todd |
|
From: Mike W. <wi...@ce...> - 2001-03-31 16:50:40
|
Todd, > I think Brian will let us know the vote for database abstraction layer by > Monday, if not before. This will allow those coding for the current > structure to continue. I hope so. :) > programmers talking on the forums and they're ready to start coding. Others > of us are ready to redesign. Am I making any sense? Am I the only one over > here or not? I agree and I am ready to start with some plugins as soon as we get a standard. Has anyone heard anything? Mike |
|
From: Geoff S. <Ge...@Ho...> - 2001-03-31 18:47:16
|
Here's my cut on it: We need to decide what the final form of the existing phpWebsite will be. It should be a tool that only works with mySQL and is compatible with php3 and php4. This product would be "functionally stable". That means bug fixes only - no further enhancements. What will happen is this: Folks will continue to use it and they will continue to write plug-ins for it. So, it will have a life of its own. If the plug-in scheme for the existing phpWebsite is compatible with the new product, that would be nice -- but we have to get a certain amount of design work done to determine if that will be the case. I would not compromise on the new system to make the plug-in scheme work with both the current and the new product. Here's an example of something that could easily make the plug-in system for the new product incompatible with a plug-in scheme for the existing product: I mentioned the other day that the core product should include a mailing list system so that plug-ins can integrate with it. This would allow a weather plug-in, for example, to have a subscription for emailed weather updates -- freeze alerts or whatever -- that uses the built-in mailing list system. ALSO, when someone registers for a login id, they would be presented a list of email subscriptions, some of which were put there by plug-ins. The big deal here is this: topics, subtopics, etc. should be setup once and available to news stories, the links subsystem, discussion forums, and all plug-ins that require the information. When someone registers, they should be able to put in their information once and have it used throughout the system so that their is no duplicate entry of information for each plug-in. And, just as important, to eliminate duplication of effort by admins setting up the system. It may be that the old plug-ins could work in the new system -- they just wouldn't be able to take advantage of all the plug-in features without some modification -- but, we won't know that until we have a new system design. Perhaps, we should design the new system and then upgrade the existing system so that it will work with the plug-ins for the new system? If that could be done, we'd have the best of all worlds: An existing system that is stable, works on php3 and php4, and can be expanded with plug-ins. AND, those plug-ins would also work with the new system. I think it doubtful that we could achieve 100% compatibility. But, we'll have to see how it all comes out. In any event, this would allow those with immediate requirements to address them without totally locking themselves into the old system. Geoff Geoff Staples, Hostricity Web Hosting <http://www.hostricity.com/> -----Original Message----- From: php...@li... [mailto:php...@li...]On Behalf Of Mike Windsor Sent: Saturday, March 31, 2001 10:51 AM To: php...@li... Subject: Re: [Phpwebsite-developers] Roadmap Todd, > I think Brian will let us know the vote for database abstraction layer by > Monday, if not before. This will allow those coding for the current > structure to continue. I hope so. :) > programmers talking on the forums and they're ready to start coding. Others > of us are ready to redesign. Am I making any sense? Am I the only one over > here or not? I agree and I am ready to start with some plugins as soon as we get a standard. Has anyone heard anything? Mike _______________________________________________ Phpwebsite-developers mailing list Php...@li... http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers |
|
From: Todd O. <to...@da...> - 2001-04-01 02:23:57
|
> We need to decide what the final form of the existing phpWebsite will be. It > should be a tool that only works with mySQL and is compatible with php3 and > php4. This product would be "functionally stable". That means bug fixes > only - no further enhancements. Agreed! We'll leave it mySQL only, good idea. > ALSO, when someone registers for a login id, they would be presented > a list of email subscriptions, some of which were put there by plug-ins. This "alert" function seems interesting to me. Is anyone working on a detailed design proposal for this? I am working on my core proposal, which I hope to publish no later than Monday (even if slightly incomplete). The "alerts" won't be in it however. > The big deal here is this: topics, subtopics, etc. should be setup once and > available to news stories, the links subsystem, discussion forums, and all > plug-ins that require the information. When someone registers, they should > be able to put in their information once and have it used throughout the > system so that their is no duplicate entry of information for each plug-in. Is this what everyone wants? This is where I'm currently working. If we do want the "topics" and "subtopics" to be consistant across the organization, then this needs to be in the core. Once the topics are defined for each organization, then the plug-in modules can draw on them (topics) immediately. --Todd |
|
From: Geoff S. <Ge...@Ho...> - 2001-04-01 03:03:27
|
HERE'S MY QUESTION: WHAT CORE "SERVICES" DOES THE BASE SYSTEM NEED TO PROVIDE TO PLUG-INS? There are certain things that will be common across many plug-ins. These things should be part of the core. Some of the things I've thought about that would be common across many plug-ins are: Administrative services should extend to plug-ins. For example, if the system allows separate administrators for topics or sub-topics, sub-webs, whatever, this should extend across plug-ins that use topics, sub-topics, etc. Mailing list functionality - the ability to have mailing lists for a plug-in that can be setup when someone registers for a login id. Themes - plug ins should be able to "inherit" the theme from the site. I'm hoping that we can come up with a complete list of the services that the core system should provide to plug-ins. Geoff -----Original Message----- From: php...@li... [mailto:php...@li...]On Behalf Of Todd Owen Sent: Saturday, March 31, 2001 8:24 PM To: php...@li... Subject: Re: [Phpwebsite-developers] Roadmap > We need to decide what the final form of the existing phpWebsite will be. It > should be a tool that only works with mySQL and is compatible with php3 and > php4. This product would be "functionally stable". That means bug fixes > only - no further enhancements. Agreed! We'll leave it mySQL only, good idea. > ALSO, when someone registers for a login id, they would be presented > a list of email subscriptions, some of which were put there by plug-ins. This "alert" function seems interesting to me. Is anyone working on a detailed design proposal for this? I am working on my core proposal, which I hope to publish no later than Monday (even if slightly incomplete). The "alerts" won't be in it however. > The big deal here is this: topics, subtopics, etc. should be setup once and > available to news stories, the links subsystem, discussion forums, and all > plug-ins that require the information. When someone registers, they should > be able to put in their information once and have it used throughout the > system so that their is no duplicate entry of information for each plug-in. Is this what everyone wants? This is where I'm currently working. If we do want the "topics" and "subtopics" to be consistant across the organization, then this needs to be in the core. Once the topics are defined for each organization, then the plug-in modules can draw on them (topics) immediately. --Todd _______________________________________________ Phpwebsite-developers mailing list Php...@li... http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers |
|
From: Todd O. <to...@da...> - 2001-04-01 03:22:49
|
In developing an application framework for phpWebSite, I have tried to review as many projects as possible to learn from their success (and mistakes). I continue to see many areas where we can look to phpGW's success. The following documentation link gives a good overview of their plug-in API and language API. http://www.phpgroupware.org/phpgroupware/phpgwapi/doc/ For those working with the translation interface, is phpGW's database translation system too much of a performance hit? Is it easier just to work with a text file? I would like some others to review the following code from the phpGW project (phpGroupWare-0.9.9p1.tar.gz): Access Control List class: phpgroupware/phpgwapi/inc/phpgw_accounts_shared.inc.php Templates (the templates look very much like those proposed here before, although they use the phplib template class): phpgroupware/phpgwapi/templates/ Session Management and general object design: phpgroupware/phpgwapi/inc/phpgw_common.inc.php phpgroupware/phpgwapi/inc/phpgw.inc.php Do we use the phpgw classes as they are, modify them to meet our need, or neither? --Todd |
|
From: Aaron A. <aa...@wc...> - 2001-04-02 12:08:21
|
Check out http://binarycloud.com (it may save some work for people looking to do the things described below): binarycloud is a platform for building web applications with PHP It includes basic services like authentication, permissions, a template engine, database abstraction etc., an extensive collection of libraries, and a framework for configuring the system and building your own logic. Also, binarycloud is compatible with PEAR. --- Aaron Adams |
|
From: Todd O. <to...@da...> - 2001-04-02 17:44:50
|
Re: [Phpwebsite-developers] binarycloudI've been reviewing binarycloud = this morning and don't see much new. Most of the classes are either = PEAR or from the class repository. The xml database setups and dumps = looked interesting, but I saw much more that I liked in phpGroupWare. --Todd |
|
From: Spiggy T. <th...@me...> - 2001-04-01 03:32:49
|
> > > The big deal here is this: topics, subtopics, etc. should be setup once >and > > available to news stories, the links subsystem, discussion forums, and all > > plug-ins that require the information. When someone registers, they should > > be able to put in their information once and have it used throughout the > > system so that their is no duplicate entry of information for each >plug-in. >Is this what everyone wants? This is where I'm currently working. If we do >want the "topics" and "subtopics" to be consistant across the organization, >then this needs to be in the core. Once the topics are defined for each >organization, then the plug-in modules can draw on them (topics) >immediately. i think it would make most sense this way. what id also like is to have a possibility of having a user portal kind of approach. not user submitted stuff (although they can) but user chosen content.. like choose a 'track' you're interested in and get news, articles etc on that topic. what i am thinking is choosing just one topic out of the options available... or if one of the topics is gardening and the user has no interest on it.. he/she can choose to ignore it completely. of course the admin could choose to override this (maybe the main topic IS gardening). anyway, i managed to accomplish a small victory Friday. phpwebsite will be considered as the portal for my college. woohoo! what phpws does is enough for now. im hoping the real deal will be functional when the testing is over :) paivi |
|
From: Bob M. <web...@is...> - 2001-04-01 03:46:26
|
Hi everyone, I have seen a post not to long ago about this portal and saw no response from anyone...I would like to suggest everyone take a look at it here http://www.kodewulf.za.net/index.php this portal has a new blocksystem and here is the quote from the developers: There are no left-, right-, admin- and mainblock in this system. For this types of blocks exists only one in the new system. The Custom Block. You can set every blocktype as an admin block. You can set the displayorder for the blocks. You set the side of the block. Left or right. You set that the block is visible or not. For the blocktypes other then the customblock you can input a new Title for this block and add an addional content above or after the original content. you can also weigh the blocks in a specific order...these guys did a nice job IMHO... Bob McCambridge -----Original Message----- From: php...@li... [mailto:php...@li...]On Behalf Of Spiggy TheCat Sent: Saturday, March 31, 2001 10:36 PM To: php...@li... Subject: Re: [Phpwebsite-developers] Roadmap > > > The big deal here is this: topics, subtopics, etc. should be setup once >and > > available to news stories, the links subsystem, discussion forums, and all > > plug-ins that require the information. When someone registers, they should > > be able to put in their information once and have it used throughout the > > system so that their is no duplicate entry of information for each >plug-in. >Is this what everyone wants? This is where I'm currently working. If we do >want the "topics" and "subtopics" to be consistant across the organization, >then this needs to be in the core. Once the topics are defined for each >organization, then the plug-in modules can draw on them (topics) >immediately. i think it would make most sense this way. what id also like is to have a possibility of having a user portal kind of approach. not user submitted stuff (although they can) but user chosen content.. like choose a 'track' you're interested in and get news, articles etc on that topic. what i am thinking is choosing just one topic out of the options available... or if one of the topics is gardening and the user has no interest on it.. he/she can choose to ignore it completely. of course the admin could choose to override this (maybe the main topic IS gardening). anyway, i managed to accomplish a small victory Friday. phpwebsite will be considered as the portal for my college. woohoo! what phpws does is enough for now. im hoping the real deal will be functional when the testing is over :) paivi _______________________________________________ Phpwebsite-developers mailing list Php...@li... http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X