Menu
▾
▴
[Phpwebsite-developers] RE: Phpwebsite-developers digest, Vol 1 #43 - 10 msgs
|
From: Bob M. <web...@is...> - 2001-03-30 22:20:48
|
Hello everyone, I have been formally asked to join the developement team on this project and have some questions. 1. What is the current status of this project (it appears to be going in several different directions). 2. Is the core code going to be rewritten? 3. Is the user authentication system thats in place now going to be changed? ie. session handling, cookie based... 4. Is there a set standard for the plugins and themes? 5. Who is the final decision maker on this project? Does this person have a roadmap? Has anything been decided at this time? 6. Is there going to be a stripped down version of the core code and leave everything else as a plugin? I see too many responses in regards to what I have mentioned above and see no actual plan or structure. I would like to get started on this as I have customers that are very interested in this project but who are not willing to wait on something that will take too long to accomplish. I have also been working on this from another aspect as well and that is the integration of phpWebSite and vBulletin along with many plugins that I have already written, I have slowed my progress down for obvious reasons and would like to see a solid foundation set so we can just get on with this and produce the best CMS/Portal there is. Any comments or feedback? Thamk you, Bob McCambridge -----Original Message----- From: php...@li... [mailto:php...@li...]On Behalf Of php...@li... Sent: Friday, March 30, 2001 11:27 AM To: php...@li... Subject: Phpwebsite-developers digest, Vol 1 #43 - 10 msgs Send Phpwebsite-developers mailing list submissions to php...@li... To subscribe or unsubscribe via the World Wide Web, visit http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers or, via email, send a message with subject or body 'help' to php...@li... You can reach the person managing the list at php...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of Phpwebsite-developers digest..." Today's Topics: 1. Re: Template system: Proposal (Karsten Dambekalns) 2. Re: Template system: Proposal (clayton collie) 3. Re: Integrated User/Group & Permissions (clayton collie) 4. Re: Template system: Proposal (Todd Owen) 5. Re: Roadmap (Todd Owen) 6. Good Feature to Consider [long] (clayton collie) 7. Re: Integrated User/Group & Permissions (clayton collie) 8. Re: Integrated User/Group & Permissions (Todd Owen) 9. SV: [Phpwebsite-developers] Roadmap (Frits Jensen) 10. Re: Good Feature to Consider [long] (Karsten Dambekalns) --__--__-- Message: 1 Date: Fri, 30 Mar 2001 15:40:19 +0200 From: Karsten Dambekalns <k.d...@tu...> To: php...@li... Subject: Re: [Phpwebsite-developers] Template system: Proposal Organization: fishfarm Reply-To: php...@li... --V88s5gaDVPzZ0KCq Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 30, 2001 at 07:56:17AM -0500, Todd Owen wrote: > > leftbox > > rightbox > > main >=20 > I think we're selling the project short if we have leftbox and rightbox, > etc. The themes need to be more generic and flexible. Such as the > following: >=20 > --Objects on a certain page > nav_bar, weather, articles, poll1, poll2 (second instance), job_posts, > header, footer Right. But will these be "blocks" or not? That is, do we need special styles for those? I think we should stick with something like left,right,main, for the sake of simplicity. If we jave something like {leftblocks}, we have the opportunity to let the system reorder the single blocks within that. > --Theme/template > <html><body> > <style sheet here> > {header}<br /> > <table> > <tr><td>{nav_bar}</ td><td>{articles}</ td> > <td>{poll1}</ td><td>{poll2}</ td></ tr> <hr /> > <tr><td>{weather}</ td><td>{job_posts}</ td></ tr> > </ table> > <br />{footer} > </ body></ html> How would the system know that those placeholders exist? And what about a plugin? Is this was to go into the {plugin} part of the template, all would be well. But if that plugin neede something like {my_blah_plugin}, you wouldn't be able to use that plugin with some other theme... > You see my point. We need to have each of the page objects separate, then > allow the theme/template to arrange them independant of left, main and to= p. Yes, seperatley, but following some rules. If I may lay out some ideas... (we might have something like this as documentataion on "how to write themes"): -------------------------- - A theme has to provide at least one page template, one block template and exactly one stylesheet. - The stylesheet *must* define the following classes and tags in that class= es: (insert with what Frits and/or others come up) [1] - The stylesheet *may* define additional styles for classes or tags used solely in the corresponding template. The must not interfer with the standard PHPWS style/class names. [1] - The page template *must* provide placeholders for: - blocks1, blocks2, blocks3, blocks4 [2] - plugins1, plugins2 [2] - header [3] - footer [3] - main [4] - menu - The block template *must* define a standard block for use with the format_block($title,$content) function (or whatever function there may be). - The theme *may* define more block templates, which can be assigned to individual blocks through the admin interface. -------------------------- This is mainly a proposal, although I would consider it thought through, at least in a basic way :-) [1] By setting up rules for the stylesheet, we achieve a minimum level of compatibility between templates. By allowing additional rules in them, we give designers some more freedom. [2] The page must define 4 block and 2 plugin placeholders, because we could give the possibility to assign a plugin or block to one of the block or plugin "places". I do not name them blocks_left, blocks_top, et al, because that would imply a position. Having them numbered, gives a theme author the possibility to place blocks1 and blocks2 directly above each other, for example. - Question: shall we seperate blocks and plugins, or shall plugins be plced like blocks? - Question: Are 4 (6) blocks/block positions enough? [3] These would be for placing some smallprint (like at the bottom of the page and what is $titlebar in config.php now) [4] Here would go anything else that is produced dynamically (except the menu, of course). REMEMBER: These rules are for standard themes (and their authors), they make sure that a theme is fully compatible with an out-of-the-box install of PHPWS. If one wants to develop a theme for personal use, he/she could easily omit blocks3 and blocks4, as well as the header. He wouldn't be able to complain about being able to assign plugin x to blocks3, though :-) And such a template wouldn't pass QA at Appstate and therefore wouldn't be offered on the download page. That's it, sorry for the much too long post (again!) :o) Regards, Karsten --=20 Why do we have to hide from the police, daddy? Because we use emacs, son. They use vi. ----------------------------- mailto:k.d...@tu... w=B3: http://www.k-fish.de/ gpg: http://www.k-fish.de/mykeys.gpg --V88s5gaDVPzZ0KCq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1e-SuSE (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6xIzCzmcQByaBiO8RAgW2AKDelxt940Ns6ynE6bWcXBRrTW4AtACgwSHj CpzGpVmPVHP5dseRA/bjf7Y= =wyIR -----END PGP SIGNATURE----- --V88s5gaDVPzZ0KCq-- --__--__-- Message: 2 From: "clayton collie" <cc...@ca...> To: <php...@li...> Subject: Re: [Phpwebsite-developers] Template system: Proposal Date: Fri, 30 Mar 2001 09:15:17 -0500 Reply-To: php...@li... Karsten, > - The page template *must* provide placeholders for: > - blocks1, blocks2, blocks3, blocks4 [2] > - plugins1, plugins2 [2] > - header [3] > - footer [3] > - main [4] i hate to harp on Smarty again, but one nicety it has is that you (the developer) can define custom tags which can take parameters which can come from PHP variables or a config file. So you can have something like : {block number=$block_number position=$block_position theme=$site_theme} to implement this you would then define a function in an addon file which takes the parameters passed to it and return an html fragment. if needed, you can put the tag in a template block which generates the required parameters. btw for some reason, all your messages appear as attachments in LookOut Express ----- Original Message ----- From: "Karsten Dambekalns" <k.d...@tu...> To: <php...@li...> Sent: Friday, 30. March 2001 8:40 Subject: Re: [Phpwebsite-developers] Template system: Proposal --__--__-- Message: 3 From: "clayton collie" <cc...@ca...> To: <php...@li...> Subject: Re: [Phpwebsite-developers] Integrated User/Group & Permissions Date: Fri, 30 Mar 2001 09:31:24 -0500 Reply-To: php...@li... WD, i dont know if its ok to send attachments through the list. email me privately (my email address is visible, right ?) and i'll send it to you .. ----- Original Message ----- From: "W.D.Sumilang" <wa...@on...> To: <php...@li...> Sent: Thursday, 29. March 2001 18:16 Subject: RE: [Phpwebsite-developers] Integrated User/Group & Permissions --__--__-- Message: 4 From: "Todd Owen" <to...@da...> To: <php...@li...> Subject: Re: [Phpwebsite-developers] Template system: Proposal Date: Fri, 30 Mar 2001 09:35:38 -0500 Organization: Data Dynamix Reply-To: php...@li... Karsten, you're correct; we should make the themes use block1, block2, etc. to make them more generic, in lieu of the specific names I gave them. We should have an agreed upon set of style sheet parameters that is used throughout the PHP code on the site including plug-in modules. If a plug-in developer wants to use a new CSS parameter, that's OK, but it must fall back to one of the standards if not included in a default theme--this would keep things from breaking (i.e. looking strange). --Todd TRANSLATE[[ As a loyal vi user, I continue to take offense to Karsten's signature block. Unless it stops, all Big Brother vi users will be forced to retaliate ;) ]] --__--__-- Message: 5 From: "Todd Owen" <to...@da...> To: <php...@li...> Subject: Re: [Phpwebsite-developers] Roadmap Date: Fri, 30 Mar 2001 09:39:04 -0500 Organization: Data Dynamix Reply-To: php...@li... 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 --__--__-- Message: 6 From: "clayton collie" <cc...@ca...> To: <php...@li...> Subject: [Phpwebsite-developers] Good Feature to Consider [long] Date: Fri, 30 Mar 2001 10:00:19 -0500 Reply-To: php...@li... This is long, so bear with me ... in my portal seeking travels, i ran across TerraCotta (www.terracottasoftware.com) which provides basic infrastucture for site-building. the docs make for good reading. they have a few very interesting features (one of which is that you can automatically download and install features from other terracotta sites - dont ask me about security) in any case one of the issues i was contemplating was one of module dependencies (actually there are two levels of dependency, but i'll just deal with one) lets say david d. developer creates a plugin which mails out notices when concerts are added to the event calendar. well as it stands, we would have to go in and modify the calendar code to accomodate this. also, if he wants to give the 1000th registered member a free subscription to his dead-tree magazine, he'd have to muck about in the code again. and what if he decides to yank the calendar plugin ? well then youve got orphan DB entries to deal with and your other plugins will crash and burn expecting to find something that aint there. one way to handle this is by Alerts ( TC's description and implementation details at www.terracottasoftware.com/tc/doc/alerts ). basically you register interest in events with a callback. when those events occur, your code gets called. these "events" are stored in the database, and you can set up a cron job to process them. they have urgency levels, so a low-disk quota event would get handled before user registration event. They can also be filtered. so in our example the calendar module would call a raise_event() function whenever someone added a new entry (events have associated data, so you can store details). The registration module can raise an event when someone registers. Alerts can get expensive, so we dont do them for very frequently occurring events. Also for efficiency purposes, we can have an events_registered field in the plugins table so that a plugin only needs to raise an event if someone is interested. <question to self>then again, can we manage all of this via cron? but this way we have a greater level control which we can exercise via a web interface</question> just a thought... BTW PHPWeblog uses their html parser to screen user posts. it has a configurable level of screening. Their "Views" feature is an interesting take on block content handling. We should probably look a this too. ----- Original Message ----- From: "Mike Windsor" <wi...@ce...> To: <php...@li...> Sent: Thursday, 29. March 2001 22:16 Subject: [Phpwebsite-developers] Roadmap > Hey, > Was there a meeting scheduled for tomorrow? Is it still on? Will a decision > "roadmap" be laid out tomorrow on March 30? > Just wondering when we will get some direction? Not that I will be much > help but I would like to know if I should continue to follow this project or > find another. Although I have limited code knowledge I would like to began > to learn something maybe about plugins. I've looked at some of the plugins > now and see a little bit about how they work, but it sounds like it might > get changed around a bit. > I've talked to other people who have made forums or weather scripts or > financial scripts and I convinced some of them to take a look at phpWebSite, > they and I believe that the first plugin in any category will more than > likely be the standad in the beginning which will bring more people to their > own script and improve it. I think if you end up debating on the best > approach to long many are going to lose interest and go with the next > version of nuke5 that is going to have "modules", and this project will > lose out. I understand things like this take planning and so forth, but my > wish would be for a very well thought out decision done in a timely matter. > Hopefully we get a sense of direction by this weekend. > Anyway, I'll just sit here with my sharp stick and prod you along <g> > > > winzor > (wanna be) > > > > ----- Original Message ----- > From: "Spiggy TheCat" <th...@me...> > To: <php...@li...> > Sent: Thursday, March 29, 2001 8:14 PM > Subject: [Phpwebsite-developers] about mysql (slightly OT) > > > > people who checked the openacs site, might have stumbled into this (rather > > lengthy with all the comments) article. people at openacs seem to be > really > > against mysql. > > > > http://openacs.org/philosophy/why-not-mysql.html > > > > paivi > > > > > > _______________________________________________ > > Phpwebsite-developers mailing list > > Php...@li... > > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > > > > > > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers --__--__-- Message: 7 From: "clayton collie" <cc...@ca...> To: <php...@li...> Subject: Re: [Phpwebsite-developers] Integrated User/Group & Permissions Date: Fri, 30 Mar 2001 10:09:53 -0500 Reply-To: php...@li... Alain, > http://www.phpsecurepages.f2s.com/ > > This looks really good ! yes, but the problem is granularity. this only deals with coarse-grained, page-level access. we need (i think) a generalized system to deal with arbitrary objects in the system (can user x or group g do y with object a) ----- Original Message ----- From: "Alain Fontaine" <al...@va...> To: <php...@li...> Sent: Thursday, 29. March 2001 17:29 Subject: RE: [Phpwebsite-developers] Integrated User/Group & Permissions > Hi, > > http://www.phpsecurepages.f2s.com/ > > This looks really good ! > > Take a look. > > Alain > > > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers --__--__-- Message: 8 From: "Todd Owen" <to...@da...> To: <php...@li...> Subject: Re: [Phpwebsite-developers] Integrated User/Group & Permissions Date: Fri, 30 Mar 2001 10:43:54 -0500 Organization: Data Dynamix Reply-To: php...@li... > yes, but the problem is granularity. this only deals with coarse-grained, > page-level access. we need (i think) a generalized system to deal with > arbitrary objects in the system (can user x or group g do y with object a) I agree that we need per object instance level access control. This means that you may only have one forum plug-in, which the site admin gets to control, but two forum instances that require separate access control by different users. This is part of my roadmap. --Todd --__--__-- Message: 9 From: Frits Jensen <FJ...@uv...> To: "'php...@li...'" <php...@li...> Subject: SV: [Phpwebsite-developers] Roadmap Date: Fri, 30 Mar 2001 17:31:22 +0200 Reply-To: php...@li... 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 > --__--__-- Message: 10 Date: Fri, 30 Mar 2001 18:16:03 +0200 From: Karsten Dambekalns <k.d...@tu...> To: php...@li... Subject: Re: [Phpwebsite-developers] Good Feature to Consider [long] Organization: fishfarm Reply-To: php...@li... --jKBxcB1XkHIR0Eqt Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 30, 2001 at 10:00:19AM -0500, clayton collie wrote: > one way to handle this is by Alerts ( TC's description and implementation > details at www.terracottasoftware.com/tc/doc/alerts ). basically you > register interest in events with a callback. when those events occur, your Another source of information about his is the excellent book by Till Gerken "Web Application Development with PHP4" published by New Riders. He describes the callback system used in phpChat - which can be downloaded at http://www.phpwizard.net/ and also is a good reading :-) There we could look at callback functionality realized in PHP... Regards, Karsten --=20 Why do we have to hide from the police, daddy? Because we use emacs, son. They use vi. ----------------------------- mailto:k.d...@tu... w=B3: http://www.k-fish.de/ gpg: http://www.k-fish.de/mykeys.gpg --jKBxcB1XkHIR0Eqt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1e-SuSE (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6xLFCzmcQByaBiO8RAn5VAJ44jPcWgPuqg3jK9t5x2vK1rRQmRgCfeGWT H5oZ3kjEWCgP7AYD8YyFo2I= =rX7E -----END PGP SIGNATURE----- --jKBxcB1XkHIR0Eqt-- --__--__-- _______________________________________________ Phpwebsite-developers mailing list Php...@li... http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers End of Phpwebsite-developers Digest |
