From dirk at haun-online.de Wed Dec 1 15:58:06 2004 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 1 Dec 2004 21:58:06 +0100 Subject: [geeklog-devel] Another SpamX Message-ID: <20041201205806.11344@smtp.haun-online.de> It seems someone else also came up with the name "SpamX": http://www.hendricom.com/ I don't see any claims that it's a registered trademark, though. bye, Dirk -- http://www.haun-online.de/ http://www.macosx-faq.de/ From vfuria at gmail.com Wed Dec 1 16:09:47 2004 From: vfuria at gmail.com (Vincent Furia) Date: Wed, 1 Dec 2004 16:09:47 -0500 Subject: [geeklog-devel] Another SpamX In-Reply-To: <20041201205806.11344@smtp.haun-online.de> References: <20041201205806.11344@smtp.haun-online.de> Message-ID: <8319e2d6041201130969423cf5@mail.gmail.com> A search of the US Trademark database didn't turn up any matches. We can always start calling it "Geeklog's SpamX". -Vinny On Wed, 1 Dec 2004 21:58:06 +0100, Dirk Haun wrote: > It seems someone else also came up with the name "SpamX": > > http://www.hendricom.com/ > > I don't see any claims that it's a registered trademark, though. > > bye, Dirk > > -- > http://www.haun-online.de/ > http://www.macosx-faq.de/ > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tomw at pigstye.net Wed Dec 1 16:19:34 2004 From: tomw at pigstye.net (Tom) Date: Wed, 1 Dec 2004 16:19:34 -0500 Subject: [geeklog-devel] Another SpamX In-Reply-To: <8319e2d6041201130969423cf5@mail.gmail.com> Message-ID: Call it whatever -----Original Message----- From: geeklog-devel-admin at lists.geeklog.net [mailto:geeklog-devel-admin at lists.geeklog.net]On Behalf Of Vincent Furia Sent: Wednesday, December 01, 2004 4:10 PM To: geeklog-devel at lists.geeklog.net Subject: Re: [geeklog-devel] Another SpamX A search of the US Trademark database didn't turn up any matches. We can always start calling it "Geeklog's SpamX". -Vinny On Wed, 1 Dec 2004 21:58:06 +0100, Dirk Haun wrote: > It seems someone else also came up with the name "SpamX": > > http://www.hendricom.com/ > > I don't see any claims that it's a registered trademark, though. > > bye, Dirk > > -- > http://www.haun-online.de/ > http://www.macosx-faq.de/ > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.289 / Virus Database: 265.4.4 - Release Date: 11/30/2004 From euan at heatherengineering.com Wed Dec 1 19:58:05 2004 From: euan at heatherengineering.com (Euan McKay) Date: Thu, 2 Dec 2004 09:58:05 +0900 Subject: [geeklog-devel] 1.3.10 and Asian languages problem Message-ID: <394C80E0-43FD-11D9-88CC-000D9339F3E2@heatherengineering.com> Dirk, I just got an email from Sam Stone pointing out a problem with double-byte languages (at least for Japanese and Chinese). UTF8 works fine for Japanese, not sure about Chinese. However, saving stories in HTML mode in Japanese EUC encoding and Chinese encodings causes text to be corrupted. Saving in normal text mode works fine, so I guess this must be a problem with a filter somewhere? Sorry for not noticing this in the RC versions - I'll make a point of testing them more thoroughly in the future. Cheers, Euan. ************************************************* Heather Engineering - no job too small http://www.heatherengineering.com/ info at heatherengineering.com/ ************************************************* From tony at tonybibbs.com Thu Dec 2 09:50:14 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 02 Dec 2004 08:50:14 -0600 Subject: [geeklog-devel] Another SpamX In-Reply-To: References: Message-ID: <41AF2BA6.7020100@tonybibbs.com> Call it "Please-stop-spamming-my-blog-you-f8cker-x" Very descriptive and highly doubt it that someone else would come up with it. --Tony Tom wrote: >Call it whatever > >-----Original Message----- >From: geeklog-devel-admin at lists.geeklog.net >[mailto:geeklog-devel-admin at lists.geeklog.net]On Behalf Of Vincent Furia >Sent: Wednesday, December 01, 2004 4:10 PM >To: geeklog-devel at lists.geeklog.net >Subject: Re: [geeklog-devel] Another SpamX > > >A search of the US Trademark database didn't turn up any matches. We >can always start calling it "Geeklog's SpamX". > >-Vinny > > >On Wed, 1 Dec 2004 21:58:06 +0100, Dirk Haun wrote: > > >>It seems someone else also came up with the name "SpamX": >> >> http://www.hendricom.com/ >> >>I don't see any claims that it's a registered trademark, though. >> >>bye, Dirk >> >>-- >>http://www.haun-online.de/ >>http://www.macosx-faq.de/ >> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > >-- >No virus found in this incoming message. >Checked by AVG Anti-Virus. >Version: 7.0.289 / Virus Database: 265.4.4 - Release Date: 11/30/2004 > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From tomw at pigstye.net Thu Dec 2 10:03:03 2004 From: tomw at pigstye.net (Tom) Date: Thu, 2 Dec 2004 10:03:03 -0500 Subject: [geeklog-devel] Another SpamX In-Reply-To: <41AF2BA6.7020100@tonybibbs.com> Message-ID: I like that one ;) Tom Tony wrote: Call it "Please-stop-spamming-my-blog-you-f8cker-x" Very descriptive and highly doubt it that someone else would come up with it. --Tony Tom wrote: >Call it whatever > >-----Original Message----- >From: geeklog-devel-admin at lists.geeklog.net >[mailto:geeklog-devel-admin at lists.geeklog.net]On Behalf Of Vincent Furia >Sent: Wednesday, December 01, 2004 4:10 PM >To: geeklog-devel at lists.geeklog.net >Subject: Re: [geeklog-devel] Another SpamX > > >A search of the US Trademark database didn't turn up any matches. We >can always start calling it "Geeklog's SpamX". > >-Vinny > > >On Wed, 1 Dec 2004 21:58:06 +0100, Dirk Haun wrote: > > >>It seems someone else also came up with the name "SpamX": >> >> http://www.hendricom.com/ >> >>I don't see any claims that it's a registered trademark, though. >> >>bye, Dirk >> >>-- >>http://www.haun-online.de/ >>http://www.macosx-faq.de/ >> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > >-- >No virus found in this incoming message. >Checked by AVG Anti-Virus. >Version: 7.0.289 / Virus Database: 265.4.4 - Release Date: 11/30/2004 > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.289 / Virus Database: 265.4.4 - Release Date: 11/30/2004 From tony at tonybibbs.com Thu Dec 2 10:41:31 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 02 Dec 2004 09:41:31 -0600 Subject: [geeklog-devel] Geeklog 2 Framework Code in Action In-Reply-To: <8319e2d6041201094577a3f41@mail.gmail.com> References: <41A384D7.9020206@tonybibbs.com> <8319e2d6041201094577a3f41@mail.gmail.com> Message-ID: <41AF37AB.1060709@tonybibbs.com> For time sake I have attached the code I have already. The code is for a sample Hunting Log Book application. It has a little bit of everything but is far from complete. I'm sending this because Vinny is chompin' at the bit to get started. I wrote this sample application to demonstrate a few things: 1) use of MVCnPHP and how it allows us to generate small, atomic and easily managed code. 2) use of Propel...without it the code would be at least 300% bigger 3) use of a Data Access Object. This object uses propel and hides the propel details from the developer for the most part. Thus GL2 developers should have to write very little SQL 4) use of named queries 5) use of the PEAR::HTML_Template_Flexy engine 6) concepts on how to do data validation and formating in this new paradigm. I'm not 100% satisfied with what I have but it is a step in the direction I think it should go. 7) This shows the use of a List Of Values table. It is a single table that can be reused to multiple times for look up values. This is probably something many of you are familiar with but I wanted to point this out because it reduces the number of data structures we'd need considerably since look-up tables can now all reside in a single table structure. As you view this, *please* ignore the layout...I'm not a layout guy. Here are the things worth noting. First, don't look into the underlying framework code too much until you get a feel for the basic code. Specifically, your first gander should focus on code in the following directories: /path/to/HuntingLog/commands /path/to/HuntingLog/views /path/to/HuntingLog/templates That's where the magic happens. The commands and views directory are where the MVCnPHP commands and views go respectively. Take time to notice and, hopefully, appreciate how little code exists in many of them. Granted my sample application is quite trivial, but try and draw comparison's to how much code you would write to do the same thing with the 1.3.x code. After you do that, there are some abstract classes in each of those directories that so some basic setup stuff. You should look into those and understand them as we'll need to The templates directory is where the Flexy templates go. The layout I have defined in this app doesn't support the notion of a theme...I can add that later with little trouble as it is just a matter of how we want to layout the directories. I haven't exercised all the features of flexy in the views I have but it does do the most common things. Flexy works quite differently from PHPLib that 1.3.x so I would read up on the documentation for it. You'll notice this code in the commands and views have absolutely no SQL in them. Propel should generate 90% of the SQL and the other 10% must go into the /path/to/system/Data_Access/NamedQueries.xml. I'm sure there will be a debate as to why all custom SQL must go in an XML file so here are a few reasons: 1) Cleaner code in the commands/views. It isn't muddled with SQL 2) Having the SQL in a single file allows us to reuse queries and gives us a single place for making modifcations should the DB structures change. 3) The biggest benefit which isn't implemented yet, is that I can use the queries in that XML file and generate a single PHPUnit2 script that would regression test all the queries with a single command. This is a huge time saver in the case where we have massive structure updates that will undoubtedly happen during alpha development. Again, this isn't implemented but I'm working on it now. Also missing from this implementation is the ability to allow more than one query XML file. This will be required for plugins as it will allow them to manage their own file for named queries seperate form those used by the core GL2 kernel. Here are the crude instructions for installing this. NOTE: Phing is not required but Propel is because I haven't packaged the code into this tarball. In the first GL2 alpha we'd obviously fix that but I don't want anyone freaking about about requireing Propel. Oh, and you'll notice Propel requires Phing...this is only for doing builds. I've already done the build for the app in this case. If you want a copy of this tarball modified to include the Propel code please let me know...I'd be more than happy to do it since installing Propel can be a bit tricky. 1) Make sure you have PHP5 ;-) 2) unpack into webtree 3) Make sure you have a version of MySQL that supports INNODB and foreign keys. 4) create a database for this sample app 5) Import /path/to/HuntingLog/data/create.sql into your database 6) edit config.php to match your system 7) edit the database settings in /path/to/HuntingLog/system/Propel/HuntingLog-conf.php 8) Now open browser and point it to index.php Please only review it for the features I have noted. This is meant to be a throw away prototype and I assume we'll make many changes in the short term to the framework. By all means fire over any questions. If you have no questions but get it installed successfully even letting me know you got it installed would be nice. --Tony -------------- next part -------------- A non-text attachment was scrubbed... Name: HuntingLog.tar.gz Type: application/gzip Size: 117195 bytes Desc: not available URL: From geeklog at langfamily.ca Thu Dec 2 10:47:49 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Thu, 2 Dec 2004 10:47:49 -0500 Subject: [geeklog-devel] Geeklog 2 Framework Code in Action References: <41A384D7.9020206@tonybibbs.com> <8319e2d6041201094577a3f41@mail.gmail.com> <41AF37AB.1060709@tonybibbs.com> Message-ID: <012501c4d886$46abad90$650a10ac@XPBL2> Looks good Tony .. and I will try to get it installed over the next week to check it out. It certainly looks like a lot of work has been completed. Cheers and I'll let you know how it goes. Blaine ----- Original Message ----- From: "Tony Bibbs" To: Sent: Thursday, December 02, 2004 10:41 AM Subject: [geeklog-devel] Geeklog 2 Framework Code in Action For time sake I have attached the code I have already. The code is for a sample Hunting Log Book application. It has a little bit of everything but is far from complete. I'm sending this because Vinny is chompin' at the bit to get started. I wrote this sample application to demonstrate a few things: 1) use of MVCnPHP and how it allows us to generate small, atomic and easily managed code. 2) use of Propel...without it the code would be at least 300% bigger 3) use of a Data Access Object. This object uses propel and hides the propel details from the developer for the most part. Thus GL2 developers should have to write very little SQL 4) use of named queries 5) use of the PEAR::HTML_Template_Flexy engine 6) concepts on how to do data validation and formating in this new paradigm. I'm not 100% satisfied with what I have but it is a step in the direction I think it should go. 7) This shows the use of a List Of Values table. It is a single table that can be reused to multiple times for look up values. This is probably something many of you are familiar with but I wanted to point this out because it reduces the number of data structures we'd need considerably since look-up tables can now all reside in a single table structure. As you view this, *please* ignore the layout...I'm not a layout guy. Here are the things worth noting. First, don't look into the underlying framework code too much until you get a feel for the basic code. Specifically, your first gander should focus on code in the following directories: /path/to/HuntingLog/commands /path/to/HuntingLog/views /path/to/HuntingLog/templates That's where the magic happens. The commands and views directory are where the MVCnPHP commands and views go respectively. Take time to notice and, hopefully, appreciate how little code exists in many of them. Granted my sample application is quite trivial, but try and draw comparison's to how much code you would write to do the same thing with the 1.3.x code. After you do that, there are some abstract classes in each of those directories that so some basic setup stuff. You should look into those and understand them as we'll need to The templates directory is where the Flexy templates go. The layout I have defined in this app doesn't support the notion of a theme...I can add that later with little trouble as it is just a matter of how we want to layout the directories. I haven't exercised all the features of flexy in the views I have but it does do the most common things. Flexy works quite differently from PHPLib that 1.3.x so I would read up on the documentation for it. You'll notice this code in the commands and views have absolutely no SQL in them. Propel should generate 90% of the SQL and the other 10% must go into the /path/to/system/Data_Access/NamedQueries.xml. I'm sure there will be a debate as to why all custom SQL must go in an XML file so here are a few reasons: 1) Cleaner code in the commands/views. It isn't muddled with SQL 2) Having the SQL in a single file allows us to reuse queries and gives us a single place for making modifcations should the DB structures change. 3) The biggest benefit which isn't implemented yet, is that I can use the queries in that XML file and generate a single PHPUnit2 script that would regression test all the queries with a single command. This is a huge time saver in the case where we have massive structure updates that will undoubtedly happen during alpha development. Again, this isn't implemented but I'm working on it now. Also missing from this implementation is the ability to allow more than one query XML file. This will be required for plugins as it will allow them to manage their own file for named queries seperate form those used by the core GL2 kernel. Here are the crude instructions for installing this. NOTE: Phing is not required but Propel is because I haven't packaged the code into this tarball. In the first GL2 alpha we'd obviously fix that but I don't want anyone freaking about about requireing Propel. Oh, and you'll notice Propel requires Phing...this is only for doing builds. I've already done the build for the app in this case. If you want a copy of this tarball modified to include the Propel code please let me know...I'd be more than happy to do it since installing Propel can be a bit tricky. 1) Make sure you have PHP5 ;-) 2) unpack into webtree 3) Make sure you have a version of MySQL that supports INNODB and foreign keys. 4) create a database for this sample app 5) Import /path/to/HuntingLog/data/create.sql into your database 6) edit config.php to match your system 7) edit the database settings in /path/to/HuntingLog/system/Propel/HuntingLog-conf.php 8) Now open browser and point it to index.php Please only review it for the features I have noted. This is meant to be a throw away prototype and I assume we'll make many changes in the short term to the framework. By all means fire over any questions. If you have no questions but get it installed successfully even letting me know you got it installed would be nice. --Tony From justin.carlson at gmail.com Thu Dec 2 10:54:30 2004 From: justin.carlson at gmail.com (Justin Carlson) Date: Thu, 2 Dec 2004 09:54:30 -0600 Subject: [geeklog-devel] Another SpamX In-Reply-To: References: <41AF2BA6.7020100@tonybibbs.com> Message-ID: <3d1a3f4e0412020754681038d7@mail.gmail.com> Take any of the following: Spam, Geek, Log, Comment, Post, Ad Add any of the following: Shield, Guard, Guardian, Bouncer, Fortify GeekGuard, Comment Bouncer, Post Shield Eh maybe it sounded better in my mind. On Thu, 2 Dec 2004 10:03:03 -0500, Tom wrote: > I like that one ;) > > Tom > > > > Tony wrote: > > Call it "Please-stop-spamming-my-blog-you-f8cker-x" > > Very descriptive and highly doubt it that someone else would come up > with it. > > --Tony > > Tom wrote: > > >Call it whatever > > > >-----Original Message----- > >From: geeklog-devel-admin at lists.geeklog.net > >[mailto:geeklog-devel-admin at lists.geeklog.net]On Behalf Of Vincent Furia > >Sent: Wednesday, December 01, 2004 4:10 PM > >To: geeklog-devel at lists.geeklog.net > >Subject: Re: [geeklog-devel] Another SpamX > > > > > >A search of the US Trademark database didn't turn up any matches. We > >can always start calling it "Geeklog's SpamX". > > > >-Vinny > > > > > >On Wed, 1 Dec 2004 21:58:06 +0100, Dirk Haun wrote: > > > > > >>It seems someone else also came up with the name "SpamX": > >> > >> http://www.hendricom.com/ > >> > >>I don't see any claims that it's a registered trademark, though. > >> > >>bye, Dirk > >> > >>-- > >>http://www.haun-online.de/ > >>http://www.macosx-faq.de/ > >> > >>_______________________________________________ > >>geeklog-devel mailing list > >>geeklog-devel at lists.geeklog.net > >>http://lists.geeklog.net/listinfo/geeklog-devel > >> > >> > >> > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > >-- > >No virus found in this incoming message. > >Checked by AVG Anti-Virus. > >Version: 7.0.289 / Virus Database: 265.4.4 - Release Date: 11/30/2004 > > > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > > -- > > > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.289 / Virus Database: 265.4.4 - Release Date: 11/30/2004 > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Thu Dec 2 11:30:19 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 02 Dec 2004 10:30:19 -0600 Subject: [geeklog-devel] Geeklog 2 Framework Code in Action In-Reply-To: <012501c4d886$46abad90$650a10ac@XPBL2> References: <41A384D7.9020206@tonybibbs.com> <8319e2d6041201094577a3f41@mail.gmail.com> <41AF37AB.1060709@tonybibbs.com> <012501c4d886$46abad90$650a10ac@XPBL2> Message-ID: <41AF431B.6060700@tonybibbs.com> Also worth noting for you plugin developers is that you don't have to use MVCnPHP nor Propel. In fact, unless you have a 'big' plugin (i.e. articles, forum, calendar, etc) you probably won't want to use MVCnPHP. The use of Propel is encouraged, especially for anyone who will contribute a large number of plugins as it will save you a lot of time once you've learned how to use it. Strictly from a maintenance standpoint, though, I'd still encourage anyone willing to use both to do so. For anyone not using Propel, you can get a handle to a database connection object and issue raw SQL right there. --Tony Blaine Lang wrote: >Looks good Tony .. and I will try to get it installed over the next week to >check it out. >It certainly looks like a lot of work has been completed. > >Cheers and I'll let you know how it goes. >Blaine >----- Original Message ----- >From: "Tony Bibbs" >To: >Sent: Thursday, December 02, 2004 10:41 AM >Subject: [geeklog-devel] Geeklog 2 Framework Code in Action > > >For time sake I have attached the code I have already. The code is for >a sample Hunting Log Book application. It has a little bit of everything >but is far from complete. I'm sending this because Vinny is chompin' at >the bit to get started. I wrote this sample application to demonstrate >a few things: > >1) use of MVCnPHP and how it allows us to generate small, atomic and >easily managed code. >2) use of Propel...without it the code would be at least 300% bigger >3) use of a Data Access Object. This object uses propel and hides the >propel details from the developer for the most part. Thus GL2 >developers should have to write very little SQL >4) use of named queries >5) use of the PEAR::HTML_Template_Flexy engine >6) concepts on how to do data validation and formating in this new >paradigm. I'm not 100% satisfied with what I have but it is a step in >the direction I think it should go. >7) This shows the use of a List Of Values table. It is a single table >that can be reused to multiple times for look up values. This is >probably something many of you are familiar with but I wanted to point >this out because it reduces the number of data structures we'd need >considerably since look-up tables can now all reside in a single table >structure. > >As you view this, *please* ignore the layout...I'm not a layout guy. >Here are the things worth noting. > >First, don't look into the underlying framework code too much until you >get a feel for the basic code. Specifically, your first gander should >focus on code in the following directories: > >/path/to/HuntingLog/commands >/path/to/HuntingLog/views >/path/to/HuntingLog/templates > >That's where the magic happens. The commands and views directory are >where the MVCnPHP commands and views go respectively. Take time to >notice and, hopefully, appreciate how little code exists in many of >them. Granted my sample application is quite trivial, but try and draw >comparison's to how much code you would write to do the same thing with >the 1.3.x code. After you do that, there are some abstract classes in >each of those directories that so some basic setup stuff. You should >look into those and understand them as we'll need to > >The templates directory is where the Flexy templates go. The layout I >have defined in this app doesn't support the notion of a theme...I can >add that later with little trouble as it is just a matter of how we want >to layout the directories. I haven't exercised all the features of >flexy in the views I have but it does do the most common things. Flexy >works quite differently from PHPLib that 1.3.x so I would read up on the >documentation for it. > >You'll notice this code in the commands and views have absolutely no SQL >in them. Propel should generate 90% of the SQL and the other 10% must >go into the /path/to/system/Data_Access/NamedQueries.xml. I'm sure >there will be a debate as to why all custom SQL must go in an XML file >so here are a few reasons: > >1) Cleaner code in the commands/views. It isn't muddled with SQL >2) Having the SQL in a single file allows us to reuse queries and gives >us a single place for making modifcations should the DB structures change. >3) The biggest benefit which isn't implemented yet, is that I can use >the queries in that XML file and generate a single PHPUnit2 script that >would regression test all the queries with a single command. This is a >huge time saver in the case where we have massive structure updates that >will undoubtedly happen during alpha development. Again, this isn't >implemented but I'm working on it now. > >Also missing from this implementation is the ability to allow more than >one query XML file. This will be required for plugins as it will allow >them to manage their own file for named queries seperate form those used >by the core GL2 kernel. > >Here are the crude instructions for installing this. NOTE: Phing is not >required but Propel is because I haven't packaged the code into this >tarball. In the first GL2 alpha we'd obviously fix that but I don't want >anyone freaking about about requireing Propel. Oh, and you'll notice >Propel requires Phing...this is only for doing builds. I've already >done the build for the app in this case. If you want a copy of this >tarball modified to include the Propel code please let me know...I'd be >more than happy to do it since installing Propel can be a bit tricky. > >1) Make sure you have PHP5 ;-) >2) unpack into webtree >3) Make sure you have a version of MySQL that supports INNODB and >foreign keys. >4) create a database for this sample app >5) Import /path/to/HuntingLog/data/create.sql into your database >6) edit config.php to match your system >7) edit the database settings in >/path/to/HuntingLog/system/Propel/HuntingLog-conf.php >8) Now open browser and point it to index.php > >Please only review it for the features I have noted. This is meant to >be a throw away prototype and I assume we'll make many changes in the >short term to the framework. By all means fire over any questions. If >you have no questions but get it installed successfully even letting me >know you got it installed would be nice. > >--Tony > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From dirk at haun-online.de Tue Dec 7 13:59:28 2004 From: dirk at haun-online.de (Dirk Haun) Date: Tue, 7 Dec 2004 19:59:28 +0100 Subject: [geeklog-devel] Fwd: GL2 Feature Request Message-ID: <20041207185928.5426@smtp.haun-online.de> ---------------- Anfang Weiterleitung ---------------- Betreff: GL2 Feature Request Gesendet: Dienstag, 7. Dezember 2004 11:53 Uhr Von: John Serrao An: Dirk Haun Hello Dirk - >From what I can tell you are kinda in charge of Geeklog - its an awesome piece of software so good job. Ive noticed you guys are going to a new version and had a discussion about new features people might want to see - well i thought of one. I deployed your system for this non-profit group and no one over there knows anything about HTML so it has put a large administrative burden on me that I had never intended. Everytime they want to add an HTML page its a disaster area. Ive made them 2-3 HTML templates with 8000 comments on them but they are still confused often. They deal with globalization issues so they are publishing news almost daily but it kinda falls outside of the blog-sphere so they like to add them as static pages. They are nice people so its no big deal to help them a bit (takes me like 2 seconds) but I see a way around this. I ran into this product some other people use for super simple HTML additions to a website that is dumbed down enough for people who don't know any HTML. It was called City Desk - I found it on the net here: http://www.fogcreek.com/CityDesk/index.html Anyway, watch that demo they offer - the program appears to set up a PHP template and then drops the HTML stories into it as needed. I think Geeklog could do something like this - like a little link in the admin section that says "Static Page additions for people who dont know HTML" - you click on it and you can just drop text into a file that then drops the text into a pre-determined template. It probably wouldnt even be that difficult to pull off - considering i think thats what GL does now with the blog-side of the software (but im not really sure) Maybe this is a bit out of the scope of what you guys are trying to do but Ive seen other GL installs for organizations that probably face the same problems that I do. I bet this would be a huge help to many. Great product - keep up the work. If you need some help doing something not too terribly technical I would gladly offer some assistance. John Serrao ----------------- Ende Weiterleitung ----------------- -- http://www.haun-online.de/ http://mypod.de/ From dirk at haun-online.de Tue Dec 7 14:40:26 2004 From: dirk at haun-online.de (Dirk Haun) Date: Tue, 7 Dec 2004 20:40:26 +0100 Subject: [geeklog-devel] Anyone have PHP 4.1.x? Message-ID: <20041207194026.509@smtp.haun-online.de> Does anyone here have a server that's still running PHP 4.1.x? Apparently, there's a problem getting PEAR to work on PHP 4.1.x, see . There's also a forum thread that I can't find at the moment ... The problem, as I remember, was that PEAR uses a function that only exists as of PHP 4.2.0. And I think there was a PEAR package that you could install to overcome this. I wanted to look into this, but couldn't even get PHP 4.1.2 to compile on the only spare machine I have at the moment, so I was wondering if any of you still had access to such a beast. bye, Dirk -- http://www.haun-online.de/ http://www.tinyweb.de/ From tomw at pigstye.net Tue Dec 7 14:56:51 2004 From: tomw at pigstye.net (Tom) Date: Tue, 7 Dec 2004 14:56:51 -0500 Subject: [geeklog-devel] Anyone have PHP 4.1.x? In-Reply-To: <20041207194026.509@smtp.haun-online.de> Message-ID: My old server is running 4.1.2. I don't really have time to mess with it, but if you want I can set up web and shell access for you. Email me if so. TomW -----Original Message----- From: geeklog-devel-admin at lists.geeklog.net [mailto:geeklog-devel-admin at lists.geeklog.net]On Behalf Of Dirk Haun Sent: Tuesday, December 07, 2004 2:40 PM To: geeklog-devel at lists.geeklog.net Subject: [geeklog-devel] Anyone have PHP 4.1.x? Does anyone here have a server that's still running PHP 4.1.x? Apparently, there's a problem getting PEAR to work on PHP 4.1.x, see . There's also a forum thread that I can't find at the moment ... The problem, as I remember, was that PEAR uses a function that only exists as of PHP 4.2.0. And I think there was a PEAR package that you could install to overcome this. I wanted to look into this, but couldn't even get PHP 4.1.2 to compile on the only spare machine I have at the moment, so I was wondering if any of you still had access to such a beast. bye, Dirk -- http://www.haun-online.de/ http://www.tinyweb.de/ _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Tue Dec 7 15:18:51 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 07 Dec 2004 14:18:51 -0600 Subject: [geeklog-devel] Nobody got it working? Message-ID: <41B6102B.8010406@tonybibbs.com> Anybody get that sample app with most of the GL2 framework in it working? I really need some validation from the group and community before I can, in good faith, continue. Vinny, I got your message...just give it a whirl when you find time. --Tony From vfuria at gmail.com Tue Dec 7 16:18:31 2004 From: vfuria at gmail.com (Vincent Furia) Date: Tue, 7 Dec 2004 16:18:31 -0500 Subject: [geeklog-devel] Nobody got it working? In-Reply-To: <41B6102B.8010406@tonybibbs.com> References: <41B6102B.8010406@tonybibbs.com> Message-ID: <8319e2d604120713185906c5fb@mail.gmail.com> Tony, I got it working, but I haven't spend time yet studying the code. I'll get you some decent input soon I hope. -Vinny On Tue, 07 Dec 2004 14:18:51 -0600, Tony Bibbs wrote: > Anybody get that sample app with most of the GL2 framework in it working? > > I really need some validation from the group and community before I can, > in good faith, continue. > > Vinny, I got your message...just give it a whirl when you find time. > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From dirk at haun-online.de Wed Dec 8 01:57:44 2004 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 8 Dec 2004 07:57:44 +0100 Subject: [geeklog-devel] Nobody got it working? In-Reply-To: <41B6102B.8010406@tonybibbs.com> References: <41B6102B.8010406@tonybibbs.com> Message-ID: <20041208065744.14353@smtp.haun-online.de> Tony, >Anybody get that sample app with most of the GL2 framework in it working? Yeah, sorry. I said I would try it out but haven't ... So much to do, so little time ... bye, Dirk -- http://www.haun-online.de/ http://www.macosx-faq.de/ From tony at tonybibbs.com Thu Dec 9 15:18:02 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 09 Dec 2004 14:18:02 -0600 Subject: [geeklog-devel] Forum request Message-ID: <41B8B2FA.3060706@tonybibbs.com> I have a strong need for the ability for one registered use of the forum to ignore another user of the forum. As you know, banning techniques aren't that great so if I had this tool, my members could simply click a link to ignore someone. Only issue would be preventing somone from posting a link that would inadvertently force someone to be ignored. And, to that point, this must allow the ability to unban someone. This is less important for the 1.3.x core, IMHO, but might be desireable for others there as well. --Tony From tony at tonybibbs.com Thu Dec 9 20:49:34 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 09 Dec 2004 19:49:34 -0600 Subject: [geeklog-devel] Here I sit... Message-ID: <41B900AE.50808@tonybibbs.com> Here I sit, broken hearted. Came to code but only farted. My keyboard here is about to explode...because nobody has yet to review my code. From geeklog at langfamily.ca Thu Dec 9 21:55:45 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Thu, 9 Dec 2004 21:55:45 -0500 Subject: [geeklog-devel] Here I sit... References: <41B900AE.50808@tonybibbs.com> Message-ID: <18b201c4de63$be8fa4f0$650a10ac@XPBL2> Aren't we the clever one :) I only wish your code was as good as your poetry ;) It's on my list really .... hehe, Blaine ----- Original Message ----- From: "Tony Bibbs" To: Sent: Thursday, December 09, 2004 8:49 PM Subject: [geeklog-devel] Here I sit... Here I sit, broken hearted. Came to code but only farted. My keyboard here is about to explode...because nobody has yet to review my code. _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From dirk at haun-online.de Fri Dec 10 13:21:12 2004 From: dirk at haun-online.de (Dirk Haun) Date: Fri, 10 Dec 2004 19:21:12 +0100 Subject: [geeklog-devel] Bugs in 1.3.10 Message-ID: <20041210182112.27229@smtp.haun-online.de> Okay, the first bug reports for 1.3.10 are in. Nothing dramatic, but quite a few minor things. Looks like our next goal should be a bugfix release, i.e. 1.3.10-1. I've already fixed a few "easy" ones in CVS and will start looking into the others over the weekend. I don't plan to rush this one out and I'm not opposed to tossing in a few (minor) improvements or new features as well. Is anyone aware of any problems that are not listed in the bugtracker? Yes, Vinny, I remember the bit about magic_quotes_qpc and the What's Related links. Blaine, I had to undo the change you made to search.php that disallowed empty search query strings since it broke the "More by " and "More from " options. If you'd like to submit another fix for the problem you originally tried to fix here, please take these into account. Also, Blaine, I see you mentioned you had a fix for the archive templates being used prematurely? And finally, a coding note: Since we've raised the minimum requirements to PHP 4.1.0 now, all new code should use the $_GET, $_POST, and $_REQUEST arrays instead of $HTTP_GET_VARS and $HTTP_POST_VARS. bye, Dirk -- http://www.haun-online.de/ http://www.macosx-faq.de/ From tony at tonybibbs.com Fri Dec 10 17:15:15 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 10 Dec 2004 16:15:15 -0600 Subject: [geeklog-devel] Framework Message-ID: <41BA1FF3.70101@tonybibbs.com> I know you are all busy and that some of you still hope to review the code I sent over. In the interest of getting some sort of feedback I have released the code on geeklog.net: http://www.geeklog.net/article.php/GL2FrameworkCode Just an FYI --Tony From geeklog at langfamily.ca Fri Dec 10 19:07:19 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Fri, 10 Dec 2004 19:07:19 -0500 Subject: [geeklog-devel] Framework References: <41BA1FF3.70101@tonybibbs.com> Message-ID: <015e01c4df15$61f5c320$650a10ac@XPBL2> Tony, It appears the link to your code in that article is not working. Blaine ----- Original Message ----- From: "Tony Bibbs" To: Sent: Friday, December 10, 2004 5:15 PM Subject: [geeklog-devel] Framework I know you are all busy and that some of you still hope to review the code I sent over. In the interest of getting some sort of feedback I have released the code on geeklog.net: http://www.geeklog.net/article.php/GL2FrameworkCode Just an FYI --Tony _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Fri Dec 10 19:21:42 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 10 Dec 2004 18:21:42 -0600 Subject: [geeklog-devel] Framework In-Reply-To: <015e01c4df15$61f5c320$650a10ac@XPBL2> References: <41BA1FF3.70101@tonybibbs.com> <015e01c4df15$61f5c320$650a10ac@XPBL2> Message-ID: <41BA3D96.2080103@tonybibbs.com> Fixed. Thanks. --Tony Blaine Lang wrote: >Tony, > >It appears the link to your code in that article is not working. > >Blaine >----- Original Message ----- >From: "Tony Bibbs" >To: >Sent: Friday, December 10, 2004 5:15 PM >Subject: [geeklog-devel] Framework > > >I know you are all busy and that some of you still hope to review the >code I sent over. In the interest of getting some sort of feedback I >have released the code on geeklog.net: > >http://www.geeklog.net/article.php/GL2FrameworkCode > >Just an FYI > >--Tony >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From geeklog at langfamily.ca Fri Dec 10 22:30:58 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Fri, 10 Dec 2004 22:30:58 -0500 Subject: [geeklog-devel] Framework References: <41BA1FF3.70101@tonybibbs.com> <015e01c4df15$61f5c320$650a10ac@XPBL2> <41BA3D96.2080103@tonybibbs.com> Message-ID: <000f01c4df31$d4856500$650a10ac@XPBL2> Tony, Well, I after more then an hour I still don't have it running. Been tracking down the source of multiple path related issues and there appears to be no end. I can't get the include path in php.ini to work and had to edit paths in the files. [edit] source to this is noted at end of this message - Install propel and that required the PEAR Log class. - Install PEAR flexy But I've been editing some dozen files in the archive you sent for the app as expected paths are not working and I just restored it as is. Still more changes need - example: Warning: main(HuntingLog/om/BaseHlUser.php) [function.main]: failed to open stream: No such file or directory in g:\www2root\HuntingLog\system\Propel\HuntingLog\HlUser.php on line 2 Line 2 is: require_once 'HuntingLog/om/BaseHlUser.php'; The H1User.php is in the HuntingLog/system/Propel/HuntingLog folder and the om folder is below this. So not sure why the include has the HuntingLog directory I made a bunch of changes prior to this as well - I was just trying to make it work. Example: Index.php - line 4: The includes.php is not in the pubic_html folder. Fix that and then line 5 has an error. I did this as noted for about a dozen files and I'm still not done. I set $hlConf['path'] and $hlConf['site_url'] So what did I do wrong or is wrong ? BTW: This is what was messing up my php.ini setting for the includes setting: The line at the end of the config.php to set the include_path - should that not be with a ; instead of a : ini_set('include_path', ini_get('include_path') . ";{$hlConf['path']}:{$hlConf['path_system']}"); Blaine From vfuria at gmail.com Fri Dec 10 22:52:17 2004 From: vfuria at gmail.com (Vincent Furia) Date: Fri, 10 Dec 2004 22:52:17 -0500 Subject: [geeklog-devel] Framework In-Reply-To: <000f01c4df31$d4856500$650a10ac@XPBL2> References: <41BA1FF3.70101@tonybibbs.com> <015e01c4df15$61f5c320$650a10ac@XPBL2> <41BA3D96.2080103@tonybibbs.com> <000f01c4df31$d4856500$650a10ac@XPBL2> Message-ID: <8319e2d60412101952527b3825@mail.gmail.com> Blaine, (Tony,) I had to mess around a lot with the paths as well to get things working (though I did finally get things working). I had to edit config.php and then I had to add the path /path/to/HuntingLog/system/Propel to the include path. I did this by adding it into the ini_set in config.php. Hopefully that will get you up and running. Once you figure out _everything_ (and that is a lot) things will start to make sense. I'm kind of afraid we're going to make development too hard for dabblers. If we go this route, we'll need to come up with some simple way to add basic functionality. I have been looking at it Tony. I'll have more input soon. Promise. -Vinny On Fri, 10 Dec 2004 22:30:58 -0500, Blaine Lang wrote: > Tony, > > Well, I after more then an hour I still don't have it running. Been tracking > down the source of multiple path related issues and there appears to be no > end. > > I can't get the include path in php.ini to work and had to edit paths in the > files. > [edit] source to this is noted at end of this message > > - Install propel and that required the PEAR Log class. > - Install PEAR flexy > > But I've been editing some dozen files in the archive you sent for the app > as expected paths are not working and I just restored it as is. > Still more changes need - example: > > Warning: main(HuntingLog/om/BaseHlUser.php) [function.main]: failed to open > stream: No such file or directory in > g:\www2root\HuntingLog\system\Propel\HuntingLog\HlUser.php on line 2 > > Line 2 is: > require_once 'HuntingLog/om/BaseHlUser.php'; > > The H1User.php is in the HuntingLog/system/Propel/HuntingLog folder and the > om folder is below this. > So not sure why the include has the HuntingLog directory > > I made a bunch of changes prior to this as well - I was just trying to make > it work. > Example: > > Index.php - line 4: > The includes.php is not in the pubic_html folder. > > Fix that and then line 5 has an error. > > I did this as noted for about a dozen files and I'm still not done. > > I set $hlConf['path'] and $hlConf['site_url'] > > So what did I do wrong or is wrong ? > > BTW: This is what was messing up my php.ini setting for the includes > setting: > The line at the end of the config.php to set the include_path - should that > not be with a ; instead of a : > ini_set('include_path', ini_get('include_path') . > ";{$hlConf['path']}:{$hlConf['path_system']}"); > > Blaine > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Sat Dec 11 10:29:50 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Sat, 11 Dec 2004 09:29:50 -0600 Subject: [geeklog-devel] Framework In-Reply-To: <8319e2d60412101952527b3825@mail.gmail.com> References: <41BA1FF3.70101@tonybibbs.com> <015e01c4df15$61f5c320$650a10ac@XPBL2> <41BA3D96.2080103@tonybibbs.com> <000f01c4df31$d4856500$650a10ac@XPBL2> <8319e2d60412101952527b3825@mail.gmail.com> Message-ID: <41BB126E.9090809@tonybibbs.com> Yeah, keep in mind that I could have included propel's classes in the tarball which would have made most of your battles a mute point. I'll probably do that form now on. It shouldn't be too hard for dabblers until they get to the point they want to start doing their own database changes...that's where using Propel in conjunction with Phing comes in. Despite that, I think this is something we can document well enough to get people moving along. Fire over any additional questions. --Tony Vincent Furia wrote: >Blaine, (Tony,) > >I had to mess around a lot with the paths as well to get things >working (though I did finally get things working). I had to edit >config.php and then I had to add the path >/path/to/HuntingLog/system/Propel to the include path. I did this by >adding it into the ini_set in config.php. > >Hopefully that will get you up and running. Once you figure out >_everything_ (and that is a lot) things will start to make sense. I'm >kind of afraid we're going to make development too hard for dabblers. >If we go this route, we'll need to come up with some simple way to add >basic functionality. > >I have been looking at it Tony. I'll have more input soon. Promise. > >-Vinny > > >On Fri, 10 Dec 2004 22:30:58 -0500, Blaine Lang wrote: > > >>Tony, >> >>Well, I after more then an hour I still don't have it running. Been tracking >>down the source of multiple path related issues and there appears to be no >>end. >> >>I can't get the include path in php.ini to work and had to edit paths in the >>files. >>[edit] source to this is noted at end of this message >> >>- Install propel and that required the PEAR Log class. >>- Install PEAR flexy >> >>But I've been editing some dozen files in the archive you sent for the app >>as expected paths are not working and I just restored it as is. >>Still more changes need - example: >> >>Warning: main(HuntingLog/om/BaseHlUser.php) [function.main]: failed to open >>stream: No such file or directory in >>g:\www2root\HuntingLog\system\Propel\HuntingLog\HlUser.php on line 2 >> >>Line 2 is: >>require_once 'HuntingLog/om/BaseHlUser.php'; >> >>The H1User.php is in the HuntingLog/system/Propel/HuntingLog folder and the >>om folder is below this. >>So not sure why the include has the HuntingLog directory >> >>I made a bunch of changes prior to this as well - I was just trying to make >>it work. >>Example: >> >>Index.php - line 4: >>The includes.php is not in the pubic_html folder. >> >>Fix that and then line 5 has an error. >> >>I did this as noted for about a dozen files and I'm still not done. >> >>I set $hlConf['path'] and $hlConf['site_url'] >> >>So what did I do wrong or is wrong ? >> >>BTW: This is what was messing up my php.ini setting for the includes >>setting: >>The line at the end of the config.php to set the include_path - should that >>not be with a ; instead of a : >>ini_set('include_path', ini_get('include_path') . >>";{$hlConf['path']}:{$hlConf['path_system']}"); >> >>Blaine >> >> >> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From geeklog at langfamily.ca Sat Dec 11 10:37:21 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Sat, 11 Dec 2004 10:37:21 -0500 Subject: [geeklog-devel] Framework References: <41BA1FF3.70101@tonybibbs.com> <015e01c4df15$61f5c320$650a10ac@XPBL2> <41BA3D96.2080103@tonybibbs.com> <000f01c4df31$d4856500$650a10ac@XPBL2> <8319e2d60412101952527b3825@mail.gmail.com> <41BB126E.9090809@tonybibbs.com> Message-ID: <004c01c4df97$4e5dea90$650a10ac@XPBL2> Tony, Actually getting propel installed was the easiest of the tasks. Read my note all the way - I note the real issues with the archive as I see them. Blaine ----- Original Message ----- From: "Tony Bibbs" To: Sent: Saturday, December 11, 2004 10:29 AM Subject: Re: [geeklog-devel] Framework Yeah, keep in mind that I could have included propel's classes in the tarball which would have made most of your battles a mute point. I'll probably do that form now on. It shouldn't be too hard for dabblers until they get to the point they want to start doing their own database changes...that's where using Propel in conjunction with Phing comes in. Despite that, I think this is something we can document well enough to get people moving along. Fire over any additional questions. --Tony Vincent Furia wrote: >Blaine, (Tony,) > >I had to mess around a lot with the paths as well to get things >working (though I did finally get things working). I had to edit >config.php and then I had to add the path >/path/to/HuntingLog/system/Propel to the include path. I did this by >adding it into the ini_set in config.php. > >Hopefully that will get you up and running. Once you figure out >_everything_ (and that is a lot) things will start to make sense. I'm >kind of afraid we're going to make development too hard for dabblers. >If we go this route, we'll need to come up with some simple way to add >basic functionality. > >I have been looking at it Tony. I'll have more input soon. Promise. > >-Vinny > > >On Fri, 10 Dec 2004 22:30:58 -0500, Blaine Lang >wrote: > > >>Tony, >> >>Well, I after more then an hour I still don't have it running. Been >>tracking >>down the source of multiple path related issues and there appears to be no >>end. >> >>I can't get the include path in php.ini to work and had to edit paths in >>the >>files. >>[edit] source to this is noted at end of this message >> >>- Install propel and that required the PEAR Log class. >>- Install PEAR flexy >> >>But I've been editing some dozen files in the archive you sent for the app >>as expected paths are not working and I just restored it as is. >>Still more changes need - example: >> >>Warning: main(HuntingLog/om/BaseHlUser.php) [function.main]: failed to >>open >>stream: No such file or directory in >>g:\www2root\HuntingLog\system\Propel\HuntingLog\HlUser.php on line 2 >> >>Line 2 is: >>require_once 'HuntingLog/om/BaseHlUser.php'; >> >>The H1User.php is in the HuntingLog/system/Propel/HuntingLog folder and >>the >>om folder is below this. >>So not sure why the include has the HuntingLog directory >> >>I made a bunch of changes prior to this as well - I was just trying to >>make >>it work. >>Example: >> >>Index.php - line 4: >>The includes.php is not in the pubic_html folder. >> >>Fix that and then line 5 has an error. >> >>I did this as noted for about a dozen files and I'm still not done. >> >>I set $hlConf['path'] and $hlConf['site_url'] >> >>So what did I do wrong or is wrong ? >> >>BTW: This is what was messing up my php.ini setting for the includes >>setting: >>The line at the end of the config.php to set the include_path - should >>that >>not be with a ; instead of a : >>ini_set('include_path', ini_get('include_path') . >>";{$hlConf['path']}:{$hlConf['path_system']}"); >> >>Blaine >> >> >> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Sat Dec 11 11:18:19 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Sat, 11 Dec 2004 10:18:19 -0600 Subject: [geeklog-devel] Framework In-Reply-To: <004c01c4df97$4e5dea90$650a10ac@XPBL2> References: <41BA1FF3.70101@tonybibbs.com> <015e01c4df15$61f5c320$650a10ac@XPBL2> <41BA3D96.2080103@tonybibbs.com> <000f01c4df31$d4856500$650a10ac@XPBL2> <8319e2d60412101952527b3825@mail.gmail.com> <41BB126E.9090809@tonybibbs.com> <004c01c4df97$4e5dea90$650a10ac@XPBL2> Message-ID: <41BB1DCB.4080608@tonybibbs.com> I'll just package propel in with the tarball and redistribute. Give me a little bit. --Tony Blaine Lang wrote: >Tony, > >Actually getting propel installed was the easiest of the tasks. >Read my note all the way - I note the real issues with the archive as I see >them. > >Blaine >----- Original Message ----- >From: "Tony Bibbs" >To: >Sent: Saturday, December 11, 2004 10:29 AM >Subject: Re: [geeklog-devel] Framework > > >Yeah, keep in mind that I could have included propel's classes in the >tarball which would have made most of your battles a mute point. I'll >probably do that form now on. It shouldn't be too hard for dabblers >until they get to the point they want to start doing their own database >changes...that's where using Propel in conjunction with Phing comes in. >Despite that, I think this is something we can document well enough to >get people moving along. > >Fire over any additional questions. > >--Tony > >Vincent Furia wrote: > > > >>Blaine, (Tony,) >> >>I had to mess around a lot with the paths as well to get things >>working (though I did finally get things working). I had to edit >>config.php and then I had to add the path >>/path/to/HuntingLog/system/Propel to the include path. I did this by >>adding it into the ini_set in config.php. >> >>Hopefully that will get you up and running. Once you figure out >>_everything_ (and that is a lot) things will start to make sense. I'm >>kind of afraid we're going to make development too hard for dabblers. >>If we go this route, we'll need to come up with some simple way to add >>basic functionality. >> >>I have been looking at it Tony. I'll have more input soon. Promise. >> >>-Vinny >> >> >>On Fri, 10 Dec 2004 22:30:58 -0500, Blaine Lang >>wrote: >> >> >> >> >>>Tony, >>> >>>Well, I after more then an hour I still don't have it running. Been >>>tracking >>>down the source of multiple path related issues and there appears to be no >>>end. >>> >>>I can't get the include path in php.ini to work and had to edit paths in >>>the >>>files. >>>[edit] source to this is noted at end of this message >>> >>>- Install propel and that required the PEAR Log class. >>>- Install PEAR flexy >>> >>>But I've been editing some dozen files in the archive you sent for the app >>>as expected paths are not working and I just restored it as is. >>>Still more changes need - example: >>> >>>Warning: main(HuntingLog/om/BaseHlUser.php) [function.main]: failed to >>>open >>>stream: No such file or directory in >>>g:\www2root\HuntingLog\system\Propel\HuntingLog\HlUser.php on line 2 >>> >>>Line 2 is: >>>require_once 'HuntingLog/om/BaseHlUser.php'; >>> >>>The H1User.php is in the HuntingLog/system/Propel/HuntingLog folder and >>>the >>>om folder is below this. >>>So not sure why the include has the HuntingLog directory >>> >>>I made a bunch of changes prior to this as well - I was just trying to >>>make >>>it work. >>>Example: >>> >>>Index.php - line 4: >>>The includes.php is not in the pubic_html folder. >>> >>>Fix that and then line 5 has an error. >>> >>>I did this as noted for about a dozen files and I'm still not done. >>> >>>I set $hlConf['path'] and $hlConf['site_url'] >>> >>>So what did I do wrong or is wrong ? >>> >>>BTW: This is what was messing up my php.ini setting for the includes >>>setting: >>>The line at the end of the config.php to set the include_path - should >>>that >>>not be with a ; instead of a : >>>ini_set('include_path', ini_get('include_path') . >>>";{$hlConf['path']}:{$hlConf['path_system']}"); >>> >>>Blaine >>> >>> >>> >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >> > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From tony at tonybibbs.com Sat Dec 11 11:49:54 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Sat, 11 Dec 2004 10:49:54 -0600 Subject: [geeklog-devel] Framework In-Reply-To: <41BB1DCB.4080608@tonybibbs.com> References: <41BA1FF3.70101@tonybibbs.com> <015e01c4df15$61f5c320$650a10ac@XPBL2> <41BA3D96.2080103@tonybibbs.com> <000f01c4df31$d4856500$650a10ac@XPBL2> <8319e2d60412101952527b3825@mail.gmail.com> <41BB126E.9090809@tonybibbs.com> <004c01c4df97$4e5dea90$650a10ac@XPBL2> <41BB1DCB.4080608@tonybibbs.com> Message-ID: <41BB2532.1020404@tonybibbs.com> Ok, the new tarball only requires the path to PEAR be in your include_path. As a result of this, the tarball now includes the propel base classes. In otherwords, this should require no include_path editing. Please try again: http://www.tonybibbs.com/HuntingLog.tar.gz Sorry, should have done this from square one in the interest of time. --Tony Tony Bibbs wrote: > I'll just package propel in with the tarball and redistribute. Give > me a little bit. > > --Tony > > Blaine Lang wrote: > >> Tony, >> >> Actually getting propel installed was the easiest of the tasks. >> Read my note all the way - I note the real issues with the archive as >> I see them. >> >> Blaine >> ----- Original Message ----- From: "Tony Bibbs" >> To: >> Sent: Saturday, December 11, 2004 10:29 AM >> Subject: Re: [geeklog-devel] Framework >> >> >> Yeah, keep in mind that I could have included propel's classes in the >> tarball which would have made most of your battles a mute point. I'll >> probably do that form now on. It shouldn't be too hard for dabblers >> until they get to the point they want to start doing their own database >> changes...that's where using Propel in conjunction with Phing comes in. >> Despite that, I think this is something we can document well enough to >> get people moving along. >> >> Fire over any additional questions. >> >> --Tony >> >> Vincent Furia wrote: >> >> >> >>> Blaine, (Tony,) >>> >>> I had to mess around a lot with the paths as well to get things >>> working (though I did finally get things working). I had to edit >>> config.php and then I had to add the path >>> /path/to/HuntingLog/system/Propel to the include path. I did this by >>> adding it into the ini_set in config.php. >>> >>> Hopefully that will get you up and running. Once you figure out >>> _everything_ (and that is a lot) things will start to make sense. I'm >>> kind of afraid we're going to make development too hard for dabblers. >>> If we go this route, we'll need to come up with some simple way to add >>> basic functionality. >>> >>> I have been looking at it Tony. I'll have more input soon. Promise. >>> >>> -Vinny >>> >>> >>> On Fri, 10 Dec 2004 22:30:58 -0500, Blaine Lang >>> wrote: >>> >>> >>> >>> >>>> Tony, >>>> >>>> Well, I after more then an hour I still don't have it running. Been >>>> tracking >>>> down the source of multiple path related issues and there appears >>>> to be no >>>> end. >>>> >>>> I can't get the include path in php.ini to work and had to edit >>>> paths in the >>>> files. >>>> [edit] source to this is noted at end of this message >>>> >>>> - Install propel and that required the PEAR Log class. >>>> - Install PEAR flexy >>>> >>>> But I've been editing some dozen files in the archive you sent for >>>> the app >>>> as expected paths are not working and I just restored it as is. >>>> Still more changes need - example: >>>> >>>> Warning: main(HuntingLog/om/BaseHlUser.php) [function.main]: failed >>>> to open >>>> stream: No such file or directory in >>>> g:\www2root\HuntingLog\system\Propel\HuntingLog\HlUser.php on line 2 >>>> >>>> Line 2 is: >>>> require_once 'HuntingLog/om/BaseHlUser.php'; >>>> >>>> The H1User.php is in the HuntingLog/system/Propel/HuntingLog folder >>>> and the >>>> om folder is below this. >>>> So not sure why the include has the HuntingLog directory >>>> >>>> I made a bunch of changes prior to this as well - I was just trying >>>> to make >>>> it work. >>>> Example: >>>> >>>> Index.php - line 4: >>>> The includes.php is not in the pubic_html folder. >>>> >>>> Fix that and then line 5 has an error. >>>> >>>> I did this as noted for about a dozen files and I'm still not done. >>>> >>>> I set $hlConf['path'] and $hlConf['site_url'] >>>> >>>> So what did I do wrong or is wrong ? >>>> >>>> BTW: This is what was messing up my php.ini setting for the includes >>>> setting: >>>> The line at the end of the config.php to set the include_path - >>>> should that >>>> not be with a ; instead of a : >>>> ini_set('include_path', ini_get('include_path') . >>>> ";{$hlConf['path']}:{$hlConf['path_system']}"); >>>> >>>> Blaine >>>> >>>> >>>> >>>> _______________________________________________ >>>> geeklog-devel mailing list >>>> geeklog-devel at lists.geeklog.net >>>> http://lists.geeklog.net/listinfo/geeklog-devel >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> geeklog-devel mailing list >>> geeklog-devel at lists.geeklog.net >>> http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >> >> >> _______________________________________________ >> geeklog-devel mailing list >> geeklog-devel at lists.geeklog.net >> http://lists.geeklog.net/listinfo/geeklog-devel >> _______________________________________________ >> geeklog-devel mailing list >> geeklog-devel at lists.geeklog.net >> http://lists.geeklog.net/listinfo/geeklog-devel >> >> > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Sun Dec 12 15:24:46 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Sun, 12 Dec 2004 14:24:46 -0600 Subject: [geeklog-devel] Framework In-Reply-To: <004c01c4df97$4e5dea90$650a10ac@XPBL2> References: <41BA1FF3.70101@tonybibbs.com> <015e01c4df15$61f5c320$650a10ac@XPBL2> <41BA3D96.2080103@tonybibbs.com> <000f01c4df31$d4856500$650a10ac@XPBL2> <8319e2d60412101952527b3825@mail.gmail.com> <41BB126E.9090809@tonybibbs.com> <004c01c4df97$4e5dea90$650a10ac@XPBL2> Message-ID: <41BCA90E.5040407@tonybibbs.com> Anybody have better luck with the new tarball? --Tony Blaine Lang wrote: >Tony, > >Actually getting propel installed was the easiest of the tasks. >Read my note all the way - I note the real issues with the archive as I see >them. > >Blaine >----- Original Message ----- >From: "Tony Bibbs" >To: >Sent: Saturday, December 11, 2004 10:29 AM >Subject: Re: [geeklog-devel] Framework > > >Yeah, keep in mind that I could have included propel's classes in the >tarball which would have made most of your battles a mute point. I'll >probably do that form now on. It shouldn't be too hard for dabblers >until they get to the point they want to start doing their own database >changes...that's where using Propel in conjunction with Phing comes in. >Despite that, I think this is something we can document well enough to >get people moving along. > >Fire over any additional questions. > >--Tony > >Vincent Furia wrote: > > > >>Blaine, (Tony,) >> >>I had to mess around a lot with the paths as well to get things >>working (though I did finally get things working). I had to edit >>config.php and then I had to add the path >>/path/to/HuntingLog/system/Propel to the include path. I did this by >>adding it into the ini_set in config.php. >> >>Hopefully that will get you up and running. Once you figure out >>_everything_ (and that is a lot) things will start to make sense. I'm >>kind of afraid we're going to make development too hard for dabblers. >>If we go this route, we'll need to come up with some simple way to add >>basic functionality. >> >>I have been looking at it Tony. I'll have more input soon. Promise. >> >>-Vinny >> >> >>On Fri, 10 Dec 2004 22:30:58 -0500, Blaine Lang >>wrote: >> >> >> >> >>>Tony, >>> >>>Well, I after more then an hour I still don't have it running. Been >>>tracking >>>down the source of multiple path related issues and there appears to be no >>>end. >>> >>>I can't get the include path in php.ini to work and had to edit paths in >>>the >>>files. >>>[edit] source to this is noted at end of this message >>> >>>- Install propel and that required the PEAR Log class. >>>- Install PEAR flexy >>> >>>But I've been editing some dozen files in the archive you sent for the app >>>as expected paths are not working and I just restored it as is. >>>Still more changes need - example: >>> >>>Warning: main(HuntingLog/om/BaseHlUser.php) [function.main]: failed to >>>open >>>stream: No such file or directory in >>>g:\www2root\HuntingLog\system\Propel\HuntingLog\HlUser.php on line 2 >>> >>>Line 2 is: >>>require_once 'HuntingLog/om/BaseHlUser.php'; >>> >>>The H1User.php is in the HuntingLog/system/Propel/HuntingLog folder and >>>the >>>om folder is below this. >>>So not sure why the include has the HuntingLog directory >>> >>>I made a bunch of changes prior to this as well - I was just trying to >>>make >>>it work. >>>Example: >>> >>>Index.php - line 4: >>>The includes.php is not in the pubic_html folder. >>> >>>Fix that and then line 5 has an error. >>> >>>I did this as noted for about a dozen files and I'm still not done. >>> >>>I set $hlConf['path'] and $hlConf['site_url'] >>> >>>So what did I do wrong or is wrong ? >>> >>>BTW: This is what was messing up my php.ini setting for the includes >>>setting: >>>The line at the end of the config.php to set the include_path - should >>>that >>>not be with a ; instead of a : >>>ini_set('include_path', ini_get('include_path') . >>>";{$hlConf['path']}:{$hlConf['path_system']}"); >>> >>>Blaine >>> >>> >>> >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >> > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From tony at tonybibbs.com Mon Dec 13 11:07:15 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 13 Dec 2004 10:07:15 -0600 Subject: [geeklog-devel] GL2 Framework Message-ID: <41BDBE33.9080406@tonybibbs.com> I've yet to hear anything substantive since the original 12/2 email I sent on the topic. In the interest of time I'm going to move on but it is worth noting one thing. The GL2 progress has been embarassingly slow. I take full accountablity for this. This latest effort to move forward on the codebase will be my last. ..if things stagnate again I will formally put my GL coding days behind me and leave the entire long term vision of GL to Dirk. To help keep things moving I am hoping to delegate as much work as possible to those with more time...however you might note that quality help is a rare commodity. The progress that can be made is directly tied the help I cant count on. I've had a number of nibbles from people willing to help but none of them panned out, nearly all sighting time commitments. So to expand on what I have already said, unless I can get other developers to devote some amount of time to GL2 I will need to officially kill the notion of GL2. To that end I am setting a Februrary 1st deadline for myself and any that choose to help on producing the complete GL2 framework code so that plugin development can begin. Anything short of that I will view as failure. I've cc'd the users mailing list in the hopes that some on that list might consider contributing to GL2. My apologies if this all sounded a bit dramatic...I simply wanted to, one last time, assert my hopes to get the project moving and my willingness to step aside for the lack of progress. --Tony From dirk at haun-online.de Mon Dec 13 13:18:01 2004 From: dirk at haun-online.de (Dirk Haun) Date: Mon, 13 Dec 2004 19:18:01 +0100 Subject: [geeklog-devel] Framework In-Reply-To: <41BCA90E.5040407@tonybibbs.com> References: <41BCA90E.5040407@tonybibbs.com> Message-ID: <20041213181801.29291@smtp.haun-online.de> >Anybody have better luck with the new tarball? I got it to work eventually (with the new tarball and after installing the Creole, Flexy, and Log packages). Well, sort of - can't add any new hunts ("Cannot add or update a child row: a foreign key constraint fails") but the rest seems to work. Plain-text passwords in the database? Tsk, tsk, ... ;-) I agree that it's really nice to see how much it does with that small amount of code (your code, that is[1]) which is typical for good OO-based designs. But this needs a *good* set of development docs to get people started (myself included ...). bye, Dirk [1] You need a a huge amount of 3rd party code as compared to the code that actually makes up the application. But that ratio would get better when you're actually developing an application as big as Geeklog. This is obvious, I guess - just wanted to point it out again :-) -- http://www.haun-online.de/ http://geeklog.info/ From tony at tonybibbs.com Mon Dec 13 13:49:48 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 13 Dec 2004 12:49:48 -0600 Subject: [geeklog-devel] Framework In-Reply-To: <20041213181801.29291@smtp.haun-online.de> References: <41BCA90E.5040407@tonybibbs.com> <20041213181801.29291@smtp.haun-online.de> Message-ID: <41BDE44C.4060202@tonybibbs.com> Dirk Haun wrote: >I got it to work eventually (with the new tarball and after installing >the Creole, Flexy, and Log packages). > Yeah, I'll add a comment about those. I should have included Creole in with the Propel stuff so that would go away in a 'real' application. Obviously the Flexy/Log stuff would need to work similar to 1.3.x where you can get all required 3rd party code in a tarball or install it yourself via 'pear install'. >Well, sort of - can't add any new >hunts ("Cannot add or update a child row: a foreign key constraint >fails") but the rest seems to work. > > I'll recheck the create.sql and make sure I haven't made any changes. This should work for the most part. >Plain-text passwords in the database? Tsk, tsk, ... ;-) > > Yeah, just didn't want to fight with MD5's while building it ;-) >I agree that it's really nice to see how much it does with that small >amount of code (your code, that is[1]) which is typical for good OO-based >designs. But this needs a *good* set of development docs to get people >started (myself included ...). > > I agree on the docs portion of it. I guess I was hoping on some initial feedback before I put the time needed to do the development documents together. Didn't want to make that investment if it got picked apart too bad. Did you have any input on the use of MVC, Propel or the Data Access Layer? Also, any thoughts on how Flexy was used? Any input for or against would be nice. >[1] You need a a huge amount of 3rd party code as compared to the code >that actually makes up the application. But that ratio would get better >when you're actually developing an application as big as Geeklog. This is >obvious, I guess - just wanted to point it out again :-) > > Right, the Propel/Creole code along with the PEAR libraries are going to make up for a fairly substantial amount of the total code. Good thing, though, is it is code wouldn't have to maintain. Thanks for taking a look, --Tony From tony at tonybibbs.com Mon Dec 13 14:01:07 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 13 Dec 2004 13:01:07 -0600 Subject: [geeklog-devel] Namespaces Message-ID: <41BDE6F3.7040301@tonybibbs.com> GL2 will need to be careful with namespaces because of it's object oriented nature. I'd like to propose that we follow the PEAR model for name our classes. To illustrate here is an example. All core Geeklog code would start with the Geeklog_ prefix in their class names. Thus the draft of the plugin API that Vinny created would be named Geeklog_PluginInterface. It would reside, however, in a file simply called PluginInterface.php in the system directory for Geeklog 2. Plugins would use their own namespace so, for example, the forum plugins would use something like Forum_ as the prefix for all it's code. The obvious problems with namespaces is GL2 will need to officially track and manage the namespaces...this involves allowing plugin developers to register a namespace effectively reserving it for their exclusive use. This isn't terribly different than the notion of plugin names in GL 1.3.x. I wanted to throw this in for dicussion as this will need to be finalized and documented well early on. --Tony From dirk at haun-online.de Mon Dec 13 14:05:39 2004 From: dirk at haun-online.de (Dirk Haun) Date: Mon, 13 Dec 2004 20:05:39 +0100 Subject: [geeklog-devel] GL2 Framework In-Reply-To: <41BDBE33.9080406@tonybibbs.com> References: <41BDBE33.9080406@tonybibbs.com> Message-ID: <20041213190539.30096@smtp.haun-online.de> Tony, >if things stagnate again I >will formally put my GL coding days behind me and leave the entire long >term vision of GL to Dirk. Hmm, but GL2 is my long-term vision ... I mean, looking back, I didn't originally plan to get involved in GL development as much as I am now. And I was always hoping to hand Geeklog back to you at one point - once GL2 has reached a certain stage. I can see enough potential in 1.3 to go for another year or maybe even 2, but eventually it will have to be replaced with something new. And I don't feel like I could develop a new system from scratch - I just don't have the time for that. You can always count on me for GL2 module development, but I'd happily leave the core development in someone else's hands ... bye, Dirk -- http://www.haun-online.de/ http://www.haun.info/ From tony at tonybibbs.com Mon Dec 13 14:31:10 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 13 Dec 2004 13:31:10 -0600 Subject: [geeklog-devel] Look-up Tables in GL2 Message-ID: <41BDEDFE.1060500@tonybibbs.com> Today in GL 1.3.x we have a number of look up tables (e.g. gl_postmodes, gl_cookiecodes, gl_featurecodes, etc). All nearly look exactly the same in terms of their structure but they serve wildly different needs. In GL2 I'm proposing we use a single table to serve all those needs. This isn't anything 'new' in concept but it is new to GL. Anyway I call this table the List_of_Values table and it would look roughly like this: CREATE TABLE list_of_values ( lov_id int(10) unsigned NOT NULL auto_increment, group_name varchar (30) NOT NULL, short_name varchar(30) NOT NULL, description varchar(128), enabled tinyint(1) NOT NULL DEFAULT '1', sort_order mediumint(10) NOT NULL DEFAULT '0', PRIMARY KEY (lov_id), INDEX (group_name) ) TYPE=INNODB; I don't think there will be much argument over the structure but I wanted to make sure this made sense to everybody. The issue I really wanted to discuss was one brought up by someone recently (name escapes me) on how to handle the translation of text stored in drop downs. I have been assuming we would pipe the text in the actual database table through our translation library...seems simple enough but I wanted to make sure I wasn't over looking anything. --Tony From tony at tonybibbs.com Mon Dec 13 14:39:26 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 13 Dec 2004 13:39:26 -0600 Subject: [geeklog-devel] GL2 Framework In-Reply-To: <20041213190539.30096@smtp.haun-online.de> References: <41BDBE33.9080406@tonybibbs.com> <20041213190539.30096@smtp.haun-online.de> Message-ID: <41BDEFEE.7090905@tonybibbs.com> >Hmm, but GL2 is my long-term vision ... > > That's good to know. I thought that is where you stood but I didn't want to make any assumptions at this point considering how long things have gone since I first proposed starting GL2 to now. >I can see enough potential in 1.3 to go for another year or maybe even 2, >but eventually it will have to be replaced with something new. And I >don't feel like I could develop a new system from scratch - I just don't >have the time for that. > > That is my exact dilemna. So this raises the question I think I posed a long time ago which is shouldn't we consider drawing a line in the sand where we only do bugs, security fixes and minor enhancments to 1.3.x and focus all our attention on 2.x? I think the general concensus at the time was that was a good idea but we simply didn't develop this into a real plan. I think a real plan would involve mapping out the remaining tasks you'd like to see done in 1.3.x and partitioning those out into a set of releases with some loose target dates. That would allow us to do some real planning for GL2. >You can always count on me for GL2 module development, but I'd happily >leave the core development in someone else's hands ... > > Good. You know it's funny how things evolved. I got into GL similar to the way you did which ended up being a full range of duties that were, at the time, easier to manage because I had 'extra' time. I think all of us core developers have similar issues so I think if we could simply figure out how to focus our energies into GL2 in an organized way we could really get a lot done. Of course, I'd like us to add a few new developers as well... Thanks for the input. It should stir up some conversation. --Tony From geeklog at langfamily.ca Mon Dec 13 15:16:24 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Mon, 13 Dec 2004 15:16:24 -0500 Subject: [geeklog-devel] Framework References: <41BA1FF3.70101@tonybibbs.com> <015e01c4df15$61f5c320$650a10ac@XPBL2> <41BA3D96.2080103@tonybibbs.com> <000f01c4df31$d4856500$650a10ac@XPBL2> <8319e2d60412101952527b3825@mail.gmail.com> <41BB126E.9090809@tonybibbs.com> <004c01c4df97$4e5dea90$650a10ac@XPBL2> <41BCA90E.5040407@tonybibbs.com> Message-ID: <01dd01c4e150$9e8758c0$650a10ac@XPBL2> Tony, I had much better luck with this archive. I still had to modify your ini set line in the config.php to use a ; instead of a : as a path delimiter. I can now have a look at the code as it's quite a change architecturally but I like the concepts. I'm sure it pays off once you get over the learning curve and have the codebase in place. Blaine ----- Original Message ----- From: "Tony Bibbs" To: Sent: Sunday, December 12, 2004 3:24 PM Subject: Re: [geeklog-devel] Framework Anybody have better luck with the new tarball? --Tony Blaine Lang wrote: >Tony, > >Actually getting propel installed was the easiest of the tasks. >Read my note all the way - I note the real issues with the archive as I see >them. > >Blaine >----- Original Message ----- >From: "Tony Bibbs" >To: >Sent: Saturday, December 11, 2004 10:29 AM >Subject: Re: [geeklog-devel] Framework > > >Yeah, keep in mind that I could have included propel's classes in the >tarball which would have made most of your battles a mute point. I'll >probably do that form now on. It shouldn't be too hard for dabblers >until they get to the point they want to start doing their own database >changes...that's where using Propel in conjunction with Phing comes in. >Despite that, I think this is something we can document well enough to >get people moving along. > >Fire over any additional questions. > >--Tony > >Vincent Furia wrote: > > > >>Blaine, (Tony,) >> >>I had to mess around a lot with the paths as well to get things >>working (though I did finally get things working). I had to edit >>config.php and then I had to add the path >>/path/to/HuntingLog/system/Propel to the include path. I did this by >>adding it into the ini_set in config.php. >> >>Hopefully that will get you up and running. Once you figure out >>_everything_ (and that is a lot) things will start to make sense. I'm >>kind of afraid we're going to make development too hard for dabblers. >>If we go this route, we'll need to come up with some simple way to add >>basic functionality. >> >>I have been looking at it Tony. I'll have more input soon. Promise. >> >>-Vinny >> >> >>On Fri, 10 Dec 2004 22:30:58 -0500, Blaine Lang >>wrote: >> >> >> >> >>>Tony, >>> >>>Well, I after more then an hour I still don't have it running. Been >>>tracking >>>down the source of multiple path related issues and there appears to be >>>no >>>end. >>> >>>I can't get the include path in php.ini to work and had to edit paths in >>>the >>>files. >>>[edit] source to this is noted at end of this message >>> >>>- Install propel and that required the PEAR Log class. >>>- Install PEAR flexy >>> >>>But I've been editing some dozen files in the archive you sent for the >>>app >>>as expected paths are not working and I just restored it as is. >>>Still more changes need - example: >>> >>>Warning: main(HuntingLog/om/BaseHlUser.php) [function.main]: failed to >>>open >>>stream: No such file or directory in >>>g:\www2root\HuntingLog\system\Propel\HuntingLog\HlUser.php on line 2 >>> >>>Line 2 is: >>>require_once 'HuntingLog/om/BaseHlUser.php'; >>> >>>The H1User.php is in the HuntingLog/system/Propel/HuntingLog folder and >>>the >>>om folder is below this. >>>So not sure why the include has the HuntingLog directory >>> >>>I made a bunch of changes prior to this as well - I was just trying to >>>make >>>it work. >>>Example: >>> >>>Index.php - line 4: >>>The includes.php is not in the pubic_html folder. >>> >>>Fix that and then line 5 has an error. >>> >>>I did this as noted for about a dozen files and I'm still not done. >>> >>>I set $hlConf['path'] and $hlConf['site_url'] >>> >>>So what did I do wrong or is wrong ? >>> >>>BTW: This is what was messing up my php.ini setting for the includes >>>setting: >>>The line at the end of the config.php to set the include_path - should >>>that >>>not be with a ; instead of a : >>>ini_set('include_path', ini_get('include_path') . >>>";{$hlConf['path']}:{$hlConf['path_system']}"); >>> >>>Blaine >>> >>> >>> >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >> > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From geeklog at langfamily.ca Mon Dec 13 15:30:21 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Mon, 13 Dec 2004 15:30:21 -0500 Subject: [geeklog-devel] GL2 Framework References: <41BDBE33.9080406@tonybibbs.com> Message-ID: <01ea01c4e152$91395cc0$650a10ac@XPBL2> Tony, I have been contributing on the 1.3 support and development but with all my plugins the demand is very high on my time to maintain them. The codebase for the forum plugin alone very demanding. And the other core plugins need a lot more attention and they are used heavily by the current users. It's imperative that the 1.3.x code base continue the excellent support that Dirk and others of the team have been able to maintain and I don't think anyone is saying anything else. I am solidly behind GL2 but also am very dependant on 1.3 and it's become a very solid development framework for me. I definitely want to contribute on the API and Module area of development. >From what I've seen so far, it's not the team members and wana-be team members lack of desire and intent to contrbute it's that we have different cycles of available time. -- Blaine ----- Original Message ----- From: "Tony Bibbs" To: ; Sent: Monday, December 13, 2004 11:07 AM Subject: [geeklog-devel] GL2 Framework I've yet to hear anything substantive since the original 12/2 email I sent on the topic. In the interest of time I'm going to move on but it is worth noting one thing. The GL2 progress has been embarassingly slow. I take full accountablity for this. This latest effort to move forward on the codebase will be my last. ..if things stagnate again I will formally put my GL coding days behind me and leave the entire long term vision of GL to Dirk. To help keep things moving I am hoping to delegate as much work as possible to those with more time...however you might note that quality help is a rare commodity. The progress that can be made is directly tied the help I cant count on. I've had a number of nibbles from people willing to help but none of them panned out, nearly all sighting time commitments. So to expand on what I have already said, unless I can get other developers to devote some amount of time to GL2 I will need to officially kill the notion of GL2. To that end I am setting a Februrary 1st deadline for myself and any that choose to help on producing the complete GL2 framework code so that plugin development can begin. Anything short of that I will view as failure. I've cc'd the users mailing list in the hopes that some on that list might consider contributing to GL2. My apologies if this all sounded a bit dramatic...I simply wanted to, one last time, assert my hopes to get the project moving and my willingness to step aside for the lack of progress. --Tony _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Mon Dec 13 15:31:32 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 13 Dec 2004 14:31:32 -0600 Subject: [geeklog-devel] Framework In-Reply-To: <01dd01c4e150$9e8758c0$650a10ac@XPBL2> References: <41BA1FF3.70101@tonybibbs.com> <015e01c4df15$61f5c320$650a10ac@XPBL2> <41BA3D96.2080103@tonybibbs.com> <000f01c4df31$d4856500$650a10ac@XPBL2> <8319e2d60412101952527b3825@mail.gmail.com> <41BB126E.9090809@tonybibbs.com> <004c01c4df97$4e5dea90$650a10ac@XPBL2> <41BCA90E.5040407@tonybibbs.com> <01dd01c4e150$9e8758c0$650a10ac@XPBL2> Message-ID: <41BDFC24.3040005@tonybibbs.com> Yeah, forgot that on windows that would cause a problem. Thanks, --Tony Blaine Lang wrote: >Tony, > >I had much better luck with this archive. >I still had to modify your ini set line in the config.php to use a ; instead >of a : as a path delimiter. > >I can now have a look at the code as it's quite a change architecturally but >I like the concepts. >I'm sure it pays off once you get over the learning curve and have the >codebase in place. > >Blaine >----- Original Message ----- >From: "Tony Bibbs" >To: >Sent: Sunday, December 12, 2004 3:24 PM >Subject: Re: [geeklog-devel] Framework > > >Anybody have better luck with the new tarball? > >--Tony > >Blaine Lang wrote: > > > >>Tony, >> >>Actually getting propel installed was the easiest of the tasks. >>Read my note all the way - I note the real issues with the archive as I see >>them. >> >>Blaine >>----- Original Message ----- >>From: "Tony Bibbs" >>To: >>Sent: Saturday, December 11, 2004 10:29 AM >>Subject: Re: [geeklog-devel] Framework >> >> >>Yeah, keep in mind that I could have included propel's classes in the >>tarball which would have made most of your battles a mute point. I'll >>probably do that form now on. It shouldn't be too hard for dabblers >>until they get to the point they want to start doing their own database >>changes...that's where using Propel in conjunction with Phing comes in. >>Despite that, I think this is something we can document well enough to >>get people moving along. >> >>Fire over any additional questions. >> >>--Tony >> >>Vincent Furia wrote: >> >> >> >> >> >>>Blaine, (Tony,) >>> >>>I had to mess around a lot with the paths as well to get things >>>working (though I did finally get things working). I had to edit >>>config.php and then I had to add the path >>>/path/to/HuntingLog/system/Propel to the include path. I did this by >>>adding it into the ini_set in config.php. >>> >>>Hopefully that will get you up and running. Once you figure out >>>_everything_ (and that is a lot) things will start to make sense. I'm >>>kind of afraid we're going to make development too hard for dabblers. >>>If we go this route, we'll need to come up with some simple way to add >>>basic functionality. >>> >>>I have been looking at it Tony. I'll have more input soon. Promise. >>> >>>-Vinny >>> >>> >>>On Fri, 10 Dec 2004 22:30:58 -0500, Blaine Lang >>>wrote: >>> >>> >>> >>> >>> >>> >>>>Tony, >>>> >>>>Well, I after more then an hour I still don't have it running. Been >>>>tracking >>>>down the source of multiple path related issues and there appears to be >>>>no >>>>end. >>>> >>>>I can't get the include path in php.ini to work and had to edit paths in >>>>the >>>>files. >>>>[edit] source to this is noted at end of this message >>>> >>>>- Install propel and that required the PEAR Log class. >>>>- Install PEAR flexy >>>> >>>>But I've been editing some dozen files in the archive you sent for the >>>>app >>>>as expected paths are not working and I just restored it as is. >>>>Still more changes need - example: >>>> >>>>Warning: main(HuntingLog/om/BaseHlUser.php) [function.main]: failed to >>>>open >>>>stream: No such file or directory in >>>>g:\www2root\HuntingLog\system\Propel\HuntingLog\HlUser.php on line 2 >>>> >>>>Line 2 is: >>>>require_once 'HuntingLog/om/BaseHlUser.php'; >>>> >>>>The H1User.php is in the HuntingLog/system/Propel/HuntingLog folder and >>>>the >>>>om folder is below this. >>>>So not sure why the include has the HuntingLog directory >>>> >>>>I made a bunch of changes prior to this as well - I was just trying to >>>>make >>>>it work. >>>>Example: >>>> >>>>Index.php - line 4: >>>>The includes.php is not in the pubic_html folder. >>>> >>>>Fix that and then line 5 has an error. >>>> >>>>I did this as noted for about a dozen files and I'm still not done. >>>> >>>>I set $hlConf['path'] and $hlConf['site_url'] >>>> >>>>So what did I do wrong or is wrong ? >>>> >>>>BTW: This is what was messing up my php.ini setting for the includes >>>>setting: >>>>The line at the end of the config.php to set the include_path - should >>>>that >>>>not be with a ; instead of a : >>>>ini_set('include_path', ini_get('include_path') . >>>>";{$hlConf['path']}:{$hlConf['path_system']}"); >>>> >>>>Blaine >>>> >>>> >>>> >>>>_______________________________________________ >>>>geeklog-devel mailing list >>>>geeklog-devel at lists.geeklog.net >>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >> > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From dirk at haun-online.de Mon Dec 13 15:25:39 2004 From: dirk at haun-online.de (Dirk Haun) Date: Mon, 13 Dec 2004 21:25:39 +0100 Subject: [geeklog-devel] Framework In-Reply-To: <01dd01c4e150$9e8758c0$650a10ac@XPBL2> References: <01dd01c4e150$9e8758c0$650a10ac@XPBL2> Message-ID: <20041213202539.32669@smtp.haun-online.de> Blaine wrote: >I still had to modify your ini set line in the config.php to use a ; instead >of a : as a path delimiter. Windows, eh? Tony, you may want to use PATH_SEPARATOR. See lib-common.php :-) bye, Dirk -- http://www.haun-online.de/ http://www.handful-of-sparks.de/ From dirk at haun-online.de Mon Dec 13 15:27:57 2004 From: dirk at haun-online.de (Dirk Haun) Date: Mon, 13 Dec 2004 21:27:57 +0100 Subject: [geeklog-devel] Namespaces In-Reply-To: <41BDE6F3.7040301@tonybibbs.com> References: <41BDE6F3.7040301@tonybibbs.com> Message-ID: <20041213202757.16011@smtp.haun-online.de> Tony, >All core Geeklog code would start with the Geeklog_ prefix in their >class names. [...] >I wanted to throw this in for dicussion as this will need to be >finalized and documented well early on. Sounds okay to me. I couldn't believe that PHP 5 doesn't support namespaces yet, but apparently it doesn't. I wonder were I got the idea from ... bye, Dirk -- http://www.haun-online.de/ http://www.macosx-faq.de/ From tony at tonybibbs.com Mon Dec 13 15:37:37 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 13 Dec 2004 14:37:37 -0600 Subject: [geeklog-devel] GL2 Framework In-Reply-To: <01ea01c4e152$91395cc0$650a10ac@XPBL2> References: <41BDBE33.9080406@tonybibbs.com> <01ea01c4e152$91395cc0$650a10ac@XPBL2> Message-ID: <41BDFD91.3070607@tonybibbs.com> Yeah, I'm making no assumptions on what people are doing with their free time. It's obvious with my wife-and-two-kids-under-3 lifestyle that I won't have the time to do a lot of day-to-day coding but I do have enough time to do organize the general direction and help on critical pieces of code. My only hope is to build a somewhat devoted group for GL2. Being devoted doesn't require a lot of time, just consistent amounts of time on a week-by-week basis. Having Vinny is a start and I was just contacted by someone else who got my message on the users lists that sounds promising. I think ideally I'd have 5 people on the gl2 kernel...4 at a minumum to meet the Feb. 1 date. I think if you can review code from time-to-time while you do your 1.3.x work that is a good start. We can never have enough eyes on code. Thanks, --Tony Blaine Lang wrote: >Tony, > >I have been contributing on the 1.3 support and development but with all my >plugins the demand is very high on my time to maintain them. The codebase >for the forum plugin alone very demanding. And the other core plugins need a >lot more attention and they are used heavily by the current users. > >It's imperative that the 1.3.x code base continue the excellent support that >Dirk and others of the team have been able to maintain and I don't think >anyone is saying anything else. I am solidly behind GL2 but also am very >dependant on 1.3 and it's become a very solid development framework for me. > >I definitely want to contribute on the API and Module area of development. > >>From what I've seen so far, it's not the team members and wana-be team >members lack of desire and intent to contrbute it's that we have different >cycles of available time. > >-- Blaine > >----- Original Message ----- >From: "Tony Bibbs" >To: ; >Sent: Monday, December 13, 2004 11:07 AM >Subject: [geeklog-devel] GL2 Framework > > >I've yet to hear anything substantive since the original 12/2 email I >sent on the topic. In the interest of time I'm going to move on but it >is worth noting one thing. The GL2 progress has been embarassingly >slow. I take full accountablity for this. This latest effort to move >forward on the codebase will be my last. ..if things stagnate again I >will formally put my GL coding days behind me and leave the entire long >term vision of GL to Dirk. To help keep things moving I am hoping to >delegate as much work as possible to those with more time...however you >might note that quality help is a rare commodity. The progress that can >be made is directly tied the help I cant count on. I've had a number of >nibbles from people willing to help but none of them panned out, nearly >all sighting time commitments. So to expand on what I have already >said, unless I can get other developers to devote some amount of time to >GL2 I will need to officially kill the notion of GL2. To that end I am >setting a Februrary 1st deadline for myself and any that choose to help >on producing the complete GL2 framework code so that plugin development >can begin. Anything short of that I will view as failure. > >I've cc'd the users mailing list in the hopes that some on that list >might consider contributing to GL2. > >My apologies if this all sounded a bit dramatic...I simply wanted to, >one last time, assert my hopes to get the project moving and my >willingness to step aside for the lack of progress. > >--Tony >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From dirk at haun-online.de Mon Dec 13 15:39:19 2004 From: dirk at haun-online.de (Dirk Haun) Date: Mon, 13 Dec 2004 21:39:19 +0100 Subject: [geeklog-devel] Look-up Tables in GL2 In-Reply-To: <41BDEDFE.1060500@tonybibbs.com> References: <41BDEDFE.1060500@tonybibbs.com> Message-ID: <20041213203919.4481@smtp.haun-online.de> Tony, >In GL2 I'm proposing we use a single table to serve all those needs. Makes sense. >The issue I really >wanted to discuss was one brought up by someone recently (name escapes >me) on how to handle the translation of text stored in drop downs. I >have been assuming we would pipe the text in the actual database table >through our translation library...seems simple enough but I wanted to >make sure I wasn't over looking anything. Remind me again where GL2 will keep the translated text strings - in language files or in the database? Anyway, I seem to remember that when there's no translation for a string, it would use the english text, so there's no problem with keeping things consistent. That would be okay then (and would get rid of one of the annoyances in the 1.3 design). bye, Dirk -- http://www.haun-online.de/ http://www.tinyweb.de/ From tony at tonybibbs.com Mon Dec 13 16:03:51 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 13 Dec 2004 15:03:51 -0600 Subject: [geeklog-devel] Look-up Tables in GL2 In-Reply-To: <20041213203919.4481@smtp.haun-online.de> References: <41BDEDFE.1060500@tonybibbs.com> <20041213203919.4481@smtp.haun-online.de> Message-ID: <41BE03B7.8050209@tonybibbs.com> Right now we plan on using Translation2 from PEAR. They support using the database and gettext. I'm not sure which we plan to favor...I was leaving that decision until Vinny finishes taking a look at it. Also I think Translation2 will always use the default langauge in the case a string was missing but I'd have to double check that. Thanks, --Tony Dirk Haun wrote: >Tony, > > > >>In GL2 I'm proposing we use a single table to serve all those needs. >> >> > >Makes sense. > > > > >>The issue I really >>wanted to discuss was one brought up by someone recently (name escapes >>me) on how to handle the translation of text stored in drop downs. I >>have been assuming we would pipe the text in the actual database table >>through our translation library...seems simple enough but I wanted to >>make sure I wasn't over looking anything. >> >> > >Remind me again where GL2 will keep the translated text strings - in >language files or in the database? > >Anyway, I seem to remember that when there's no translation for a string, >it would use the english text, so there's no problem with keeping things >consistent. > >That would be okay then (and would get rid of one of the annoyances in >the 1.3 design). > >bye, Dirk > > > > From vfuria at gmail.com Mon Dec 13 16:21:28 2004 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 13 Dec 2004 16:21:28 -0500 Subject: [geeklog-devel] Namespaces In-Reply-To: <20041213202757.16011@smtp.haun-online.de> References: <41BDE6F3.7040301@tonybibbs.com> <20041213202757.16011@smtp.haun-online.de> Message-ID: <8319e2d604121313213a3a17b2@mail.gmail.com> I agree that this is the way to go. I'll try to update what documentation we have on the wiki with this... -Vinny On Mon, 13 Dec 2004 21:27:57 +0100, Dirk Haun wrote: > Tony, > > >All core Geeklog code would start with the Geeklog_ prefix in their > >class names. > [...] > >I wanted to throw this in for dicussion as this will need to be > >finalized and documented well early on. > > Sounds okay to me. > > I couldn't believe that PHP 5 doesn't support namespaces yet, but > apparently it doesn't. I wonder were I got the idea from ... > > bye, Dirk > > -- > http://www.haun-online.de/ > http://www.macosx-faq.de/ > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From vfuria at gmail.com Mon Dec 13 16:29:45 2004 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 13 Dec 2004 16:29:45 -0500 Subject: [geeklog-devel] Look-up Tables in GL2 In-Reply-To: <41BE03B7.8050209@tonybibbs.com> References: <41BDEDFE.1060500@tonybibbs.com> <20041213203919.4481@smtp.haun-online.de> <41BE03B7.8050209@tonybibbs.com> Message-ID: <8319e2d604121313294032bc47@mail.gmail.com> Right now I'm leaning toward using the Translation2's gettext for doing all the translation. It's pretty smooth, very fast, and will even work on PHP installs without gettext support (though obviously not as quickly as with gettext support). Another advantage is that we'll be able to modify the translation files online via a web-based administration tool. I didn't want to go with database for a couple reasons. If we went the database root we'd have to do caching and other tricks for speed or else performance would be really awful. Also Translation2 only supports PEAR::DB, which would mean a hassle since Propel only supports Creole. We'd either have to run with two DB abstraction layers (really, really bad) or else port one or the other library to the other DB layer (more work then I think any of us want to commit two). Besides that I don't see any big advantages to using the DB over gettext. If anyone knows of any please speak up now. Also I encourage people to try out Translation2 if you get the chance. Though its not necessary, I think you'll get a kick out of how easy it will make things. -Vinny On Mon, 13 Dec 2004 15:03:51 -0600, Tony Bibbs wrote: > Right now we plan on using Translation2 from PEAR. They support using > the database and gettext. I'm not sure which we plan to favor...I was > leaving that decision until Vinny finishes taking a look at it. Also I > think Translation2 will always use the default langauge in the case a > string was missing but I'd have to double check that. > > Thanks, > > --Tony > > Dirk Haun wrote: > > >Tony, > > > > > > > >>In GL2 I'm proposing we use a single table to serve all those needs. > >> > >> > > > >Makes sense. > > > > > > > > > >>The issue I really > >>wanted to discuss was one brought up by someone recently (name escapes > >>me) on how to handle the translation of text stored in drop downs. I > >>have been assuming we would pipe the text in the actual database table > >>through our translation library...seems simple enough but I wanted to > >>make sure I wasn't over looking anything. > >> > >> > > > >Remind me again where GL2 will keep the translated text strings - in > >language files or in the database? > > > >Anyway, I seem to remember that when there's no translation for a string, > >it would use the english text, so there's no problem with keeping things > >consistent. > > > >That would be okay then (and would get rid of one of the annoyances in > >the 1.3 design). > > > >bye, Dirk > > > > > > > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From vfuria at gmail.com Mon Dec 13 16:32:10 2004 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 13 Dec 2004 16:32:10 -0500 Subject: [geeklog-devel] Look-up Tables in GL2 In-Reply-To: <41BDEDFE.1060500@tonybibbs.com> References: <41BDEDFE.1060500@tonybibbs.com> Message-ID: <8319e2d60412131332354bf373@mail.gmail.com> Oh yeah, the lookup table looks good to me. Though I would suggest a name change. :) "lov" seems a bit strong to me. ;) -Vinny Apologies to anyone injured by the really, really bad humor. On Mon, 13 Dec 2004 13:31:10 -0600, Tony Bibbs wrote: > Today in GL 1.3.x we have a number of look up tables (e.g. gl_postmodes, > gl_cookiecodes, gl_featurecodes, etc). All nearly look exactly the same > in terms of their structure but they serve wildly different needs. In > GL2 I'm proposing we use a single table to serve all those needs. This > isn't anything 'new' in concept but it is new to GL. Anyway I call this > table the List_of_Values table and it would look roughly like this: > > CREATE TABLE list_of_values ( > lov_id int(10) unsigned NOT NULL auto_increment, > group_name varchar (30) NOT NULL, > short_name varchar(30) NOT NULL, > description varchar(128), > enabled tinyint(1) NOT NULL DEFAULT '1', > sort_order mediumint(10) NOT NULL DEFAULT '0', > PRIMARY KEY (lov_id), > INDEX (group_name) > ) TYPE=INNODB; > > I don't think there will be much argument over the structure but I > wanted to make sure this made sense to everybody. The issue I really > wanted to discuss was one brought up by someone recently (name escapes > me) on how to handle the translation of text stored in drop downs. I > have been assuming we would pipe the text in the actual database table > through our translation library...seems simple enough but I wanted to > make sure I wasn't over looking anything. > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From dirk at haun-online.de Mon Dec 13 16:48:45 2004 From: dirk at haun-online.de (Dirk Haun) Date: Mon, 13 Dec 2004 22:48:45 +0100 Subject: [geeklog-devel] Look-up Tables in GL2 In-Reply-To: <8319e2d604121313294032bc47@mail.gmail.com> References: <8319e2d604121313294032bc47@mail.gmail.com> Message-ID: <20041213214845.18567@smtp.haun-online.de> Vinny, >Right now I'm leaning toward using the Translation2's gettext for >doing all the translation. It's pretty smooth, very fast, and will >even work on PHP installs without gettext support Good point. GL2's requirements are already pretty steep, and gettext doesn't seem to be widely available. >Also I encourage people to try out Translation2 if you get the chance. Right, I remember another of Tony's emails that I didn't respond to [hangs head in shame] bye, Dirk -- http://www.haun-online.de/ http://www.macosx-faq.de/ From tony at tonybibbs.com Mon Dec 13 17:25:00 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 13 Dec 2004 16:25:00 -0600 Subject: [geeklog-devel] Filtering in GL2 Message-ID: <41BE16BC.2080407@tonybibbs.com> Dirk, You have done a lot of work building the filtering functions in 1.3.x. They are quite new to me (I don't think any code I have written ever used them). I think you have gotten to a point where you are pretty happy with how all that works. I was thinking of simply pulling those functions out into a class for GL2 as I don't see our needs for this in GL2 changing. I have a couple of questions assuming that is true: 1) is all the code minus the kses code yours? I'm thinking about the dual license issue here so if I have to 'rewrite' them enough to make them ours I will. If they are yours I won't need to touch them...if you think contributions came from elsewhere I will. 2) are there any missing features in the current filtering scheme you can think of? Any limitations (speed, etc) worth discussing? --Tony From geeklog at langfamily.ca Mon Dec 13 18:02:35 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Mon, 13 Dec 2004 18:02:35 -0500 Subject: [geeklog-devel] Filtering in GL2 References: <41BE16BC.2080407@tonybibbs.com> Message-ID: <028701c4e167$d574cfe0$650a10ac@XPBL2> Tony, The filtering of input parms as you know is very important and an area that has really improved since GL 1.3.8 but I would like to suggest we need to rethink the method used as we have had to extend and add COM functions to do various filtering an now there are too many that at times conflict with each other. Dirk and I have talked on and off about the need for a OO class that would be more flexible and consistent. Also we need to be able to pass an array of parms so that we don't have to make 10 function calls at times with larger forms for example. This class needs to have all the common dataoperations - filter - prepfordisplay - handles stripslashes and html entities - prepforSave - handles quotes - prepforOS -- handles directory path delimiters for example. - censor There is more but my headcold is effecting my neural network ;) ----- Original Message ----- From: "Tony Bibbs" To: Sent: Monday, December 13, 2004 5:25 PM Subject: [geeklog-devel] Filtering in GL2 Dirk, You have done a lot of work building the filtering functions in 1.3.x. They are quite new to me (I don't think any code I have written ever used them). I think you have gotten to a point where you are pretty happy with how all that works. I was thinking of simply pulling those functions out into a class for GL2 as I don't see our needs for this in GL2 changing. I have a couple of questions assuming that is true: 1) is all the code minus the kses code yours? I'm thinking about the dual license issue here so if I have to 'rewrite' them enough to make them ours I will. If they are yours I won't need to touch them...if you think contributions came from elsewhere I will. 2) are there any missing features in the current filtering scheme you can think of? Any limitations (speed, etc) worth discussing? --Tony _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Mon Dec 13 19:29:42 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 13 Dec 2004 18:29:42 -0600 Subject: [geeklog-devel] Filtering in GL2 In-Reply-To: <028701c4e167$d574cfe0$650a10ac@XPBL2> References: <41BE16BC.2080407@tonybibbs.com> <028701c4e167$d574cfe0$650a10ac@XPBL2> Message-ID: <41BE33F6.3000304@tonybibbs.com> Blaine Lang wrote: >Dirk and I have talked on and off about the need for a OO class that would >be more flexible and consistent. >Also we need to be able to pass an array of parms so that we don't have to >make 10 function calls at times with larger forms for example. > >This class needs to have all the common dataoperations >- filter > > Here I assume you mean the stuff the kses filter does along with stripping of unwanted HTML, right? >- prepfordisplay - handles stripslashes and html entities >- prepforSave - handles quotes > > Quote handling in GL2 should be transparent to the developer. Recall that all custom SQL goes into a named query file and that the SQL that goes in there should use prepared SQL as opposed to the kind of SQL found in 1.3.x. Similarly, Propel handles the retrieval of the data into objects so that should be transparent as well. >- prepforOS -- handles directory path delimiters for example. > > What else is done here beside path delimiters? >- censor > > Sounds good. Anyone want to take a stab at defining the function prototypes of the oo-based class? I'm not sure of all the things we are talking about here. --Tony From tony at tonybibbs.com Mon Dec 13 20:54:25 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 13 Dec 2004 19:54:25 -0600 Subject: [geeklog-devel] GL2 ACL Message-ID: <41BE47D1.9080907@tonybibbs.com> Ok, I did some digging around in the archives looking for what we had discussed for Access Control Lists (ACL) in Geeklog 2. Vinny recommended this: http://lists.geeklog.net/pipermail/geeklog-devel/2003-June/000688.html Vinny, is this still the direction you are thinking of? If so I have a question: - the acl table listed has an id field as the PK. Right after that is an item field which, I assume is a foreign key to the item table. So what's the relation between the acl table and item table? 1-to-1? 1-to-many? - So your goal, to be clear, is to be able to, on a user-by-user bases or group-by-group basis control access to an item. What's the performance implication on this? For the others on the list, this has nothing to do with the Auth_Enterprise work that has been done. Auth_Enterprise controls access to the application, the ACL's build on that by providing detailed item-level security. --Tony From geeklog at langfamily.ca Mon Dec 13 21:44:21 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Mon, 13 Dec 2004 21:44:21 -0500 Subject: [geeklog-devel] Filtering in GL2 References: <41BE16BC.2080407@tonybibbs.com> <028701c4e167$d574cfe0$650a10ac@XPBL2> <41BE33F6.3000304@tonybibbs.com> Message-ID: <02c401c4e186$d0e0fed0$650a10ac@XPBL2> Tony wrote: > Here I assume you mean the stuff the kses filter does along with stripping > of unwanted HTML, right? Correct. Today we have a number of format related functions: COM_killJS, COM_checkHTML, COM_handleCode, COM_undoSpecialChars, COM_formatEmail, COM_stripslashes, COM_applyFilter, COM_makeClickableLinks, COM_highlightQuery, COM_santizeID I think I got them all There are also: COM_buildURL, COM_setArgNames, COM_getArgument In addition, there is much more code inside the app that is adding or stripping. These have been added over time to address common needs but a major task to replace and consolidate the core GL 1.3 codebase. Still, it would be good to create a new OO based class and start to use it and slowing migrate scripts. The 1.3.x platform and plugins could be used to test such a new common class. I'd like to get more input but would be willing to take the lead on developing this. ----- Original Message ----- From: "Tony Bibbs" To: Sent: Monday, December 13, 2004 7:29 PM Subject: Re: [geeklog-devel] Filtering in GL2 Blaine Lang wrote: >Dirk and I have talked on and off about the need for a OO class that would >be more flexible and consistent. >Also we need to be able to pass an array of parms so that we don't have to >make 10 function calls at times with larger forms for example. > >This class needs to have all the common dataoperations >- filter > > Here I assume you mean the stuff the kses filter does along with stripping of unwanted HTML, right? >- prepfordisplay - handles stripslashes and html entities >- prepforSave - handles quotes > > Quote handling in GL2 should be transparent to the developer. Recall that all custom SQL goes into a named query file and that the SQL that goes in there should use prepared SQL as opposed to the kind of SQL found in 1.3.x. Similarly, Propel handles the retrieval of the data into objects so that should be transparent as well. >- prepforOS -- handles directory path delimiters for example. > > What else is done here beside path delimiters? >- censor > > Sounds good. Anyone want to take a stab at defining the function prototypes of the oo-based class? I'm not sure of all the things we are talking about here. --Tony _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From vfuria at gmail.com Mon Dec 13 23:43:35 2004 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 13 Dec 2004 23:43:35 -0500 Subject: [geeklog-devel] Filtering in GL2 In-Reply-To: <02c401c4e186$d0e0fed0$650a10ac@XPBL2> References: <41BE16BC.2080407@tonybibbs.com> <028701c4e167$d574cfe0$650a10ac@XPBL2> <41BE33F6.3000304@tonybibbs.com> <02c401c4e186$d0e0fed0$650a10ac@XPBL2> Message-ID: <8319e2d6041213204363d8f9f6@mail.gmail.com> I vote for Blaine. :) One thing I'd really like to see is for this class to autodetect the different php.ini settings (magic quotes, others?) as appropriate (including OS) and react accordingly. Also, if possible, it should be able to do basic "sanitizing" of form input without needing an explicit call by a plugin or function (basically, act directly on $_REQUEST when the gl script is first called). I know that is all obvious, but I thought it worth while to state it. Let us know if you need any help Blaine. ;) -Vinny On Mon, 13 Dec 2004 21:44:21 -0500, Blaine Lang wrote: > Tony wrote: > > Here I assume you mean the stuff the kses filter does along with stripping > > of unwanted HTML, right? > > Correct. Today we have a number of format related functions: > COM_killJS, > COM_checkHTML, > COM_handleCode, > COM_undoSpecialChars, > COM_formatEmail, > COM_stripslashes, > COM_applyFilter, > COM_makeClickableLinks, > COM_highlightQuery, > COM_santizeID > > I think I got them all > > There are also: > COM_buildURL, > COM_setArgNames, > COM_getArgument > > In addition, there is much more code inside the app that is adding or > stripping. > These have been added over time to address common needs but a major task to > replace and consolidate the core GL 1.3 codebase. > > Still, it would be good to create a new OO based class and start to use it > and slowing migrate scripts. > The 1.3.x platform and plugins could be used to test such a new common > class. > > I'd like to get more input but would be willing to take the lead on > developing this. > > ----- Original Message ----- > From: "Tony Bibbs" > To: > Sent: Monday, December 13, 2004 7:29 PM > Subject: Re: [geeklog-devel] Filtering in GL2 > > Blaine Lang wrote: > > >Dirk and I have talked on and off about the need for a OO class that would > >be more flexible and consistent. > >Also we need to be able to pass an array of parms so that we don't have to > >make 10 function calls at times with larger forms for example. > > > >This class needs to have all the common dataoperations > >- filter > > > > > Here I assume you mean the stuff the kses filter does along with > stripping of unwanted HTML, right? > > >- prepfordisplay - handles stripslashes and html entities > >- prepforSave - handles quotes > > > > > Quote handling in GL2 should be transparent to the developer. Recall > that all custom SQL goes into a named query file and that the SQL that > goes in there should use prepared SQL as opposed to the kind of SQL > found in 1.3.x. Similarly, Propel handles the retrieval of the data > into objects so that should be transparent as well. > > >- prepforOS -- handles directory path delimiters for example. > > > > > What else is done here beside path delimiters? > > >- censor > > > > > Sounds good. Anyone want to take a stab at defining the function > prototypes of the oo-based class? I'm not sure of all the things we are > talking about here. > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From vfuria at gmail.com Mon Dec 13 23:54:37 2004 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 13 Dec 2004 23:54:37 -0500 Subject: [geeklog-devel] GL2 ACL In-Reply-To: <41BE47D1.9080907@tonybibbs.com> References: <41BE47D1.9080907@tonybibbs.com> Message-ID: <8319e2d604121320542af0ca86@mail.gmail.com> On Mon, 13 Dec 2004 19:54:25 -0600, Tony Bibbs wrote: > Vinny, is this still the direction you are thinking of? If so I have a > question: Yes, I'll do my best to answer. > - the acl table listed has an id field as the PK. Right after that is > an item field which, I assume is a foreign key to the item table. So > what's the relation between the acl table and item table? 1-to-1? > 1-to-many? 1 item can have many rows in the acl table. > - So your goal, to be clear, is to be able to, on a user-by-user bases > or group-by-group basis control access to an item. What's the > performance implication on this? Actually I don't think performance will be a problem. All that needs to be done is a single SQL call with a straight join or two DB calls. I suspect that Propel will do the latter. In any case the select (and/or join) will be on table indices so it will be very fast. When I first started out with this idea I did a sample using 1.3.x's article table and making a basic acl table. The difference between getting the permissions via 1.3.x methods vs. with acls was not noticible until I was selecting hundreds of articles and even then I wouldn't call the difference a huge performance hit. Unfortunately I think I lost that code... > For the others on the list, this has nothing to do with the > Auth_Enterprise work that has been done. Auth_Enterprise controls > access to the application, the ACL's build on that by providing detailed > item-level security. Yes, though I still will argue that Geeklog should keep a "permissions" table (story.edit, etc) internally and ACLs should be kept against that as well. But I bet Tony and I will talk about that later. :) And so people know where I got most of these ideas: I did a lot of work with the Andrew File System (AFS) in school, and grew to really like the granularity of its permissions system. Heres a web site that goes into the basics of that: http://www.psc.edu/general/filesys/afs/setpermissions.html. Hopefully you'll be able to see what I was shooting for. -Vinny From vfuria at gmail.com Tue Dec 14 00:15:39 2004 From: vfuria at gmail.com (Vincent Furia) Date: Tue, 14 Dec 2004 00:15:39 -0500 Subject: [geeklog-devel] Framework In-Reply-To: <41BA1FF3.70101@tonybibbs.com> References: <41BA1FF3.70101@tonybibbs.com> Message-ID: <8319e2d604121321154d4b98e4@mail.gmail.com> Tony (and everyone), This response was a long time in coming but hopefully it will be worth it. I now know more than I really ever wanted to about what Tony would like to see in a Hunting Log. :) Most everything looks to be on the up and up. I really liked how Propel and the MVCnPHP interact to make an application really easy to put together. I'm even starting to get used to the idea of having a central store to keep SQL queries (though it still seems a bit strange). We're going to need to expand it though to be able to handle different queries for different databases (hopefully a rare occurrence, but something I could easily see happening). Concerns: Creole. I'm sure its good, and everything I've read about it seems positive but it isn't in wide spread use and I have yet to see a performance benchmark with it compared to some of the other DB abstraction layers. The only reason I'm worried is that a slow abstraction layer can hamstring the speed of the entire program. This was seen a couple years ago when ADODB was 2-3x faster than PEAR::DB. I know a few projects that were using PEAR and suffered as a result (I understand that PEAR::DB has improved a lot since then, this was just an example). Dislikes: I don't like using the DAO to abstract past the Propel classes. It seems silly and $dao->save($hunt) makes less sense to me than $hunt->save(). I understand you want to abstact in case we decide to replace Propel (or Creole, or something) some time in the distant future, but I think we could do that just as easily by changing the $hunt class, or inheriting it and overloading the necessary functions. And a note, I haven't actually looked at the code inside Propel or Creole. Unless someone (Tony) has taken a look, it might be a small risk that the code may be unmaintainable (though I doubt it). While Tony pointed out all this code is supported. If any of these projects one day die we may have to pick it up just to keep GL2 working... We really shouldn't depend on code that we would not be willing to maintain if push came to shove. -Vinny On Fri, 10 Dec 2004 16:15:15 -0600, Tony Bibbs wrote: > I know you are all busy and that some of you still hope to review the > code I sent over. In the interest of getting some sort of feedback I > have released the code on geeklog.net: > > http://www.geeklog.net/article.php/GL2FrameworkCode > > Just an FYI > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Tue Dec 14 09:25:58 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 14 Dec 2004 08:25:58 -0600 Subject: [geeklog-devel] Filtering in GL2 In-Reply-To: <8319e2d6041213204363d8f9f6@mail.gmail.com> References: <41BE16BC.2080407@tonybibbs.com> <028701c4e167$d574cfe0$650a10ac@XPBL2> <41BE33F6.3000304@tonybibbs.com> <02c401c4e186$d0e0fed0$650a10ac@XPBL2> <8319e2d6041213204363d8f9f6@mail.gmail.com> Message-ID: <41BEF7F6.5070608@tonybibbs.com> Vinny, this is all good for the 1.3.x version of the class. The 2.0 version, though, need not worry about magic quotes as Propel should take care of that. --Tony Vincent Furia wrote: >I vote for Blaine. :) > >One thing I'd really like to see is for this class to autodetect the >different php.ini settings (magic quotes, others?) as appropriate >(including OS) and react accordingly. Also, if possible, it should be >able to do basic "sanitizing" of form input without needing an >explicit call by a plugin or function (basically, act directly on >$_REQUEST when the gl script is first called). > >I know that is all obvious, but I thought it worth while to state it. >Let us know if you need any help Blaine. ;) > >-Vinny > > >On Mon, 13 Dec 2004 21:44:21 -0500, Blaine Lang wrote: > > >>Tony wrote: >> >> >>>Here I assume you mean the stuff the kses filter does along with stripping >>>of unwanted HTML, right? >>> >>> >>Correct. Today we have a number of format related functions: >> COM_killJS, >> COM_checkHTML, >> COM_handleCode, >> COM_undoSpecialChars, >> COM_formatEmail, >> COM_stripslashes, >> COM_applyFilter, >> COM_makeClickableLinks, >> COM_highlightQuery, >> COM_santizeID >> >>I think I got them all >> >>There are also: >> COM_buildURL, >> COM_setArgNames, >> COM_getArgument >> >>In addition, there is much more code inside the app that is adding or >>stripping. >>These have been added over time to address common needs but a major task to >>replace and consolidate the core GL 1.3 codebase. >> >>Still, it would be good to create a new OO based class and start to use it >>and slowing migrate scripts. >>The 1.3.x platform and plugins could be used to test such a new common >>class. >> >>I'd like to get more input but would be willing to take the lead on >>developing this. >> >>----- Original Message ----- >>From: "Tony Bibbs" >>To: >>Sent: Monday, December 13, 2004 7:29 PM >>Subject: Re: [geeklog-devel] Filtering in GL2 >> >>Blaine Lang wrote: >> >> >> >>>Dirk and I have talked on and off about the need for a OO class that would >>>be more flexible and consistent. >>>Also we need to be able to pass an array of parms so that we don't have to >>>make 10 function calls at times with larger forms for example. >>> >>>This class needs to have all the common dataoperations >>>- filter >>> >>> >>> >>> >>Here I assume you mean the stuff the kses filter does along with >>stripping of unwanted HTML, right? >> >> >> >>>- prepfordisplay - handles stripslashes and html entities >>>- prepforSave - handles quotes >>> >>> >>> >>> >>Quote handling in GL2 should be transparent to the developer. Recall >>that all custom SQL goes into a named query file and that the SQL that >>goes in there should use prepared SQL as opposed to the kind of SQL >>found in 1.3.x. Similarly, Propel handles the retrieval of the data >>into objects so that should be transparent as well. >> >> >> >>>- prepforOS -- handles directory path delimiters for example. >>> >>> >>> >>> >>What else is done here beside path delimiters? >> >> >> >>>- censor >>> >>> >>> >>> >>Sounds good. Anyone want to take a stab at defining the function >>prototypes of the oo-based class? I'm not sure of all the things we are >>talking about here. >> >>--Tony >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From tony at tonybibbs.com Tue Dec 14 09:30:47 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 14 Dec 2004 08:30:47 -0600 Subject: [geeklog-devel] GL2 ACL In-Reply-To: <8319e2d604121320542af0ca86@mail.gmail.com> References: <41BE47D1.9080907@tonybibbs.com> <8319e2d604121320542af0ca86@mail.gmail.com> Message-ID: <41BEF917.4030806@tonybibbs.com> Vincent Furia wrote: >Actually I don't think performance will be a problem. All that needs >to be done is a single SQL call with a straight join or two DB calls. >I suspect that Propel will do the latter. > We can force Propel to do it the way we ask. If it natively wants to do 2 calls we can use a named query and force a join instead. There may even be a way to do the joins with the Propel models themselves but this I haven't tried yet. >Yes, though I still will argue that Geeklog should keep a >"permissions" table (story.edit, etc) internally and ACLs should be >kept against that as well. But I bet Tony and I will talk about that >later. :) > > Right, the system privileges would go in Auth_Enterprise. The item-level settings would go in the gl-database. Of course, we will combine the data structures of the two so we are really talking about the same database. >And so people know where I got most of these ideas: I did a lot of >work with the Andrew File System (AFS) in school, and grew to really >like the granularity of its permissions system. Heres a web site that >goes into the basics of that: >http://www.psc.edu/general/filesys/afs/setpermissions.html. Hopefully >you'll be able to see what I was shooting for. > > Didn't know that. I'll have to take a gander. --Tony From tony at tonybibbs.com Tue Dec 14 09:53:05 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 14 Dec 2004 08:53:05 -0600 Subject: [geeklog-devel] Framework In-Reply-To: <8319e2d604121321154d4b98e4@mail.gmail.com> References: <41BA1FF3.70101@tonybibbs.com> <8319e2d604121321154d4b98e4@mail.gmail.com> Message-ID: <41BEFE51.3010202@tonybibbs.com> Vincent Furia wrote: >I now know more than I really ever wanted to about what Tony >would like to see in a Hunting Log. :) > > Lol! >Most everything looks to be on the up and up. I really liked how >Propel and the MVCnPHP interact to make an application really easy to >put together. I'm even starting to get used to the idea of having a >central store to keep SQL queries (though it still seems a bit >strange). We're going to need to expand it though to be able to >handle different queries for different databases (hopefully a rare >occurrence, but something I could easily see happening). > > Yeah, good point. There are probably two ways to do this: 1) Each named_query file could be tied to specific database (read: dsn) 2) Modify the non-existent (but soon to be created) xml schema (i.e. .xsd) to wrap the tags in a tag. Only issue there is do we care to support queries that pull data across more than one database? I vote for no...that's too complicated and I think in that case you should just get a handle to the database connections you need and go to work yourself. As much as I would like to keep our commands/views free of SQL there will always be exceptions. >Concerns: Creole. I'm sure its good, and everything I've read about >it seems positive but it isn't in wide spread use and I have yet to >see a performance benchmark with it compared to some of the other DB >abstraction layers. The only reason I'm worried is that a slow >abstraction layer can hamstring the speed of the entire program. This >was seen a couple years ago when ADODB was 2-3x faster than PEAR::DB. >I know a few projects that were using PEAR and suffered as a result (I >understand that PEAR::DB has improved a lot since then, this was just >an example). > >Dislikes: I don't like using the DAO to abstract past the Propel >classes. It seems silly and $dao->save($hunt) makes less sense to me >than $hunt->save(). I understand you want to abstact in case we >decide to replace Propel (or Creole, or something) some time in the >distant future, but I think we could do that just as easily by >changing the $hunt class, or inheriting it and overloading the >necessary functions. > > I'll tackle both of these at the same time. Using the DAO layer should address your concerns about Creole both from a performance view and a shelf-life perspective. It may seem like an un-needed layer of abstraction but it builds just the sort of buffer we need so that if we needed to make drastic changes to our data access layer that our commands/views/etc wouldn't have to change much. I can see your points on the using, for example, the save() method right on the model object but I argue that this is actually a design flaw of Propel as it breaks the rule of encapsulation. Domain objects, IMHO, shouldn't need to know how to persist themselves to the database. The persistence mechanism should be its own atomic bit of code and it should know how to save any domain object. I've sent a note to the propel-users list in hopes of having one of them address the performance concerns. I'd like to think they have done some benchmarking already...but you never know. >And a note, I haven't actually looked at the code inside Propel or >Creole. Unless someone (Tony) has taken a look, it might be a small >risk that the code may be unmaintainable (though I doubt it). While >Tony pointed out all this code is supported. If any of these projects >one day die we may have to pick it up just to keep GL2 working... We >really shouldn't depend on code that we would not be willing to >maintain if push came to shove. > > I've looked at some of the code. AFAICT, it's in pretty good shape with a fairly good design. The model objects generate by Propel are actually quite straightforward...the most complicated code is the lazy loading of child objects for a given domain object and even that stuff isn't too bad. But don't take my word for it...others should give it a gander and tell me what they think. Oh, and I haven't looked at the Creole code at all. --Tony From tony at tonybibbs.com Tue Dec 14 13:03:47 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 14 Dec 2004 12:03:47 -0600 Subject: [geeklog-devel] MVCnPHP Message-ID: <41BF2B03.9020801@tonybibbs.com> FYI, I have just updated the MVCnPHP package on my local machine to use the new namespace concept I mentioned yesterday. I'm also going to make a PEAR package out of it (though, it will not be in PEAR). This should make it infinitely easier for developers on GL2 to install/upgrade. There were some other minor changes I made such as string the .class.php out of the file names (since nearly all PHP5 files will be classes) and I refactored the code a bit. Fire off any questions if you have any. Otherwise I'll post a notice when the PEAR packaage is ready. --Tony From tony at tonybibbs.com Tue Dec 14 14:18:39 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 14 Dec 2004 13:18:39 -0600 Subject: [geeklog-devel] MVCnPHP In-Reply-To: <41BF2B03.9020801@tonybibbs.com> References: <41BF2B03.9020801@tonybibbs.com> Message-ID: <41BF3C8F.3010905@tonybibbs.com> Ok, you can install MVCnPHP simply by typing: $>pear install http://www.tonybibbs.com/Geeklog_MVCnPHP-2.0.0.tgz It will install it to your PEAR directory in Geeklog/MVCnPHP/ We will package this up in the GL2 tarball with each release but we'll allow the package to be upgraded in between releases (if needed) using this method. --Tony Tony Bibbs wrote: > FYI, I have just updated the MVCnPHP package on my local machine to > use the new namespace concept I mentioned yesterday. I'm also going > to make a PEAR package out of it (though, it will not be in PEAR). > This should make it infinitely easier for developers on GL2 to > install/upgrade. > > There were some other minor changes I made such as string the > .class.php out of the file names (since nearly all PHP5 files will be > classes) and I refactored the code a bit. > > Fire off any questions if you have any. Otherwise I'll post a notice > when the PEAR packaage is ready. > > --Tony > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Wed Dec 15 12:39:10 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 15 Dec 2004 11:39:10 -0600 Subject: [geeklog-devel] GL2 ACL In-Reply-To: <41BEF917.4030806@tonybibbs.com> References: <41BE47D1.9080907@tonybibbs.com> <8319e2d604121320542af0ca86@mail.gmail.com> <41BEF917.4030806@tonybibbs.com> Message-ID: <41C076BE.9040103@tonybibbs.com> Vinny, any chance you can I can hash this out ASAP? I've a minimalist data model created that I'd like to pipe through Propel. I know a lot will change but it will at least put the whole security issue to bed. I've been in IRC hoping to catch up with you but gl-bot keeps telling me you haven't been around in 9 days ;-) Also, I'm thinking strongly about not including Auth_Enterprise by default. I think GL2 should function alone and allow it to be easily customized to use any auth system. Auth_Enterprise is a real work of art but I think the installation and administration is complex and would only suit large or business oriented sites. --Tony Tony Bibbs wrote: > Vincent Furia wrote: > >> Actually I don't think performance will be a problem. All that needs >> to be done is a single SQL call with a straight join or two DB calls. >> I suspect that Propel will do the latter. > > We can force Propel to do it the way we ask. If it natively wants to > do 2 calls we can use a named query and force a join instead. There > may even be a way to do the joins with the Propel models themselves > but this I haven't tried yet. > >> Yes, though I still will argue that Geeklog should keep a >> "permissions" table (story.edit, etc) internally and ACLs should be >> kept against that as well. But I bet Tony and I will talk about that >> later. :) >> >> > Right, the system privileges would go in Auth_Enterprise. The > item-level settings would go in the gl-database. Of course, we will > combine the data structures of the two so we are really talking about > the same database. > >> And so people know where I got most of these ideas: I did a lot of >> work with the Andrew File System (AFS) in school, and grew to really >> like the granularity of its permissions system. Heres a web site that >> goes into the basics of that: >> http://www.psc.edu/general/filesys/afs/setpermissions.html. Hopefully >> you'll be able to see what I was shooting for. >> >> > Didn't know that. I'll have to take a gander. > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel From vfuria at gmail.com Wed Dec 15 13:03:19 2004 From: vfuria at gmail.com (Vincent Furia) Date: Wed, 15 Dec 2004 13:03:19 -0500 Subject: [geeklog-devel] GL2 ACL In-Reply-To: <41C076BE.9040103@tonybibbs.com> References: <41BE47D1.9080907@tonybibbs.com> <8319e2d604121320542af0ca86@mail.gmail.com> <41BEF917.4030806@tonybibbs.com> <41C076BE.9040103@tonybibbs.com> Message-ID: <8319e2d604121510035870297b@mail.gmail.com> Not sure when I'll have time to spend on IRC (I can't do that from work). If you just use propel to generate the basic data model for the ACLs I think that would be a good start. I think either of us could write the xml for that...then its probably just a matter of extending the acl and item classes that propel creates (and potentially the peer classes as well). Extending the classes can come later though. First things first, and that is getting the xml schema done... First one to get it done email the other? I wasn't sure how much you might have coded up already. We should get the schema.xml for GL2 "core" done soon at any rate I think... Let me know which way you want to play it. I'm game. I should have one or two hours every night this week and then a couple over the weekend as well to work on some stuff. The decision on Auth_Enterprise sounds good to me. Propel can generate some nice simple user and group tables for us to work with. -Vinny P.S. Might it be time for a separate GL2-devel mailing list? On Wed, 15 Dec 2004 11:39:10 -0600, Tony Bibbs wrote: > Vinny, any chance you can I can hash this out ASAP? I've a minimalist > data model created that I'd like to pipe through Propel. I know a lot > will change but it will at least put the whole security issue to bed. > I've been in IRC hoping to catch up with you but gl-bot keeps telling me > you haven't been around in 9 days ;-) > > Also, I'm thinking strongly about not including Auth_Enterprise by > default. I think GL2 should function alone and allow it to be easily > customized to use any auth system. Auth_Enterprise is a real work of > art but I think the installation and administration is complex and would > only suit large or business oriented sites. > > --Tony > > Tony Bibbs wrote: > > > Vincent Furia wrote: > > > >> Actually I don't think performance will be a problem. All that needs > >> to be done is a single SQL call with a straight join or two DB calls. > >> I suspect that Propel will do the latter. > > > > We can force Propel to do it the way we ask. If it natively wants to > > do 2 calls we can use a named query and force a join instead. There > > may even be a way to do the joins with the Propel models themselves > > but this I haven't tried yet. > > > >> Yes, though I still will argue that Geeklog should keep a > >> "permissions" table (story.edit, etc) internally and ACLs should be > >> kept against that as well. But I bet Tony and I will talk about that > >> later. :) > >> > >> > > Right, the system privileges would go in Auth_Enterprise. The > > item-level settings would go in the gl-database. Of course, we will > > combine the data structures of the two so we are really talking about > > the same database. > > > >> And so people know where I got most of these ideas: I did a lot of > >> work with the Andrew File System (AFS) in school, and grew to really > >> like the granularity of its permissions system. Heres a web site that > >> goes into the basics of that: > >> http://www.psc.edu/general/filesys/afs/setpermissions.html. Hopefully > >> you'll be able to see what I was shooting for. > >> > >> > > Didn't know that. I'll have to take a gander. > > > > --Tony > > _______________________________________________ > > geeklog-devel mailing list > > geeklog-devel at lists.geeklog.net > > http://lists.geeklog.net/listinfo/geeklog-devel > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Wed Dec 15 13:38:53 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 15 Dec 2004 12:38:53 -0600 Subject: [geeklog-devel] GL2 ACL In-Reply-To: <8319e2d604121510035870297b@mail.gmail.com> References: <41BE47D1.9080907@tonybibbs.com> <8319e2d604121320542af0ca86@mail.gmail.com> <41BEF917.4030806@tonybibbs.com> <41C076BE.9040103@tonybibbs.com> <8319e2d604121510035870297b@mail.gmail.com> Message-ID: <41C084BD.7010503@tonybibbs.com> Can you send me the CREATE TABLE syntax with the ACL stuff in it? As an FYI, I'm modeling everything in the database and generating the schema.xml from it as opposed to the other way around. I'll work on the rest of the kernel-only datastructures. We'll want to bring Dwight in soon for a real DBA's perspective and then we can open up that work to the community for fruther scrutiny. --Tony Vincent Furia wrote: >Not sure when I'll have time to spend on IRC (I can't do that from >work). If you just use propel to generate the basic data model for >the ACLs I think that would be a good start. I think either of us >could write the xml for that...then its probably just a matter of >extending the acl and item classes that propel creates (and >potentially the peer classes as well). > >Extending the classes can come later though. First things first, and >that is getting the xml schema done... First one to get it done email >the other? I wasn't sure how much you might have coded up already. >We should get the schema.xml for GL2 "core" done soon at any rate I >think... > >Let me know which way you want to play it. I'm game. I should have >one or two hours every night this week and then a couple over the >weekend as well to work on some stuff. > >The decision on Auth_Enterprise sounds good to me. Propel can >generate some nice simple user and group tables for us to work with. > >-Vinny > >P.S. Might it be time for a separate GL2-devel mailing list? > >On Wed, 15 Dec 2004 11:39:10 -0600, Tony Bibbs wrote: > > >>Vinny, any chance you can I can hash this out ASAP? I've a minimalist >>data model created that I'd like to pipe through Propel. I know a lot >>will change but it will at least put the whole security issue to bed. >>I've been in IRC hoping to catch up with you but gl-bot keeps telling me >>you haven't been around in 9 days ;-) >> >>Also, I'm thinking strongly about not including Auth_Enterprise by >>default. I think GL2 should function alone and allow it to be easily >>customized to use any auth system. Auth_Enterprise is a real work of >>art but I think the installation and administration is complex and would >>only suit large or business oriented sites. >> >>--Tony >> >>Tony Bibbs wrote: >> >> >> >>>Vincent Furia wrote: >>> >>> >>> >>>>Actually I don't think performance will be a problem. All that needs >>>>to be done is a single SQL call with a straight join or two DB calls. >>>>I suspect that Propel will do the latter. >>>> >>>> >>>We can force Propel to do it the way we ask. If it natively wants to >>>do 2 calls we can use a named query and force a join instead. There >>>may even be a way to do the joins with the Propel models themselves >>>but this I haven't tried yet. >>> >>> >>> >>>>Yes, though I still will argue that Geeklog should keep a >>>>"permissions" table (story.edit, etc) internally and ACLs should be >>>>kept against that as well. But I bet Tony and I will talk about that >>>>later. :) >>>> >>>> >>>> >>>> >>>Right, the system privileges would go in Auth_Enterprise. The >>>item-level settings would go in the gl-database. Of course, we will >>>combine the data structures of the two so we are really talking about >>>the same database. >>> >>> >>> >>>>And so people know where I got most of these ideas: I did a lot of >>>>work with the Andrew File System (AFS) in school, and grew to really >>>>like the granularity of its permissions system. Heres a web site that >>>>goes into the basics of that: >>>>http://www.psc.edu/general/filesys/afs/setpermissions.html. Hopefully >>>>you'll be able to see what I was shooting for. >>>> >>>> >>>> >>>> >>>Didn't know that. I'll have to take a gander. >>> >>>--Tony >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From tony at tonybibbs.com Wed Dec 15 14:04:19 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 15 Dec 2004 13:04:19 -0600 Subject: [geeklog-devel] GL2 ACL In-Reply-To: <41C084BD.7010503@tonybibbs.com> References: <41BE47D1.9080907@tonybibbs.com> <8319e2d604121320542af0ca86@mail.gmail.com> <41BEF917.4030806@tonybibbs.com> <41C076BE.9040103@tonybibbs.com> <8319e2d604121510035870297b@mail.gmail.com> <41C084BD.7010503@tonybibbs.com> Message-ID: <41C08AB3.60509@tonybibbs.com> Vinny, here is a link to the original model well over a year old: http://geeklog.tsystemscorp.com/staticpages/index.php?page=20030612212743102 Is the itemACL table the same as you were envisioning it? --Tony Tony Bibbs wrote: > Can you send me the CREATE TABLE syntax with the ACL stuff in it? As > an FYI, I'm modeling everything in the database and generating the > schema.xml from it as opposed to the other way around. > > I'll work on the rest of the kernel-only datastructures. We'll want > to bring Dwight in soon for a real DBA's perspective and then we can > open up that work to the community for fruther scrutiny. > > --Tony > > Vincent Furia wrote: > >> Not sure when I'll have time to spend on IRC (I can't do that from >> work). If you just use propel to generate the basic data model for >> the ACLs I think that would be a good start. I think either of us >> could write the xml for that...then its probably just a matter of >> extending the acl and item classes that propel creates (and >> potentially the peer classes as well). >> >> Extending the classes can come later though. First things first, and >> that is getting the xml schema done... First one to get it done email >> the other? I wasn't sure how much you might have coded up already. >> We should get the schema.xml for GL2 "core" done soon at any rate I >> think... >> >> Let me know which way you want to play it. I'm game. I should have >> one or two hours every night this week and then a couple over the >> weekend as well to work on some stuff. >> >> The decision on Auth_Enterprise sounds good to me. Propel can >> generate some nice simple user and group tables for us to work with. >> >> -Vinny >> >> P.S. Might it be time for a separate GL2-devel mailing list? >> >> On Wed, 15 Dec 2004 11:39:10 -0600, Tony Bibbs >> wrote: >> >> >>> Vinny, any chance you can I can hash this out ASAP? I've a minimalist >>> data model created that I'd like to pipe through Propel. I know a lot >>> will change but it will at least put the whole security issue to bed. >>> I've been in IRC hoping to catch up with you but gl-bot keeps >>> telling me >>> you haven't been around in 9 days ;-) >>> >>> Also, I'm thinking strongly about not including Auth_Enterprise by >>> default. I think GL2 should function alone and allow it to be easily >>> customized to use any auth system. Auth_Enterprise is a real work of >>> art but I think the installation and administration is complex and >>> would >>> only suit large or business oriented sites. >>> >>> --Tony >>> >>> Tony Bibbs wrote: >>> >>> >>> >>>> Vincent Furia wrote: >>>> >>>> >>>> >>>>> Actually I don't think performance will be a problem. All that needs >>>>> to be done is a single SQL call with a straight join or two DB calls. >>>>> I suspect that Propel will do the latter. >>>>> >>>> >>>> We can force Propel to do it the way we ask. If it natively wants to >>>> do 2 calls we can use a named query and force a join instead. There >>>> may even be a way to do the joins with the Propel models themselves >>>> but this I haven't tried yet. >>>> >>>> >>>> >>>>> Yes, though I still will argue that Geeklog should keep a >>>>> "permissions" table (story.edit, etc) internally and ACLs should be >>>>> kept against that as well. But I bet Tony and I will talk about that >>>>> later. :) >>>>> >>>>> >>>>> >>>> >>>> Right, the system privileges would go in Auth_Enterprise. The >>>> item-level settings would go in the gl-database. Of course, we will >>>> combine the data structures of the two so we are really talking about >>>> the same database. >>>> >>>> >>>> >>>>> And so people know where I got most of these ideas: I did a lot of >>>>> work with the Andrew File System (AFS) in school, and grew to really >>>>> like the granularity of its permissions system. Heres a web site >>>>> that >>>>> goes into the basics of that: >>>>> http://www.psc.edu/general/filesys/afs/setpermissions.html. >>>>> Hopefully >>>>> you'll be able to see what I was shooting for. >>>>> >>>>> >>>>> >>>> >>>> Didn't know that. I'll have to take a gander. >>>> >>>> --Tony >>>> _______________________________________________ >>>> geeklog-devel mailing list >>>> geeklog-devel at lists.geeklog.net >>>> http://lists.geeklog.net/listinfo/geeklog-devel >>>> >>> >>> _______________________________________________ >>> geeklog-devel mailing list >>> geeklog-devel at lists.geeklog.net >>> http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >> >> _______________________________________________ >> geeklog-devel mailing list >> geeklog-devel at lists.geeklog.net >> http://lists.geeklog.net/listinfo/geeklog-devel >> >> > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel From vfuria at gmail.com Wed Dec 15 14:27:11 2004 From: vfuria at gmail.com (Vincent Furia) Date: Wed, 15 Dec 2004 14:27:11 -0500 Subject: [geeklog-devel] GL2 ACL In-Reply-To: <41C08AB3.60509@tonybibbs.com> References: <41BE47D1.9080907@tonybibbs.com> <8319e2d604121320542af0ca86@mail.gmail.com> <41BEF917.4030806@tonybibbs.com> <41C076BE.9040103@tonybibbs.com> <8319e2d604121510035870297b@mail.gmail.com> <41C084BD.7010503@tonybibbs.com> <41C08AB3.60509@tonybibbs.com> Message-ID: <8319e2d604121511277a170fb@mail.gmail.com> Yup, though you'd probably want to throw an autoincrement int in front as a primary key. Indexes would have go on user_id and group_id and item_id. Also, I'd like to vote for writing the xml and then generating the sql ddl rather than the other way around. It seems much cleaner to me. -Vinny On Wed, 15 Dec 2004 13:04:19 -0600, Tony Bibbs wrote: > Vinny, here is a link to the original model well over a year old: > > http://geeklog.tsystemscorp.com/staticpages/index.php?page=20030612212743102 > > Is the itemACL table the same as you were envisioning it? > > --Tony > > Tony Bibbs wrote: > > > Can you send me the CREATE TABLE syntax with the ACL stuff in it? As > > an FYI, I'm modeling everything in the database and generating the > > schema.xml from it as opposed to the other way around. > > > > I'll work on the rest of the kernel-only datastructures. We'll want > > to bring Dwight in soon for a real DBA's perspective and then we can > > open up that work to the community for fruther scrutiny. > > > > --Tony > > > > Vincent Furia wrote: > > > >> Not sure when I'll have time to spend on IRC (I can't do that from > >> work). If you just use propel to generate the basic data model for > >> the ACLs I think that would be a good start. I think either of us > >> could write the xml for that...then its probably just a matter of > >> extending the acl and item classes that propel creates (and > >> potentially the peer classes as well). > >> > >> Extending the classes can come later though. First things first, and > >> that is getting the xml schema done... First one to get it done email > >> the other? I wasn't sure how much you might have coded up already. > >> We should get the schema.xml for GL2 "core" done soon at any rate I > >> think... > >> > >> Let me know which way you want to play it. I'm game. I should have > >> one or two hours every night this week and then a couple over the > >> weekend as well to work on some stuff. > >> > >> The decision on Auth_Enterprise sounds good to me. Propel can > >> generate some nice simple user and group tables for us to work with. > >> > >> -Vinny > >> > >> P.S. Might it be time for a separate GL2-devel mailing list? > >> > >> On Wed, 15 Dec 2004 11:39:10 -0600, Tony Bibbs > >> wrote: > >> > >> > >>> Vinny, any chance you can I can hash this out ASAP? I've a minimalist > >>> data model created that I'd like to pipe through Propel. I know a lot > >>> will change but it will at least put the whole security issue to bed. > >>> I've been in IRC hoping to catch up with you but gl-bot keeps > >>> telling me > >>> you haven't been around in 9 days ;-) > >>> > >>> Also, I'm thinking strongly about not including Auth_Enterprise by > >>> default. I think GL2 should function alone and allow it to be easily > >>> customized to use any auth system. Auth_Enterprise is a real work of > >>> art but I think the installation and administration is complex and > >>> would > >>> only suit large or business oriented sites. > >>> > >>> --Tony > >>> > >>> Tony Bibbs wrote: > >>> > >>> > >>> > >>>> Vincent Furia wrote: > >>>> > >>>> > >>>> > >>>>> Actually I don't think performance will be a problem. All that needs > >>>>> to be done is a single SQL call with a straight join or two DB calls. > >>>>> I suspect that Propel will do the latter. > >>>>> > >>>> > >>>> We can force Propel to do it the way we ask. If it natively wants to > >>>> do 2 calls we can use a named query and force a join instead. There > >>>> may even be a way to do the joins with the Propel models themselves > >>>> but this I haven't tried yet. > >>>> > >>>> > >>>> > >>>>> Yes, though I still will argue that Geeklog should keep a > >>>>> "permissions" table (story.edit, etc) internally and ACLs should be > >>>>> kept against that as well. But I bet Tony and I will talk about that > >>>>> later. :) > >>>>> > >>>>> > >>>>> > >>>> > >>>> Right, the system privileges would go in Auth_Enterprise. The > >>>> item-level settings would go in the gl-database. Of course, we will > >>>> combine the data structures of the two so we are really talking about > >>>> the same database. > >>>> > >>>> > >>>> > >>>>> And so people know where I got most of these ideas: I did a lot of > >>>>> work with the Andrew File System (AFS) in school, and grew to really > >>>>> like the granularity of its permissions system. Heres a web site > >>>>> that > >>>>> goes into the basics of that: > >>>>> http://www.psc.edu/general/filesys/afs/setpermissions.html. > >>>>> Hopefully > >>>>> you'll be able to see what I was shooting for. > >>>>> > >>>>> > >>>>> > >>>> > >>>> Didn't know that. I'll have to take a gander. > >>>> > >>>> --Tony > >>>> _______________________________________________ > >>>> geeklog-devel mailing list > >>>> geeklog-devel at lists.geeklog.net > >>>> http://lists.geeklog.net/listinfo/geeklog-devel > >>>> > >>> > >>> _______________________________________________ > >>> geeklog-devel mailing list > >>> geeklog-devel at lists.geeklog.net > >>> http://lists.geeklog.net/listinfo/geeklog-devel > >>> > >>> > >> > >> _______________________________________________ > >> geeklog-devel mailing list > >> geeklog-devel at lists.geeklog.net > >> http://lists.geeklog.net/listinfo/geeklog-devel > >> > >> > > > > _______________________________________________ > > geeklog-devel mailing list > > geeklog-devel at lists.geeklog.net > > http://lists.geeklog.net/listinfo/geeklog-devel > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From dwight at trumbower.com Wed Dec 15 14:36:34 2004 From: dwight at trumbower.com (dwight at trumbower.com) Date: Wed, 15 Dec 2004 14:36:34 -0500 (EST) Subject: [geeklog-devel] GL2 ACL In-Reply-To: <8319e2d604121511277a170fb@mail.gmail.com> References: <41BE47D1.9080907@tonybibbs.com> <8319e2d604121320542af0ca86@mail.gmail.com> <41BEF917.4030806@tonybibbs.com> <41C076BE.9040103@tonybibbs.com> <8319e2d604121510035870297b@mail.gmail.com> <41C084BD.7010503@tonybibbs.com> <41C08AB3.60509@tonybibbs.com> <8319e2d604121511277a170fb@mail.gmail.com> Message-ID: <16610.192.136.16.3.1103139394.squirrel@192.136.16.3> > Also, I'd like to vote for writing the xml and then generating the sql > ddl rather than the other way around. It seems much cleaner to me. The DBA in me would vote that way too. The developer in me might disagree. :) Dwight From tony at tonybibbs.com Wed Dec 15 14:45:05 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 15 Dec 2004 13:45:05 -0600 Subject: [geeklog-devel] GL2 ACL In-Reply-To: <8319e2d604121511277a170fb@mail.gmail.com> References: <41BE47D1.9080907@tonybibbs.com> <8319e2d604121320542af0ca86@mail.gmail.com> <41BEF917.4030806@tonybibbs.com> <41C076BE.9040103@tonybibbs.com> <8319e2d604121510035870297b@mail.gmail.com> <41C084BD.7010503@tonybibbs.com> <41C08AB3.60509@tonybibbs.com> <8319e2d604121511277a170fb@mail.gmail.com> Message-ID: <41C09441.2020008@tonybibbs.com> Vincent Furia wrote: >Yup, though you'd probably want to throw an autoincrement int in front >as a primary key. Indexes would have go on user_id and group_id and >item_id. > > Sounds good. >Also, I'd like to vote for writing the xml and then generating the sql >ddl rather than the other way around. It seems much cleaner to me. > > Sorry, I think backwards. Actually the beauty of this is that this is a developer-by-developer preference. Actually, I submitted a patch to a bug in Propel that was caused Propel to ignore MySQL's foreign keys. This is because back when Propel was started, foreign keys in MySQL were in their infancy. Given that, I think you'd have a similar 'bug' going the other direction...but I could be wrong. --Tony From tony at tonybibbs.com Wed Dec 15 14:55:58 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 15 Dec 2004 13:55:58 -0600 Subject: [geeklog-devel] Blocks in GL2 as Plugin? Message-ID: <41C096CE.1030904@tonybibbs.com> Were any of you thinking blocks would be part of the actual GL2 kernel or should they exist, instead, as a plugin? The more I think of it, the more I think they are simply a plugin...though, they will probably be used to render content served up by nearly every other plugin that would be installed. --Tony From tony at tonybibbs.com Wed Dec 15 15:50:14 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 15 Dec 2004 14:50:14 -0600 Subject: [geeklog-devel] Custom user attributes in GL2 Message-ID: <41C0A386.4020804@tonybibbs.com> Anybody have any input on how to best address providing the community with fairly easy way to add custom attributes for users in GL2? I don't I have a good idea on how to do this. My hopes are that plugins would have their own one-to-one mapping from the core user table to their own user table with addition information. Assuming that is OK, how do we handle things the site admin simply wants to add (e.g. msn id, pgp key, etc). --Tony From dwight at trumbower.com Wed Dec 15 16:16:44 2004 From: dwight at trumbower.com (dwight at trumbower.com) Date: Wed, 15 Dec 2004 16:16:44 -0500 (EST) Subject: [geeklog-devel] Custom user attributes in GL2 In-Reply-To: <41C0A386.4020804@tonybibbs.com> References: <41C0A386.4020804@tonybibbs.com> Message-ID: <18160.192.136.16.3.1103145404.squirrel@192.136.16.3> The easiest way I know of, one table. column name - String column type - specifies, long, int, string ect column data - data as a string Might need xref table to show where it is used. At least this is how would start. > Anybody have any input on how to best address providing the community > with fairly easy way to add custom attributes for users in GL2? > > I don't I have a good idea on how to do this. My hopes are that plugins > would have their own one-to-one mapping from the core user table to > their own user table with addition information. Assuming that is OK, > how do we handle things the site admin simply wants to add (e.g. msn id, > pgp key, etc). > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From dirk at haun-online.de Wed Dec 15 16:21:09 2004 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 15 Dec 2004 22:21:09 +0100 Subject: [geeklog-devel] Filtering in GL2 In-Reply-To: <41BE33F6.3000304@tonybibbs.com> References: <41BE33F6.3000304@tonybibbs.com> Message-ID: <20041215212109.16678@smtp.haun-online.de> Tony, >Quote handling in GL2 should be transparent to the developer. Recall >that all custom SQL goes into a named query file and that the SQL that >goes in there should use prepared SQL as opposed to the kind of SQL >found in 1.3.x. What about SQL injection attempts then? There's several sorts of filtering that have to be done, and ideally (I think), they should be handled by different "entities" (for lack of a better word), as opposed to the all-in-one approach that 1.3's COM_applyFilter implements. I.e. an SQL request should be parsed for injections / malformed SQL by the entity that handles SQL (would that be Propel then or Creole?). JavaScript, unwanted HTML, etc. should be handled by the module that handles the post (or whatever data is being processed), as it may be acceptable for one module, but unacceptable for another. bye, Dirk -- http://www.haun-online.de/ http://geeklog.info/ From vfuria at gmail.com Wed Dec 15 16:57:58 2004 From: vfuria at gmail.com (Vincent Furia) Date: Wed, 15 Dec 2004 16:57:58 -0500 Subject: [geeklog-devel] Custom user attributes in GL2 In-Reply-To: <18160.192.136.16.3.1103145404.squirrel@192.136.16.3> References: <41C0A386.4020804@tonybibbs.com> <18160.192.136.16.3.1103145404.squirrel@192.136.16.3> Message-ID: <8319e2d6041215135717910b51@mail.gmail.com> I'm with Dwight. This way all user data is in one place (and the plugins can put user data there as well). -Vinny On Wed, 15 Dec 2004 16:16:44 -0500 (EST), dwight at trumbower.com wrote: > The easiest way I know of, one table. > > column name - String > column type - specifies, long, int, string ect > column data - data as a string > > Might need xref table to show where it is used. At least this is how would > start. > > > > Anybody have any input on how to best address providing the community > > with fairly easy way to add custom attributes for users in GL2? > > > > I don't I have a good idea on how to do this. My hopes are that plugins > > would have their own one-to-one mapping from the core user table to > > their own user table with addition information. Assuming that is OK, > > how do we handle things the site admin simply wants to add (e.g. msn id, > > pgp key, etc). > > > > --Tony > > _______________________________________________ > > geeklog-devel mailing list > > geeklog-devel at lists.geeklog.net > > http://lists.geeklog.net/listinfo/geeklog-devel > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Wed Dec 15 17:17:22 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 15 Dec 2004 16:17:22 -0600 Subject: [geeklog-devel] Filtering in GL2 In-Reply-To: <20041215212109.16678@smtp.haun-online.de> References: <41BE33F6.3000304@tonybibbs.com> <20041215212109.16678@smtp.haun-online.de> Message-ID: <41C0B7F2.6040806@tonybibbs.com> My response is below. Dirk Haun wrote: >What about SQL injection attempts then? > >There's several sorts of filtering that have to be done, and ideally (I >think), they should be handled by different "entities" (for lack of a >better word), as opposed to the all-in-one approach that 1.3's >COM_applyFilter implements. > >I.e. an SQL request should be parsed for injections / malformed SQL by >the entity that handles SQL (would that be Propel then or Creole?). > >JavaScript, unwanted HTML, etc. should be handled by the module that >handles the post (or whatever data is being processed), as it may be >acceptable for one module, but unacceptable for another. > > That's understandable. However, it is worth noting a few things: 1) As a GL2 standard, any custom sql (i.e. that not automatically created by propel) must be in a prepared statement format. This standard automatically makes GL2 less vulnerable (read the section "Why use prepared statements" on this page: http://dev.mysql.com/tech-resources/articles/4.1/prepared-statements.html Now, I realize this is MySQL specific and I hope to maintain DB independence but nearly all 'real' DBMS support some form of prepared statements. 2) Saving using the save() method on the Propel generated domain objects all get converted to prepared statements. So, not to be naive, SQL injection may still be possible but it should be considerably harder for a programmer in GL2 to allow for such a thing to happen. That only takes care of, to a large degree, SQL injections. All your other points are valid and I think that having a single class with a bunch of atomic filter methods for various things (i.e. javascript, html, etc) makes sense at the kernel level...not necessarily at the plugin level. I only say that because if we have at least a base filtering class in the kernel, each plugin can override it as needed (in fact, I think this makes sense as a 1.3.x enhancement). And if I heard right, Blaine will be doing a draft of this class, no? --Tony From tony at tonybibbs.com Wed Dec 15 17:24:09 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 15 Dec 2004 16:24:09 -0600 Subject: [geeklog-devel] Custom user attributes in GL2 In-Reply-To: <8319e2d6041215135717910b51@mail.gmail.com> References: <41C0A386.4020804@tonybibbs.com> <18160.192.136.16.3.1103145404.squirrel@192.136.16.3> <8319e2d6041215135717910b51@mail.gmail.com> Message-ID: <41C0B989.6010900@tonybibbs.com> I'm fine with data driving the custom user stuff..l I would still say, though, you'd want real columns in the GL2 user table for thing we know we need (i.e. username, password, etc) for performance reasons alone, right? Regardless, going this route will make the use of Propel a little bit messy as the user class generated by propel won't know anything about the custom attributes in the database. Also, for clarity, are you suggesting we do this for all plugin specific user attributes? I don't think you are and if you are we probably want to discuss the pros/cons between that and having a plugins specific user table with a one-to-one relationship with the kernel user table. --Tony Vincent Furia wrote: >I'm with Dwight. This way all user data is in one place (and the >plugins can put user data there as well). > >-Vinny > > >On Wed, 15 Dec 2004 16:16:44 -0500 (EST), dwight at trumbower.com > wrote: > > >>The easiest way I know of, one table. >> >>column name - String >>column type - specifies, long, int, string ect >>column data - data as a string >> >>Might need xref table to show where it is used. At least this is how would >>start. >> >> >> >> >>>Anybody have any input on how to best address providing the community >>>with fairly easy way to add custom attributes for users in GL2? >>> >>>I don't I have a good idea on how to do this. My hopes are that plugins >>>would have their own one-to-one mapping from the core user table to >>>their own user table with addition information. Assuming that is OK, >>>how do we handle things the site admin simply wants to add (e.g. msn id, >>>pgp key, etc). >>> >>>--Tony >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From dwight at trumbower.com Wed Dec 15 17:36:01 2004 From: dwight at trumbower.com (dwight at trumbower.com) Date: Wed, 15 Dec 2004 17:36:01 -0500 (EST) Subject: [geeklog-devel] Custom user attributes in GL2 In-Reply-To: <41C0B989.6010900@tonybibbs.com> References: <41C0A386.4020804@tonybibbs.com> <18160.192.136.16.3.1103145404.squirrel@192.136.16.3> <8319e2d6041215135717910b51@mail.gmail.com> <41C0B989.6010900@tonybibbs.com> Message-ID: <41673.192.136.16.3.1103150161.squirrel@192.136.16.3> Ok, I'm confused. I don't see username and password as custom attributes. Custom attributes are usually used to enhance the base package and allow customers to add a few fields of data to customize a screen. The old days, you just created 5-10 fields, called user1, user2,...user10. So every table had 10 extra fields. The new way puts only the fields you want in a combined table, just like your List Of Values(LOV) table. The hard part is displaying these fields. The easiest way is to have them all grouped together at the end of a screen. Know when people want to move them around in different places, it gets tricky. Also if you need to handle select option fields, radio fields and check box fields there will need some more supporting tables. Dwight > I'm fine with data driving the custom user stuff..l > > I would still say, though, you'd want real columns in the GL2 user table > for thing we know we need (i.e. username, password, etc) for performance > reasons alone, right? Regardless, going this route will make the use of > Propel a little bit messy as the user class generated by propel won't > know anything about the custom attributes in the database. > > Also, for clarity, are you suggesting we do this for all plugin specific > user attributes? I don't think you are and if you are we probably want > to discuss the pros/cons between that and having a plugins specific user > table with a one-to-one relationship with the kernel user table. > > --Tony > > Vincent Furia wrote: > >>I'm with Dwight. This way all user data is in one place (and the >>plugins can put user data there as well). >> >>-Vinny >> >> >>On Wed, 15 Dec 2004 16:16:44 -0500 (EST), dwight at trumbower.com >> wrote: >> >> >>>The easiest way I know of, one table. >>> >>>column name - String >>>column type - specifies, long, int, string ect >>>column data - data as a string >>> >>>Might need xref table to show where it is used. At least this is how >>> would >>>start. >>> >>> >>> >>> >>>>Anybody have any input on how to best address providing the community >>>>with fairly easy way to add custom attributes for users in GL2? >>>> >>>>I don't I have a good idea on how to do this. My hopes are that >>>> plugins >>>>would have their own one-to-one mapping from the core user table to >>>>their own user table with addition information. Assuming that is OK, >>>>how do we handle things the site admin simply wants to add (e.g. msn >>>> id, >>>>pgp key, etc). >>>> >>>>--Tony >>>>_______________________________________________ >>>>geeklog-devel mailing list >>>>geeklog-devel at lists.geeklog.net >>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>> >>>> >>>> >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Wed Dec 15 17:38:22 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 15 Dec 2004 16:38:22 -0600 Subject: [geeklog-devel] Draft of schema for GL2 Message-ID: <41C0BCDE.9080709@tonybibbs.com> Here is the database creates for GL2. NOTE: this does not work in MySQL yet...I tried it and got a few bugs to work out but I'm sending it more for conversation than actual use. Tomorrow I will work those kinks out and generate the first Propel classes from them. Please review and critique... --Tony -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: create.sql URL: From tony at tonybibbs.com Wed Dec 15 17:41:15 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 15 Dec 2004 16:41:15 -0600 Subject: [geeklog-devel] Custom user attributes in GL2 In-Reply-To: <41673.192.136.16.3.1103150161.squirrel@192.136.16.3> References: <41C0A386.4020804@tonybibbs.com> <18160.192.136.16.3.1103145404.squirrel@192.136.16.3> <8319e2d6041215135717910b51@mail.gmail.com> <41C0B989.6010900@tonybibbs.com> <41673.192.136.16.3.1103150161.squirrel@192.136.16.3> Message-ID: <41C0BD8B.9020208@tonybibbs.com> Your saying the same thing I am. I was bit confused by Vinny's response which sounded a bit like (put everything in there) which I am guessing he didn't mean but I wanted to be perfectly clear on. I think your table will be more complicated...you'll probably want things like min/max values, required indicators, etc. That's in addition to the ability to choose from a finite set of values. The more I think about it, the more I think we might want to delay doing anything with customer user attributes until we get to a point where the kernel is up and plugins are being written. Thoughts? --Tony dwight at trumbower.com wrote: >Ok, I'm confused. I don't see username and password as custom attributes. > >Custom attributes are usually used to enhance the base package and allow >customers to add a few fields of data to customize a screen. The old days, >you just created 5-10 fields, called user1, user2,...user10. So every >table had 10 extra fields. > >The new way puts only the fields you want in a combined table, just like >your List Of Values(LOV) table. > >The hard part is displaying these fields. The easiest way is to have them >all grouped together at the end of a screen. Know when people want to move >them around in different places, it gets tricky. > >Also if you need to handle select option fields, radio fields and check >box fields there will need some more supporting tables. > > >Dwight > > > > > >>I'm fine with data driving the custom user stuff..l >> >>I would still say, though, you'd want real columns in the GL2 user table >>for thing we know we need (i.e. username, password, etc) for performance >>reasons alone, right? Regardless, going this route will make the use of >>Propel a little bit messy as the user class generated by propel won't >>know anything about the custom attributes in the database. >> >>Also, for clarity, are you suggesting we do this for all plugin specific >>user attributes? I don't think you are and if you are we probably want >>to discuss the pros/cons between that and having a plugins specific user >>table with a one-to-one relationship with the kernel user table. >> >>--Tony >> >>Vincent Furia wrote: >> >> >> >>>I'm with Dwight. This way all user data is in one place (and the >>>plugins can put user data there as well). >>> >>>-Vinny >>> >>> >>>On Wed, 15 Dec 2004 16:16:44 -0500 (EST), dwight at trumbower.com >>> wrote: >>> >>> >>> >>> >>>>The easiest way I know of, one table. >>>> >>>>column name - String >>>>column type - specifies, long, int, string ect >>>>column data - data as a string >>>> >>>>Might need xref table to show where it is used. At least this is how >>>>would >>>>start. >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Anybody have any input on how to best address providing the community >>>>>with fairly easy way to add custom attributes for users in GL2? >>>>> >>>>>I don't I have a good idea on how to do this. My hopes are that >>>>>plugins >>>>>would have their own one-to-one mapping from the core user table to >>>>>their own user table with addition information. Assuming that is OK, >>>>>how do we handle things the site admin simply wants to add (e.g. msn >>>>>id, >>>>>pgp key, etc). >>>>> >>>>>--Tony >>>>>_______________________________________________ >>>>>geeklog-devel mailing list >>>>>geeklog-devel at lists.geeklog.net >>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>> >>>>> >>>>> >>>>> >>>>> >>>>_______________________________________________ >>>>geeklog-devel mailing list >>>>geeklog-devel at lists.geeklog.net >>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>> >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From vfuria at gmail.com Wed Dec 15 21:00:42 2004 From: vfuria at gmail.com (Vincent Furia) Date: Wed, 15 Dec 2004 21:00:42 -0500 Subject: [geeklog-devel] Custom user attributes in GL2 In-Reply-To: <41C0BD8B.9020208@tonybibbs.com> References: <41C0A386.4020804@tonybibbs.com> <18160.192.136.16.3.1103145404.squirrel@192.136.16.3> <8319e2d6041215135717910b51@mail.gmail.com> <41C0B989.6010900@tonybibbs.com> <41673.192.136.16.3.1103150161.squirrel@192.136.16.3> <41C0BD8B.9020208@tonybibbs.com> Message-ID: <8319e2d60412151800cdd82b2@mail.gmail.com> How about this: do the absolute minimum and create a plugin to handle custom user info. That fits more with our paradigm, right? -Vinny On Wed, 15 Dec 2004 16:41:15 -0600, Tony Bibbs wrote: > Your saying the same thing I am. I was bit confused by Vinny's response > which sounded a bit like (put everything in there) which I am guessing > he didn't mean but I wanted to be perfectly clear on. I think your > table will be more complicated...you'll probably want things like > min/max values, required indicators, etc. That's in addition to the > ability to choose from a finite set of values. > > The more I think about it, the more I think we might want to delay doing > anything with customer user attributes until we get to a point where the > kernel is up and plugins are being written. Thoughts? > > --Tony > > dwight at trumbower.com wrote: > > >Ok, I'm confused. I don't see username and password as custom attributes. > > > >Custom attributes are usually used to enhance the base package and allow > >customers to add a few fields of data to customize a screen. The old days, > >you just created 5-10 fields, called user1, user2,...user10. So every > >table had 10 extra fields. > > > >The new way puts only the fields you want in a combined table, just like > >your List Of Values(LOV) table. > > > >The hard part is displaying these fields. The easiest way is to have them > >all grouped together at the end of a screen. Know when people want to move > >them around in different places, it gets tricky. > > > >Also if you need to handle select option fields, radio fields and check > >box fields there will need some more supporting tables. > > > > > >Dwight > > > > > > > > > > > >>I'm fine with data driving the custom user stuff..l > >> > >>I would still say, though, you'd want real columns in the GL2 user table > >>for thing we know we need (i.e. username, password, etc) for performance > >>reasons alone, right? Regardless, going this route will make the use of > >>Propel a little bit messy as the user class generated by propel won't > >>know anything about the custom attributes in the database. > >> > >>Also, for clarity, are you suggesting we do this for all plugin specific > >>user attributes? I don't think you are and if you are we probably want > >>to discuss the pros/cons between that and having a plugins specific user > >>table with a one-to-one relationship with the kernel user table. > >> > >>--Tony > >> > >>Vincent Furia wrote: > >> > >> > >> > >>>I'm with Dwight. This way all user data is in one place (and the > >>>plugins can put user data there as well). > >>> > >>>-Vinny > >>> > >>> > >>>On Wed, 15 Dec 2004 16:16:44 -0500 (EST), dwight at trumbower.com > >>> wrote: > >>> > >>> > >>> > >>> > >>>>The easiest way I know of, one table. > >>>> > >>>>column name - String > >>>>column type - specifies, long, int, string ect > >>>>column data - data as a string > >>>> > >>>>Might need xref table to show where it is used. At least this is how > >>>>would > >>>>start. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Anybody have any input on how to best address providing the community > >>>>>with fairly easy way to add custom attributes for users in GL2? > >>>>> > >>>>>I don't I have a good idea on how to do this. My hopes are that > >>>>>plugins > >>>>>would have their own one-to-one mapping from the core user table to > >>>>>their own user table with addition information. Assuming that is OK, > >>>>>how do we handle things the site admin simply wants to add (e.g. msn > >>>>>id, > >>>>>pgp key, etc). > >>>>> > >>>>>--Tony > >>>>>_______________________________________________ > >>>>>geeklog-devel mailing list > >>>>>geeklog-devel at lists.geeklog.net > >>>>>http://lists.geeklog.net/listinfo/geeklog-devel > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>_______________________________________________ > >>>>geeklog-devel mailing list > >>>>geeklog-devel at lists.geeklog.net > >>>>http://lists.geeklog.net/listinfo/geeklog-devel > >>>> > >>>> > >>>> > >>>> > >>>> > >>>_______________________________________________ > >>>geeklog-devel mailing list > >>>geeklog-devel at lists.geeklog.net > >>>http://lists.geeklog.net/listinfo/geeklog-devel > >>> > >>> > >>> > >>> > >>_______________________________________________ > >>geeklog-devel mailing list > >>geeklog-devel at lists.geeklog.net > >>http://lists.geeklog.net/listinfo/geeklog-devel > >> > >> > >> > > > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From vfuria at gmail.com Wed Dec 15 22:49:19 2004 From: vfuria at gmail.com (Vincent Furia) Date: Wed, 15 Dec 2004 22:49:19 -0500 Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <41C0BCDE.9080709@tonybibbs.com> References: <41C0BCDE.9080709@tonybibbs.com> Message-ID: <8319e2d6041215194928e8cf17@mail.gmail.com> Comments in line, hopefully this method of commenting will work... On Wed, 15 Dec 2004 16:38:22 -0600, Tony Bibbs wrote: > CREATE TABLE gl2_list_of_values ( > lov_id int unsigned NOT NULL auto_increment, > group_name varchar(30) NOT NULL, > short_name varchar(40) NOT NULL, > description varchar(128), > enabled tinyint NOT NULL DEFAULT 1, > sort_order mediumint NOT NULL DEFAULT '0', > PRIMARY KEY (lov_id), > INDEX (group_name), > INDEX (short_name), > INDEX (enabled) > ) TYPE=INNODB; I just don't like the name, but I can't come up with anything better (how is that for useless input?). > CREATE TABLE gl2_event ( Another name issue, this one with a suggestion and a valid reason: What about "action" instead of "event" the problem here is a language domain collision between our idea of gl2 events vs. calendar events. "action" is a possible replacement, so is "act" or any synonym that makes sense. I'm open to suggestions, but I think "event" needs to change. (And I know, I'm the one who called them "events" to begin with). > event_id int unsigned NOT NULL auto_increment, > event_name varchar(40) NOT NULL, NEW COLUMN: event_plugin_id int unsigned NOT NULL DESC force events to be associated with a specific plugin > description varchar (255) NOT NULL, > PRIMARY KEY(event_id), > INDEX(event_name) > ) TYPE=INNODB; > > CREATE TABLE gl2_plugin ( > plugin_id int unsigned NOT NULL auto_increment, > plugin_name varchar(128) NOT NULL, > version varchar(20) NOT NULL, > homepage varchar(128) NOT NULL, > enabled tinyint unsigned NOT NULL DEFAULT 1, > PRIMARY KEY(plugin_id), > INDEX(plugin_name), > INDEX(enabled) > ) TYPE=INNODB; We might want to require that version be a float (or int?) so that we can do version dependency checking with some reasonable results. (i.e. check for version of forum >= 2.3). > > CREATE TABLE gl2_eventListener ( > event_id int unsigned NOT NULL, > plugin_id int unsigned NOT NULL, > PRIMARY KEY(event_id, plugin_id), > FOREIGN KEY (event_id) REFERENCES gl2_event(event_id), > FOREIGN KEY (plugin_id) REFERENCES gl2_plugin(plugin_id) > ) TYPE=INNODB; > > CREATE TABLE gl2_user ( > user_id int unsigned NOT NULL auto_increment, > registration_date int unsigned NOT NULL, > profile_views mediumint unsigned NOT NULL DEFAULT 0, we should consider keeping counts in a separate table, hopefully this will prevent the locking issues previously experienced with article view counts. We could recommend that plugins use the same table as needed. > items_per_page tinyint unsigned NOT NULL DEFAULT 10, > language_id int unsigned NOT NULL, > user_name varchar(25) NOT NULL, > password varchar(35) NOT NULL, > enabled tinyint unsigned NOT NULL, > email VARCHAR(128) NOT NULL, > comment_mode_id int unsigned NOT NULL, > comment_order_id int unsigned NOT NULL, > comment_limit tinyint unsigned NOT NULL default '0', > cookie_timeout int unsigned NOT NULL, > locale varchar(3), > date_format_id int unsigned NOT NULL, > blocks_enabled tinyint unsigned DEFAULT 1, > PRIMARY KEY(user_id), > INDEX (user_name), > INDEX (enabled), > INDEX (email), > FOREIGN KEY (comment_mode_id) REFERENCES gl2_list_of_values(lov_id), > FOREIGN KEY (comment_order_id) REFERENCES gl2_list_of_values(lov_id), > FOREIGN KEY (date_format_id) REFERENCES gl2_list_of_values(lov_id) > ) TYPE=INNODB; > > CREATE TABLE gl2_user_supp ( > user_id int unsigned NOT NULL, > signature varchar(128), > biography text, > first_name varchar(30), > last_name varchar(30), > homepage varchar(50), > PRIMARY KEY(user_id), > FOREIGN KEY(user_id) REFERENCES gl2_user(user_id), > ) TYPE=INNODB; I think this table should be combined with the gl2_user. I like the idea of having a plugin that will handle supplemental user information. > > CREATE TABLE gl2_group ( > group_id int unsigned NOT NULL auto_increment, > logical_name varchar(30) NOT NULL, > display_name varchar(50) NOT NULL, > description varchar(255) NOT NULL, > ) TYPE=INNODB; What is the difference between a "logical name" and a "display name"? Is differentiating them necessary? > > CREATE TABLE gl2_privilege ( > code varchar(30) NOT NULL, > description varchar(255) NOT NULL, > PRIMARY KEY(code) > ) TYPE=INNODB; > > CREATE TABLE gl2_privilege_access ( > code varchar(30) NOT NULL, > user_id int unsigned, > group_id int unsigned, > INDEX(code), > FOREIGN KEY(user_id) REFERENCES gl2_user(user_id), > FOREIGN KEY(group_id) REFERENCES gl2_group(group_id) > ) TYPE=INNODB; > > CREATE TABLE gl2_group_assignment ( > main_group_id int unsigned NOT NULL, > assigned_user_id int unsigned, > assigned_group_id int unsigned, > FOREIGN KEY(main_group_id) REFERENCES gl2_group(group_id), > FOREIGN KEY(assigned_user_id) REFERENCES gl2_user(user_id), > FOREIGN KEY(assigned_group_id) REFERENCES gl2_group(group_id) > ) TYPE=INNODB; > > CREATE TABLE gl2_ban ( > ban_id int unsigned NOT NULL auto_increment, > user_id int unsigned, > ip_address varchar(11), > start_date int unsigned NOT NULL, > end_date int unsigned NOT NULL, > reason_id int unsigned NOT NULL, > PRIMARY KEY(ban_id), > FOREIGN KEY(user_id) REFERENCES gl2_user(user_id), > FOREIGN KEY(reason_id) REFERENCES gl2_list_of_values(lov_id) > ) TYPE=INNODB; I think ban should be a plugin... > > CREATE TABLE gl2_catalog ( > catalog_id mediumint unsigned NOT NULL auto_increment, > catalog_name varchar(50) NOT NULL > date_created int unsigned NOT NULL > ) TYPE=INNODB; A catalog is just a set of categories correct? Why not keep that info in the gl2_category table? (i.e. what's the justification for a separate table). Alternatively should it just go in the list_of_values table? Why keep the date created? > > CREATE TABLE gl2_category ( > category_id mediumint unsigned NOT NULL, > catalog_id mediumint unsigned NOT NULL, > category_name varchar NOT NULL, > parent_category_id mediumint unsigned NOT NULL, > image_url VARCHAR(128) DEFAULT 'NULL', > sort_num tinyint unsigned DEFAULT NULL, > enabled tinyint unsigned NOT NULL DEFAULT 1, > owner_id int unsigned NOT NULL, > group_id mediumint unsigned NOT NULL, > owner_permissions tinyint unsigned NOT NULL, > anon_permissions tinyint unsigned NOT NULL, > member_permissions tinyint NOT NULL, > group_permissions tinyint NOT NULL, > FOREIGN KEY (catalog_id) REFERENCES gl2_catalog(catalog_id), > INDEX (enabled) > ) TYPE=INNODB; Should we use the modified preorder traversal numbering to store the hierarchical structure of the categories within a catalog (i.e. like comments in 1.3.10)? All the owner/group id and permissions stuff should be removed...just use the acl table. We don't want to deal with two different systems for determining permissions. In fact, why not make categories "items"? (then categories can be in categories, won't that be cool?) > > CREATE TABLE gl2_item ( > item_id int unsigned NOT NULL auto_increment, > type_id int unsigned NOT NULL, > user_id int unsigned NOT NULL, > category_id INT unsigned NOT NULL, > date_created int unsigned NOT NULL, > num_views mediumint unsigned NOT NULL DEFAULT 0, > state_id int unsigned NOT NULL, > num_emails mediumint unsigned NOT NULL DEFAULT 0, I think the num_views and num_emails should be moved to a separate table (see gl2_user table above). > num_ratings mediumint unsigned NOT NULL DEFAULT 0, > rating_sum int unsigned NOT NULL DEFAULT 0, I think ratings should be handled by a plugin. > expiration_date int unsigned DEFAULT NULL, > parent_item_id int unsigned DEFAULT NULL, NEW COLUMN: enabled tinyint DEFAULT 1 DESC have the ability to "switch off" items. > PRIMARY KEY(item_id), > FOREIGN KEY(type_id) REFERENCES gl2_list_of_values(lov_id), > FOREIGN KEY(user_id) REFERENCES gl2_user(user_id), > FOREIGN KEY(category_id) REFERENCES gl2_catgory(category_id), > FOREIGN KEY(state_id) REFERENCES gl2_item_type_state(state_id), > FOREIGN KEY(parent_item_id) REFERENCES gl2_item(item_id) > ) TYPE=INNODB; Do we want an association table between items and categories so items can be in multiple categories? > > CREATE TABLE gl2_item_acl ( > acl_id int unsigned NOT NULL auto_increment, > item_id int unsigned NOT NULL, > user_id int unsigned, > group_id int unsigned, > rights smallint unsigned NOT NULL, > PRIMARY KEY(acl_id), > FOREIGN KEY(item_id) REFERENCES gl2_item(item_id), > FOREIGN KEY(user_id) REFERENCES gl2_user(user_id), > FOREIGN KEY(group_id) REFERENCES gl2_group(group_id) > ) TYPE=INNODB; Looks good > > CREATE TABLE gl2_comment ( > comment_id int unsigned NOT NULL auto_increment, > item_id int unsigned NOT NULL, > subject varchar(50) NOT NULL, > comment_text text NOT NULL, > parent_id int unsigned, > ip_address varchar(11) NOT NULL > PRIMARY KEY(comment_id), > FOREIGN KEY(item_id) REFERENCES gl2_item(item_id), > FOREIGN KEY(parent_id) REFERENCES gl2_comment(comment_id) > ) TYPE=INNODB; Should comments be a plugin? That way if you want a "forum like" comment vs traditional system you can just switch out the plugin? If you really (REALLY) want this do you want to keep the hierarchical comment structure we added to 1.3.10 (modified preorder traversal) > > CREATE TABLE gl2_item_type_state ( > state_id int unsigned NOT NULL auto_increment, > type_id int unsigned NOT NULL, > state_name varchar(30) NOT NULL, > description varchar(255), > PRIMARY KEY(state_id), > FOREIGN KEY(type_id) REFERENCES gl2_list_of_values(lov_id) > ) TYPE=INNODB; If these are going to be different for different items, shouldn't it be kept by the individual plugin managing the item? From tony at tonybibbs.com Wed Dec 15 22:49:08 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 15 Dec 2004 21:49:08 -0600 Subject: [geeklog-devel] Custom user attributes in GL2 In-Reply-To: <8319e2d60412151800cdd82b2@mail.gmail.com> References: <41C0A386.4020804@tonybibbs.com> <18160.192.136.16.3.1103145404.squirrel@192.136.16.3> <8319e2d6041215135717910b51@mail.gmail.com> <41C0B989.6010900@tonybibbs.com> <41673.192.136.16.3.1103150161.squirrel@192.136.16.3> <41C0BD8B.9020208@tonybibbs.com> <8319e2d60412151800cdd82b2@mail.gmail.com> Message-ID: <41C105B4.7070608@tonybibbs.com> DIng, ding, ding I think we have a winner. Only thing is how you would customize the content based on the existence (or lack thereof) of such a plugin. --Tony Vincent Furia wrote: >How about this: do the absolute minimum and create a plugin to handle >custom user info. That fits more with our paradigm, right? > >-Vinny > >On Wed, 15 Dec 2004 16:41:15 -0600, Tony Bibbs wrote: > > >>Your saying the same thing I am. I was bit confused by Vinny's response >>which sounded a bit like (put everything in there) which I am guessing >>he didn't mean but I wanted to be perfectly clear on. I think your >>table will be more complicated...you'll probably want things like >>min/max values, required indicators, etc. That's in addition to the >>ability to choose from a finite set of values. >> >>The more I think about it, the more I think we might want to delay doing >>anything with customer user attributes until we get to a point where the >>kernel is up and plugins are being written. Thoughts? >> >>--Tony >> >>dwight at trumbower.com wrote: >> >> >> >>>Ok, I'm confused. I don't see username and password as custom attributes. >>> >>>Custom attributes are usually used to enhance the base package and allow >>>customers to add a few fields of data to customize a screen. The old days, >>>you just created 5-10 fields, called user1, user2,...user10. So every >>>table had 10 extra fields. >>> >>>The new way puts only the fields you want in a combined table, just like >>>your List Of Values(LOV) table. >>> >>>The hard part is displaying these fields. The easiest way is to have them >>>all grouped together at the end of a screen. Know when people want to move >>>them around in different places, it gets tricky. >>> >>>Also if you need to handle select option fields, radio fields and check >>>box fields there will need some more supporting tables. >>> >>> >>>Dwight >>> >>> >>> >>> >>> >>> >>> >>>>I'm fine with data driving the custom user stuff..l >>>> >>>>I would still say, though, you'd want real columns in the GL2 user table >>>>for thing we know we need (i.e. username, password, etc) for performance >>>>reasons alone, right? Regardless, going this route will make the use of >>>>Propel a little bit messy as the user class generated by propel won't >>>>know anything about the custom attributes in the database. >>>> >>>>Also, for clarity, are you suggesting we do this for all plugin specific >>>>user attributes? I don't think you are and if you are we probably want >>>>to discuss the pros/cons between that and having a plugins specific user >>>>table with a one-to-one relationship with the kernel user table. >>>> >>>>--Tony >>>> >>>>Vincent Furia wrote: >>>> >>>> >>>> >>>> >>>> >>>>>I'm with Dwight. This way all user data is in one place (and the >>>>>plugins can put user data there as well). >>>>> >>>>>-Vinny >>>>> >>>>> >>>>>On Wed, 15 Dec 2004 16:16:44 -0500 (EST), dwight at trumbower.com >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>The easiest way I know of, one table. >>>>>> >>>>>>column name - String >>>>>>column type - specifies, long, int, string ect >>>>>>column data - data as a string >>>>>> >>>>>>Might need xref table to show where it is used. At least this is how >>>>>>would >>>>>>start. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Anybody have any input on how to best address providing the community >>>>>>>with fairly easy way to add custom attributes for users in GL2? >>>>>>> >>>>>>>I don't I have a good idea on how to do this. My hopes are that >>>>>>>plugins >>>>>>>would have their own one-to-one mapping from the core user table to >>>>>>>their own user table with addition information. Assuming that is OK, >>>>>>>how do we handle things the site admin simply wants to add (e.g. msn >>>>>>>id, >>>>>>>pgp key, etc). >>>>>>> >>>>>>>--Tony >>>>>>>_______________________________________________ >>>>>>>geeklog-devel mailing list >>>>>>>geeklog-devel at lists.geeklog.net >>>>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>_______________________________________________ >>>>>>geeklog-devel mailing list >>>>>>geeklog-devel at lists.geeklog.net >>>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>_______________________________________________ >>>>>geeklog-devel mailing list >>>>>geeklog-devel at lists.geeklog.net >>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>_______________________________________________ >>>>geeklog-devel mailing list >>>>geeklog-devel at lists.geeklog.net >>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>> >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From vfuria at gmail.com Wed Dec 15 22:53:18 2004 From: vfuria at gmail.com (Vincent Furia) Date: Wed, 15 Dec 2004 22:53:18 -0500 Subject: [geeklog-devel] Blocks in GL2 as Plugin? In-Reply-To: <41C096CE.1030904@tonybibbs.com> References: <41C096CE.1030904@tonybibbs.com> Message-ID: <8319e2d6041215195391a132b@mail.gmail.com> Instead of a "block plugin" how about individual plugins be able to generate blocks as they want (and how the admin configures). This can even include "center block" stuff. We could have a generic plugin that is available for adding random blocks. Also we could have a totally separate plugin to handle RDF/RSS blocks. More complicated blocks, say a weather block, could be their own plugin. -Vinny On Wed, 15 Dec 2004 13:55:58 -0600, Tony Bibbs wrote: > Were any of you thinking blocks would be part of the actual GL2 kernel > or should they exist, instead, as a plugin? The more I think of it, the > more I think they are simply a plugin...though, they will probably be > used to render content served up by nearly every other plugin that would > be installed. > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From vfuria at gmail.com Wed Dec 15 23:00:06 2004 From: vfuria at gmail.com (Vincent Furia) Date: Wed, 15 Dec 2004 23:00:06 -0500 Subject: [geeklog-devel] Custom user attributes in GL2 In-Reply-To: <41C105B4.7070608@tonybibbs.com> References: <41C0A386.4020804@tonybibbs.com> <18160.192.136.16.3.1103145404.squirrel@192.136.16.3> <8319e2d6041215135717910b51@mail.gmail.com> <41C0B989.6010900@tonybibbs.com> <41673.192.136.16.3.1103150161.squirrel@192.136.16.3> <41C0BD8B.9020208@tonybibbs.com> <8319e2d60412151800cdd82b2@mail.gmail.com> <41C105B4.7070608@tonybibbs.com> Message-ID: <8319e2d604121520003720cef1@mail.gmail.com> On Wed, 15 Dec 2004 21:49:08 -0600, Tony Bibbs wrote: > DIng, ding, ding I think we have a winner. > > Only thing is how you would customize the content based on the existence > (or lack thereof) of such a plugin. That is the entire idea behind the 'event' architecture. When displaying a profile page, core GL2 just triggers an event, if any plugin is listening it can respond... Think 1.3.x plugin hooks on drugs. -Vinny From tony at tonybibbs.com Wed Dec 15 23:19:05 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 15 Dec 2004 22:19:05 -0600 Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <8319e2d6041215194928e8cf17@mail.gmail.com> References: <41C0BCDE.9080709@tonybibbs.com> <8319e2d6041215194928e8cf17@mail.gmail.com> Message-ID: <41C10CB9.2060109@tonybibbs.com> Great feedback. My comments below Vincent Furia wrote: >I just don't like the name, but I can't come up with anything better >(how is that for useless input?). > > Lol, yeah, pretty useless. I'm open to suggestions should one hit you. >Another name issue, this one with a suggestion and a valid reason: >What about "action" instead of "event" the problem here is a language >domain collision between our idea of gl2 events vs. calendar events. >"action" is a possible replacement, so is "act" or any synonym that >makes sense. I'm open to suggestions, but I think "event" needs to >change. (And I know, I'm the one who called them "events" to begin >with). > > gl2_action is fine by me. However, just as we have namespace issues in the code with class names we could have similar issues with table names between plugins. I think we should try to address this with some sort of standard, if possible. >NEW COLUMN: event_plugin_id int unsigned NOT NULL DESC force events to >be associated with a specific plugin > > I thought the same thing. Only question I have is what about kernel-based actions? >We might want to require that version be a float (or int?) so that we >can do version dependency checking with some reasonable results. >(i.e. check for version of forum >= 2.3). > > Yeah, makes sense. >we should consider keeping counts in a separate table, hopefully this >will prevent the locking issues previously experienced with article >view counts. We could recommend that plugins use the same table as >needed. > > Where's the DBMS trigger feature when you need it? Are the locking issues still an issue with INNODB table types? Does moving them to a separate table really get rid of the problem? Seem you'd still have a problem with locking, though, not as much. >I think this table should be combined with the gl2_user. I like the >idea of having a plugin that will handle supplemental user >information. > > I'm OK with this. I don't like all the different user tables in 1.3.x. >What is the difference between a "logical name" and a "display name"? >Is differentiating them necessary? > > Logical name would be what you use in security checks. Something like today's SEC_inGroup('story_admin'). story_admin would be the logical name. However when you show the name of the group, say, on a group administration page you would see Story Admin. By splitting the two you could, in theory, change the name of the group without breaking your code granted you keep the logical name the smae. >I think ban should be a plugin... > > Hrm, never really thought of that. Any implications against doing this? >A catalog is just a set of categories correct? Why not keep that info >in the gl2_category table? (i.e. what's the justification for a >separate table). Alternatively should it just go in the >list_of_values table? Why keep the date created? > > The idea here is that plugins can quickly reuse these structures should they have a need to categorize some amount of data. Thus, the links plugin would have it's own catalog different form the story plugin's categories. Putting the catalogs in the list of values makes sense. >Should we use the modified preorder traversal numbering to store the >hierarchical structure of the categories within a catalog (i.e. like >comments in 1.3.10)? > Hrm, haven't even looked at the .10 code. If I hear you what you are saying is we essentially cache the hierarchy instead of having expensive recursive method calls to build it in real time. I'd be fine with that. I'll look at the .10 schema and make needed changes. >All the owner/group id and permissions stuff >should be removed...just use the acl table. We don't want to deal >with two different systems for determining permissions. In fact, why >not make categories "items"? (then categories can be in categories, >won't that be cool?) > > Yeah, not sure how that snuck in there. >I think the num_views and num_emails should be moved to a separate >table (see gl2_user table above). > > I agree we should handle counts in a consistent manner. The locking issues are all I'm interested in figuring out before we decide on a direction. >I think ratings should be handled by a plugin. > > Could, but I think this is a basic need for almost all plugins. In fact, this could even be expanded to users. I could be convinced otherwise. We all want the GL2 kernel to be as lean and mean as possible but I think we also want to ensure that anything in the kernel is truly a resource that will be needed other plugins. >NEW COLUMN: enabled tinyint DEFAULT 1 DESC have the ability to "switch >off" items. > > Agreed. >Do we want an association table between items and categories so items >can be in multiple categories? > > Good question. It gives more flexibility...a tad bit more complexity. Any objections? >Looks good > > Should be, you created th ACL table ;-) >Should comments be a plugin? That way if you want a "forum like" >comment vs traditional system you can just switch out the plugin? If >you really (REALLY) want this do you want to keep the hierarchical >comment structure we added to 1.3.10 (modified preorder traversal) > > > I lump this in with the same issue with the ban plugin. It's a basic decision as to what should be considered part of the kernel versus something that isn't. I think this begs the need for a basic set of criteria that we agree on that should help us determine if something should be a plugin or in the kernel code. >If these are going to be different for different items, shouldn't it >be kept by the individual plugin managing the item? > > What I was trying to achieve here is a plugin would insert a new set of item types (1 or more). Each type can have their own set of states as this allows for customized work-ish tasks that are item-type specific. So to answer your question, yes, the plugin would insert their data, we are simply providing the structures. Thanks for the input. Are there any table that are missing. I feel good about the dialog on what was there but I'm a bit worried I may be missing something that may be a critical need for the kernel. --Tony From tony at tonybibbs.com Wed Dec 15 23:22:10 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 15 Dec 2004 22:22:10 -0600 Subject: [geeklog-devel] Custom user attributes in GL2 In-Reply-To: <8319e2d604121520003720cef1@mail.gmail.com> References: <41C0A386.4020804@tonybibbs.com> <18160.192.136.16.3.1103145404.squirrel@192.136.16.3> <8319e2d6041215135717910b51@mail.gmail.com> <41C0B989.6010900@tonybibbs.com> <41673.192.136.16.3.1103150161.squirrel@192.136.16.3> <41C0BD8B.9020208@tonybibbs.com> <8319e2d60412151800cdd82b2@mail.gmail.com> <41C105B4.7070608@tonybibbs.com> <8319e2d604121520003720cef1@mail.gmail.com> Message-ID: <41C10D72.7090200@tonybibbs.com> Vincent Furia wrote: >That is the entire idea behind the 'event' architecture. When >displaying a profile page, core GL2 just triggers an event, if any >plugin is listening it can respond... Think 1.3.x plugin hooks on >drugs. > > Yeah, so the only issue I have is some plugins may require others, no? If so how do we handle such dependencies? Similarly, plugins may optionally support features from other plugins. This whole plugin architecture is really sexy. I really get excited thinking about the possibilities. Yumm, drugs ;-) --Tony From vfuria at gmail.com Wed Dec 15 23:38:14 2004 From: vfuria at gmail.com (Vincent Furia) Date: Wed, 15 Dec 2004 23:38:14 -0500 Subject: [geeklog-devel] Custom user attributes in GL2 In-Reply-To: <41C10D72.7090200@tonybibbs.com> References: <41C0A386.4020804@tonybibbs.com> <18160.192.136.16.3.1103145404.squirrel@192.136.16.3> <8319e2d6041215135717910b51@mail.gmail.com> <41C0B989.6010900@tonybibbs.com> <41673.192.136.16.3.1103150161.squirrel@192.136.16.3> <41C0BD8B.9020208@tonybibbs.com> <8319e2d60412151800cdd82b2@mail.gmail.com> <41C105B4.7070608@tonybibbs.com> <8319e2d604121520003720cef1@mail.gmail.com> <41C10D72.7090200@tonybibbs.com> Message-ID: <8319e2d604121520386ccdf070@mail.gmail.com> I think plugin dependencies should be evaluated (and "asserted") at install/upgrade/uninstall time. That way we won't have to keep anything in the DB. And we'll be operating fairly safely. Plugins of course will have to figure out for themselves what dependencies they require. -Vinny On Wed, 15 Dec 2004 22:22:10 -0600, Tony Bibbs wrote: > Vincent Furia wrote: > > >That is the entire idea behind the 'event' architecture. When > >displaying a profile page, core GL2 just triggers an event, if any > >plugin is listening it can respond... Think 1.3.x plugin hooks on > >drugs. > > > > > Yeah, so the only issue I have is some plugins may require others, no? > If so how do we handle such dependencies? Similarly, plugins may > optionally support features from other plugins. > > This whole plugin architecture is really sexy. I really get excited > thinking about the possibilities. > > Yumm, drugs ;-) > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Wed Dec 15 23:47:06 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 15 Dec 2004 22:47:06 -0600 Subject: [geeklog-devel] Custom user attributes in GL2 In-Reply-To: <8319e2d604121520386ccdf070@mail.gmail.com> References: <41C0A386.4020804@tonybibbs.com> <18160.192.136.16.3.1103145404.squirrel@192.136.16.3> <8319e2d6041215135717910b51@mail.gmail.com> <41C0B989.6010900@tonybibbs.com> <41673.192.136.16.3.1103150161.squirrel@192.136.16.3> <41C0BD8B.9020208@tonybibbs.com> <8319e2d60412151800cdd82b2@mail.gmail.com> <41C105B4.7070608@tonybibbs.com> <8319e2d604121520003720cef1@mail.gmail.com> <41C10D72.7090200@tonybibbs.com> <8319e2d604121520386ccdf070@mail.gmail.com> Message-ID: <41C1134A.4040308@tonybibbs.com> Sounds good. I'd say the plugin API should reflect the support of dependency checking, no? --Tony Vincent Furia wrote: >I think plugin dependencies should be evaluated (and "asserted") at >install/upgrade/uninstall time. That way we won't have to keep >anything in the DB. And we'll be operating fairly safely. Plugins of >course will have to figure out for themselves what dependencies they >require. > >-Vinny > > >On Wed, 15 Dec 2004 22:22:10 -0600, Tony Bibbs wrote: > > >>Vincent Furia wrote: >> >> >> >>>That is the entire idea behind the 'event' architecture. When >>>displaying a profile page, core GL2 just triggers an event, if any >>>plugin is listening it can respond... Think 1.3.x plugin hooks on >>>drugs. >>> >>> >>> >>> >>Yeah, so the only issue I have is some plugins may require others, no? >>If so how do we handle such dependencies? Similarly, plugins may >>optionally support features from other plugins. >> >>This whole plugin architecture is really sexy. I really get excited >>thinking about the possibilities. >> >>Yumm, drugs ;-) >> >>--Tony >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From vfuria at gmail.com Wed Dec 15 23:52:40 2004 From: vfuria at gmail.com (Vincent Furia) Date: Wed, 15 Dec 2004 23:52:40 -0500 Subject: [geeklog-devel] Custom user attributes in GL2 In-Reply-To: <41C1134A.4040308@tonybibbs.com> References: <41C0A386.4020804@tonybibbs.com> <41C0B989.6010900@tonybibbs.com> <41673.192.136.16.3.1103150161.squirrel@192.136.16.3> <41C0BD8B.9020208@tonybibbs.com> <8319e2d60412151800cdd82b2@mail.gmail.com> <41C105B4.7070608@tonybibbs.com> <8319e2d604121520003720cef1@mail.gmail.com> <41C10D72.7090200@tonybibbs.com> <8319e2d604121520386ccdf070@mail.gmail.com> <41C1134A.4040308@tonybibbs.com> Message-ID: <8319e2d6041215205276ab2438@mail.gmail.com> Definitely. The plugin should tell the core what dependencies it has, then the core should automagically determine if its okay for the plugin to install. -Vinny On Wed, 15 Dec 2004 22:47:06 -0600, Tony Bibbs wrote: > Sounds good. I'd say the plugin API should reflect the support of > dependency checking, no? > > --Tony > > Vincent Furia wrote: > > >I think plugin dependencies should be evaluated (and "asserted") at > >install/upgrade/uninstall time. That way we won't have to keep > >anything in the DB. And we'll be operating fairly safely. Plugins of > >course will have to figure out for themselves what dependencies they > >require. > > > >-Vinny > > > > > >On Wed, 15 Dec 2004 22:22:10 -0600, Tony Bibbs wrote: > > > > > >>Vincent Furia wrote: > >> > >> > >> > >>>That is the entire idea behind the 'event' architecture. When > >>>displaying a profile page, core GL2 just triggers an event, if any > >>>plugin is listening it can respond... Think 1.3.x plugin hooks on > >>>drugs. > >>> > >>> > >>> > >>> > >>Yeah, so the only issue I have is some plugins may require others, no? > >>If so how do we handle such dependencies? Similarly, plugins may > >>optionally support features from other plugins. > >> > >>This whole plugin architecture is really sexy. I really get excited > >>thinking about the possibilities. > >> > >>Yumm, drugs ;-) > >> > >>--Tony > >>_______________________________________________ > >>geeklog-devel mailing list > >>geeklog-devel at lists.geeklog.net > >>http://lists.geeklog.net/listinfo/geeklog-devel > >> > >> > >> > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From geeklog at langfamily.ca Thu Dec 16 01:18:12 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Thu, 16 Dec 2004 01:18:12 -0500 Subject: [geeklog-devel] Blocks in GL2 as Plugin? References: <41C096CE.1030904@tonybibbs.com> <8319e2d6041215195391a132b@mail.gmail.com> Message-ID: <005801c4e337$05b04100$650a10ac@XPBL2> I may be out of sync but let me ask these questions: Will the core not have a fundamental underlying layout control facility for formatting common site components ? Does there not need to be some core component or set of operations that control the site layout? - header, footer, blocks which are the basic building blocks of the site. Plugin's essentially today call and need to call the common functions to wrap the site layout around their content. You may be referring to the Block Editor and for that I think we need to explore what the ideal set of features need to be. It may be a replaceable component but the underlying table structure to support a basic editor or advanced editor need to be in place. If we agree that blocks are the basic building blocks of the site content we can explore what additional attributes are needed. Are blocks just an item in GL2 or do they need to be identified and stand on their own ? Blaine ----- Original Message ----- From: "Vincent Furia" To: Sent: Wednesday, December 15, 2004 10:53 PM Subject: Re: [geeklog-devel] Blocks in GL2 as Plugin? Instead of a "block plugin" how about individual plugins be able to generate blocks as they want (and how the admin configures). This can even include "center block" stuff. We could have a generic plugin that is available for adding random blocks. Also we could have a totally separate plugin to handle RDF/RSS blocks. More complicated blocks, say a weather block, could be their own plugin. -Vinny On Wed, 15 Dec 2004 13:55:58 -0600, Tony Bibbs wrote: > Were any of you thinking blocks would be part of the actual GL2 kernel > or should they exist, instead, as a plugin? The more I think of it, the > more I think they are simply a plugin...though, they will probably be > used to render content served up by nearly every other plugin that would > be installed. > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From geeklog at langfamily.ca Thu Dec 16 01:30:24 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Thu, 16 Dec 2004 01:30:24 -0500 Subject: [geeklog-devel] Custom user attributes in GL2 References: <41C0A386.4020804@tonybibbs.com> <18160.192.136.16.3.1103145404.squirrel@192.136.16.3> <8319e2d6041215135717910b51@mail.gmail.com> <41C0B989.6010900@tonybibbs.com> <41673.192.136.16.3.1103150161.squirrel@192.136.16.3> <41C0BD8B.9020208@tonybibbs.com> Message-ID: <006101c4e338$b9791350$650a10ac@XPBL2> I like the idea of a flexible table driven set of site-defined userprofile fields that could be used for registration or for extending the user profile. This could be a plugin as it could be a plugin today in 1.3.X I recently developed a formEditor plugin that allows you to create a form that has any number of fields from a wide array of field types. I used one table to define the fields for all forms where fieldtype is just a varchar that is one of the plugin defined types. When I display the form, I either use a default layout or a custom template if assigned. We can do the same and it's pretty flexible. Fields would need to include: - id - field_type (varchar 32) - field_attributes - if we are using a default layout, you need this - field_order - label (or linked to language independant feature) - required_for_registration - is_manditory ----- Original Message ----- From: "Tony Bibbs" To: Sent: Wednesday, December 15, 2004 5:41 PM Subject: Re: [geeklog-devel] Custom user attributes in GL2 Your saying the same thing I am. I was bit confused by Vinny's response which sounded a bit like (put everything in there) which I am guessing he didn't mean but I wanted to be perfectly clear on. I think your table will be more complicated...you'll probably want things like min/max values, required indicators, etc. That's in addition to the ability to choose from a finite set of values. The more I think about it, the more I think we might want to delay doing anything with customer user attributes until we get to a point where the kernel is up and plugins are being written. Thoughts? --Tony dwight at trumbower.com wrote: >Ok, I'm confused. I don't see username and password as custom attributes. > >Custom attributes are usually used to enhance the base package and allow >customers to add a few fields of data to customize a screen. The old days, >you just created 5-10 fields, called user1, user2,...user10. So every >table had 10 extra fields. > >The new way puts only the fields you want in a combined table, just like >your List Of Values(LOV) table. > >The hard part is displaying these fields. The easiest way is to have them >all grouped together at the end of a screen. Know when people want to move >them around in different places, it gets tricky. > >Also if you need to handle select option fields, radio fields and check >box fields there will need some more supporting tables. > > >Dwight > > > > > >>I'm fine with data driving the custom user stuff..l >> >>I would still say, though, you'd want real columns in the GL2 user table >>for thing we know we need (i.e. username, password, etc) for performance >>reasons alone, right? Regardless, going this route will make the use of >>Propel a little bit messy as the user class generated by propel won't >>know anything about the custom attributes in the database. >> >>Also, for clarity, are you suggesting we do this for all plugin specific >>user attributes? I don't think you are and if you are we probably want >>to discuss the pros/cons between that and having a plugins specific user >>table with a one-to-one relationship with the kernel user table. >> >>--Tony >> >>Vincent Furia wrote: >> >> >> >>>I'm with Dwight. This way all user data is in one place (and the >>>plugins can put user data there as well). >>> >>>-Vinny >>> >>> >>>On Wed, 15 Dec 2004 16:16:44 -0500 (EST), dwight at trumbower.com >>> wrote: >>> >>> >>> >>> >>>>The easiest way I know of, one table. >>>> >>>>column name - String >>>>column type - specifies, long, int, string ect >>>>column data - data as a string >>>> >>>>Might need xref table to show where it is used. At least this is how >>>>would >>>>start. >>>> >>>> >>>> >>>> >>>> >>>> >>>>>Anybody have any input on how to best address providing the community >>>>>with fairly easy way to add custom attributes for users in GL2? >>>>> >>>>>I don't I have a good idea on how to do this. My hopes are that >>>>>plugins >>>>>would have their own one-to-one mapping from the core user table to >>>>>their own user table with addition information. Assuming that is OK, >>>>>how do we handle things the site admin simply wants to add (e.g. msn >>>>>id, >>>>>pgp key, etc). >>>>> >>>>>--Tony >>>>>_______________________________________________ >>>>>geeklog-devel mailing list >>>>>geeklog-devel at lists.geeklog.net >>>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>>> >>>>> >>>>> >>>>> >>>>> >>>>_______________________________________________ >>>>geeklog-devel mailing list >>>>geeklog-devel at lists.geeklog.net >>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>> >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Thu Dec 16 09:59:25 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 16 Dec 2004 08:59:25 -0600 Subject: [geeklog-devel] Blocks in GL2 as Plugin? In-Reply-To: <005801c4e337$05b04100$650a10ac@XPBL2> References: <41C096CE.1030904@tonybibbs.com> <8319e2d6041215195391a132b@mail.gmail.com> <005801c4e337$05b04100$650a10ac@XPBL2> Message-ID: <41C1A2CD.4060402@tonybibbs.com> Blaine Lang wrote: >I may be out of sync but let me ask these questions: > >Will the core not have a fundamental underlying layout control facility for >formatting common site components ? > > Yes it will >Does there not need to be some core component or set of operations that >control the site layout? > - header, footer, blocks which are the basic building blocks of the site. > > I think the question is more a logistical one. Just how atomic do we want the kernel to be? There are two scenarios I seen playing out with respect to blocks. The first is that blocks aren't implemented as plugins and all related code exist in files within the kernel. That's essentially no different than 1.3.x today. The other school of thought would be to move it to a plugin and and leave it up to the other plugins to mark it as a dependency. I don't think philosophically I have an opinion. However, architecturally, I think the plugin route makes things harder. For example, take the sample application I wrote. The abstract class in BaseViewFlexy.php exposes the showHeader() and showFooter() methods allowing all children to reuse that code. So if we applied this same technique to blocks, there maybe a getBlock() method in this abstract class which is a part of the kernel source. Now assume the block features are implemented in a plugin. Immediately you can't have the equivalent of the getBlock() method on the BaseViewFlexy class because we can't assume the block plugin is installed. So in this case any plugin wishing to use blocks would probably end up creating their own abstract class that extends the BaseViewFlexy class and would add the getBlock() method. Then all their views would use that new class. While that is feasible, the problem is that I think you'll have nearly every plugin in GL2 wanting to use blocks and so you'll have a copy of this sort of new abstact class in each plugin implementation which seems like a duplication of code. So I think I am back with Blaine in that the block code needs to be in the kernel. The beauty of this is plugins still have the option of overriding anything in our classes because of the new OO-design so the plugins still maintain ultimate control over their use of blocks. >Are blocks just an item in GL2 or do they need to be identified and stand on >their own ? > > Uh, how about both. I'm not sure what you are asking but let me give my two cents to see if this answers this question. I do see a record for every block in GL2 in the gl2_item table. This is because the item table includes some already important things a block will want to track (ACL's, owner, creation date, etc). Then you'll have a gl2_block table that has all the block specific data. --Tony From tony at tonybibbs.com Thu Dec 16 12:04:34 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 16 Dec 2004 11:04:34 -0600 Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <41C10CB9.2060109@tonybibbs.com> References: <41C0BCDE.9080709@tonybibbs.com> <8319e2d6041215194928e8cf17@mail.gmail.com> <41C10CB9.2060109@tonybibbs.com> Message-ID: <41C1C022.2040408@tonybibbs.com> New schema is attached. I added the gl2_block table...this may have been a bit premature since we are still discussing it. You can choose to ignore it pending the outcome of that discussion. Here's what I did: 1) Any referenct to 'event' was changed to 'action' 2) I added a plugin_id to the action table, only outstanding issue is how are we representing kernel events? 3) Versions can't be floats if they have two decimal points can they? I think the validation on this needs to happen via the save's validation logic and I think we need to standardize that all version numbers are in the format x.y.z 4) I didn't do anything with count fields...that's pending further discussion 5) The supplemental user stuff was added to the gl2_user table 6) gl2_ban table was removed. I agree this can be doing via a plugin 7) I didn't see any datastructures related to preoder traversal stuff in categories. I looked in the latest mysql_tables_and_data.php file on the comments table and didn't see a field that looked like what I was expecting. What am I missing, Vinny? 8) Added enabled flag to gl2_item 9) removed the security related fields form the category stuff, then changed category_id to be item_id so we don't have to worry about category_id/item_id collisions on ACL table. 10) added gl2_item_category which is an association table between items and categories. Please review the outstanding issues in my previous email and get back to me ASAP. NOTE, this still won't import into MySQL yet. I'll work on that tonight. --Tony Tony Bibbs wrote: > Great feedback. My comments below > > Vincent Furia wrote: > >> I just don't like the name, but I can't come up with anything better >> (how is that for useless input?). >> >> > Lol, yeah, pretty useless. I'm open to suggestions should one hit you. > >> Another name issue, this one with a suggestion and a valid reason: >> What about "action" instead of "event" the problem here is a language >> domain collision between our idea of gl2 events vs. calendar events. >> "action" is a possible replacement, so is "act" or any synonym that >> makes sense. I'm open to suggestions, but I think "event" needs to >> change. (And I know, I'm the one who called them "events" to begin >> with). >> >> > gl2_action is fine by me. However, just as we have namespace issues > in the code with class names we could have similar issues with table > names between plugins. I think we should try to address this with some > sort of standard, if possible. > >> NEW COLUMN: event_plugin_id int unsigned NOT NULL DESC force events to >> be associated with a specific plugin >> >> > I thought the same thing. Only question I have is what about > kernel-based actions? > >> We might want to require that version be a float (or int?) so that we >> can do version dependency checking with some reasonable results. >> (i.e. check for version of forum >= 2.3). >> >> > Yeah, makes sense. > >> we should consider keeping counts in a separate table, hopefully this >> will prevent the locking issues previously experienced with article >> view counts. We could recommend that plugins use the same table as >> needed. >> >> > Where's the DBMS trigger feature when you need it? Are the locking > issues still an issue with INNODB table types? Does moving them to a > separate table really get rid of the problem? Seem you'd still have a > problem with locking, though, not as much. > >> I think this table should be combined with the gl2_user. I like the >> idea of having a plugin that will handle supplemental user >> information. >> >> > I'm OK with this. I don't like all the different user tables in 1.3.x. > >> What is the difference between a "logical name" and a "display name"? >> Is differentiating them necessary? >> >> > Logical name would be what you use in security checks. Something like > today's SEC_inGroup('story_admin'). story_admin would be the logical > name. However when you show the name of the group, say, on a group > administration page you would see Story Admin. By splitting the two > you could, in theory, change the name of the group without breaking > your code granted you keep the logical name the smae. > >> I think ban should be a plugin... >> >> > Hrm, never really thought of that. Any implications against doing this? > >> A catalog is just a set of categories correct? Why not keep that info >> in the gl2_category table? (i.e. what's the justification for a >> separate table). Alternatively should it just go in the >> list_of_values table? Why keep the date created? >> >> > The idea here is that plugins can quickly reuse these structures > should they have a need to categorize some amount of data. Thus, the > links plugin would have it's own catalog different form the story > plugin's categories. Putting the catalogs in the list of values makes > sense. > >> Should we use the modified preorder traversal numbering to store the >> hierarchical structure of the categories within a catalog (i.e. like >> comments in 1.3.10)? > > Hrm, haven't even looked at the .10 code. If I hear you what you are > saying is we essentially cache the hierarchy instead of having > expensive recursive method calls to build it in real time. I'd be > fine with that. I'll look at the .10 schema and make needed changes. > >> All the owner/group id and permissions stuff >> should be removed...just use the acl table. We don't want to deal >> with two different systems for determining permissions. In fact, why >> not make categories "items"? (then categories can be in categories, >> won't that be cool?) >> >> > Yeah, not sure how that snuck in there. > >> I think the num_views and num_emails should be moved to a separate >> table (see gl2_user table above). >> >> > I agree we should handle counts in a consistent manner. The locking > issues are all I'm interested in figuring out before we decide on a > direction. > >> I think ratings should be handled by a plugin. >> >> > Could, but I think this is a basic need for almost all plugins. In > fact, this could even be expanded to users. I could be convinced > otherwise. We all want the GL2 kernel to be as lean and mean as > possible but I think we also want to ensure that anything in the > kernel is truly a resource that will be needed other plugins. > >> NEW COLUMN: enabled tinyint DEFAULT 1 DESC have the ability to "switch >> off" items. >> >> > Agreed. > >> Do we want an association table between items and categories so items >> can be in multiple categories? >> >> > Good question. It gives more flexibility...a tad bit more complexity. > Any objections? > >> Looks good >> >> > Should be, you created th ACL table ;-) > >> Should comments be a plugin? That way if you want a "forum like" >> comment vs traditional system you can just switch out the plugin? If >> you really (REALLY) want this do you want to keep the hierarchical >> comment structure we added to 1.3.10 (modified preorder traversal) >> >> >> > I lump this in with the same issue with the ban plugin. It's a basic > decision as to what should be considered part of the kernel versus > something that isn't. I think this begs the need for a basic set of > criteria that we agree on that should help us determine if something > should be a plugin or in the kernel code. > >> If these are going to be different for different items, shouldn't it >> be kept by the individual plugin managing the item? >> >> > What I was trying to achieve here is a plugin would insert a new set > of item types (1 or more). Each type can have their own set of states > as this allows for customized work-ish tasks that are item-type > specific. So to answer your question, yes, the plugin would insert > their data, we are simply providing the structures. > > Thanks for the input. Are there any table that are missing. I feel > good about the dialog on what was there but I'm a bit worried I may be > missing something that may be a critical need for the kernel. > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: create.sql URL: From tony at tonybibbs.com Thu Dec 16 12:24:29 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 16 Dec 2004 11:24:29 -0600 Subject: [geeklog-devel] [Fwd: Re: [propel] Performance Benchmarks] Message-ID: <41C1C4CD.4010907@tonybibbs.com> Turns out someone else ran benchmarks on Creole. When I get the results I'll send them on. --Tony -------- Original Message -------- Subject: Re: [propel] Performance Benchmarks Date: Thu, 16 Dec 2004 10:16:14 +0100 From: D?nes Szab? Reply-To: users at propel.tigris.org To: users at propel.tigris.org References: <41BEFBAA.3080602 at tonybibbs.com> <41C10D74.2020502 at velum.net> <41C112F0.4050706 at tonybibbs.com> Hi! I have posted my benchmarks suite (based on adodb benchmark) and results to gmane.comp.php.propel.users news but it didn't appear. :( If you want, I'll send it again to this list. On Wed, 15 Dec 2004 22:45:36 -0600, Tony Bibbs wrote: > Thanks for the response, I know that wasn't an easy question to answer. -- [dt] --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe at propel.tigris.org For additional commands, e-mail: users-help at propel.tigris.org From dwight at trumbower.com Thu Dec 16 12:33:24 2004 From: dwight at trumbower.com (dwight at trumbower.com) Date: Thu, 16 Dec 2004 12:33:24 -0500 (EST) Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <41C1C022.2040408@tonybibbs.com> References: <41C0BCDE.9080709@tonybibbs.com> <8319e2d6041215194928e8cf17@mail.gmail.com> <41C10CB9.2060109@tonybibbs.com> <41C1C022.2040408@tonybibbs.com> Message-ID: <17687.192.136.16.3.1103218404.squirrel@192.136.16.3> Foreign Keys are a good thing, but I wouldn't plan on any db specific functionality with them. MYISAM doesn't work with foreign keys and 90% of the users won't be using innodb. > New schema is attached. I added the gl2_block table...this may have > been a bit premature since we are still discussing it. You can choose > to ignore it pending the outcome of that discussion. > > Here's what I did: > 1) Any referenct to 'event' was changed to 'action' > 2) I added a plugin_id to the action table, only outstanding issue is > how are we representing kernel events? > 3) Versions can't be floats if they have two decimal points can they? I > think the validation on this needs to happen via the save's validation > logic and I think we need to standardize that all version numbers are in > the format x.y.z > 4) I didn't do anything with count fields...that's pending further > discussion > 5) The supplemental user stuff was added to the gl2_user table > 6) gl2_ban table was removed. I agree this can be doing via a plugin > 7) I didn't see any datastructures related to preoder traversal stuff in > categories. I looked in the latest mysql_tables_and_data.php file on > the comments table and didn't see a field that looked like what I was > expecting. What am I missing, Vinny? > 8) Added enabled flag to gl2_item > 9) removed the security related fields form the category stuff, then > changed category_id to be item_id so we don't have to worry about > category_id/item_id collisions on ACL table. > 10) added gl2_item_category which is an association table between items > and categories. > > Please review the outstanding issues in my previous email and get back > to me ASAP. NOTE, this still won't import into MySQL yet. I'll work on > that tonight. > > --Tony > > > > Tony Bibbs wrote: > >> Great feedback. My comments below >> >> Vincent Furia wrote: >> >>> I just don't like the name, but I can't come up with anything better >>> (how is that for useless input?). >>> >>> >> Lol, yeah, pretty useless. I'm open to suggestions should one hit you. >> >>> Another name issue, this one with a suggestion and a valid reason: >>> What about "action" instead of "event" the problem here is a language >>> domain collision between our idea of gl2 events vs. calendar events. >>> "action" is a possible replacement, so is "act" or any synonym that >>> makes sense. I'm open to suggestions, but I think "event" needs to >>> change. (And I know, I'm the one who called them "events" to begin >>> with). >>> >>> >> gl2_action is fine by me. However, just as we have namespace issues >> in the code with class names we could have similar issues with table >> names between plugins. I think we should try to address this with some >> sort of standard, if possible. >> >>> NEW COLUMN: event_plugin_id int unsigned NOT NULL DESC force events to >>> be associated with a specific plugin >>> >>> >> I thought the same thing. Only question I have is what about >> kernel-based actions? >> >>> We might want to require that version be a float (or int?) so that we >>> can do version dependency checking with some reasonable results. >>> (i.e. check for version of forum >= 2.3). >>> >>> >> Yeah, makes sense. >> >>> we should consider keeping counts in a separate table, hopefully this >>> will prevent the locking issues previously experienced with article >>> view counts. We could recommend that plugins use the same table as >>> needed. >>> >>> >> Where's the DBMS trigger feature when you need it? Are the locking >> issues still an issue with INNODB table types? Does moving them to a >> separate table really get rid of the problem? Seem you'd still have a >> problem with locking, though, not as much. >> >>> I think this table should be combined with the gl2_user. I like the >>> idea of having a plugin that will handle supplemental user >>> information. >>> >>> >> I'm OK with this. I don't like all the different user tables in 1.3.x. >> >>> What is the difference between a "logical name" and a "display name"? >>> Is differentiating them necessary? >>> >>> >> Logical name would be what you use in security checks. Something like >> today's SEC_inGroup('story_admin'). story_admin would be the logical >> name. However when you show the name of the group, say, on a group >> administration page you would see Story Admin. By splitting the two >> you could, in theory, change the name of the group without breaking >> your code granted you keep the logical name the smae. >> >>> I think ban should be a plugin... >>> >>> >> Hrm, never really thought of that. Any implications against doing this? >> >>> A catalog is just a set of categories correct? Why not keep that info >>> in the gl2_category table? (i.e. what's the justification for a >>> separate table). Alternatively should it just go in the >>> list_of_values table? Why keep the date created? >>> >>> >> The idea here is that plugins can quickly reuse these structures >> should they have a need to categorize some amount of data. Thus, the >> links plugin would have it's own catalog different form the story >> plugin's categories. Putting the catalogs in the list of values makes >> sense. >> >>> Should we use the modified preorder traversal numbering to store the >>> hierarchical structure of the categories within a catalog (i.e. like >>> comments in 1.3.10)? >> >> Hrm, haven't even looked at the .10 code. If I hear you what you are >> saying is we essentially cache the hierarchy instead of having >> expensive recursive method calls to build it in real time. I'd be >> fine with that. I'll look at the .10 schema and make needed changes. >> >>> All the owner/group id and permissions stuff >>> should be removed...just use the acl table. We don't want to deal >>> with two different systems for determining permissions. In fact, why >>> not make categories "items"? (then categories can be in categories, >>> won't that be cool?) >>> >>> >> Yeah, not sure how that snuck in there. >> >>> I think the num_views and num_emails should be moved to a separate >>> table (see gl2_user table above). >>> >>> >> I agree we should handle counts in a consistent manner. The locking >> issues are all I'm interested in figuring out before we decide on a >> direction. >> >>> I think ratings should be handled by a plugin. >>> >>> >> Could, but I think this is a basic need for almost all plugins. In >> fact, this could even be expanded to users. I could be convinced >> otherwise. We all want the GL2 kernel to be as lean and mean as >> possible but I think we also want to ensure that anything in the >> kernel is truly a resource that will be needed other plugins. >> >>> NEW COLUMN: enabled tinyint DEFAULT 1 DESC have the ability to "switch >>> off" items. >>> >>> >> Agreed. >> >>> Do we want an association table between items and categories so items >>> can be in multiple categories? >>> >>> >> Good question. It gives more flexibility...a tad bit more complexity. >> Any objections? >> >>> Looks good >>> >>> >> Should be, you created th ACL table ;-) >> >>> Should comments be a plugin? That way if you want a "forum like" >>> comment vs traditional system you can just switch out the plugin? If >>> you really (REALLY) want this do you want to keep the hierarchical >>> comment structure we added to 1.3.10 (modified preorder traversal) >>> >>> >>> >> I lump this in with the same issue with the ban plugin. It's a basic >> decision as to what should be considered part of the kernel versus >> something that isn't. I think this begs the need for a basic set of >> criteria that we agree on that should help us determine if something >> should be a plugin or in the kernel code. >> >>> If these are going to be different for different items, shouldn't it >>> be kept by the individual plugin managing the item? >>> >>> >> What I was trying to achieve here is a plugin would insert a new set >> of item types (1 or more). Each type can have their own set of states >> as this allows for customized work-ish tasks that are item-type >> specific. So to answer your question, yes, the plugin would insert >> their data, we are simply providing the structures. >> >> Thanks for the input. Are there any table that are missing. I feel >> good about the dialog on what was there but I'm a bit worried I may be >> missing something that may be a critical need for the kernel. >> >> --Tony >> _______________________________________________ >> geeklog-devel mailing list >> geeklog-devel at lists.geeklog.net >> http://lists.geeklog.net/listinfo/geeklog-devel > > > From vfuria at gmail.com Thu Dec 16 12:38:25 2004 From: vfuria at gmail.com (Vincent Furia) Date: Thu, 16 Dec 2004 12:38:25 -0500 Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <17687.192.136.16.3.1103218404.squirrel@192.136.16.3> References: <41C0BCDE.9080709@tonybibbs.com> <8319e2d6041215194928e8cf17@mail.gmail.com> <41C10CB9.2060109@tonybibbs.com> <41C1C022.2040408@tonybibbs.com> <17687.192.136.16.3.1103218404.squirrel@192.136.16.3> Message-ID: <8319e2d604121609382f8c4fe5@mail.gmail.com> I thought we agreed previously that GL2 would force the use of INNODB under mysql for a variety of reasons. Among them the ability to use foreign keys. Is there a distribution of mysql in common use that doesn't support INNODB? Should we work to support MYISAM tables? -Vinny P.S. Dwight, I (and Tony too I think) really appreciated your input on the DB issues. I think you're by far the most experienced DB person reading the list. On Thu, 16 Dec 2004 12:33:24 -0500 (EST), dwight at trumbower.com wrote: > Foreign Keys are a good thing, but I wouldn't plan on any db specific > functionality with them. MYISAM doesn't work with foreign keys and 90% of > the users won't be using innodb. > > > New schema is attached. I added the gl2_block table...this may have > > been a bit premature since we are still discussing it. You can choose > > to ignore it pending the outcome of that discussion. > > > > Here's what I did: > > 1) Any referenct to 'event' was changed to 'action' > > 2) I added a plugin_id to the action table, only outstanding issue is > > how are we representing kernel events? > > 3) Versions can't be floats if they have two decimal points can they? I > > think the validation on this needs to happen via the save's validation > > logic and I think we need to standardize that all version numbers are in > > the format x.y.z > > 4) I didn't do anything with count fields...that's pending further > > discussion > > 5) The supplemental user stuff was added to the gl2_user table > > 6) gl2_ban table was removed. I agree this can be doing via a plugin > > 7) I didn't see any datastructures related to preoder traversal stuff in > > categories. I looked in the latest mysql_tables_and_data.php file on > > the comments table and didn't see a field that looked like what I was > > expecting. What am I missing, Vinny? > > 8) Added enabled flag to gl2_item > > 9) removed the security related fields form the category stuff, then > > changed category_id to be item_id so we don't have to worry about > > category_id/item_id collisions on ACL table. > > 10) added gl2_item_category which is an association table between items > > and categories. > > > > Please review the outstanding issues in my previous email and get back > > to me ASAP. NOTE, this still won't import into MySQL yet. I'll work on > > that tonight. > > > > --Tony > > > > > > > > Tony Bibbs wrote: > > > >> Great feedback. My comments below > >> > >> Vincent Furia wrote: > >> > >>> I just don't like the name, but I can't come up with anything better > >>> (how is that for useless input?). > >>> > >>> > >> Lol, yeah, pretty useless. I'm open to suggestions should one hit you. > >> > >>> Another name issue, this one with a suggestion and a valid reason: > >>> What about "action" instead of "event" the problem here is a language > >>> domain collision between our idea of gl2 events vs. calendar events. > >>> "action" is a possible replacement, so is "act" or any synonym that > >>> makes sense. I'm open to suggestions, but I think "event" needs to > >>> change. (And I know, I'm the one who called them "events" to begin > >>> with). > >>> > >>> > >> gl2_action is fine by me. However, just as we have namespace issues > >> in the code with class names we could have similar issues with table > >> names between plugins. I think we should try to address this with some > >> sort of standard, if possible. > >> > >>> NEW COLUMN: event_plugin_id int unsigned NOT NULL DESC force events to > >>> be associated with a specific plugin > >>> > >>> > >> I thought the same thing. Only question I have is what about > >> kernel-based actions? > >> > >>> We might want to require that version be a float (or int?) so that we > >>> can do version dependency checking with some reasonable results. > >>> (i.e. check for version of forum >= 2.3). > >>> > >>> > >> Yeah, makes sense. > >> > >>> we should consider keeping counts in a separate table, hopefully this > >>> will prevent the locking issues previously experienced with article > >>> view counts. We could recommend that plugins use the same table as > >>> needed. > >>> > >>> > >> Where's the DBMS trigger feature when you need it? Are the locking > >> issues still an issue with INNODB table types? Does moving them to a > >> separate table really get rid of the problem? Seem you'd still have a > >> problem with locking, though, not as much. > >> > >>> I think this table should be combined with the gl2_user. I like the > >>> idea of having a plugin that will handle supplemental user > >>> information. > >>> > >>> > >> I'm OK with this. I don't like all the different user tables in 1.3.x. > >> > >>> What is the difference between a "logical name" and a "display name"? > >>> Is differentiating them necessary? > >>> > >>> > >> Logical name would be what you use in security checks. Something like > >> today's SEC_inGroup('story_admin'). story_admin would be the logical > >> name. However when you show the name of the group, say, on a group > >> administration page you would see Story Admin. By splitting the two > >> you could, in theory, change the name of the group without breaking > >> your code granted you keep the logical name the smae. > >> > >>> I think ban should be a plugin... > >>> > >>> > >> Hrm, never really thought of that. Any implications against doing this? > >> > >>> A catalog is just a set of categories correct? Why not keep that info > >>> in the gl2_category table? (i.e. what's the justification for a > >>> separate table). Alternatively should it just go in the > >>> list_of_values table? Why keep the date created? > >>> > >>> > >> The idea here is that plugins can quickly reuse these structures > >> should they have a need to categorize some amount of data. Thus, the > >> links plugin would have it's own catalog different form the story > >> plugin's categories. Putting the catalogs in the list of values makes > >> sense. > >> > >>> Should we use the modified preorder traversal numbering to store the > >>> hierarchical structure of the categories within a catalog (i.e. like > >>> comments in 1.3.10)? > >> > >> Hrm, haven't even looked at the .10 code. If I hear you what you are > >> saying is we essentially cache the hierarchy instead of having > >> expensive recursive method calls to build it in real time. I'd be > >> fine with that. I'll look at the .10 schema and make needed changes. > >> > >>> All the owner/group id and permissions stuff > >>> should be removed...just use the acl table. We don't want to deal > >>> with two different systems for determining permissions. In fact, why > >>> not make categories "items"? (then categories can be in categories, > >>> won't that be cool?) > >>> > >>> > >> Yeah, not sure how that snuck in there. > >> > >>> I think the num_views and num_emails should be moved to a separate > >>> table (see gl2_user table above). > >>> > >>> > >> I agree we should handle counts in a consistent manner. The locking > >> issues are all I'm interested in figuring out before we decide on a > >> direction. > >> > >>> I think ratings should be handled by a plugin. > >>> > >>> > >> Could, but I think this is a basic need for almost all plugins. In > >> fact, this could even be expanded to users. I could be convinced > >> otherwise. We all want the GL2 kernel to be as lean and mean as > >> possible but I think we also want to ensure that anything in the > >> kernel is truly a resource that will be needed other plugins. > >> > >>> NEW COLUMN: enabled tinyint DEFAULT 1 DESC have the ability to "switch > >>> off" items. > >>> > >>> > >> Agreed. > >> > >>> Do we want an association table between items and categories so items > >>> can be in multiple categories? > >>> > >>> > >> Good question. It gives more flexibility...a tad bit more complexity. > >> Any objections? > >> > >>> Looks good > >>> > >>> > >> Should be, you created th ACL table ;-) > >> > >>> Should comments be a plugin? That way if you want a "forum like" > >>> comment vs traditional system you can just switch out the plugin? If > >>> you really (REALLY) want this do you want to keep the hierarchical > >>> comment structure we added to 1.3.10 (modified preorder traversal) > >>> > >>> > >>> > >> I lump this in with the same issue with the ban plugin. It's a basic > >> decision as to what should be considered part of the kernel versus > >> something that isn't. I think this begs the need for a basic set of > >> criteria that we agree on that should help us determine if something > >> should be a plugin or in the kernel code. > >> > >>> If these are going to be different for different items, shouldn't it > >>> be kept by the individual plugin managing the item? > >>> > >>> > >> What I was trying to achieve here is a plugin would insert a new set > >> of item types (1 or more). Each type can have their own set of states > >> as this allows for customized work-ish tasks that are item-type > >> specific. So to answer your question, yes, the plugin would insert > >> their data, we are simply providing the structures. > >> > >> Thanks for the input. Are there any table that are missing. I feel > >> good about the dialog on what was there but I'm a bit worried I may be > >> missing something that may be a critical need for the kernel. > >> > >> --Tony > >> _______________________________________________ > >> geeklog-devel mailing list > >> geeklog-devel at lists.geeklog.net > >> http://lists.geeklog.net/listinfo/geeklog-devel > > > > > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Thu Dec 16 12:43:29 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 16 Dec 2004 11:43:29 -0600 Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <8319e2d604121609382f8c4fe5@mail.gmail.com> References: <41C0BCDE.9080709@tonybibbs.com> <8319e2d6041215194928e8cf17@mail.gmail.com> <41C10CB9.2060109@tonybibbs.com> <41C1C022.2040408@tonybibbs.com> <17687.192.136.16.3.1103218404.squirrel@192.136.16.3> <8319e2d604121609382f8c4fe5@mail.gmail.com> Message-ID: <41C1C941.3000408@tonybibbs.com> I think we have to require INNODB. Without it you don't get foreign keys nor transaction support. Two things, IMHO, I don't want to live without. I think eventually ISP's will get their act together and start supporting versions of MySQL that support INNODB (why that wouldn't be the default table type moving forward is beyond me). Vinny, to answer your question, the compilation of MySQL must have the innodb support added to the ./configure. So that would be a distribution specific thing. To your point, though, I think it would be really dumb for distro's not to support INNODB by default. --Tony Vincent Furia wrote: >I thought we agreed previously that GL2 would force the use of INNODB >under mysql for a variety of reasons. Among them the ability to use >foreign keys. Is there a distribution of mysql in common use that >doesn't support INNODB? Should we work to support MYISAM tables? > >-Vinny > >P.S. Dwight, I (and Tony too I think) really appreciated your input on >the DB issues. I think you're by far the most experienced DB person >reading the list. > >On Thu, 16 Dec 2004 12:33:24 -0500 (EST), dwight at trumbower.com > wrote: > > >>Foreign Keys are a good thing, but I wouldn't plan on any db specific >>functionality with them. MYISAM doesn't work with foreign keys and 90% of >>the users won't be using innodb. >> >> >> >>>New schema is attached. I added the gl2_block table...this may have >>>been a bit premature since we are still discussing it. You can choose >>>to ignore it pending the outcome of that discussion. >>> >>>Here's what I did: >>>1) Any referenct to 'event' was changed to 'action' >>>2) I added a plugin_id to the action table, only outstanding issue is >>>how are we representing kernel events? >>>3) Versions can't be floats if they have two decimal points can they? I >>>think the validation on this needs to happen via the save's validation >>>logic and I think we need to standardize that all version numbers are in >>>the format x.y.z >>>4) I didn't do anything with count fields...that's pending further >>>discussion >>>5) The supplemental user stuff was added to the gl2_user table >>>6) gl2_ban table was removed. I agree this can be doing via a plugin >>>7) I didn't see any datastructures related to preoder traversal stuff in >>>categories. I looked in the latest mysql_tables_and_data.php file on >>>the comments table and didn't see a field that looked like what I was >>>expecting. What am I missing, Vinny? >>>8) Added enabled flag to gl2_item >>>9) removed the security related fields form the category stuff, then >>>changed category_id to be item_id so we don't have to worry about >>>category_id/item_id collisions on ACL table. >>>10) added gl2_item_category which is an association table between items >>>and categories. >>> >>>Please review the outstanding issues in my previous email and get back >>>to me ASAP. NOTE, this still won't import into MySQL yet. I'll work on >>>that tonight. >>> >>>--Tony >>> >>> >>> >>>Tony Bibbs wrote: >>> >>> >>> >>>>Great feedback. My comments below >>>> >>>>Vincent Furia wrote: >>>> >>>> >>>> >>>>>I just don't like the name, but I can't come up with anything better >>>>>(how is that for useless input?). >>>>> >>>>> >>>>> >>>>> >>>>Lol, yeah, pretty useless. I'm open to suggestions should one hit you. >>>> >>>> >>>> >>>>>Another name issue, this one with a suggestion and a valid reason: >>>>>What about "action" instead of "event" the problem here is a language >>>>>domain collision between our idea of gl2 events vs. calendar events. >>>>>"action" is a possible replacement, so is "act" or any synonym that >>>>>makes sense. I'm open to suggestions, but I think "event" needs to >>>>>change. (And I know, I'm the one who called them "events" to begin >>>>>with). >>>>> >>>>> >>>>> >>>>> >>>>gl2_action is fine by me. However, just as we have namespace issues >>>>in the code with class names we could have similar issues with table >>>>names between plugins. I think we should try to address this with some >>>>sort of standard, if possible. >>>> >>>> >>>> >>>>>NEW COLUMN: event_plugin_id int unsigned NOT NULL DESC force events to >>>>>be associated with a specific plugin >>>>> >>>>> >>>>> >>>>> >>>>I thought the same thing. Only question I have is what about >>>>kernel-based actions? >>>> >>>> >>>> >>>>>We might want to require that version be a float (or int?) so that we >>>>>can do version dependency checking with some reasonable results. >>>>>(i.e. check for version of forum >= 2.3). >>>>> >>>>> >>>>> >>>>> >>>>Yeah, makes sense. >>>> >>>> >>>> >>>>>we should consider keeping counts in a separate table, hopefully this >>>>>will prevent the locking issues previously experienced with article >>>>>view counts. We could recommend that plugins use the same table as >>>>>needed. >>>>> >>>>> >>>>> >>>>> >>>>Where's the DBMS trigger feature when you need it? Are the locking >>>>issues still an issue with INNODB table types? Does moving them to a >>>>separate table really get rid of the problem? Seem you'd still have a >>>>problem with locking, though, not as much. >>>> >>>> >>>> >>>>>I think this table should be combined with the gl2_user. I like the >>>>>idea of having a plugin that will handle supplemental user >>>>>information. >>>>> >>>>> >>>>> >>>>> >>>>I'm OK with this. I don't like all the different user tables in 1.3.x. >>>> >>>> >>>> >>>>>What is the difference between a "logical name" and a "display name"? >>>>>Is differentiating them necessary? >>>>> >>>>> >>>>> >>>>> >>>>Logical name would be what you use in security checks. Something like >>>>today's SEC_inGroup('story_admin'). story_admin would be the logical >>>>name. However when you show the name of the group, say, on a group >>>>administration page you would see Story Admin. By splitting the two >>>>you could, in theory, change the name of the group without breaking >>>>your code granted you keep the logical name the smae. >>>> >>>> >>>> >>>>>I think ban should be a plugin... >>>>> >>>>> >>>>> >>>>> >>>>Hrm, never really thought of that. Any implications against doing this? >>>> >>>> >>>> >>>>>A catalog is just a set of categories correct? Why not keep that info >>>>>in the gl2_category table? (i.e. what's the justification for a >>>>>separate table). Alternatively should it just go in the >>>>>list_of_values table? Why keep the date created? >>>>> >>>>> >>>>> >>>>> >>>>The idea here is that plugins can quickly reuse these structures >>>>should they have a need to categorize some amount of data. Thus, the >>>>links plugin would have it's own catalog different form the story >>>>plugin's categories. Putting the catalogs in the list of values makes >>>>sense. >>>> >>>> >>>> >>>>>Should we use the modified preorder traversal numbering to store the >>>>>hierarchical structure of the categories within a catalog (i.e. like >>>>>comments in 1.3.10)? >>>>> >>>>> >>>>Hrm, haven't even looked at the .10 code. If I hear you what you are >>>>saying is we essentially cache the hierarchy instead of having >>>>expensive recursive method calls to build it in real time. I'd be >>>>fine with that. I'll look at the .10 schema and make needed changes. >>>> >>>> >>>> >>>>>All the owner/group id and permissions stuff >>>>>should be removed...just use the acl table. We don't want to deal >>>>>with two different systems for determining permissions. In fact, why >>>>>not make categories "items"? (then categories can be in categories, >>>>>won't that be cool?) >>>>> >>>>> >>>>> >>>>> >>>>Yeah, not sure how that snuck in there. >>>> >>>> >>>> >>>>>I think the num_views and num_emails should be moved to a separate >>>>>table (see gl2_user table above). >>>>> >>>>> >>>>> >>>>> >>>>I agree we should handle counts in a consistent manner. The locking >>>>issues are all I'm interested in figuring out before we decide on a >>>>direction. >>>> >>>> >>>> >>>>>I think ratings should be handled by a plugin. >>>>> >>>>> >>>>> >>>>> >>>>Could, but I think this is a basic need for almost all plugins. In >>>>fact, this could even be expanded to users. I could be convinced >>>>otherwise. We all want the GL2 kernel to be as lean and mean as >>>>possible but I think we also want to ensure that anything in the >>>>kernel is truly a resource that will be needed other plugins. >>>> >>>> >>>> >>>>>NEW COLUMN: enabled tinyint DEFAULT 1 DESC have the ability to "switch >>>>>off" items. >>>>> >>>>> >>>>> >>>>> >>>>Agreed. >>>> >>>> >>>> >>>>>Do we want an association table between items and categories so items >>>>>can be in multiple categories? >>>>> >>>>> >>>>> >>>>> >>>>Good question. It gives more flexibility...a tad bit more complexity. >>>>Any objections? >>>> >>>> >>>> >>>>>Looks good >>>>> >>>>> >>>>> >>>>> >>>>Should be, you created th ACL table ;-) >>>> >>>> >>>> >>>>>Should comments be a plugin? That way if you want a "forum like" >>>>>comment vs traditional system you can just switch out the plugin? If >>>>>you really (REALLY) want this do you want to keep the hierarchical >>>>>comment structure we added to 1.3.10 (modified preorder traversal) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>I lump this in with the same issue with the ban plugin. It's a basic >>>>decision as to what should be considered part of the kernel versus >>>>something that isn't. I think this begs the need for a basic set of >>>>criteria that we agree on that should help us determine if something >>>>should be a plugin or in the kernel code. >>>> >>>> >>>> >>>>>If these are going to be different for different items, shouldn't it >>>>>be kept by the individual plugin managing the item? >>>>> >>>>> >>>>> >>>>> >>>>What I was trying to achieve here is a plugin would insert a new set >>>>of item types (1 or more). Each type can have their own set of states >>>>as this allows for customized work-ish tasks that are item-type >>>>specific. So to answer your question, yes, the plugin would insert >>>>their data, we are simply providing the structures. >>>> >>>>Thanks for the input. Are there any table that are missing. I feel >>>>good about the dialog on what was there but I'm a bit worried I may be >>>>missing something that may be a critical need for the kernel. >>>> >>>>--Tony >>>>_______________________________________________ >>>>geeklog-devel mailing list >>>>geeklog-devel at lists.geeklog.net >>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>> >>>> >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From dwight at trumbower.com Thu Dec 16 13:00:25 2004 From: dwight at trumbower.com (dwight at trumbower.com) Date: Thu, 16 Dec 2004 13:00:25 -0500 (EST) Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <41C1C941.3000408@tonybibbs.com> References: <41C0BCDE.9080709@tonybibbs.com> <8319e2d6041215194928e8cf17@mail.gmail.com> <41C10CB9.2060109@tonybibbs.com> <41C1C022.2040408@tonybibbs.com> <17687.192.136.16.3.1103218404.squirrel@192.136.16.3> <8319e2d604121609382f8c4fe5@mail.gmail.com> <41C1C941.3000408@tonybibbs.com> Message-ID: <32375.192.136.16.3.1103220025.squirrel@192.136.16.3> > I think we have to require INNODB. Without it you don't get foreign > keys nor transaction support. Two things, IMHO, I don't want to live > without. I think eventually ISP's will get their act together and start > supporting versions of MySQL that support INNODB (why that wouldn't be > the default table type moving forward is beyond me). > Moving to INNODB is moving closer to a real DBMS and requires more administration. For one, you can't do backups unless you take the database off line or spend $500 for a product. I don't see ISP switching. Most can't handle standard mysql properly. I found this out when Dirk started making GL 1.3.x default to innodb. He changed it back to myisam with an option to make it innodb. I don't have a problem with forcing INNODB, just bringing up issues as I see them. The target user for GL2 will be much smaller than it is today. Dwight From vfuria at gmail.com Thu Dec 16 13:08:33 2004 From: vfuria at gmail.com (Vincent Furia) Date: Thu, 16 Dec 2004 13:08:33 -0500 Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <41C1C022.2040408@tonybibbs.com> References: <41C0BCDE.9080709@tonybibbs.com> <8319e2d6041215194928e8cf17@mail.gmail.com> <41C10CB9.2060109@tonybibbs.com> <41C1C022.2040408@tonybibbs.com> Message-ID: <8319e2d60412161008783ae8a2@mail.gmail.com> > 2) I added a plugin_id to the action table, only outstanding issue is > how are we representing kernel events? I'd suggest making the core a pseudo plugin (i.e. it has an entry in the plugin database probably with plugin_id value of 0). We could label it either "core" or "geeklog" or "GL2". That would provide a good way for the core gl2 to trigger and (potentially) listen for plugin events...errr...I mean actions. > 3) Versions can't be floats if they have two decimal points can they? I > think the validation on this needs to happen via the save's validation > logic and I think we need to standardize that all version numbers are in > the format x.y.z Yeah, we can get the geeklog2 core to enforce this with whatever rules we want. We could even get fancy and store the plugin code state (i.e. alpha, beta, gamma) as either part of the version or in another DB field or even just kept a constant/variable in the plugin. > 4) I didn't do anything with count fields...that's pending further > discussion Yup, I'd like to hear Dwight's input on that along with comments from the people who had been/are experiencing the locking problem. > 5) The supplemental user stuff was added to the gl2_user table But you forgot to trash the supplemental user table. :) > 7) I didn't see any datastructures related to preoder traversal stuff in > categories. I looked in the latest mysql_tables_and_data.php file on > the comments table and didn't see a field that looked like what I was > expecting. What am I missing, Vinny? You want the "lft" and "rht" columns from the comment table. Try reading this article I wrote about whats going on (I wouldn't mind a critique on the article either...): http://vinny.furiafamily.com/article.php?story=20041129154258296 Additional comments: I think we should trash the "logical_name" vs. "display_name" in the group table. The only group that should be hard coded into the code is the Root group (where members of that groups have rights everywhere). All other access/privileges should be based on ACLs and privileges. If you really want other hard coded groups we can handle "display names" by passing the group names through the translator. After saying all that I'd like to see logical_name and display_name both be replaced by a single name column. Tony said: > Putting the catalogs in the list of values makes sense. So the catalog table needs to be trashed and the category table reflect that those values are in the list of values table (still trying to come with a better name for that). Tony said: > gl2_action is fine by me. However, just as we have namespace issues in > the code with class names we could have similar issues with table names > between plugins. I think we should try to address this with some sort of > standard, if possible. Tables for a plugin should be prefixed by the GL2 prefix followed by a plugin specific prefix (probably the plugin's name). That should do it I'd think. Tony said: > I lump this in with the same issue with the ban plugin. It's a basic > decision as to what should be considered part of the kernel versus > something that isn't. I think this begs the need for a basic set of > criteria that we agree on that should help us determine if something > should be a plugin or in the kernel code. I could go either way with comments (ratings I'd lean more toward a plugin, but I wouldn't have a fit if it was in the core). In any case, we should establish those criteria you mention now before we get too far into coding. Tony said: > What I was trying to achieve here is a plugin would insert a new set of > item types (1 or more). Each type can have their own set of states as > this allows for customized work-ish tasks that are item-type specific. > So to answer your question, yes, the plugin would insert their data, we > are simply providing the structures. I think we should drop the state_id since the core has nothing to do with it and there is no guarantee (or even likelihood?) that all item types will need it. It's easy enough for plugin developers to put that in there "plugin specific item table" which by our design would have a 1-1 relationship with the item table. I think that's enough for now. I don't want to overwhelm Tony too much. :) -Vinny From tony at tonybibbs.com Thu Dec 16 14:13:01 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 16 Dec 2004 13:13:01 -0600 Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <8319e2d60412161008783ae8a2@mail.gmail.com> References: <41C0BCDE.9080709@tonybibbs.com> <8319e2d6041215194928e8cf17@mail.gmail.com> <41C10CB9.2060109@tonybibbs.com> <41C1C022.2040408@tonybibbs.com> <8319e2d60412161008783ae8a2@mail.gmail.com> Message-ID: <41C1DE3D.4070802@tonybibbs.com> Vincent Furia wrote: >I'd suggest making the core a pseudo plugin (i.e. it has an entry in >the plugin database probably with plugin_id value of 0). We could >label it either "core" or "geeklog" or "GL2". That would provide a >good way for the core gl2 to trigger and (potentially) listen for >plugin events...errr...I mean actions. > > That's fine. >Yeah, we can get the geeklog2 core to enforce this with whatever rules >we want. We could even get fancy and store the plugin code state >(i.e. alpha, beta, gamma) as either part of the version or in another >DB field or even just kept a constant/variable in the plugin. > > Sounds good >Yup, I'd like to hear Dwight's input on that along with comments from >the people who had been/are experiencing the locking problem. > > /me waits for Dwight >But you forgot to trash the supplemental user table. :) > > Oops.. I'll remove it. >>7) I didn't see any datastructures related to preoder traversal stuff in >>categories. I looked in the latest mysql_tables_and_data.php file on >>the comments table and didn't see a field that looked like what I was >>expecting. What am I missing, Vinny? >> >> >You want the "lft" and "rht" columns from the comment table. Try >reading this article I wrote about whats going on (I wouldn't mind a >critique on the article either...): >http://vinny.furiafamily.com/article.php?story=20041129154258296 > > > No comments at this time. I was wondering WTF those columns were for. Can we come up with a more descriptive name for them in the GL2 schema? In the meantime I'll be considering this versus other search tree implementations. >Additional comments: I think we should trash the "logical_name" vs. >"display_name" in the group table. The only group that should be hard >coded into the code is the Root group (where members of that groups >have rights everywhere). All other access/privileges should be based >on ACLs and privileges. If you really want other hard coded groups we >can handle "display names" by passing the group names through the >translator. After saying all that I'd like to see logical_name and >display_name both be replaced by a single name column. > > Not sure I agree. We similar logic in the 1.3.x code with respect to the inGroup() method. If you get rid of the logical name then you are also saying to get rid of the inGroup() method all together. Is that what you really want? Just want to be sure before we run off and remove it. >So the catalog table needs to be trashed and the category table >reflect that those values are in the list of values table (still >trying to come with a better name for that). > > Yeah. I'll make remaining fixes. >Tables for a plugin should be prefixed by the GL2 prefix followed by a >plugin specific prefix (probably the plugin's name). That should do >it I'd think. > > K, so you'll add this to the start of the coding standards we have? >I could go either way with comments (ratings I'd lean more toward a >plugin, but I wouldn't have a fit if it was in the core). In any >case, we should establish those criteria you mention now before we get >too far into coding. > > Ok, let me think about the criteria some and I'll post a new thread to the list on this. >I think we should drop the state_id since the core has nothing to do >with it and there is no guarantee (or even likelihood?) that all item >types will need it. It's easy enough for plugin developers to put >that in there "plugin specific item table" which by our design would >have a 1-1 relationship with the item table. > > Think of it this way. Two states at the very minimum would be 'awaiting approval' and 'approved' (or something to that effect). This would essentially mimick the submission queues we have in 1.3.x today. I'm OK with dropping this and going the plugin specific route but wanted to make sure that we really don't think this is a must have feature. >I think that's enough for now. I don't want to overwhelm Tony too much. :) > > Tag, you (and Dwight) are it. --Tony From tony at tonybibbs.com Thu Dec 16 14:24:54 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 16 Dec 2004 13:24:54 -0600 Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <32375.192.136.16.3.1103220025.squirrel@192.136.16.3> References: <41C0BCDE.9080709@tonybibbs.com> <8319e2d6041215194928e8cf17@mail.gmail.com> <41C10CB9.2060109@tonybibbs.com> <41C1C022.2040408@tonybibbs.com> <17687.192.136.16.3.1103218404.squirrel@192.136.16.3> <8319e2d604121609382f8c4fe5@mail.gmail.com> <41C1C941.3000408@tonybibbs.com> <32375.192.136.16.3.1103220025.squirrel@192.136.16.3> Message-ID: <41C1E106.8040409@tonybibbs.com> I think we are fine. Why? Well, if we develop this using foreign keys I think we cover our arses in the case someone doesn't use INNODB. That's because I'm pretty sure that if a MySQL Server that doesn't have INNODB support compiled in and somenoe imports DDL for a database that tries to use INNODB, it will simply convert them to MyISAM and ignore any FOREIGN KEY constraints (as opposed to creating an error and dying). As I said, the Propel classes enforce foreign key constraints natively (assuming the schema.xml is right) so in the MyISAM case we are still covered. Only exception to this is obviously GL2 programmers can issue raw SQL so there is the possiblity of orphaned children. But again, if all developers use INNODB the database during coding, we would catch any potential errors regardless. So, in short, I don't think MyISAM users will be effected. Of course someone will need to test this... If I am right (which I'm pretty sure I am), we will want to put a stern warning about the possible effects of not using INNODB. Also, this make the table-locking issue more complicated since we have to cover the MyISAM side of things as well. Or does it? Table locking should only occur on high traffic sites and, IMHO, you get what you get for using MyISAM on a wildly popular website. --Tony dwight at trumbower.com wrote: > Moving to INNODB is moving closer to a real DBMS and requires more > >administration. For one, you can't do backups unless you take the database >off line or spend $500 for a product. I don't see ISP switching. Most >can't handle standard mysql properly. > >I found this out when Dirk started making GL 1.3.x default to innodb. He >changed it back to myisam with an option to make it innodb. > > >I don't have a problem with forcing INNODB, just bringing up issues as I >see them. The target user for GL2 will be much smaller than it is today. > >Dwight >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From vfuria at gmail.com Thu Dec 16 14:31:36 2004 From: vfuria at gmail.com (Vincent Furia) Date: Thu, 16 Dec 2004 14:31:36 -0500 Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <41C1DE3D.4070802@tonybibbs.com> References: <41C0BCDE.9080709@tonybibbs.com> <8319e2d6041215194928e8cf17@mail.gmail.com> <41C10CB9.2060109@tonybibbs.com> <41C1C022.2040408@tonybibbs.com> <8319e2d60412161008783ae8a2@mail.gmail.com> <41C1DE3D.4070802@tonybibbs.com> Message-ID: <8319e2d60412161131206f2984@mail.gmail.com> > Not sure I agree. We similar logic in the 1.3.x code with respect to > the inGroup() method. If you get rid of the logical name then you are > also saying to get rid of the inGroup() method all together. Is that > what you really want? Just want to be sure before we run off and remove it. Yes. If you look in the geeklog code for calls to SEC_inGroup() it is really only used for the Root group. Most of the other instance where it is used it is used against a group id variable. The remainder I would argue are redundant if we better respected privileges in 1.3.x. I'd recommend a "isRoot" function, but I think "inGroup" is really not needed except when actually administering group membership. > No comments at this time. I was wondering WTF those columns were for. > Can we come up with a more descriptive name for them in the GL2 schema? > In the meantime I'll be considering this versus other search tree > implementations. Better names for those columns wouldn't hurt, I just couldn't come up with anything better when I was implementing it in 1.3.x. I looked around at other algorithms when I was first looking into improving the performance of comments and didn't find anything better. If you do find something let me know. This was, by far, the best I found. The biggest downside is that I had to lock the table during inserts, but that is really OBE since we can use transactions. -Vinny From tony at tonybibbs.com Thu Dec 16 14:35:07 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 16 Dec 2004 13:35:07 -0600 Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <8319e2d60412161131206f2984@mail.gmail.com> References: <41C0BCDE.9080709@tonybibbs.com> <8319e2d6041215194928e8cf17@mail.gmail.com> <41C10CB9.2060109@tonybibbs.com> <41C1C022.2040408@tonybibbs.com> <8319e2d60412161008783ae8a2@mail.gmail.com> <41C1DE3D.4070802@tonybibbs.com> <8319e2d60412161131206f2984@mail.gmail.com> Message-ID: <41C1E36B.3070708@tonybibbs.com> Vincent Furia wrote: >Yes. If you look in the geeklog code for calls to SEC_inGroup() it is >really only used for the Root group. Most of the other instance >where it is used it is used against a group id variable. The >remainder I would argue are redundant if we better respected >privileges in 1.3.x. I'd recommend a "isRoot" function, but I think >"inGroup" is really not needed except when actually administering >group membership. > > Ok, I say we yank it...adding that column in if deemed appropriate isn't too hard. >Better names for those columns wouldn't hurt, I just couldn't come up >with anything better when I was implementing it in 1.3.x. I looked >around at other algorithms when I was first looking into improving the >performance of comments and didn't find anything better. If you do >find something let me know. This was, by far, the best I found. The >biggest downside is that I had to lock the table during inserts, but >that is really OBE since we can use transactions. > > Was this an original implementation or was it one you borrowed from someplace? WTF does slashcode use...you'd think they'd have to have this issue nailed down by now. --Tony From vfuria at gmail.com Thu Dec 16 14:46:04 2004 From: vfuria at gmail.com (Vincent Furia) Date: Thu, 16 Dec 2004 14:46:04 -0500 Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <41C1E36B.3070708@tonybibbs.com> References: <41C0BCDE.9080709@tonybibbs.com> <8319e2d6041215194928e8cf17@mail.gmail.com> <41C10CB9.2060109@tonybibbs.com> <41C1C022.2040408@tonybibbs.com> <8319e2d60412161008783ae8a2@mail.gmail.com> <41C1DE3D.4070802@tonybibbs.com> <8319e2d60412161131206f2984@mail.gmail.com> <41C1E36B.3070708@tonybibbs.com> Message-ID: <8319e2d60412161146c2638c1@mail.gmail.com> I didn't look at slashcode. But most other CMSs I looked at just grab all the comments from the DB and use a recursive php algorithm. I didn't see any that had an efficient (or smart) way of grabbing comments. The implementation is original, the algorithm was spelled out in a couple different places with slight variations in the details. -Vinny On Thu, 16 Dec 2004 13:35:07 -0600, Tony Bibbs wrote: > Vincent Furia wrote: > > >Yes. If you look in the geeklog code for calls to SEC_inGroup() it is > >really only used for the Root group. Most of the other instance > >where it is used it is used against a group id variable. The > >remainder I would argue are redundant if we better respected > >privileges in 1.3.x. I'd recommend a "isRoot" function, but I think > >"inGroup" is really not needed except when actually administering > >group membership. > > > > > Ok, I say we yank it...adding that column in if deemed appropriate isn't > too hard. > > >Better names for those columns wouldn't hurt, I just couldn't come up > >with anything better when I was implementing it in 1.3.x. I looked > >around at other algorithms when I was first looking into improving the > >performance of comments and didn't find anything better. If you do > >find something let me know. This was, by far, the best I found. The > >biggest downside is that I had to lock the table during inserts, but > >that is really OBE since we can use transactions. > > > > > Was this an original implementation or was it one you borrowed from > someplace? WTF does slashcode use...you'd think they'd have to have > this issue nailed down by now. > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From dwight at trumbower.com Thu Dec 16 14:49:55 2004 From: dwight at trumbower.com (dwight at trumbower.com) Date: Thu, 16 Dec 2004 14:49:55 -0500 (EST) Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <41C1E106.8040409@tonybibbs.com> References: <41C0BCDE.9080709@tonybibbs.com> <8319e2d6041215194928e8cf17@mail.gmail.com> <41C10CB9.2060109@tonybibbs.com> <41C1C022.2040408@tonybibbs.com> <17687.192.136.16.3.1103218404.squirrel@192.136.16.3> <8319e2d604121609382f8c4fe5@mail.gmail.com> <41C1C941.3000408@tonybibbs.com> <32375.192.136.16.3.1103220025.squirrel@192.136.16.3> <41C1E106.8040409@tonybibbs.com> Message-ID: <46944.192.136.16.3.1103226595.squirrel@192.136.16.3> We are fine as long as you don't use foreign key specific functions. LIke Cascade deletes and updates. Which it sounds like Propel will handle this. myisam will just ignore the ddl for foreign keys. Dwight >From MySql: In MySQL Server 3.23.44 and up, the InnoDB storage engine supports checking of foreign key constraints, including CASCADE, ON DELETE, and ON UPDATE. See section 15.7.4 FOREIGN KEY Constraints. For storage engines other than InnoDB, MySQL Server parses the FOREIGN KEY syntax in CREATE TABLE statements, but does not use or store it. In the future, the implementation will be extended to store this information in the table specification file so that it may be retrieved by mysqldump and ODBC. At a later stage, foreign key constraints will be implemented for MyISAM tables as well. > I think we are fine. Why? Well, if we develop this using foreign keys > I think we cover our arses in the case someone doesn't use INNODB. > That's because I'm pretty sure that if a MySQL Server that doesn't have > INNODB support compiled in and somenoe imports DDL for a database that > tries to use INNODB, it will simply convert them to MyISAM and ignore > any FOREIGN KEY constraints (as opposed to creating an error and dying). > > As I said, the Propel classes enforce foreign key constraints natively > (assuming the schema.xml is right) so in the MyISAM case we are still > covered. Only exception to this is obviously GL2 programmers can issue > raw SQL so there is the possiblity of orphaned children. But again, if > all developers use INNODB the database during coding, we would catch any > potential errors regardless. > > So, in short, I don't think MyISAM users will be effected. Of course > someone will need to test this... > > If I am right (which I'm pretty sure I am), we will want to put a stern > warning about the possible effects of not using INNODB. Also, this make > the table-locking issue more complicated since we have to cover the > MyISAM side of things as well. Or does it? Table locking should only > occur on high traffic sites and, IMHO, you get what you get for using > MyISAM on a wildly popular website. > > --Tony > > dwight at trumbower.com wrote: > >> Moving to INNODB is moving closer to a real DBMS and requires more >> >>administration. For one, you can't do backups unless you take the >> database >>off line or spend $500 for a product. I don't see ISP switching. Most >>can't handle standard mysql properly. >> >>I found this out when Dirk started making GL 1.3.x default to innodb. He >>changed it back to myisam with an option to make it innodb. >> >> >>I don't have a problem with forcing INNODB, just bringing up issues as I >>see them. The target user for GL2 will be much smaller than it is today. >> >>Dwight >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Thu Dec 16 14:52:27 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 16 Dec 2004 13:52:27 -0600 Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <8319e2d60412161146c2638c1@mail.gmail.com> References: <41C0BCDE.9080709@tonybibbs.com> <8319e2d6041215194928e8cf17@mail.gmail.com> <41C10CB9.2060109@tonybibbs.com> <41C1C022.2040408@tonybibbs.com> <8319e2d60412161008783ae8a2@mail.gmail.com> <41C1DE3D.4070802@tonybibbs.com> <8319e2d60412161131206f2984@mail.gmail.com> <41C1E36B.3070708@tonybibbs.com> <8319e2d60412161146c2638c1@mail.gmail.com> Message-ID: <41C1E77B.1030005@tonybibbs.com> In the table on this page: http://vinny.furiafamily.com/article.php?story=20041129154258296 How does a new comment get it's rht, lft values? I'm fuzzy on that. Anyway, it looks good to me. For column names in GL2 how about leftIndex and rightIndex? --Tony How do you know what the rht Vincent Furia wrote: >I didn't look at slashcode. But most other CMSs I looked at just grab >all the comments from the DB and use a recursive php algorithm. I >didn't see any that had an efficient (or smart) way of grabbing >comments. > >The implementation is original, the algorithm was spelled out in a >couple different places with slight variations in the details. > >-Vinny > > >On Thu, 16 Dec 2004 13:35:07 -0600, Tony Bibbs wrote: > > >>Vincent Furia wrote: >> >> >> >>>Yes. If you look in the geeklog code for calls to SEC_inGroup() it is >>>really only used for the Root group. Most of the other instance >>>where it is used it is used against a group id variable. The >>>remainder I would argue are redundant if we better respected >>>privileges in 1.3.x. I'd recommend a "isRoot" function, but I think >>>"inGroup" is really not needed except when actually administering >>>group membership. >>> >>> >>> >>> >>Ok, I say we yank it...adding that column in if deemed appropriate isn't >>too hard. >> >> >> >>>Better names for those columns wouldn't hurt, I just couldn't come up >>>with anything better when I was implementing it in 1.3.x. I looked >>>around at other algorithms when I was first looking into improving the >>>performance of comments and didn't find anything better. If you do >>>find something let me know. This was, by far, the best I found. The >>>biggest downside is that I had to lock the table during inserts, but >>>that is really OBE since we can use transactions. >>> >>> >>> >>> >>Was this an original implementation or was it one you borrowed from >>someplace? WTF does slashcode use...you'd think they'd have to have >>this issue nailed down by now. >> >>--Tony >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From tony at tonybibbs.com Thu Dec 16 14:54:12 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 16 Dec 2004 13:54:12 -0600 Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <46944.192.136.16.3.1103226595.squirrel@192.136.16.3> References: <41C0BCDE.9080709@tonybibbs.com> <8319e2d6041215194928e8cf17@mail.gmail.com> <41C10CB9.2060109@tonybibbs.com> <41C1C022.2040408@tonybibbs.com> <17687.192.136.16.3.1103218404.squirrel@192.136.16.3> <8319e2d604121609382f8c4fe5@mail.gmail.com> <41C1C941.3000408@tonybibbs.com> <32375.192.136.16.3.1103220025.squirrel@192.136.16.3> <41C1E106.8040409@tonybibbs.com> <46944.192.136.16.3.1103226595.squirrel@192.136.16.3> Message-ID: <41C1E7E4.8090801@tonybibbs.com> Sweet. --Tony dwight at trumbower.com wrote: >We are fine as long as you don't use foreign key specific functions. LIke >Cascade deletes and updates. Which it sounds like Propel will handle this. >myisam will just ignore the ddl for foreign keys. > >Dwight > >>From MySql: >In MySQL Server 3.23.44 and up, the InnoDB storage engine supports >checking of foreign key constraints, including CASCADE, ON DELETE, and ON >UPDATE. See section 15.7.4 FOREIGN KEY Constraints. > >For storage engines other than InnoDB, MySQL Server parses the FOREIGN KEY >syntax in CREATE TABLE statements, but does not use or store it. In the >future, the implementation will be extended to store this information in >the table specification file so that it may be retrieved by mysqldump and >ODBC. At a later stage, foreign key constraints will be implemented for >MyISAM tables as well. > > > > > > >>I think we are fine. Why? Well, if we develop this using foreign keys >>I think we cover our arses in the case someone doesn't use INNODB. >>That's because I'm pretty sure that if a MySQL Server that doesn't have >>INNODB support compiled in and somenoe imports DDL for a database that >>tries to use INNODB, it will simply convert them to MyISAM and ignore >>any FOREIGN KEY constraints (as opposed to creating an error and dying). >> >>As I said, the Propel classes enforce foreign key constraints natively >>(assuming the schema.xml is right) so in the MyISAM case we are still >>covered. Only exception to this is obviously GL2 programmers can issue >>raw SQL so there is the possiblity of orphaned children. But again, if >>all developers use INNODB the database during coding, we would catch any >>potential errors regardless. >> >>So, in short, I don't think MyISAM users will be effected. Of course >>someone will need to test this... >> >>If I am right (which I'm pretty sure I am), we will want to put a stern >>warning about the possible effects of not using INNODB. Also, this make >>the table-locking issue more complicated since we have to cover the >>MyISAM side of things as well. Or does it? Table locking should only >>occur on high traffic sites and, IMHO, you get what you get for using >>MyISAM on a wildly popular website. >> >>--Tony >> >>dwight at trumbower.com wrote: >> >> >> >>>Moving to INNODB is moving closer to a real DBMS and requires more >>> >>>administration. For one, you can't do backups unless you take the >>>database >>>off line or spend $500 for a product. I don't see ISP switching. Most >>>can't handle standard mysql properly. >>> >>>I found this out when Dirk started making GL 1.3.x default to innodb. He >>>changed it back to myisam with an option to make it innodb. >>> >>> >>>I don't have a problem with forcing INNODB, just bringing up issues as I >>>see them. The target user for GL2 will be much smaller than it is today. >>> >>>Dwight >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From dwight at trumbower.com Thu Dec 16 14:56:49 2004 From: dwight at trumbower.com (dwight at trumbower.com) Date: Thu, 16 Dec 2004 14:56:49 -0500 (EST) Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <8319e2d60412161146c2638c1@mail.gmail.com> References: <41C0BCDE.9080709@tonybibbs.com> <8319e2d6041215194928e8cf17@mail.gmail.com> <41C10CB9.2060109@tonybibbs.com> <41C1C022.2040408@tonybibbs.com> <8319e2d60412161008783ae8a2@mail.gmail.com> <41C1DE3D.4070802@tonybibbs.com> <8319e2d60412161131206f2984@mail.gmail.com> <41C1E36B.3070708@tonybibbs.com> <8319e2d60412161146c2638c1@mail.gmail.com> Message-ID: <20042.192.136.16.3.1103227009.squirrel@192.136.16.3> SQL Trees and such,"comments" One of the "fathers" of SQL trees - Joe Celko. http://www.ibase.ru/devinfo/DBMSTrees/sqltrees.html Another decent article. http://www.sqlteam.com/item.asp?ItemID=8866 > I didn't look at slashcode. But most other CMSs I looked at just grab > all the comments from the DB and use a recursive php algorithm. I > didn't see any that had an efficient (or smart) way of grabbing > comments. > > The implementation is original, the algorithm was spelled out in a > couple different places with slight variations in the details. > > -Vinny > > > On Thu, 16 Dec 2004 13:35:07 -0600, Tony Bibbs wrote: >> Vincent Furia wrote: >> >> >Yes. If you look in the geeklog code for calls to SEC_inGroup() it is >> >really only used for the Root group. Most of the other instance >> >where it is used it is used against a group id variable. The >> >remainder I would argue are redundant if we better respected >> >privileges in 1.3.x. I'd recommend a "isRoot" function, but I think >> >"inGroup" is really not needed except when actually administering >> >group membership. >> > >> > >> Ok, I say we yank it...adding that column in if deemed appropriate isn't >> too hard. >> >> >Better names for those columns wouldn't hurt, I just couldn't come up >> >with anything better when I was implementing it in 1.3.x. I looked >> >around at other algorithms when I was first looking into improving the >> >performance of comments and didn't find anything better. If you do >> >find something let me know. This was, by far, the best I found. The >> >biggest downside is that I had to lock the table during inserts, but >> >that is really OBE since we can use transactions. >> > >> > >> Was this an original implementation or was it one you borrowed from >> someplace? WTF does slashcode use...you'd think they'd have to have >> this issue nailed down by now. >> >> --Tony >> _______________________________________________ >> geeklog-devel mailing list >> geeklog-devel at lists.geeklog.net >> http://lists.geeklog.net/listinfo/geeklog-devel >> > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Thu Dec 16 15:00:12 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 16 Dec 2004 14:00:12 -0600 Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <20042.192.136.16.3.1103227009.squirrel@192.136.16.3> References: <41C0BCDE.9080709@tonybibbs.com> <8319e2d6041215194928e8cf17@mail.gmail.com> <41C10CB9.2060109@tonybibbs.com> <41C1C022.2040408@tonybibbs.com> <8319e2d60412161008783ae8a2@mail.gmail.com> <41C1DE3D.4070802@tonybibbs.com> <8319e2d60412161131206f2984@mail.gmail.com> <41C1E36B.3070708@tonybibbs.com> <8319e2d60412161146c2638c1@mail.gmail.com> <20042.192.136.16.3.1103227009.squirrel@192.136.16.3> Message-ID: <41C1E94C.6020906@tonybibbs.com> Excellent, looks like Vinny more than did his homework on this one (not that I doubted him). I say because of this we should make the comments part of the core...that way we can hide the complexity of the inserts/deletes from plugin authors. --Tony dwight at trumbower.com wrote: >SQL Trees and such,"comments" > >One of the "fathers" of SQL trees - Joe Celko. >http://www.ibase.ru/devinfo/DBMSTrees/sqltrees.html > >Another decent article. >http://www.sqlteam.com/item.asp?ItemID=8866 > > > > >>I didn't look at slashcode. But most other CMSs I looked at just grab >>all the comments from the DB and use a recursive php algorithm. I >>didn't see any that had an efficient (or smart) way of grabbing >>comments. >> >>The implementation is original, the algorithm was spelled out in a >>couple different places with slight variations in the details. >> >>-Vinny >> >> >>On Thu, 16 Dec 2004 13:35:07 -0600, Tony Bibbs wrote: >> >> >>>Vincent Furia wrote: >>> >>> >>> >>>>Yes. If you look in the geeklog code for calls to SEC_inGroup() it is >>>>really only used for the Root group. Most of the other instance >>>>where it is used it is used against a group id variable. The >>>>remainder I would argue are redundant if we better respected >>>>privileges in 1.3.x. I'd recommend a "isRoot" function, but I think >>>>"inGroup" is really not needed except when actually administering >>>>group membership. >>>> >>>> >>>> >>>> >>>Ok, I say we yank it...adding that column in if deemed appropriate isn't >>>too hard. >>> >>> >>> >>>>Better names for those columns wouldn't hurt, I just couldn't come up >>>>with anything better when I was implementing it in 1.3.x. I looked >>>>around at other algorithms when I was first looking into improving the >>>>performance of comments and didn't find anything better. If you do >>>>find something let me know. This was, by far, the best I found. The >>>>biggest downside is that I had to lock the table during inserts, but >>>>that is really OBE since we can use transactions. >>>> >>>> >>>> >>>> >>>Was this an original implementation or was it one you borrowed from >>>someplace? WTF does slashcode use...you'd think they'd have to have >>>this issue nailed down by now. >>> >>>--Tony >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From vfuria at gmail.com Thu Dec 16 15:07:53 2004 From: vfuria at gmail.com (Vincent Furia) Date: Thu, 16 Dec 2004 15:07:53 -0500 Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <41C1E77B.1030005@tonybibbs.com> References: <41C0BCDE.9080709@tonybibbs.com> <8319e2d6041215194928e8cf17@mail.gmail.com> <41C10CB9.2060109@tonybibbs.com> <41C1C022.2040408@tonybibbs.com> <8319e2d60412161008783ae8a2@mail.gmail.com> <41C1DE3D.4070802@tonybibbs.com> <8319e2d60412161131206f2984@mail.gmail.com> <41C1E36B.3070708@tonybibbs.com> <8319e2d60412161146c2638c1@mail.gmail.com> <41C1E77B.1030005@tonybibbs.com> Message-ID: <8319e2d6041216120715cabd62@mail.gmail.com> Whatever names you think best. I just have a continuing giant brain fart whenever I try to think of new names for those... For a new comment, the value of leftIndex is the parent comments rightIndex. The value of rightIndex is the parent comments rightIndex + 1. All Indexes (left and right) for all comments that have a value greater than the new comments leftIndex are increased by two. I guess I need to explain that better in my article. You might want to draw some pictures. I had to do that a lot to prove to myself that inserts and deletes would always work. Also if you use this algorithm you technically don't need the pid column (the parent id can be found easily given the left and right indexes of a child comment). I left the pid column in 1.3.x so I wouldn't need to rewrite even more comment code. -Vinny On Thu, 16 Dec 2004 13:52:27 -0600, Tony Bibbs wrote: > In the table on this page: > > http://vinny.furiafamily.com/article.php?story=20041129154258296 > > How does a new comment get it's rht, lft values? I'm fuzzy on that. > Anyway, it looks good to me. For column names in GL2 how about > leftIndex and rightIndex? > > --Tony > > How do you know what the rht > Vincent Furia wrote: > > >I didn't look at slashcode. But most other CMSs I looked at just grab > >all the comments from the DB and use a recursive php algorithm. I > >didn't see any that had an efficient (or smart) way of grabbing > >comments. > > > >The implementation is original, the algorithm was spelled out in a > >couple different places with slight variations in the details. > > > >-Vinny > > > > > >On Thu, 16 Dec 2004 13:35:07 -0600, Tony Bibbs wrote: > > > > > >>Vincent Furia wrote: > >> > >> > >> > >>>Yes. If you look in the geeklog code for calls to SEC_inGroup() it is > >>>really only used for the Root group. Most of the other instance > >>>where it is used it is used against a group id variable. The > >>>remainder I would argue are redundant if we better respected > >>>privileges in 1.3.x. I'd recommend a "isRoot" function, but I think > >>>"inGroup" is really not needed except when actually administering > >>>group membership. > >>> > >>> > >>> > >>> > >>Ok, I say we yank it...adding that column in if deemed appropriate isn't > >>too hard. > >> > >> > >> > >>>Better names for those columns wouldn't hurt, I just couldn't come up > >>>with anything better when I was implementing it in 1.3.x. I looked > >>>around at other algorithms when I was first looking into improving the > >>>performance of comments and didn't find anything better. If you do > >>>find something let me know. This was, by far, the best I found. The > >>>biggest downside is that I had to lock the table during inserts, but > >>>that is really OBE since we can use transactions. > >>> > >>> > >>> > >>> > >>Was this an original implementation or was it one you borrowed from > >>someplace? WTF does slashcode use...you'd think they'd have to have > >>this issue nailed down by now. > >> > >>--Tony > >>_______________________________________________ > >>geeklog-devel mailing list > >>geeklog-devel at lists.geeklog.net > >>http://lists.geeklog.net/listinfo/geeklog-devel > >> > >> > >> > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Thu Dec 16 15:26:51 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 16 Dec 2004 14:26:51 -0600 Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <8319e2d6041216120715cabd62@mail.gmail.com> References: <41C0BCDE.9080709@tonybibbs.com> <8319e2d6041215194928e8cf17@mail.gmail.com> <41C10CB9.2060109@tonybibbs.com> <41C1C022.2040408@tonybibbs.com> <8319e2d60412161008783ae8a2@mail.gmail.com> <41C1DE3D.4070802@tonybibbs.com> <8319e2d60412161131206f2984@mail.gmail.com> <41C1E36B.3070708@tonybibbs.com> <8319e2d60412161146c2638c1@mail.gmail.com> <41C1E77B.1030005@tonybibbs.com> <8319e2d6041216120715cabd62@mail.gmail.com> Message-ID: <41C1EF8B.2080908@tonybibbs.com> Gotcha. Ok, so I'll yank the parent_id out altogether. This is sweet. Yeah, drawing a picture would probably help. --Tony Vincent Furia wrote: >Whatever names you think best. I just have a continuing giant brain >fart whenever I try to think of new names for those... > >For a new comment, the value of leftIndex is the parent comments >rightIndex. The value of rightIndex is the parent comments rightIndex >+ 1. All Indexes (left and right) for all comments that have a value >greater than the new comments leftIndex are increased by two. I guess >I need to explain that better in my article. > >You might want to draw some pictures. I had to do that a lot to prove >to myself that inserts and deletes would always work. > >Also if you use this algorithm you technically don't need the pid >column (the parent id can be found easily given the left and right >indexes of a child comment). I left the pid column in 1.3.x so I >wouldn't need to rewrite even more comment code. > >-Vinny > > >On Thu, 16 Dec 2004 13:52:27 -0600, Tony Bibbs wrote: > > >>In the table on this page: >> >>http://vinny.furiafamily.com/article.php?story=20041129154258296 >> >>How does a new comment get it's rht, lft values? I'm fuzzy on that. >>Anyway, it looks good to me. For column names in GL2 how about >>leftIndex and rightIndex? >> >>--Tony >> >>How do you know what the rht >>Vincent Furia wrote: >> >> >> >>>I didn't look at slashcode. But most other CMSs I looked at just grab >>>all the comments from the DB and use a recursive php algorithm. I >>>didn't see any that had an efficient (or smart) way of grabbing >>>comments. >>> >>>The implementation is original, the algorithm was spelled out in a >>>couple different places with slight variations in the details. >>> >>>-Vinny >>> >>> >>>On Thu, 16 Dec 2004 13:35:07 -0600, Tony Bibbs wrote: >>> >>> >>> >>> >>>>Vincent Furia wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Yes. If you look in the geeklog code for calls to SEC_inGroup() it is >>>>>really only used for the Root group. Most of the other instance >>>>>where it is used it is used against a group id variable. The >>>>>remainder I would argue are redundant if we better respected >>>>>privileges in 1.3.x. I'd recommend a "isRoot" function, but I think >>>>>"inGroup" is really not needed except when actually administering >>>>>group membership. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Ok, I say we yank it...adding that column in if deemed appropriate isn't >>>>too hard. >>>> >>>> >>>> >>>> >>>> >>>>>Better names for those columns wouldn't hurt, I just couldn't come up >>>>>with anything better when I was implementing it in 1.3.x. I looked >>>>>around at other algorithms when I was first looking into improving the >>>>>performance of comments and didn't find anything better. If you do >>>>>find something let me know. This was, by far, the best I found. The >>>>>biggest downside is that I had to lock the table during inserts, but >>>>>that is really OBE since we can use transactions. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>Was this an original implementation or was it one you borrowed from >>>>someplace? WTF does slashcode use...you'd think they'd have to have >>>>this issue nailed down by now. >>>> >>>>--Tony >>>>_______________________________________________ >>>>geeklog-devel mailing list >>>>geeklog-devel at lists.geeklog.net >>>>http://lists.geeklog.net/listinfo/geeklog-devel >>>> >>>> >>>> >>>> >>>> >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From tony at tonybibbs.com Thu Dec 16 16:43:51 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 16 Dec 2004 15:43:51 -0600 Subject: [geeklog-devel] Actual Working Schema for GL2 Message-ID: <41C20197.2050102@tonybibbs.com> Ok, I've attached a working version of the schema. Worth noting, is anywhere in the old schema where we had parent_id fields I replaced them with the left_index, right_index. Seems to me that if it is good enough for comment performance, it's good enough for everyone else. Next up is to build the first set of Propel classes from this schema. Cross your fingers. --Tony -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: create.sql URL: From dirk at haun-online.de Thu Dec 16 17:00:17 2004 From: dirk at haun-online.de (Dirk Haun) Date: Thu, 16 Dec 2004 23:00:17 +0100 Subject: [geeklog-devel] Actual Working Schema for GL2 In-Reply-To: <41C20197.2050102@tonybibbs.com> References: <41C20197.2050102@tonybibbs.com> Message-ID: <20041216220017.1167@smtp.haun-online.de> Tony wrote: >CREATE TABLE gl2_user ( Time zone? bye, Dirk -- http://www.haun-online.de/ http://mypod.de/ From tony at tonybibbs.com Thu Dec 16 17:33:53 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Thu, 16 Dec 2004 16:33:53 -0600 Subject: [geeklog-devel] Actual Working Schema for GL2 In-Reply-To: <20041216220017.1167@smtp.haun-online.de> References: <41C20197.2050102@tonybibbs.com> <20041216220017.1167@smtp.haun-online.de> Message-ID: <41C20D51.3000100@tonybibbs.com> oops. I'll add it. Dirk Haun wrote: >Tony wrote: > > > >>CREATE TABLE gl2_user ( >> >> > >Time zone? > >bye, Dirk > > > > From justin.carlson at gmail.com Thu Dec 16 17:41:16 2004 From: justin.carlson at gmail.com (Justin Carlson) Date: Thu, 16 Dec 2004 16:41:16 -0600 Subject: [geeklog-devel] Article throttle. Message-ID: <3d1a3f4e041216144179604a10@mail.gmail.com> Some sites get nailed, by links from slashdot, or other similar sites. An example would be GrokLaw. I've got what I think is an incredibly simple solution. I've taken the current version of Geeklog, and added these lines: to the conf file: // Article // This will allow you to setup a throttle based on guests and direct links to // stories. For example, if you set the throttle to 300, and there are 300 guest // users online, any story or article linked from another site will only display // the text of the item, no layout or general site graphics. This very simplistic // method of bandwidth protection could save your site in the event of a // sudden surge of activity. $_CONF['throttle'] = '0'; // A value of '0' will shut the throttle off. (default) Then in public_html/article.php, I've added the following code at or near line 73 ( after the if (isset ($HTTP_POST_VARS['mode'])) { } block. // Throttle $rs = DB_query( "SELECT DISTINCT uid,remote_ip FROM {$_TABLES['sessions']} WHERE uid = 1" ); if($_CONF['throttle']>0 && DB_numRows($rs)>=$_CONF['throttle'] && !eregi($_CONF['site_url'],$_SERVER['HTTP_REFERER'])) $mode='print'; What this does is extremely simple. The owner of the website sets a throttle, which is a number of guest users. Once this number is reached, any article accessed from an external link or directly accessed will display in print mode. This should greatly reduce the number of database queries, as well as the number of GET requests to the server. ( No site graphics, only story graphics ). For GL2, I'd like to build more into the site, to allow any page to be throttled, but for the current release I feel is pretty decent. I have not contributed before. I am looking for thoughts and, I guess, someone to place this into the test site for including in the next version. From justin.carlson at gmail.com Thu Dec 16 17:46:51 2004 From: justin.carlson at gmail.com (Justin Carlson) Date: Thu, 16 Dec 2004 16:46:51 -0600 Subject: [geeklog-devel] Re: Article throttle. In-Reply-To: <3d1a3f4e041216144179604a10@mail.gmail.com> References: <3d1a3f4e041216144179604a10@mail.gmail.com> Message-ID: <3d1a3f4e041216144611bd4812@mail.gmail.com> I should probably clean this a little for read-ability, and so it does not query if the throttle is not on: // Throttle if($_CONF['throttle']>0){ $rs = DB_query( "SELECT DISTINCT uid,remote_ip FROM {$_TABLES['sessions']} WHERE uid = 1" ); if(DB_numRows($rs)>=$_CONF['throttle'])}{ if(!eregi($_CONF['site_url'],$_SERVER['HTTP_REFERER'])){ $mode='print'; } } } On Thu, 16 Dec 2004 16:41:16 -0600, Justin Carlson wrote: > Some sites get nailed, by links from slashdot, or other similar sites. > An example would be GrokLaw. > > I've got what I think is an incredibly simple solution. > I've taken the current version of Geeklog, and added these lines: to > the conf file: > > // Article > // This will allow you to setup a throttle based on guests and direct links to > // stories. For example, if you set the throttle to 300, and there are 300 guest > // users online, any story or article linked from another site will only display > // the text of the item, no layout or general site graphics. This very > simplistic > // method of bandwidth protection could save your site in the event of a > // sudden surge of activity. > $_CONF['throttle'] = '0'; > // A value of '0' will shut the throttle off. (default) > > Then in public_html/article.php, I've added the following code at or > near line 73 ( after the if (isset ($HTTP_POST_VARS['mode'])) { } > block. > > // Throttle > $rs = DB_query( "SELECT DISTINCT uid,remote_ip FROM > {$_TABLES['sessions']} WHERE uid = 1" ); > if($_CONF['throttle']>0 && DB_numRows($rs)>=$_CONF['throttle'] && > !eregi($_CONF['site_url'],$_SERVER['HTTP_REFERER'])) $mode='print'; > > What this does is extremely simple. The owner of the website sets a > throttle, which is a number of guest users. Once this number is > reached, any article accessed from an external link or directly > accessed will display in print mode. This should greatly reduce the > number of database queries, as well as the number of GET requests to > the server. ( No site graphics, only story graphics ). > > For GL2, I'd like to build more into the site, to allow any page to be > throttled, but for the current release I feel is pretty decent. > > I have not contributed before. I am looking for thoughts and, I guess, > someone to place this into the test site for including in the next > version. > From vfuria at gmail.com Thu Dec 16 23:36:21 2004 From: vfuria at gmail.com (Vincent Furia) Date: Thu, 16 Dec 2004 23:36:21 -0500 Subject: [geeklog-devel] Actual Working Schema for GL2 In-Reply-To: <41C20197.2050102@tonybibbs.com> References: <41C20197.2050102@tonybibbs.com> Message-ID: <8319e2d60412162036731a06d3@mail.gmail.com> Tony, A couple more things: 1. You don't need the left_index or right_index in gl_category since it has 1-1 relationship with the item table which already has those. 2. Why are you using INTs for dates? Why not TIMESTAMPs or DATETIMEs? 3. Don't forget you want indexes on columns on which you plan to sort. 4. In gl2_group change the display_name column to group_name to be consistent. 5. I think we should standardize on just a couple lengths of varchar fields (all URLs should be 256, all _names should be 40 or 50). - the homepage varchar in gl2_user is way too short, presumably this is a URL 6. gl2_item_type_state seems redundant. Just use the LOV Table, where the group_name indicates type and the lov_id/short_name indicate that state. Or am I missing something? -Vinny On Thu, 16 Dec 2004 15:43:51 -0600, Tony Bibbs wrote: > Ok, I've attached a working version of the schema. Worth noting, is > anywhere in the old schema where we had parent_id fields I replaced them > with the left_index, right_index. Seems to me that if it is good enough > for comment performance, it's good enough for everyone else. > > Next up is to build the first set of Propel classes from this schema. > Cross your fingers. > > --Tony From justin.carlson at gmail.com Fri Dec 17 03:38:15 2004 From: justin.carlson at gmail.com (Justin Carlson) Date: Fri, 17 Dec 2004 02:38:15 -0600 Subject: [geeklog-devel] Actual Working Schema for GL2 In-Reply-To: <8319e2d60412162036731a06d3@mail.gmail.com> References: <41C20197.2050102@tonybibbs.com> <8319e2d60412162036731a06d3@mail.gmail.com> Message-ID: <3d1a3f4e0412170038530d2970@mail.gmail.com> > 2. Why are you using INTs for dates? Why not TIMESTAMPs or DATETIMEs? For mktime() or time() stamps, at least, that's what I like to use. Then users can choose whatever they want via a dropdown, allowing them to easily set zone and date format. From vfuria at gmail.com Fri Dec 17 08:27:34 2004 From: vfuria at gmail.com (Vincent Furia) Date: Fri, 17 Dec 2004 08:27:34 -0500 Subject: [geeklog-devel] Actual Working Schema for GL2 In-Reply-To: <3d1a3f4e0412170038530d2970@mail.gmail.com> References: <41C20197.2050102@tonybibbs.com> <8319e2d60412162036731a06d3@mail.gmail.com> <3d1a3f4e0412170038530d2970@mail.gmail.com> Message-ID: <8319e2d60412170527498d5c18@mail.gmail.com> Then why not use TIMESTAMPs or DATETIMEs? Changing the format of a date/time string is a trivial and fast operation. Plus using DATETIMEs allows you to use any date from 1-1-0000 to 12-21-9999 as opposed to just ~1970 to ~2037. Both have the same flexibility as using a timestamp stored as an int, in addition they give you more flexibility to do calculations on the server using mysql's time functions. -Vinny On Fri, 17 Dec 2004 02:38:15 -0600, Justin Carlson wrote: > > 2. Why are you using INTs for dates? Why not TIMESTAMPs or DATETIMEs? > > For mktime() or time() stamps, at least, that's what I like to use. > Then users can choose whatever they want via a dropdown, allowing them > to easily set zone and date format. > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Fri Dec 17 10:34:14 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 17 Dec 2004 09:34:14 -0600 Subject: [geeklog-devel] Actual Working Schema for GL2 In-Reply-To: <8319e2d60412162036731a06d3@mail.gmail.com> References: <41C20197.2050102@tonybibbs.com> <8319e2d60412162036731a06d3@mail.gmail.com> Message-ID: <41C2FC76.6070407@tonybibbs.com> Vincent Furia wrote: >Tony, > >A couple more things: > >1. You don't need the left_index or right_index in gl_category since >it has 1-1 relationship with the item table which already has those. > > Right you are >2. Why are you using INTs for dates? Why not TIMESTAMPs or DATETIMEs? > > Well, we need to discuss the issue of dates. Date handling, even with an ORM can be a PITA with the native types from a DBMS. I need to play with Propel more with this before we make a decision. Long and short is I want to be sure the code that works with dates works across DBMS's >3. Don't forget you want indexes on columns on which you plan to sort. > > I'll double check. If there are some you think I missed send them over for verification. >4. In gl2_group change the display_name column to group_name to be consistent. > > Right >5. I think we should standardize on just a couple lengths of varchar >fields (all URLs should be 256, all _names should be 40 or 50). > - the homepage varchar in gl2_user is way too short, presumably >this is a URL > > Yeah, I was thinking the same thing. I'm betting Dwight might have some good standards to start with. I was simply pulling the length out of my backside (if you can't tell) >6. gl2_item_type_state seems redundant. Just use the LOV Table, where >the group_name indicates type and the lov_id/short_name indicate that >state. Or am I missing something? > > Yeah, made the change. >-Vinny > > >On Thu, 16 Dec 2004 15:43:51 -0600, Tony Bibbs wrote: > > >>Ok, I've attached a working version of the schema. Worth noting, is >>anywhere in the old schema where we had parent_id fields I replaced them >>with the left_index, right_index. Seems to me that if it is good enough >>for comment performance, it's good enough for everyone else. >> >>Next up is to build the first set of Propel classes from this schema. >>Cross your fingers. >> >>--Tony >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From justin.carlson at gmail.com Fri Dec 17 11:04:56 2004 From: justin.carlson at gmail.com (Justin Carlson) Date: Fri, 17 Dec 2004 10:04:56 -0600 Subject: [geeklog-devel] Actual Working Schema for GL2 In-Reply-To: <8319e2d60412170527498d5c18@mail.gmail.com> References: <41C20197.2050102@tonybibbs.com> <8319e2d60412162036731a06d3@mail.gmail.com> <3d1a3f4e0412170038530d2970@mail.gmail.com> <8319e2d60412170527498d5c18@mail.gmail.com> Message-ID: <3d1a3f4e041217080465387817@mail.gmail.com> That's fine and all, just offering my thoughts. It is true that it limits you to 1970 - 2037 or so, and that is a drawback if you are working with dates in that range. ( If you plan on storing people's birthdays or whatever ). I've just seen: $example = date($userPref,$dbdatedata); and think it's pretty simple. It's also sort-easy, of course YYYY-MM-DD HH:II:SS would sort and that point is moot Tony's point is very valid. On Fri, 17 Dec 2004 08:27:34 -0500, Vincent Furia wrote: > Then why not use TIMESTAMPs or DATETIMEs? Changing the format of a > date/time string is a trivial and fast operation. Plus using > DATETIMEs allows you to use any date from 1-1-0000 to 12-21-9999 as > opposed to just ~1970 to ~2037. Both have the same flexibility as > using a timestamp stored as an int, in addition they give you more > flexibility to do calculations on the server using mysql's time > functions. > > -Vinny > > On Fri, 17 Dec 2004 02:38:15 -0600, Justin Carlson > wrote: > > > 2. Why are you using INTs for dates? Why not TIMESTAMPs or DATETIMEs? > > > > For mktime() or time() stamps, at least, that's what I like to use. > > Then users can choose whatever they want via a dropdown, allowing them > > to easily set zone and date format. > > _______________________________________________ > > geeklog-devel mailing list > > geeklog-devel at lists.geeklog.net > > http://lists.geeklog.net/listinfo/geeklog-devel > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Fri Dec 17 11:25:22 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 17 Dec 2004 10:25:22 -0600 Subject: [geeklog-devel] GL2 and CVS Message-ID: <41C30872.8030204@tonybibbs.com> At what point should I start checking stuff into CVS? I've yet another modified database schema that I added timezone stuff too along with changes per Vinny's suggestions in his last email. I didn't touch the date/time fields yet. Anyway, my point is I have a Propel build so do you want me to CVS this as the first version or simply wait until we iron all the outstanding database issues? --Tony From tony at tonybibbs.com Fri Dec 17 11:45:50 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 17 Dec 2004 10:45:50 -0600 Subject: [geeklog-devel] [Fwd: Re: [propel] Multiple DBMS's and date/time] Message-ID: <41C30D3E.806@tonybibbs.com> Seems like we should go with the timestamp data type. Read below. --Tony -------- Original Message -------- Subject: Re: [propel] Multiple DBMS's and date/time Date: Fri, 17 Dec 2004 11:36:17 -0500 (EST) From: Hans Lellelid Reply-To: users at propel.tigris.org To: users at propel.tigris.org References: <41C304F4.7020205 at tonybibbs.com> <15195.69.17.56.162.1103300475.spork at webmail.hozn.net> <41C308F8.2090905 at tonybibbs.com> Yeah, I'm quite sure you can set it at runtime, though you may need to set it before opening the connection. I used to set it in Creole MSSQLConnection class, but there was some reason that this wasn't always a good idea. ... perhaps it was breaking when using freetds instead of MS libs or something. -Hans > Cool. Is the MSSQL option you refer to in php.ini something I can set > at runtime via ini_set()? > > --Tony > > Hans Lellelid wrote: > >>>I have a project that will be supported under multiple DBMS's (MySQL, >>>Postgres and MS SQL). We are doing the general database design and we >>>are to the topic of how to formate date/time values. All our values >>>will be after 1970 so timestamps are an options. My question is whether >>>or not to use the native date/time types in the DBMS via Propel. Does >>>Propel handle this well or am I better of using a timestamp datatype or >>>int? >>> >>> >>> >> >>Propel handles this well and I would advise you to use TIMESTAMP rather >>than INT. >> >>TIMESTAMP will be converted to the best representation (e.g. for MySQL it >>will use DATETIME) for the RDBMS. The only thing you'll probably want to >>fix is the MSSQL ini option (in php.ini) to have it use standard ISO date >>formats. >> >>The getter methods that are generated by Propel will actually allow you >> to >>specify date/time formatters: >> >>$myobj->getTimeCol("Y-m-d"); // date()-formatting >> >>or >> >>$myobj->getTimeCol("%c"); // strftime()-formatting >> >>or >> >>$myobj->getTimeCol(null); // native unix timestamp >> >>or >> >>$myobj->getTimeCol(); // default is ISO: Y-m-d H:i:s >> >>Hope that helps. >> >>-Hans >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: users-unsubscribe at propel.tigris.org >>For additional commands, e-mail: users-help at propel.tigris.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe at propel.tigris.org > For additional commands, e-mail: users-help at propel.tigris.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe at propel.tigris.org For additional commands, e-mail: users-help at propel.tigris.org From vfuria at gmail.com Fri Dec 17 12:16:53 2004 From: vfuria at gmail.com (Vincent Furia) Date: Fri, 17 Dec 2004 12:16:53 -0500 Subject: [geeklog-devel] [Fwd: Re: [propel] Multiple DBMS's and date/time] In-Reply-To: <41C30D3E.806@tonybibbs.com> References: <41C30D3E.806@tonybibbs.com> Message-ID: <8319e2d6041217091616d9aa54@mail.gmail.com> TIMESTAMP in Propel == DATETIME in MySQL. So in mysql DDL you'd want to use DATETIME. -Vinny On Fri, 17 Dec 2004 10:45:50 -0600, Tony Bibbs wrote: > Seems like we should go with the timestamp data type. Read below. > > --Tony > > -------- Original Message -------- > Subject: Re: [propel] Multiple DBMS's and date/time > Date: Fri, 17 Dec 2004 11:36:17 -0500 (EST) > From: Hans Lellelid > Reply-To: users at propel.tigris.org > To: users at propel.tigris.org > References: <41C304F4.7020205 at tonybibbs.com> > <15195.69.17.56.162.1103300475.spork at webmail.hozn.net> > <41C308F8.2090905 at tonybibbs.com> > > Yeah, I'm quite sure you can set it at runtime, though you may need to set > it before opening the connection. I used to set it in Creole > MSSQLConnection class, but there was some reason that this wasn't always a > good idea. ... perhaps it was breaking when using freetds instead of MS > libs or something. > > -Hans > > > Cool. Is the MSSQL option you refer to in php.ini something I can set > > at runtime via ini_set()? > > > > --Tony > > > > Hans Lellelid wrote: > > > >>>I have a project that will be supported under multiple DBMS's (MySQL, > >>>Postgres and MS SQL). We are doing the general database design and we > >>>are to the topic of how to formate date/time values. All our values > >>>will be after 1970 so timestamps are an options. My question is whether > >>>or not to use the native date/time types in the DBMS via Propel. Does > >>>Propel handle this well or am I better of using a timestamp datatype or > >>>int? > >>> > >>> > >>> > >> > >>Propel handles this well and I would advise you to use TIMESTAMP rather > >>than INT. > >> > >>TIMESTAMP will be converted to the best representation (e.g. for MySQL it > >>will use DATETIME) for the RDBMS. The only thing you'll probably want to > >>fix is the MSSQL ini option (in php.ini) to have it use standard ISO date > >>formats. > >> > >>The getter methods that are generated by Propel will actually allow you > >> to > >>specify date/time formatters: > >> > >>$myobj->getTimeCol("Y-m-d"); // date()-formatting > >> > >>or > >> > >>$myobj->getTimeCol("%c"); // strftime()-formatting > >> > >>or > >> > >>$myobj->getTimeCol(null); // native unix timestamp > >> > >>or > >> > >>$myobj->getTimeCol(); // default is ISO: Y-m-d H:i:s > >> > >>Hope that helps. > >> > >>-Hans > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: users-unsubscribe at propel.tigris.org > >>For additional commands, e-mail: users-help at propel.tigris.org > >> > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscribe at propel.tigris.org > > For additional commands, e-mail: users-help at propel.tigris.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe at propel.tigris.org > For additional commands, e-mail: users-help at propel.tigris.org > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From vfuria at gmail.com Fri Dec 17 12:18:55 2004 From: vfuria at gmail.com (Vincent Furia) Date: Fri, 17 Dec 2004 12:18:55 -0500 Subject: [geeklog-devel] GL2 and CVS In-Reply-To: <41C30872.8030204@tonybibbs.com> References: <41C30872.8030204@tonybibbs.com> Message-ID: <8319e2d604121709185d398b81@mail.gmail.com> CVS or Subversion? I'd like to see us switch to subversion as CVS support seems to be dropping off rapidly. Switching from CVS to subversion, from a user perspective, isn't too horrible a change if you spend just a little time with the subversion documentation. Obviously if we're voting on this, my vote goes to subversion. -Vinny On Fri, 17 Dec 2004 10:25:22 -0600, Tony Bibbs wrote: > At what point should I start checking stuff into CVS? I've yet another > modified database schema that I added timezone stuff too along with > changes per Vinny's suggestions in his last email. I didn't touch the > date/time fields yet. > > Anyway, my point is I have a Propel build so do you want me to CVS this > as the first version or simply wait until we iron all the outstanding > database issues? > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Fri Dec 17 13:46:56 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 17 Dec 2004 12:46:56 -0600 Subject: [geeklog-devel] GL2 and CVS In-Reply-To: <8319e2d604121709185d398b81@mail.gmail.com> References: <41C30872.8030204@tonybibbs.com> <8319e2d604121709185d398b81@mail.gmail.com> Message-ID: <41C329A0.2020401@tonybibbs.com> Subversion is fine. I've read enough and see a lot of reputable projects moving to it. And, if we need any other reason for dropping CVS, it's not being actively developed near as much. My question still stands, though ;-) --Tony Vincent Furia wrote: >CVS or Subversion? I'd like to see us switch to subversion as CVS >support seems to be dropping off rapidly. Switching from CVS to >subversion, from a user perspective, isn't too horrible a change if >you spend just a little time with the subversion documentation. >Obviously if we're voting on this, my vote goes to subversion. > >-Vinny > > >On Fri, 17 Dec 2004 10:25:22 -0600, Tony Bibbs wrote: > > >>At what point should I start checking stuff into CVS? I've yet another >>modified database schema that I added timezone stuff too along with >>changes per Vinny's suggestions in his last email. I didn't touch the >>date/time fields yet. >> >>Anyway, my point is I have a Propel build so do you want me to CVS this >>as the first version or simply wait until we iron all the outstanding >>database issues? >> >>--Tony >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From dirk at haun-online.de Fri Dec 17 14:30:42 2004 From: dirk at haun-online.de (Dirk Haun) Date: Fri, 17 Dec 2004 20:30:42 +0100 Subject: [geeklog-devel] InnoDB (was: Draft of schema for GL2) In-Reply-To: <41C1C941.3000408@tonybibbs.com> References: <41C1C941.3000408@tonybibbs.com> Message-ID: <20041217193042.17701@smtp.haun-online.de> (trying to catch up with all the posts here ...) >I think eventually ISP's will get their act together and start >supporting versions of MySQL that support INNODB (why that wouldn't be >the default table type moving forward is beyond me). My hosting service still uses MySQL 3.23.57. They say they're not happy with how MySQL 4.0.x performed in their tests. And no, InnoDB support is not built into that 3.23.57 install. There is some indication that they will move over to MySQL 4.x eventually in the not too-distant future, though. But this is just a real-life example. The hosting service has a good reputation and I'm very happy with them, so they must be doing something right ... Upgrading PHP seems to be less complicated. geeklog.info is running on PHP 5.0.3 since yesterday, only hours after it was released (they let you choose between PHP 4 and 5 on a per-domain basis). bye, Dirk -- http://www.haun-online.de/ http://www.tinyweb.de/ From dirk at haun-online.de Fri Dec 17 14:54:43 2004 From: dirk at haun-online.de (Dirk Haun) Date: Fri, 17 Dec 2004 20:54:43 +0100 Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <41C10CB9.2060109@tonybibbs.com> References: <41C10CB9.2060109@tonybibbs.com> Message-ID: <20041217195443.32304@smtp.haun-online.de> >>Do we want an association table between items and categories so items >>can be in multiple categories? >> >> >Good question. It gives more flexibility...a tad bit more complexity. >Any objections? If this would enable stories to be in multiple topics, blocks to be in multiple topics, and smililar constructs, then our users want it ... I have to admit I'm not quite sure what you're actually talking about here ;-) bye, Dirk -- http://www.haun-online.de/ http://www.macosx-faq.de/ From tony at tonybibbs.com Fri Dec 17 16:15:17 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 17 Dec 2004 15:15:17 -0600 Subject: [geeklog-devel] InnoDB In-Reply-To: <20041217193042.17701@smtp.haun-online.de> References: <41C1C941.3000408@tonybibbs.com> <20041217193042.17701@smtp.haun-online.de> Message-ID: <41C34C65.9090406@tonybibbs.com> Gotcha. Point well taken. Glad the INNODB issue isn't really an issue since the MySQL folks were proactive enough to simply convert them to MyISAM. --Tony Dirk Haun wrote: >(trying to catch up with all the posts here ...) > > > >>I think eventually ISP's will get their act together and start >>supporting versions of MySQL that support INNODB (why that wouldn't be >>the default table type moving forward is beyond me). >> >> > >My hosting service still uses MySQL 3.23.57. They say they're not happy >with how MySQL 4.0.x performed in their tests. And no, InnoDB support is >not built into that 3.23.57 install. > >There is some indication that they will move over to MySQL 4.x eventually >in the not too-distant future, though. But this is just a real-life >example. The hosting service has a good reputation and I'm very happy >with them, so they must be doing something right ... > >Upgrading PHP seems to be less complicated. geeklog.info is running on >PHP 5.0.3 since yesterday, only hours after it was released (they let you >choose between PHP 4 and 5 on a per-domain basis). > >bye, Dirk > > > > From tony at tonybibbs.com Fri Dec 17 16:18:36 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 17 Dec 2004 15:18:36 -0600 Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <20041217195443.32304@smtp.haun-online.de> References: <41C10CB9.2060109@tonybibbs.com> <20041217195443.32304@smtp.haun-online.de> Message-ID: <41C34D2C.2050607@tonybibbs.com> Lol, well this is exactly that point. Items are the generic abstraction of 'things' in GL2 (blocks, stories, links, etc). So, to be clear we are allowing the article plugin, for example, to have a story tied to more than one topic in 1.3.10 terminology. --Tony Dirk Haun wrote: >>>Do we want an association table between items and categories so items >>>can be in multiple categories? >>> >>> >>> >>> >>Good question. It gives more flexibility...a tad bit more complexity. >>Any objections? >> >> > >If this would enable stories to be in multiple topics, blocks to be in >multiple topics, and smililar constructs, then our users want it ... > >I have to admit I'm not quite sure what you're actually talking about here ;-) > >bye, Dirk > > > > From tony at tonybibbs.com Fri Dec 17 16:35:08 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 17 Dec 2004 15:35:08 -0600 Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <20041217195443.32304@smtp.haun-online.de> References: <41C10CB9.2060109@tonybibbs.com> <20041217195443.32304@smtp.haun-online.de> Message-ID: <41C3510C.4090206@tonybibbs.com> Ok, I've attached the latest schema. My next question is do we need to worry about the potential size of the gl2_item table from a performance view point? I just did some preliminary counts on key tables for Iowa Outdoors and I would have in the neighborhood of 150,000 records in the item table. So extrapolate that out to, say a Groklaw, I think you could get well into the millions of records. I don't think it's the number of rows in the database that bothers me as much as doing the joins to all the plugin-specific one-to-one item tables to the main item table at the same time. Someone with a real DBA mindset needs to make sure I'm not going off my rocker. --Tony Dirk Haun wrote: >>>Do we want an association table between items and categories so items >>>can be in multiple categories? >>> >>> >>> >>> >>Good question. It gives more flexibility...a tad bit more complexity. >>Any objections? >> >> > >If this would enable stories to be in multiple topics, blocks to be in >multiple topics, and smililar constructs, then our users want it ... > >I have to admit I'm not quite sure what you're actually talking about here ;-) > >bye, Dirk > > > > From tony at tonybibbs.com Fri Dec 17 16:39:41 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 17 Dec 2004 15:39:41 -0600 Subject: [geeklog-devel] Draft of schema for GL2 In-Reply-To: <41C3510C.4090206@tonybibbs.com> References: <41C10CB9.2060109@tonybibbs.com> <20041217195443.32304@smtp.haun-online.de> <41C3510C.4090206@tonybibbs.com> Message-ID: <41C3521D.6040104@tonybibbs.com> (sigh) it's attached. Tony Bibbs wrote: > Ok, I've attached the latest schema. > > My next question is do we need to worry about the potential size of > the gl2_item table from a performance view point? > > I just did some preliminary counts on key tables for Iowa Outdoors and > I would have in the neighborhood of 150,000 records in the item > table. So extrapolate that out to, say a Groklaw, I think you could > get well into the millions of records. > > I don't think it's the number of rows in the database that bothers me > as much as doing the joins to all the plugin-specific one-to-one item > tables to the main item table at the same time. > > Someone with a real DBA mindset needs to make sure I'm not going off > my rocker. > > --Tony > > Dirk Haun wrote: > >>>> Do we want an association table between items and categories so items >>>> can be in multiple categories? >>>> >>>> >>>> >>> >>> Good question. It gives more flexibility...a tad bit more >>> complexity. Any objections? >>> >> >> >> If this would enable stories to be in multiple topics, blocks to be in >> multiple topics, and smililar constructs, then our users want it ... >> >> I have to admit I'm not quite sure what you're actually talking about >> here ;-) >> >> bye, Dirk >> >> >> >> > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: create.sql URL: From vfuria at gmail.com Fri Dec 17 16:51:46 2004 From: vfuria at gmail.com (Vincent Furia) Date: Fri, 17 Dec 2004 16:51:46 -0500 Subject: [geeklog-devel] GL2 License Message-ID: <8319e2d6041217135114d40e82@mail.gmail.com> We should decide on a license now, before we get into any serious coding (I know, too late for Tony). I'd like to see us use the LGPL, assuming there is no conflict with using the LGPL with PHP licensed code (I don't think there is one). Plugins of course could be licensed however the developer see fits. Of course if no one else wants to go the LGPL route I'd accept a PHP style license. Other licenses will be considered on a case by case basis. -Vinny From tomw at pigstye.net Fri Dec 17 16:57:45 2004 From: tomw at pigstye.net (Tom Willett) Date: Fri, 17 Dec 2004 16:57:45 -0500 Subject: [geeklog-devel] PHP Vulns Message-ID: <41C35659.2060505@pigstye.net> Looking at the latest php vulnerabilities http://www.hardened-php.net/advisories/012004.txt It looks like the code in Geeklog proper is OK but pear distributed with Geekloog and magpierss (used in spamx) use some of the vulnerable functions. At least Geeklog was not listed as a vulnerable script like: - phpBB2 - Invision Board - vBulletin - Woltlab Burning Board 2.x - Serendipity Weblog - phpAds(New) were. -- Tom Willett tomw at pigstye.net From tony at tonybibbs.com Fri Dec 17 17:01:29 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 17 Dec 2004 16:01:29 -0600 Subject: [geeklog-devel] GL2 License In-Reply-To: <8319e2d6041217135114d40e82@mail.gmail.com> References: <8319e2d6041217135114d40e82@mail.gmail.com> Message-ID: <41C35739.6090709@tonybibbs.com> I say dual license. This would force us to take all community based contributions and rewrite them into GL2 (ala MySQL) but it gives us flexiblity. The only thing I want to prevent is ISP's leeching from us by offering GL2 as a service offering and not giving anything back. I'm not saying they have to give money (which would be nice) but hosting (like pair does now) or some other value add for the project would be nice. Just my two cents. --Tony Vincent Furia wrote: >We should decide on a license now, before we get into any serious >coding (I know, too late for Tony). I'd like to see us use the LGPL, >assuming there is no conflict with using the LGPL with PHP licensed >code (I don't think there is one). Plugins of course could be >licensed however the developer see fits. > >Of course if no one else wants to go the LGPL route I'd accept a PHP >style license. Other licenses will be considered on a case by case >basis. > >-Vinny >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From dirk at haun-online.de Fri Dec 17 17:17:56 2004 From: dirk at haun-online.de (Dirk Haun) Date: Fri, 17 Dec 2004 23:17:56 +0100 Subject: [geeklog-devel] Article throttle. In-Reply-To: <3d1a3f4e041216144179604a10@mail.gmail.com> References: <3d1a3f4e041216144179604a10@mail.gmail.com> Message-ID: <20041217221756.15135@smtp.haun-online.de> Justin, >What this does is extremely simple. The owner of the website sets a >throttle, which is a number of guest users. Once this number is >reached, any article accessed from an external link or directly >accessed will display in print mode. This should greatly reduce the >number of database queries Sounds interesting. My suspicion, though, is that in most cases, it's the index page that is hit by most of the traffic. Especially Slashdot readers are known not to RTFA :P Are our friends from Groklaw still around? Niels, Peter? bye, Dirk -- http://www.haun-online.de/ http://www.tinyweb.de/ From tony at tonybibbs.com Fri Dec 17 17:44:56 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 17 Dec 2004 16:44:56 -0600 Subject: [geeklog-devel] GL2 and CVS In-Reply-To: <41C329A0.2020401@tonybibbs.com> References: <41C30872.8030204@tonybibbs.com> <8319e2d604121709185d398b81@mail.gmail.com> <41C329A0.2020401@tonybibbs.com> Message-ID: <41C36168.7010902@tonybibbs.com> Ok, the server I have at the colo is on a fairly recent version of Apache 1. Subversion requires Apache 2 so I'll need to upgrade apache first. That said, I'll probably start it off in CVS since, I hear, that Subversion can convert CVS repositories over. --Tony Tony Bibbs wrote: > Subversion is fine. I've read enough and see a lot of reputable > projects moving to it. And, if we need any other reason for dropping > CVS, it's not being actively developed near as much. > > My question still stands, though ;-) > > --Tony > > Vincent Furia wrote: > >> CVS or Subversion? I'd like to see us switch to subversion as CVS >> support seems to be dropping off rapidly. Switching from CVS to >> subversion, from a user perspective, isn't too horrible a change if >> you spend just a little time with the subversion documentation. >> Obviously if we're voting on this, my vote goes to subversion. >> >> -Vinny >> >> >> On Fri, 17 Dec 2004 10:25:22 -0600, Tony Bibbs >> wrote: >> >> >>> At what point should I start checking stuff into CVS? I've yet another >>> modified database schema that I added timezone stuff too along with >>> changes per Vinny's suggestions in his last email. I didn't touch the >>> date/time fields yet. >>> >>> Anyway, my point is I have a Propel build so do you want me to CVS this >>> as the first version or simply wait until we iron all the outstanding >>> database issues? >>> >>> --Tony >>> _______________________________________________ >>> geeklog-devel mailing list >>> geeklog-devel at lists.geeklog.net >>> http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >> >> _______________________________________________ >> geeklog-devel mailing list >> geeklog-devel at lists.geeklog.net >> http://lists.geeklog.net/listinfo/geeklog-devel >> >> > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Fri Dec 17 18:25:20 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 17 Dec 2004 17:25:20 -0600 Subject: [geeklog-devel] GL2 and CVS In-Reply-To: <41C36168.7010902@tonybibbs.com> References: <41C30872.8030204@tonybibbs.com> <8319e2d604121709185d398b81@mail.gmail.com> <41C329A0.2020401@tonybibbs.com> <41C36168.7010902@tonybibbs.com> Message-ID: <41C36AE0.7000205@tonybibbs.com> Ok, first bit of code is in CVS: http://cvs.geeklog.net/cvs.php/Geeklog-2 Note that I am not including MVCnPHP and PEAR classes by default. Those directories should be added prior to a release for the community. I'm assuming all developers will install all 3rd party libraries themselves. --Tony Tony Bibbs wrote: > Ok, the server I have at the colo is on a fairly recent version of > Apache 1. Subversion requires Apache 2 so I'll need to upgrade apache > first. That said, I'll probably start it off in CVS since, I hear, > that Subversion can convert CVS repositories over. > > --Tony > > Tony Bibbs wrote: > >> Subversion is fine. I've read enough and see a lot of reputable >> projects moving to it. And, if we need any other reason for dropping >> CVS, it's not being actively developed near as much. >> >> My question still stands, though ;-) >> >> --Tony >> >> Vincent Furia wrote: >> >>> CVS or Subversion? I'd like to see us switch to subversion as CVS >>> support seems to be dropping off rapidly. Switching from CVS to >>> subversion, from a user perspective, isn't too horrible a change if >>> you spend just a little time with the subversion documentation. >>> Obviously if we're voting on this, my vote goes to subversion. >>> >>> -Vinny >>> >>> >>> On Fri, 17 Dec 2004 10:25:22 -0600, Tony Bibbs >>> wrote: >>> >>> >>>> At what point should I start checking stuff into CVS? I've yet >>>> another >>>> modified database schema that I added timezone stuff too along with >>>> changes per Vinny's suggestions in his last email. I didn't touch the >>>> date/time fields yet. >>>> >>>> Anyway, my point is I have a Propel build so do you want me to CVS >>>> this >>>> as the first version or simply wait until we iron all the outstanding >>>> database issues? >>>> >>>> --Tony >>>> _______________________________________________ >>>> geeklog-devel mailing list >>>> geeklog-devel at lists.geeklog.net >>>> http://lists.geeklog.net/listinfo/geeklog-devel >>>> >>>> >>> >>> >>> _______________________________________________ >>> geeklog-devel mailing list >>> geeklog-devel at lists.geeklog.net >>> http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >> >> _______________________________________________ >> geeklog-devel mailing list >> geeklog-devel at lists.geeklog.net >> http://lists.geeklog.net/listinfo/geeklog-devel > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Fri Dec 17 19:01:43 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 17 Dec 2004 18:01:43 -0600 Subject: [geeklog-devel] Translation2 issue Message-ID: <41C37367.9040301@tonybibbs.com> Apparently Translation2's gettext support requires we have the PEAR::I18Nv2 package installed (which is in alpha) and that seems to require the iconv extension be compiled into PHP. I'm not sure if the iconv is a temporary requirement until the PEAR::I18Nv2 coding gets further along or not. If we can't get around this, we may have to revert to the XML format, no? --Tony From vfuria at gmail.com Fri Dec 17 23:30:17 2004 From: vfuria at gmail.com (Vincent Furia) Date: Fri, 17 Dec 2004 23:30:17 -0500 Subject: [geeklog-devel] Translation2 issue In-Reply-To: <41C37367.9040301@tonybibbs.com> References: <41C37367.9040301@tonybibbs.com> Message-ID: <8319e2d60412172030cd4a99@mail.gmail.com> It wouldn't be too much work to use gettext and PEAR::File_Gettext to write a translation class that would work like Translation2. Alternatively we could simply tear the PEAR::I18Nv2 dependency out of Translation2 and roll our version (yay open source). I hate to give up gettext because its so efficient (processor and memory). -Vinny On Fri, 17 Dec 2004 18:01:43 -0600, Tony Bibbs wrote: > Apparently Translation2's gettext support requires we have the > PEAR::I18Nv2 package installed (which is in alpha) and that seems to > require the iconv extension be compiled into PHP. I'm not sure if the > iconv is a temporary requirement until the PEAR::I18Nv2 coding gets > further along or not. > > If we can't get around this, we may have to revert to the XML format, no? > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Fri Dec 17 23:33:08 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 17 Dec 2004 22:33:08 -0600 Subject: [geeklog-devel] Translation2 issue In-Reply-To: <8319e2d60412172030cd4a99@mail.gmail.com> References: <41C37367.9040301@tonybibbs.com> <8319e2d60412172030cd4a99@mail.gmail.com> Message-ID: <41C3B304.3000206@tonybibbs.com> K. I'm looking at this stuff now trying to organize the base view classes. I got some information from Alan Knowles I'll forward on as well which will help. --Tony Vincent Furia wrote: >It wouldn't be too much work to use gettext and PEAR::File_Gettext to >write a translation class that would work like Translation2. >Alternatively we could simply tear the PEAR::I18Nv2 dependency out of >Translation2 and roll our version (yay open source). I hate to give >up gettext because its so efficient (processor and memory). > >-Vinny > > >On Fri, 17 Dec 2004 18:01:43 -0600, Tony Bibbs wrote: > > >>Apparently Translation2's gettext support requires we have the >>PEAR::I18Nv2 package installed (which is in alpha) and that seems to >>require the iconv extension be compiled into PHP. I'm not sure if the >>iconv is a temporary requirement until the PEAR::I18Nv2 coding gets >>further along or not. >> >>If we can't get around this, we may have to revert to the XML format, no? >> >>--Tony >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From tony at tonybibbs.com Fri Dec 17 23:34:49 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Fri, 17 Dec 2004 22:34:49 -0600 Subject: [geeklog-devel] [Fwd: Re: Flexy translation] Message-ID: <41C3B369.8040109@tonybibbs.com> Worth reading. I'm going to try and get the SOB working tonight. --Tony -------- Original Message -------- Subject: Re: Flexy translation Date: Sat, 18 Dec 2004 11:32:52 +0800 From: Alan Knowles To: Tony Bibbs References: <41C376A4.5010305 at tonybibbs.com> Ok, you need the latest CVS (translation2 as well) - as I there are a few fixes in it.. constructor: $x = new HTML_Template_Flexy(array( ..... usual options.... 'locale' => 'fr', 'Translation2' => array('driver' => 'dataobjectsimple') )); .. a template containing.. Username will be compiled to xxx.fr.html and Noms. or you can translate blocks with HTML inside: {_( ....some text.... )_} Assuming you have set up the word in Translation2 ok.. Have a look at HTML_Template_Flexy_Translator for a few ideas - the trick is that the compiler dumps a 'gettext.serial file.' - which can be used to find the words in the template. Regards Alan Tony Bibbs wrote: > I'm using Flexy in a project that has to support multiple language. > Right now we are leaning towards using PEAR::Translation2. I know > Flexy is smart enought to build templates per locale which is great > but how do I achieve that using Translation2? > > In a template for a login page I have this: > > > > > > > ... > > Where translate() is a method on the class that renders this view. > I'm guessing I don't want to do it this way because it appears this > would cause the translate() method to get called every single request > even if the template has been compiled. Am I right in that assumption? > > --Tony > > From tony at tonybibbs.com Sat Dec 18 02:14:44 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Sat, 18 Dec 2004 01:14:44 -0600 Subject: [geeklog-devel] Geeklog-2 CVS, To-do list Message-ID: <41C3D8E4.4010507@tonybibbs.com> Ok, views/BaseViewFlexy.php needs a good looking over. Also, I added Geeklog_LoginView.php and set it as the default view in mvcconfig.xml. Note that I am including the namespace Geeklog_ in the file name (and class name for that matter). I think we have to do that to avoid having the kernel conflicting with plugins (and plugins amoungst themselves) All this is going to be fluid for the foreseeable future but at least we are moving in the right direction. Finally, I have updated the database model and rebuilt the Propel domain objects and have those in CVS as well. Haven't used any of the classes yet. Vinny, I did blow away the old geeklog-2 directory in CVS but I did do a tarball backup of the old stuff if you needed something. Note on themes. /path/to/geeklog/themes is where all themefiles will go. These will no include plugin specific templates. Geeklog-2 will ship with a single theme 'default' which I have already stubbed out. Here's the to-do list, short term: 1) BaseViewFlexy needs the translation stuff ironed out 2) Data model needs Dwights attention regarding the count fields (i.e. gl2_user.num_views) so we can make a final decision and get those changes in the data model. 3) Geeklog_LoginCommand.php needs to be implemented. This should log a user in, get the user object from the database (including privileges) and serialize it to the session. 4) BaseViewFlexyUser.php needs to be updated to correctly deserialize the user object from the session. If the user object doesn't exist it should forward on to the Login page. Otherwise it should forward on to...well that's the million dollar question. Given we have the concept of plugins for everything, we probably need to allow the user to specify the default one to use for the homepage, no? 5) We need the filtering class defined. I know Blaine volunteered originally...can you still do it? 6) Plugin API needs to have dependency checking added to it 7) Event Manager needs to be implemented. Feel free to volunteer for any of these. Vinny, you and I can jointly work on #1. I can also tackle #3. Let me know if anybody objects with any of this. --Tony From dirk at haun-online.de Sat Dec 18 04:09:46 2004 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 18 Dec 2004 10:09:46 +0100 Subject: [geeklog-devel] PHP Vulns In-Reply-To: <41C35659.2060505@pigstye.net> References: <41C35659.2060505@pigstye.net> Message-ID: <20041218090946.29026@smtp.haun-online.de> >It looks like the code in Geeklog proper is OK but pear distributed with >Geekloog and magpierss (used in spamx) use some of the vulnerable functions. Thanks, Tom. >At least Geeklog was not listed as a vulnerable script like: Well, they surely can't test each and every open source project ... I came to the same conclusion (that Geeklog is not affected) when the vulnerabilities were announced on Thursday since I know that that core code isn't using any of those functions. But I didn't check the 3rd-party code. I doubt there's a way to exploit the vulnerabilities there, though. bye, Dirk -- http://www.haun-online.de/ http://geeklog.info/ From dirk at haun-online.de Sat Dec 18 08:30:53 2004 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 18 Dec 2004 14:30:53 +0100 Subject: [geeklog-devel] Bugtracker on sf.net closed Message-ID: <20041218133053.12077@smtp.haun-online.de> FYI: I've finally managed to clear out our old bugtracker at . Only 2 bugs had to be carried over, the rest was mostly outdated, plus a few that I moved to the feature requests. Anyone volunteering to transfer over the 46 remaining feature request? :P bye, Dirk -- http://www.haun-online.de/ http://www.macosx-faq.de/ From dirk at haun-online.de Sat Dec 18 17:29:08 2004 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 18 Dec 2004 23:29:08 +0100 Subject: [geeklog-devel] Negative side effect of comment spam filtering Message-ID: <20041218222908.3663@smtp.haun-online.de> Hmm, there's a story on Slashdot on how comment spam is causing increased server load on sites running Movable Type (the guys we're borrowing the blacklist for the SpamX plugin from). In this post: the blacklist maintainer writes: |In fact, we have found that there is a fairly major bug (in terms of |effect, but not code size) which causes page rebuilding even in the case |of a comment submission which would be moderated and hence should have no |effect on the live page. This means that even if you are using comment |moderation in Movable Type and even force moderation in MT-Blacklist, |your server load is impacted just as if a comment had been posted to the |live site. This bug has been fixed in development. Now, when filtering out a comment as spam, Geeklog throws the poster back to the site's front page. In other words, I guess this could happen to us, too, if the spammers would really start attacking a Geeklog site. Sounds like it would be better if Geeklog just died, only displaying the "spam detected" message (and maybe a link back to the index page, if we want to be really nice). Comments? bye, Dirk -- http://www.haun-online.de/ http://www.handful-of-sparks.de/ From vfuria at gmail.com Sun Dec 19 01:03:51 2004 From: vfuria at gmail.com (Vincent Furia) Date: Sun, 19 Dec 2004 01:03:51 -0500 Subject: [geeklog-devel] Negative side effect of comment spam filtering In-Reply-To: <20041218222908.3663@smtp.haun-online.de> References: <20041218222908.3663@smtp.haun-online.de> Message-ID: <8319e2d604121822037a3bdf9e@mail.gmail.com> If we're redirecting to the front page I don't think this will be a problem. It sounds like MT is re-building the site front page when a spam comment comes in (i.e. no redirect). This is a problem because the page gets build even if the spammer just through out a HTTP post request. If you just send a redirect in response, likely the spammer isn't going to have his software visit the front page (and slow the number of spams he can put out). Now, we may want to look at reducing overhead as much as possible (*cough* lib-common.php *cough*) to minimize the impact of a spam comment. All of this is just a guess of course. I've never seen any MT code and I've only taken to most cursory look at our spamx plugin... -Vinny On Sat, 18 Dec 2004 23:29:08 +0100, Dirk Haun wrote: > Hmm, > > there's a story on Slashdot on how comment spam is causing increased > server load on sites running Movable Type (the guys we're borrowing the > blacklist for the SpamX plugin from). > > In this post: > > the blacklist maintainer writes: > > |In fact, we have found that there is a fairly major bug (in terms of > |effect, but not code size) which causes page rebuilding even in the case > |of a comment submission which would be moderated and hence should have no > |effect on the live page. This means that even if you are using comment > |moderation in Movable Type and even force moderation in MT-Blacklist, > |your server load is impacted just as if a comment had been posted to the > |live site. This bug has been fixed in development. > > Now, when filtering out a comment as spam, Geeklog throws the poster back > to the site's front page. In other words, I guess this could happen to > us, too, if the spammers would really start attacking a Geeklog site. > > Sounds like it would be better if Geeklog just died, only displaying the > "spam detected" message (and maybe a link back to the index page, if we > want to be really nice). > > Comments? > > bye, Dirk > > -- > http://www.haun-online.de/ > http://www.handful-of-sparks.de/ > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From dirk at haun-online.de Sun Dec 19 04:07:28 2004 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 19 Dec 2004 10:07:28 +0100 Subject: [geeklog-devel] Negative side effect of comment spam filtering In-Reply-To: <8319e2d604121822037a3bdf9e@mail.gmail.com> References: <8319e2d604121822037a3bdf9e@mail.gmail.com> Message-ID: <20041219090728.30683@smtp.haun-online.de> Vinny, >If you just send a redirect in response, likely the spammer >isn't going to have his software visit the front page (and slow the >number of spams he can put out). Good point. This seems to confirm it (from an attempted spam post): 202.134.0.136 - - [18/Dec/2004:14:06:04 -0500] "GET /forum/ createtopic.php?method=postreply&forum=10&id=27114"eid=27805 HTTP/ 1.1" 200 32932 "http://www.philippestarckwatches.co.uk/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.1.4322)" 202.134.0.136 - - [18/Dec/2004:14:07:07 -0500] "GET /forum/viewtopic.php? mode=preview&showtopic=27114&onlytopic=Yes&lastpost=true HTTP/1.1" 200 59842 "http://www.geeklog.net/forum/createtopic.php? method=postreply&forum=10&id=27114"eid=27805" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.1.4322)" 202.134.0.136 - - [18/Dec/2004:14:10:08 -0500] "POST /forum/ createtopic.php HTTP/1.1" 200 13903 "http://www.geeklog.net/forum/ createtopic.php?method=postreply&forum=10&id=27114"eid=27805" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; .NET CLR 1.1.4322)" These 3 requests came out of nowhere and there are no further requests after the POST. Actually, there are a few more requests from that same IP (somewhere in Indonesia - probably a hijacked PC), but they have nothing to do with the above spam post. It seems our "friend" here is also attempting some referrer spam, but none of the domains used in the referrer (including the above) work for me. Plus they have all been registered recently (i.e. in December 2004). bye, Dirk -- http://www.haun-online.de/ http://www.haun.info/ From dirk at haun-online.de Sun Dec 19 05:30:27 2004 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 19 Dec 2004 11:30:27 +0100 Subject: [geeklog-devel] Revised plan of action: Geeklog 1.3.11 Message-ID: <20041219103027.11902@smtp.haun-online.de> The next Geeklog release will have to be called 1.3.11, since we have to make a change in the database[1] (and so that we can keep our "same (base) version number = same database structure" rule of thumb). 1.3.11 is intended to replace 1.3.10 and I'd like to make this upgrade as painless as possible. Therefore, no changes in template files, config.php, or language files from now on, please. In fact, the only to-do item left on my agenda is the fix for posts to be archived using the archive template files too early (bug #345). Blaine? My plan is to have a Release Candidate out by Wednesday (22nd) and the final release before the end of the year. If anyone has a chance to test out the current version from CVS, please do so. I'm especially interested in any problems (or absence of problems) with submit.php and the calendar. bye, Dirk [1] http://www.geeklog.net/forum/viewtopic.php?showtopic=44219 -- http://www.haun-online.de/ http://www.haun.info/ From geeklog at langfamily.ca Sun Dec 19 10:05:26 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Sun, 19 Dec 2004 10:05:26 -0500 Subject: [geeklog-devel] Revised plan of action: Geeklog 1.3.11 References: <20041219103027.11902@smtp.haun-online.de> Message-ID: <001801c4e5dc$2ce7efa0$650a10ac@XPBL2> Dirk wrote: > The next Geeklog release will have to be called 1.3.11, since we have to make a change in the database[1] ( I must have missed that - what was the change Dirk. > In fact, the only to-do item left on my agenda is the fix for posts to be archived using the archive template files too early (bug #345). Blaine? Got it - will do. ----- Original Message ----- From: "Dirk Haun" To: Sent: Sunday, December 19, 2004 5:30 AM Subject: [geeklog-devel] Revised plan of action: Geeklog 1.3.11 The next Geeklog release will have to be called 1.3.11, since we have to make a change in the database[1] (and so that we can keep our "same (base) version number = same database structure" rule of thumb). 1.3.11 is intended to replace 1.3.10 and I'd like to make this upgrade as painless as possible. Therefore, no changes in template files, config.php, or language files from now on, please. In fact, the only to-do item left on my agenda is the fix for posts to be archived using the archive template files too early (bug #345). Blaine? My plan is to have a Release Candidate out by Wednesday (22nd) and the final release before the end of the year. If anyone has a chance to test out the current version from CVS, please do so. I'm especially interested in any problems (or absence of problems) with submit.php and the calendar. bye, Dirk [1] http://www.geeklog.net/forum/viewtopic.php?showtopic=44219 -- http://www.haun-online.de/ http://www.haun.info/ _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From dirk at haun-online.de Sun Dec 19 12:11:20 2004 From: dirk at haun-online.de (Dirk Haun) Date: Sun, 19 Dec 2004 18:11:20 +0100 Subject: [geeklog-devel] Revised plan of action: Geeklog 1.3.11 In-Reply-To: <001801c4e5dc$2ce7efa0$650a10ac@XPBL2> References: <001801c4e5dc$2ce7efa0$650a10ac@XPBL2> Message-ID: <20041219171120.22394@smtp.haun-online.de> Blaine, >I must have missed that - what was the change Dirk. That was what the footnote was all about: In the comments table, the 'sid' field can only hold 20 characters. But a story's sid can have up to 40 characters in 1.3.10. Comments posted on such a story will not show up. bye, Dirk -- http://www.haun-online.de/ http://mypod.de/ From tony at tonybibbs.com Sun Dec 19 20:39:21 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Sun, 19 Dec 2004 19:39:21 -0600 Subject: [geeklog-devel] GL2, Default Plugin Message-ID: <41C62D49.40704@tonybibbs.com> Ok, given that all real work in GL2 will be done by plugins, after a user logs in where do we send them? Do we simply send them to a plugin homepage marked as the default? --Tony From vfuria at gmail.com Sun Dec 19 21:37:56 2004 From: vfuria at gmail.com (Vincent Furia) Date: Sun, 19 Dec 2004 21:37:56 -0500 Subject: [geeklog-devel] GL2, Default Plugin In-Reply-To: <41C62D49.40704@tonybibbs.com> References: <41C62D49.40704@tonybibbs.com> Message-ID: <8319e2d604121918377e6c37d6@mail.gmail.com> I think clearly we're going to need a "frontpage" plugin. However I don't see any harm in allowing the user (admin) to select what the default plugin is (presumably on most pages this will be the "frontpage" plugin). -Vinny On Sun, 19 Dec 2004 19:39:21 -0600, Tony Bibbs wrote: > Ok, given that all real work in GL2 will be done by plugins, after a > user logs in where do we send them? Do we simply send them to a plugin > homepage marked as the default? > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Sun Dec 19 23:33:59 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Sun, 19 Dec 2004 22:33:59 -0600 Subject: [geeklog-devel] GL2, Default Plugin In-Reply-To: <8319e2d604121918377e6c37d6@mail.gmail.com> References: <41C62D49.40704@tonybibbs.com> <8319e2d604121918377e6c37d6@mail.gmail.com> Message-ID: <41C65637.4030503@tonybibbs.com> Well, for testing purposes, we should have a kernel default homepage. It will allow for a no-plugin installation...which is clearly useless but may serve some useful testing or diagnostic services (ala phpinfo()). Obviously we'll ship GL2 with the necessary plugins to make it feature complete when compared to a stock 1.3.x but, I hope, nothing more. --Tony Vincent Furia wrote: >I think clearly we're going to need a "frontpage" plugin. However I >don't see any harm in allowing the user (admin) to select what the >default plugin is (presumably on most pages this will be the >"frontpage" plugin). > >-Vinny > > >On Sun, 19 Dec 2004 19:39:21 -0600, Tony Bibbs wrote: > > >>Ok, given that all real work in GL2 will be done by plugins, after a >>user logs in where do we send them? Do we simply send them to a plugin >>homepage marked as the default? >> >>--Tony >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From tony at tonybibbs.com Mon Dec 20 16:40:41 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 20 Dec 2004 15:40:41 -0600 Subject: [geeklog-devel] Welcome Kevin Vidomski Message-ID: <41C746D9.1040003@tonybibbs.com> Kevin Vidomski has been recruited to help with Geeklog 2 development. I don't know much about Kevin so I'm hoping his first post can formally introduce himself to the rest of the group. Kevin, welcome to the team! --Tony From tony at tonybibbs.com Mon Dec 20 16:51:21 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 20 Dec 2004 15:51:21 -0600 Subject: [geeklog-devel] GL2 Login works Message-ID: <41C74959.8020104@tonybibbs.com> Pretty soon here I will be checking in a version of Geeklog 2 which successfully authenticates a user. I have taken care to factor the code in such a way that the means by which one manages a user account can be changed by simply implementing one class and changing a setting in the config file. Being that noone has looked into the code yet (hint, hint) I'll take this time to discuss the basic design: The most basic part of the account management equation is the Geeklog_AccountManager (in AccountManager.php). It's job is to read the Account Manager it needs to create from a value in the configuration file ($glConf['account_manager']), and generate an instance of that class which is responsible for doing the work. All account managers must implement the Geeklog_AccountManagerInterface (AccountManagerInterface.php) which provides methods for creating accounts, deleting accounts, authenticating users and changing passwords. Other method will probably be added to this interface (i.e. update account, etc) but I won't bother with them until we establish the need. As such, I have created default AccountManager...named Geeklog_DefaultAccountManager in DefaultAccountManager.php (see the pattern?). All this said, one could, for example, create a LDAPAccountManager, IMAPAccountManager, etc to have GL2 authenticate to any datastore. I'd like to see LDAP and IMAP bundled in with GL2 (any takers?). So, have a look in CVS and let me know what you do/don't like about what I have so far. --Tony From justin.carlson at gmail.com Mon Dec 20 16:58:17 2004 From: justin.carlson at gmail.com (Justin Carlson) Date: Mon, 20 Dec 2004 15:58:17 -0600 Subject: [geeklog-devel] Article throttle. In-Reply-To: <20041217221756.15135@smtp.haun-online.de> References: <3d1a3f4e041216144179604a10@mail.gmail.com> <20041217221756.15135@smtp.haun-online.de> Message-ID: <3d1a3f4e0412201358588bc850@mail.gmail.com> I agree, sometimes they get a little link-happy and link it several times ( including the index. ) It also falls apart when users go back to the index from a linked article. However, even if it only catches 50% of the users, that's a large savings on bandwidth and the cpu(s) for that rush. A more complex solution for watching the entire site can/has been done, this one was just very simple. In fact, a site-wide cache system could be written, ( think about this for GL2 ) that creates static pages and updates whenever content changes. This would of course bloat the site, and should only be used by heavy traffic GL users. Just have to decide when/where to update the cached pages. Thoughts? Overkill? On Fri, 17 Dec 2004 23:17:56 +0100, Dirk Haun wrote: > Justin, > > >What this does is extremely simple. The owner of the website sets a > >throttle, which is a number of guest users. Once this number is > >reached, any article accessed from an external link or directly > >accessed will display in print mode. This should greatly reduce the > >number of database queries > > Sounds interesting. > > My suspicion, though, is that in most cases, it's the index page that is > hit by most of the traffic. Especially Slashdot readers are known not to > RTFA :P > > Are our friends from Groklaw still around? Niels, Peter? > > bye, Dirk > > -- > http://www.haun-online.de/ > http://www.tinyweb.de/ > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Mon Dec 20 17:17:26 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 20 Dec 2004 16:17:26 -0600 Subject: [geeklog-devel] Filtering in GL2 In-Reply-To: <02c401c4e186$d0e0fed0$650a10ac@XPBL2> References: <41BE16BC.2080407@tonybibbs.com> <028701c4e167$d574cfe0$650a10ac@XPBL2> <41BE33F6.3000304@tonybibbs.com> <02c401c4e186$d0e0fed0$650a10ac@XPBL2> Message-ID: <41C74F76.3050309@tonybibbs.com> Blaine, Any ETA on when you might get a draft of the class put together? If it will be a while, let me know and I can take a stab at it. --Tony Blaine Lang wrote: > >In addition, there is much more code inside the app that is adding or >stripping. >These have been added over time to address common needs but a major task to >replace and consolidate the core GL 1.3 codebase. > >Still, it would be good to create a new OO based class and start to use it >and slowing migrate scripts. >The 1.3.x platform and plugins could be used to test such a new common >class. > >I'd like to get more input but would be willing to take the lead on >developing this. > > > From tony at tonybibbs.com Mon Dec 20 17:41:28 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 20 Dec 2004 16:41:28 -0600 Subject: [geeklog-devel] Simon or a replace of? Message-ID: <41C75518.8060501@tonybibbs.com> With GL2 getting off the ground, it would sure be nice if we had a look-and-feel sort of person on the team. I'm guessing Simon's days of filling this slot are over given his inactivity on this list. Is there someone that could fill this slot? Basically we need someone who knows CSS/XHTML inside and out, some decent graphics skills. What I'd be happy to start with is just a CSS that can be used. Should I just use the current GL 1.3.x as the default? I should probably post this opening on gl.net, huh? Regardless, I promise you won't want me doing any mock-ups...I know my limitations...pretty UI's is one of them. --Tony From vidomski at lightbender.ca Mon Dec 20 17:46:40 2004 From: vidomski at lightbender.ca (Kevin Vidomski) Date: Mon, 20 Dec 2004 16:46:40 -0600 Subject: [geeklog-devel] Look and Feel Message-ID: <200412201646.40254.vidomski@lightbender.ca> Hey all, I have a bit of talent in the graphics area if need be. I use GIMP and Blender mostly. Kevin Vidomski From tony at tonybibbs.com Mon Dec 20 17:51:23 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 20 Dec 2004 16:51:23 -0600 Subject: [geeklog-devel] Geeklog-2 CVS, To-do list In-Reply-To: <41C3D8E4.4010507@tonybibbs.com> References: <41C3D8E4.4010507@tonybibbs.com> Message-ID: <41C7576B.5080600@tonybibbs.com> Here's an update on this list: Tony Bibbs wrote: > Here's the to-do list, short term: > > 1) BaseViewFlexy needs the translation stuff ironed out Sorta done. Needs to be thought through completely as I'm sure I haven't covered all our cases (not to mention I'm still fuzzy on how Translation2 works). Also need to consider the possiblity of using the xml translation2 support given all the dependencies for the gettext implementation. > 2) Data model needs Dwights attention regarding the count fields (i.e. > gl2_user.num_views) so we can make a final decision and get those > changes in the data model. Dwight? > 3) Geeklog_LoginCommand.php needs to be implemented. This should log > a user in, get the user object from the database (including > privileges) and serialize it to the session. Rought draft is done. > 4) BaseViewFlexyUser.php needs to be updated to correctly deserialize > the user object from the session. If the user object doesn't exist it > should forward on to the Login page. Otherwise it should forward on > to...well that's the million dollar question. Given we have the > concept of plugins for everything, we probably need to allow the user > to specify the default one to use for the homepage, no? Rough draft done. I'll build a kernel home page that will be the default in the case that no plugins are installed. > 5) We need the filtering class defined. I know Blaine volunteered > originally...can you still do it? Blaine was going to look into this since this would also benefit 1.3.x > 6) Plugin API needs to have dependency checking added to it Done > 7) Event Manager needs to be implemented. This will be my next project, I guess. --Tony From tony at tonybibbs.com Mon Dec 20 18:02:04 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 20 Dec 2004 17:02:04 -0600 Subject: [geeklog-devel] PluginInterface Message-ID: <41C759EC.9050209@tonybibbs.com> Any reason that all of the methods on the Geeklog_PluginInterface (PluginInterface.php) shouldn't all be static? As a refresher, the methods are: public function install(); public function uninstall(); public function upgrade(); public function getVersion(); public function handleEvent($event, $var = ''); public function getPage($request); public function getDependencies(); None of them seem to really need an instantiated object. This all came up as I thought about how we would call the handleEvent() method. Seems more logical to say: $pluginClassName::handleEvent(); Instead of $somePlugin = pluginFactory::singleton(); $somePlugin->handleEvent(); Sorry I'm posting all these questions to the list but until I get some more eyes on the actual code, I need a sanity check here and there. --Tony From geeklog at langfamily.ca Mon Dec 20 20:05:05 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Mon, 20 Dec 2004 20:05:05 -0500 Subject: [geeklog-devel] Filtering in GL2 References: <41BE16BC.2080407@tonybibbs.com> <028701c4e167$d574cfe0$650a10ac@XPBL2> <41BE33F6.3000304@tonybibbs.com> <02c401c4e186$d0e0fed0$650a10ac@XPBL2> <41C74F76.3050309@tonybibbs.com> Message-ID: <002001c4e6f9$1bb13520$650a10ac@XPBL2> Hi Tony, Entering into a busy two week period with family but I will see what I can do. Regards, Blaine ----- Original Message ----- From: "Tony Bibbs" To: Sent: Monday, December 20, 2004 5:17 PM Subject: Re: [geeklog-devel] Filtering in GL2 Blaine, Any ETA on when you might get a draft of the class put together? If it will be a while, let me know and I can take a stab at it. --Tony Blaine Lang wrote: > >In addition, there is much more code inside the app that is adding or >stripping. >These have been added over time to address common needs but a major task to >replace and consolidate the core GL 1.3 codebase. > >Still, it would be good to create a new OO based class and start to use it >and slowing migrate scripts. >The 1.3.x platform and plugins could be used to test such a new common >class. > >I'd like to get more input but would be willing to take the lead on >developing this. > > > _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From slord at marelina.com Mon Dec 20 22:16:12 2004 From: slord at marelina.com (Simon Lord) Date: Mon, 20 Dec 2004 22:16:12 -0500 Subject: [geeklog-devel] Simon or a replace of? In-Reply-To: <41C75518.8060501@tonybibbs.com> References: <41C75518.8060501@tonybibbs.com> Message-ID: I'm here tony, not going anywhere. Just a little busy (busy finding work mostly). If you need something let me know, I'll squeeze you in. On Dec 20, 2004, at 5:41 PM, Tony Bibbs wrote: > With GL2 getting off the ground, it would sure be nice if we had a > look-and-feel sort of person on the team. I'm guessing Simon's days > of filling this slot are over given his inactivity on this list. Is > there someone that could fill this slot? Basically we need someone > who knows CSS/XHTML inside and out, some decent graphics skills. What > I'd be happy to start with is just a CSS that can be used. Should I > just use the current GL 1.3.x as the default? > > I should probably post this opening on gl.net, huh? Regardless, I > promise you won't want me doing any mock-ups...I know my > limitations...pretty UI's is one of them. > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > > Sincerely, Simon From tony at tonybibbs.com Mon Dec 20 22:20:27 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 20 Dec 2004 21:20:27 -0600 Subject: [geeklog-devel] Simon or a replace of? In-Reply-To: References: <41C75518.8060501@tonybibbs.com> Message-ID: <41C7967B.6030008@tonybibbs.com> Sweet. Well, basically I know you had some input about how plugins and css, etc should work in GL2 to get around 1.3.x limitations. Could you list those out formally so I don't forget about them? When we get to a point where we need the look-and-feel stuff I'll definitley give you a buzz. My hopes is we'll start writing the article plugin soon which should produce plenty of UI stuff. --Tony Simon Lord wrote: > I'm here tony, not going anywhere. Just a little busy (busy finding > work mostly). If you need something let me know, I'll squeeze you in. > > > > On Dec 20, 2004, at 5:41 PM, Tony Bibbs wrote: > >> With GL2 getting off the ground, it would sure be nice if we had a >> look-and-feel sort of person on the team. I'm guessing Simon's days >> of filling this slot are over given his inactivity on this list. Is >> there someone that could fill this slot? Basically we need someone >> who knows CSS/XHTML inside and out, some decent graphics skills. >> What I'd be happy to start with is just a CSS that can be used. >> Should I just use the current GL 1.3.x as the default? >> >> I should probably post this opening on gl.net, huh? Regardless, I >> promise you won't want me doing any mock-ups...I know my >> limitations...pretty UI's is one of them. >> >> --Tony >> _______________________________________________ >> geeklog-devel mailing list >> geeklog-devel at lists.geeklog.net >> http://lists.geeklog.net/listinfo/geeklog-devel >> >> > Sincerely, > Simon > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Mon Dec 20 22:58:37 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 20 Dec 2004 21:58:37 -0600 Subject: [geeklog-devel] Wiki borked? Message-ID: <41C79F6D.2020908@tonybibbs.com> http://wiki.geeklog.net/wiki/index.php/Main_Page Using latest stable Firefox. Is it fubar'd for anybody else? --Tony From slord at marelina.com Mon Dec 20 23:02:04 2004 From: slord at marelina.com (Simon Lord) Date: Mon, 20 Dec 2004 23:02:04 -0500 Subject: [geeklog-devel] Simon or a replace of? In-Reply-To: <41C7967B.6030008@tonybibbs.com> References: <41C75518.8060501@tonybibbs.com> <41C7967B.6030008@tonybibbs.com> Message-ID: <12FC7EC3-5305-11D9-A313-003065C030F2@marelina.com> No problem. Technically Blaine and I have done this already, what's missing is pretty much what you're looking for and that's a rough draft for the design document. Basically we need to define a suite of classes which will be attached to specific things such as story title, story text, title background etc. After that we just need to figure out how much of the site we want done using div's as opposed to tables... On Dec 20, 2004, at 10:20 PM, Tony Bibbs wrote: > Sweet. Well, basically I know you had some input about how plugins > and css, etc should work in GL2 to get around 1.3.x limitations. > Could you list those out formally so I don't forget about them? When > we get to a point where we need the look-and-feel stuff I'll > definitley give you a buzz. My hopes is we'll start writing the > article plugin soon which should produce plenty of UI stuff. > > --Tony > > Simon Lord wrote: > >> I'm here tony, not going anywhere. Just a little busy (busy finding >> work mostly). If you need something let me know, I'll squeeze you >> in. >> >> >> >> On Dec 20, 2004, at 5:41 PM, Tony Bibbs wrote: >> >>> With GL2 getting off the ground, it would sure be nice if we had a >>> look-and-feel sort of person on the team. I'm guessing Simon's days >>> of filling this slot are over given his inactivity on this list. Is >>> there someone that could fill this slot? Basically we need someone >>> who knows CSS/XHTML inside and out, some decent graphics skills. >>> What I'd be happy to start with is just a CSS that can be used. >>> Should I just use the current GL 1.3.x as the default? >>> >>> I should probably post this opening on gl.net, huh? Regardless, I >>> promise you won't want me doing any mock-ups...I know my >>> limitations...pretty UI's is one of them. >>> >>> --Tony >>> _______________________________________________ >>> geeklog-devel mailing list >>> geeklog-devel at lists.geeklog.net >>> http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >> Sincerely, >> Simon >> >> _______________________________________________ >> geeklog-devel mailing list >> geeklog-devel at lists.geeklog.net >> http://lists.geeklog.net/listinfo/geeklog-devel > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > > !DSPAM:41c796e4292386171321209! > > Sincerely, Simon From geeklog at langfamily.ca Mon Dec 20 23:06:17 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Mon, 20 Dec 2004 23:06:17 -0500 Subject: [geeklog-devel] Wiki borked? References: <41C79F6D.2020908@tonybibbs.com> Message-ID: <000f01c4e712$6bbde090$650a10ac@XPBL2> It appears to work ok. Checked a few pages and it was fine. Blaine ----- Original Message ----- From: "Tony Bibbs" To: Sent: Monday, December 20, 2004 10:58 PM Subject: [geeklog-devel] Wiki borked? http://wiki.geeklog.net/wiki/index.php/Main_Page Using latest stable Firefox. Is it fubar'd for anybody else? --Tony _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From vfuria at gmail.com Mon Dec 20 23:44:37 2004 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 20 Dec 2004 23:44:37 -0500 Subject: [geeklog-devel] PluginInterface In-Reply-To: <41C759EC.9050209@tonybibbs.com> References: <41C759EC.9050209@tonybibbs.com> Message-ID: <8319e2d604122020444ac3261c@mail.gmail.com> Tony , Sorry I didn't talk to you about this a bit more. I built the plugin interface so that it could be called statically. As far as I could determine all the methods in the interface should be able to be called without instantiating an object. So I definitely think you're on the right track with this. -Vinny On Mon, 20 Dec 2004 17:02:04 -0600, Tony Bibbs wrote: > Any reason that all of the methods on the Geeklog_PluginInterface > (PluginInterface.php) shouldn't all be static? As a refresher, the > methods are: > > public function install(); > public function uninstall(); > public function upgrade(); > public function getVersion(); > public function handleEvent($event, $var = ''); > public function getPage($request); > public function getDependencies(); > > None of them seem to really need an instantiated object. This all came > up as I thought about how we would call the handleEvent() method. Seems > more logical to say: > > $pluginClassName::handleEvent(); > > Instead of > > $somePlugin = pluginFactory::singleton(); > $somePlugin->handleEvent(); > > Sorry I'm posting all these questions to the list but until I get some > more eyes on the actual code, I need a sanity check here and there. > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From vfuria at gmail.com Mon Dec 20 23:48:51 2004 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 20 Dec 2004 23:48:51 -0500 Subject: [geeklog-devel] Wiki borked? In-Reply-To: <000f01c4e712$6bbde090$650a10ac@XPBL2> References: <41C79F6D.2020908@tonybibbs.com> <000f01c4e712$6bbde090$650a10ac@XPBL2> Message-ID: <8319e2d6041220204822396ccb@mail.gmail.com> Works for me too. A little slow on first load, but after that it seems relatively snappy. -Vinny On Mon, 20 Dec 2004 23:06:17 -0500, Blaine Lang wrote: > It appears to work ok. Checked a few pages and it was fine. > > Blaine > ----- Original Message ----- > From: "Tony Bibbs" > To: > Sent: Monday, December 20, 2004 10:58 PM > Subject: [geeklog-devel] Wiki borked? > > http://wiki.geeklog.net/wiki/index.php/Main_Page > > Using latest stable Firefox. Is it fubar'd for anybody else? > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Tue Dec 21 09:37:49 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 21 Dec 2004 08:37:49 -0600 Subject: [geeklog-devel] Simon or a replace of? In-Reply-To: <12FC7EC3-5305-11D9-A313-003065C030F2@marelina.com> References: <41C75518.8060501@tonybibbs.com> <41C7967B.6030008@tonybibbs.com> <12FC7EC3-5305-11D9-A313-003065C030F2@marelina.com> Message-ID: <41C8353D.5000200@tonybibbs.com> Simon Lord wrote: > No problem. Technically Blaine and I have done this already, what's > missing is pretty much what you're looking for and that's a rough > draft for the design document. Basically we need to define a suite of > classes which will be attached to specific things such as story title, > story text, title background etc. If you could send those past notes and/or supporting code that would be great. One noteworthy design decision is that MVCnPHP-based plugins will allow plugins to keep their templates within their own directory structure. Use of MVCnPHP is optional, but strongly encouraged. We'll still need to figure out how to get around non-MVC/procedural plugins. > > After that we just need to figure out how much of the site we want > done using div's as opposed to tables... Hopefully as much as possible. --Tony From tony at tonybibbs.com Tue Dec 21 09:38:39 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 21 Dec 2004 08:38:39 -0600 Subject: [geeklog-devel] PluginInterface In-Reply-To: <8319e2d604122020444ac3261c@mail.gmail.com> References: <41C759EC.9050209@tonybibbs.com> <8319e2d604122020444ac3261c@mail.gmail.com> Message-ID: <41C8356F.6070208@tonybibbs.com> Excellent. Thanks for the follow-up. --Tony Vincent Furia wrote: >Tony , > >Sorry I didn't talk to you about this a bit more. I built the plugin >interface so that it could be called statically. As far as I could >determine all the methods in the interface should be able to be called >without instantiating an object. > >So I definitely think you're on the right track with this. > >-Vinny > > From tony at tonybibbs.com Tue Dec 21 14:33:16 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 21 Dec 2004 13:33:16 -0600 Subject: [geeklog-devel] Controls in GL2 Message-ID: <41C87A7C.7080308@tonybibbs.com> As you are all aware, there are a number of controls that could be used for various things. For example, for a date form field you could have a simple text field, or a series of drop downs (one for month, day and year) or something more complicated like a dropdown calendar. There are probably a number of different various of types of controls that could be used for all the different types of data that Geeklog plugins will use. We should allow for those to be customized with little to no hassle, no? Only reason I am asking is I think we may want to consider having a control factory that does this work for us. It would, upon request, take requests for a specific control, create it, set the default data and return the corresponding HTML and/or Javascript (/me cringes). The idea is we'd simply have a folder where GL2 admins could drop new or custom controls, change a template or two and have it working. ...or am I over complicated things. --Tony From geeklog at langfamily.ca Tue Dec 21 15:00:29 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Tue, 21 Dec 2004 15:00:29 -0500 Subject: [geeklog-devel] Simon or a replace of? References: <41C75518.8060501@tonybibbs.com> <41C7967B.6030008@tonybibbs.com> <12FC7EC3-5305-11D9-A313-003065C030F2@marelina.com> <41C8353D.5000200@tonybibbs.com> Message-ID: <008b01c4e797$b854f530$650a10ac@XPBL2> Tony, I've been using some of the CSS standards that Simon and I came up with and have been refining them as part of my plugin development over the past year. More specifically, I have published the recommendations to the geeklog-modules list a few weeks back. My present work on a new Forum Plugin version will in fact be able to use one set of templates and just use the CSS for themeing. This will work unless someone needs to modify a template file for one theme only. But most sites actually only use one theme. Simon has a much larger list of CSS declaration standards that were being developed as part of a new GL Theme project we were working on. This can be the base of the discussions and planning for GL2. Simon wanted to out toghether a design guide I believe. Blaine ----- Original Message ----- From: "Tony Bibbs" To: Sent: Tuesday, December 21, 2004 9:37 AM Subject: Re: [geeklog-devel] Simon or a replace of? Simon Lord wrote: > No problem. Technically Blaine and I have done this already, what's > missing is pretty much what you're looking for and that's a rough > draft for the design document. Basically we need to define a suite of > classes which will be attached to specific things such as story title, > story text, title background etc. If you could send those past notes and/or supporting code that would be great. One noteworthy design decision is that MVCnPHP-based plugins will allow plugins to keep their templates within their own directory structure. Use of MVCnPHP is optional, but strongly encouraged. We'll still need to figure out how to get around non-MVC/procedural plugins. > > After that we just need to figure out how much of the site we want > done using div's as opposed to tables... Hopefully as much as possible. --Tony _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From geeklog at langfamily.ca Tue Dec 21 15:10:30 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Tue, 21 Dec 2004 15:10:30 -0500 Subject: [geeklog-devel] Controls in GL2 References: <41C87A7C.7080308@tonybibbs.com> Message-ID: <00aa01c4e799$1f246d30$650a10ac@XPBL2> Tony, I personally am using more JS all the time for form validation and if GL2 is going to be positioned for corporate use as well then JS support is more then likely well supported in their browsers. We can also look to consider looking at IE7 https://sourceforge.net/projects/ie7/ I like the idea of having re-usable functions for generating listboxes for example. There is always a lot of common code to generate the HTML for the list. Date fields as well with a drop down calendar are nice - I use that often now. The other idea is to implement PEAR::HTML_QuickForm. We would just need to allow developers to fully extend the elements easily. Blaine ----- Original Message ----- From: "Tony Bibbs" To: Sent: Tuesday, December 21, 2004 2:33 PM Subject: [geeklog-devel] Controls in GL2 As you are all aware, there are a number of controls that could be used for various things. For example, for a date form field you could have a simple text field, or a series of drop downs (one for month, day and year) or something more complicated like a dropdown calendar. There are probably a number of different various of types of controls that could be used for all the different types of data that Geeklog plugins will use. We should allow for those to be customized with little to no hassle, no? Only reason I am asking is I think we may want to consider having a control factory that does this work for us. It would, upon request, take requests for a specific control, create it, set the default data and return the corresponding HTML and/or Javascript (/me cringes). The idea is we'd simply have a folder where GL2 admins could drop new or custom controls, change a template or two and have it working. ...or am I over complicated things. --Tony _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Tue Dec 21 15:22:42 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 21 Dec 2004 14:22:42 -0600 Subject: [geeklog-devel] Controls in GL2 In-Reply-To: <00aa01c4e799$1f246d30$650a10ac@XPBL2> References: <41C87A7C.7080308@tonybibbs.com> <00aa01c4e799$1f246d30$650a10ac@XPBL2> Message-ID: <41C88612.5050909@tonybibbs.com> Blaine Lang wrote: >Tony, > >I personally am using more JS all the time for form validation and if GL2 is >going to be positioned for corporate use as well then JS support is more >then likely well supported in their browsers. We can also look to consider >looking at IE7 https://sourceforge.net/projects/ie7/ > > Inserting client-side JS for validation shouldn't be a problem. I was more concerned with JS in controls (i.e. drop down calendar) >I like the idea of having re-usable functions for generating listboxes for >example. There is always a lot of common code to generate the HTML for the >list. > > Flexy includes most if not all the functions for generating standard HTML controls. I'm more after customized versions of controls (date control, time control, editor controls, etc) >Date fields as well with a drop down calendar are nice - I use that often >now. > > Yeah, I agree, this is more the type of scenario I was getting at. >The other idea is to implement PEAR::HTML_QuickForm. > >We would just need to allow developers to fully extend the elements easily > Actually Flexy used QuickForm for a while and then got rid of it. Quick form was more for implementing entire forms via PHP code and wasn't really intended or use in template engines. Flexy allows you to stub out, for example, your list box in the template and the code that generates it is in the view. I have an example of this one or more of the views in the sample code that you and Dirk are yet to get working (sorry, shameless dig). --Tony From geeklog at langfamily.ca Tue Dec 21 15:38:30 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Tue, 21 Dec 2004 15:38:30 -0500 Subject: [geeklog-devel] Controls in GL2 References: <41C87A7C.7080308@tonybibbs.com> <00aa01c4e799$1f246d30$650a10ac@XPBL2> <41C88612.5050909@tonybibbs.com> Message-ID: <00e901c4e79d$0852eab0$650a10ac@XPBL2> Tony wrote: > I have an example of this one or more of the views in the sample code that > you and Dirk are yet to get working (sorry, shameless dig). Are you referring to the Hunting Log? Both Dirk and I got that running after you released the version that had better control over the Paths. We both replied to the list on this - I still had the Windows issue with a ; instead of a : in the include_path. Those forms were pretty basic (by design I know). Blaine ----- Original Message ----- From: "Tony Bibbs" To: Sent: Tuesday, December 21, 2004 3:22 PM Subject: Re: [geeklog-devel] Controls in GL2 Blaine Lang wrote: >Tony, > >I personally am using more JS all the time for form validation and if GL2 >is >going to be positioned for corporate use as well then JS support is more >then likely well supported in their browsers. We can also look to consider >looking at IE7 https://sourceforge.net/projects/ie7/ > > Inserting client-side JS for validation shouldn't be a problem. I was more concerned with JS in controls (i.e. drop down calendar) >I like the idea of having re-usable functions for generating listboxes for >example. There is always a lot of common code to generate the HTML for the >list. > > Flexy includes most if not all the functions for generating standard HTML controls. I'm more after customized versions of controls (date control, time control, editor controls, etc) >Date fields as well with a drop down calendar are nice - I use that often >now. > > Yeah, I agree, this is more the type of scenario I was getting at. >The other idea is to implement PEAR::HTML_QuickForm. > >We would just need to allow developers to fully extend the elements easily > Actually Flexy used QuickForm for a while and then got rid of it. Quick form was more for implementing entire forms via PHP code and wasn't really intended or use in template engines. Flexy allows you to stub out, for example, your list box in the template and the code that generates it is in the view. I have an example of this one or more of the views in the sample code that you and Dirk are yet to get working (sorry, shameless dig). --Tony _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Tue Dec 21 16:14:02 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 21 Dec 2004 15:14:02 -0600 Subject: [geeklog-devel] Controls in GL2 In-Reply-To: <00e901c4e79d$0852eab0$650a10ac@XPBL2> References: <41C87A7C.7080308@tonybibbs.com> <00aa01c4e799$1f246d30$650a10ac@XPBL2> <41C88612.5050909@tonybibbs.com> <00e901c4e79d$0852eab0$650a10ac@XPBL2> Message-ID: <41C8921A.6080602@tonybibbs.com> Oh yeah (short memory). Anyway, here's the flexy snippet to populate a drop down: $this->getDropDown('getAllCloudCover', 'HlHunt->cloudCoverId', '' , $this->hunt->getCloudCoverId(),'lovId', 'shortName'); That's a function on one of the base views I wrote which gets translated to this: protected function getDropDown($dropDownName, $htmlFieldName, $queryArgs = '' , $setValue = '' , $idAttribute = '', $displayAttribute = '') { $resultArray = array(); $dao = DAOFactory::getDAO(); if (is_array($queryArgs) AND (count($queryArgs) > 0)) { $objArray = $dao->find($dropDownName, $queryArgs); } else { $objArray = $dao->find($dropDownName); } $idGetMethod = 'get' . ucwords($idAttribute); $displayGetMethod = 'get' . ucwords($displayAttribute); foreach ($objArray as $curObj) { $resultArray[$curObj->$idGetMethod()] = $curObj->$displayGetMethod(); } $this->flexyElements[$htmlFieldName] = new HTML_Template_Flexy_Element; $this->flexyElements[$htmlFieldName]->setOptions($resultArray); if (!empty($setValue)) { $this->flexyElements[$htmlFieldName]->setValue($setValue); } } Here's the actual field in the flexy template: Seems like a lot of code but since it all gets compiled by flexy, its quite fast. --Tony Blaine Lang wrote: >Tony wrote: > > >>I have an example of this one or more of the views in the sample code that >>you and Dirk are yet to get working >> >> >(sorry, shameless dig). > >Are you referring to the Hunting Log? >Both Dirk and I got that running after you released the version that had >better control over the Paths. >We both replied to the list on this - I still had the Windows issue with a ; >instead of a : in the include_path. > >Those forms were pretty basic (by design I know). > >Blaine >----- Original Message ----- >From: "Tony Bibbs" >To: >Sent: Tuesday, December 21, 2004 3:22 PM >Subject: Re: [geeklog-devel] Controls in GL2 > > >Blaine Lang wrote: > > > >>Tony, >> >>I personally am using more JS all the time for form validation and if GL2 >>is >>going to be positioned for corporate use as well then JS support is more >>then likely well supported in their browsers. We can also look to consider >>looking at IE7 https://sourceforge.net/projects/ie7/ >> >> >> >> >Inserting client-side JS for validation shouldn't be a problem. I was >more concerned with JS in controls (i.e. drop down calendar) > > > >>I like the idea of having re-usable functions for generating listboxes for >>example. There is always a lot of common code to generate the HTML for the >>list. >> >> >> >> >Flexy includes most if not all the functions for generating standard >HTML controls. I'm more after customized versions of controls (date >control, time control, editor controls, etc) > > > >>Date fields as well with a drop down calendar are nice - I use that often >>now. >> >> >> >> >Yeah, I agree, this is more the type of scenario I was getting at. > > > >>The other idea is to implement PEAR::HTML_QuickForm. >> >>We would just need to allow developers to fully extend the elements easily >> >> >> >Actually Flexy used QuickForm for a while and then got rid of it. Quick >form was more for implementing entire forms via PHP code and wasn't >really intended or use in template engines. Flexy allows you to stub >out, for example, your list box in the template and the code that >generates it is in the view. I have an example of this one or more of >the views in the sample code that you and Dirk are yet to get working >(sorry, shameless dig). > >--Tony > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From tony at tonybibbs.com Tue Dec 21 16:30:42 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 21 Dec 2004 15:30:42 -0600 Subject: [geeklog-devel] Globals in GL2 Message-ID: <41C89602.1030503@tonybibbs.com> Today I have a config file similar to the 1.3.x one. All values get loaded into an array, $glConf. Now, OO purists would say that you should never have to use global variables in your objects...instead you should pass them along in either the constructor or in via the method call (which ever makes sense). So my question is, are we purists or not? I've got some code that uses "global $glConf;" and some that doesn't. Just want to make sure we don't have any violent reaction to this. --Tony From justin.carlson at gmail.com Tue Dec 21 16:37:53 2004 From: justin.carlson at gmail.com (Justin Carlson) Date: Tue, 21 Dec 2004 15:37:53 -0600 Subject: [geeklog-devel] Globals in GL2 In-Reply-To: <41C89602.1030503@tonybibbs.com> References: <41C89602.1030503@tonybibbs.com> Message-ID: <3d1a3f4e04122113373fd31c23@mail.gmail.com> Going from scratch, no use cutting corners. I vote to pass the conf array to the objects. On Tue, 21 Dec 2004 15:30:42 -0600, Tony Bibbs wrote: > Today I have a config file similar to the 1.3.x one. All values get > loaded into an array, $glConf. Now, OO purists would say that you > should never have to use global variables in your objects...instead you > should pass them along in either the constructor or in via the method > call (which ever makes sense). > > So my question is, are we purists or not? I've got some code that uses > "global $glConf;" and some that doesn't. Just want to make sure we > don't have any violent reaction to this. > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From dwight at trumbower.com Tue Dec 21 16:54:08 2004 From: dwight at trumbower.com (dwight at trumbower.com) Date: Tue, 21 Dec 2004 16:54:08 -0500 (EST) Subject: [geeklog-devel] Globals in GL2 In-Reply-To: <41C89602.1030503@tonybibbs.com> References: <41C89602.1030503@tonybibbs.com> Message-ID: <16386.192.136.16.3.1103666048.squirrel@192.136.16.3> > So my question is, are we purists or not? I've got some code that uses > "global $glConf;" and some that doesn't. Just want to make sure we > don't have any violent reaction to this. Depends what your goal is. Fast practical code or easy to maintain code. :) From vfuria at gmail.com Tue Dec 21 16:56:48 2004 From: vfuria at gmail.com (Vincent Furia) Date: Tue, 21 Dec 2004 16:56:48 -0500 Subject: [geeklog-devel] Globals in GL2 In-Reply-To: <3d1a3f4e04122113373fd31c23@mail.gmail.com> References: <41C89602.1030503@tonybibbs.com> <3d1a3f4e04122113373fd31c23@mail.gmail.com> Message-ID: <8319e2d60412211356500a2aa0@mail.gmail.com> I hate that configuration array. It's the worst part about installing Geeklog. I think we should look for better solutions if we can (a configuration class/struct, something in the DB that gets cached to disk?, an xml file?). -Vinny On Tue, 21 Dec 2004 15:37:53 -0600, Justin Carlson wrote: > Going from scratch, no use cutting corners. > I vote to pass the conf array to the objects. > > > On Tue, 21 Dec 2004 15:30:42 -0600, Tony Bibbs wrote: > > Today I have a config file similar to the 1.3.x one. All values get > > loaded into an array, $glConf. Now, OO purists would say that you > > should never have to use global variables in your objects...instead you > > should pass them along in either the constructor or in via the method > > call (which ever makes sense). > > > > So my question is, are we purists or not? I've got some code that uses > > "global $glConf;" and some that doesn't. Just want to make sure we > > don't have any violent reaction to this. > > > > --Tony > > _______________________________________________ > > geeklog-devel mailing list > > geeklog-devel at lists.geeklog.net > > http://lists.geeklog.net/listinfo/geeklog-devel > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From justin.carlson at gmail.com Tue Dec 21 17:03:30 2004 From: justin.carlson at gmail.com (Justin Carlson) Date: Tue, 21 Dec 2004 16:03:30 -0600 Subject: [geeklog-devel] Globals in GL2 In-Reply-To: <16386.192.136.16.3.1103666048.squirrel@192.136.16.3> References: <41C89602.1030503@tonybibbs.com> <16386.192.136.16.3.1103666048.squirrel@192.136.16.3> Message-ID: <3d1a3f4e04122114033de1ecf3@mail.gmail.com> > Depends what your goal is. Fast practical code or easy to maintain code. :) Expand please. Which way do you consider harder to maintain, or less practical? From tony at tonybibbs.com Tue Dec 21 17:08:55 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 21 Dec 2004 16:08:55 -0600 Subject: [geeklog-devel] Globals in GL2 In-Reply-To: <8319e2d60412211356500a2aa0@mail.gmail.com> References: <41C89602.1030503@tonybibbs.com> <3d1a3f4e04122113373fd31c23@mail.gmail.com> <8319e2d60412211356500a2aa0@mail.gmail.com> Message-ID: <41C89EF7.3010103@tonybibbs.com> I don't care how the user interfaces with the configuration. I think we all agreed some time ago that most of the configuration would be web-based. But, regardless of stored format (xml, DB, etc), the data needs to be in a structure we can read. Seems an array is Ok for that, no? --Tony Vincent Furia wrote: >I hate that configuration array. It's the worst part about installing >Geeklog. I think we should look for better solutions if we can (a >configuration class/struct, something in the DB that gets cached to >disk?, an xml file?). > >-Vinny > > >On Tue, 21 Dec 2004 15:37:53 -0600, Justin Carlson > wrote: > > >>Going from scratch, no use cutting corners. >>I vote to pass the conf array to the objects. >> >> >>On Tue, 21 Dec 2004 15:30:42 -0600, Tony Bibbs wrote: >> >> >>>Today I have a config file similar to the 1.3.x one. All values get >>>loaded into an array, $glConf. Now, OO purists would say that you >>>should never have to use global variables in your objects...instead you >>>should pass them along in either the constructor or in via the method >>>call (which ever makes sense). >>> >>>So my question is, are we purists or not? I've got some code that uses >>>"global $glConf;" and some that doesn't. Just want to make sure we >>>don't have any violent reaction to this. >>> >>>--Tony >>>_______________________________________________ >>>geeklog-devel mailing list >>>geeklog-devel at lists.geeklog.net >>>http://lists.geeklog.net/listinfo/geeklog-devel >>> >>> >>> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From tony at tonybibbs.com Tue Dec 21 18:27:14 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 21 Dec 2004 17:27:14 -0600 Subject: [geeklog-devel] Plugin layout Message-ID: <41C8B152.9010404@tonybibbs.com> Right now I'm working on the EventManager which has obvious ties to the plugins that may be installed. We need to agree to some sort of directory structure for plugins. Here is what I am proposing: For any using MVCnPHP and Propel, here is what I suggest: /path/to/Geeklog-2 /public_html/ / /commands /sql /system /Propel / /NamedQueries.xml /-conf.php /themes /default / /views /index.php /mvcconfig.php You'll notice that looks almost exactly like the Geeklog-2 directory structure For plugins not using MVCnPHP and Propel: /path/to/Geeklog-2 /public_html/ / /sql /system /themes /default / Only thing I don't like is I'd prefer a way to move all code outside of the web tree. This would be very easy for MVCnPHP-based applications, however, for 1.3.x style plugins, I don't see how this is possible. One thing I do know is I want all plugin code in one place. This makes installation and upkeep simpler. However, it does potentially expose code...something I think we can manage effectively since we know about it ahead of time. Anyway, by having it in one place, we could expose some "pear install"-like behavior which would definitely have some big benefits. --Tony From tony at tonybibbs.com Tue Dec 21 18:44:56 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 21 Dec 2004 17:44:56 -0600 Subject: [geeklog-devel] Today's GL2 Accomplishment Message-ID: <41C8B578.6060509@tonybibbs.com> I've got GL2's Geeklog_EventManager.php fully implemented The only method I have had time to test so far was registerListener(). The name of the file will change to ActionManager.php to represent the decision Vinny and I agreed to on not calling them events (this was mainly for support questions since plugins will more than likely have the concept of an event in one of them such as the calendar). Speaking of testing, I need to spend some time with PHPUnit2 and figure out how to fit that in. I don't think we need to test everything we have but covering the most critical code would be nice. And, in my Eutopia, we'd even do a bit of test-first programming but that would be biting of too much at this time. --Tony From vfuria at gmail.com Tue Dec 21 22:26:57 2004 From: vfuria at gmail.com (Vincent Furia) Date: Tue, 21 Dec 2004 22:26:57 -0500 Subject: [geeklog-devel] Plugin layout In-Reply-To: <41C8B152.9010404@tonybibbs.com> References: <41C8B152.9010404@tonybibbs.com> Message-ID: <8319e2d604122119262125453b@mail.gmail.com> Tony, The entire point of the "getPage" method in the plugin interface was so that both procedural and MVCnPHP plugins could operate off the web tree. Procedural plugins could generate their web pages from that function (or functions called from their) and MVCnPHP plugins could instantiate their controller from that point. That way everything except Geeklog-2's "index.php" will lie off the web tree. Even images and files could be fetched via plugin so that access to them can be restricted without resorting to obfuscated names and such (which is bad security anyway, just ask gallery). -Vinny On Tue, 21 Dec 2004 17:27:14 -0600, Tony Bibbs wrote: > Right now I'm working on the EventManager which has obvious ties to the > plugins that may be installed. We need to agree to some sort of > directory structure for plugins. Here is what I am proposing: > > For any using MVCnPHP and Propel, here is what I suggest: > > /path/to/Geeklog-2 > /public_html/ > / > /commands > /sql > /system > /Propel > / > /NamedQueries.xml > /-conf.php > /themes > /default > / > /views > /index.php > /mvcconfig.php > > You'll notice that looks almost exactly like the Geeklog-2 directory > structure > > For plugins not using MVCnPHP and Propel: > /path/to/Geeklog-2 > /public_html/ > / > /sql > /system > /themes > /default > / > > Only thing I don't like is I'd prefer a way to move all code outside of > the web tree. This would be very easy for MVCnPHP-based applications, > however, for 1.3.x style plugins, I don't see how this is possible. > > One thing I do know is I want all plugin code in one place. This makes > installation and upkeep simpler. However, it does potentially expose > code...something I think we can manage effectively since we know about > it ahead of time. Anyway, by having it in one place, we could expose > some "pear install"-like behavior which would definitely have some big > benefits. > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From vfuria at gmail.com Tue Dec 21 23:01:16 2004 From: vfuria at gmail.com (Vincent Furia) Date: Tue, 21 Dec 2004 23:01:16 -0500 Subject: [geeklog-devel] GL2, Default Plugin In-Reply-To: <41C65637.4030503@tonybibbs.com> References: <41C62D49.40704@tonybibbs.com> <8319e2d604121918377e6c37d6@mail.gmail.com> <41C65637.4030503@tonybibbs.com> Message-ID: <8319e2d604122120012111819c@mail.gmail.com> Tony, For a "no plugin" installation I'd suggest that we default to a user preferences page (if logged in) or else a log in page. Since both components need to be part of the core, there shouldn't be an issue in having either one. Clearly we'll need a mechanism so that the default could be changed (and even the shipped Geeklog-2 could/should have different defaults set). -Vinny On Sun, 19 Dec 2004 22:33:59 -0600, Tony Bibbs wrote: > Well, for testing purposes, we should have a kernel default homepage. > It will allow for a no-plugin installation...which is clearly useless > but may serve some useful testing or diagnostic services (ala > phpinfo()). Obviously we'll ship GL2 with the necessary plugins to make > it feature complete when compared to a stock 1.3.x but, I hope, nothing > more. > > --Tony > > Vincent Furia wrote: > > >I think clearly we're going to need a "frontpage" plugin. However I > >don't see any harm in allowing the user (admin) to select what the > >default plugin is (presumably on most pages this will be the > >"frontpage" plugin). > > > >-Vinny > > > > > >On Sun, 19 Dec 2004 19:39:21 -0600, Tony Bibbs wrote: > > > > > >>Ok, given that all real work in GL2 will be done by plugins, after a > >>user logs in where do we send them? Do we simply send them to a plugin > >>homepage marked as the default? > >> > >>--Tony > >>_______________________________________________ > >>geeklog-devel mailing list > >>geeklog-devel at lists.geeklog.net > >>http://lists.geeklog.net/listinfo/geeklog-devel > >> > >> > >> > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From vfuria at gmail.com Tue Dec 21 23:08:00 2004 From: vfuria at gmail.com (Vincent Furia) Date: Tue, 21 Dec 2004 23:08:00 -0500 Subject: [geeklog-devel] Custom user attributes in GL2 In-Reply-To: <006101c4e338$b9791350$650a10ac@XPBL2> References: <41C0A386.4020804@tonybibbs.com> <18160.192.136.16.3.1103145404.squirrel@192.136.16.3> <8319e2d6041215135717910b51@mail.gmail.com> <41C0B989.6010900@tonybibbs.com> <41673.192.136.16.3.1103150161.squirrel@192.136.16.3> <41C0BD8B.9020208@tonybibbs.com> <006101c4e338$b9791350$650a10ac@XPBL2> Message-ID: <8319e2d6041221200812ecec23@mail.gmail.com> I just wanted to remark somewhere permanent that we need to keep in mind that a plugin selected for uninstall may be depended upon by other plugins. Before an uninstall is begun, we need to determine the reverse dependencies for the plugin (what plugins, if any, rely on the availability of the plugin to be uninstalled) and deal with those appropriately. This also suggests that, like PEAR packages, we allow a plugin to specify requried dependencies, recommended dependencies, and optional dependencies. Geeklog-2 (or whatever we call) should be a dependency of all plugins, though the version number could vary. Again, none of these things are issues we'll need to worry about in the short term, I just want them documented somewhere and right now this list seems like the best place (especially since I can search it using Gmail :) -VInny On Thu, 16 Dec 2004 01:30:24 -0500, Blaine Lang wrote: > I like the idea of a flexible table driven set of site-defined userprofile > fields that could be used for registration or for extending the user > profile. > This could be a plugin as it could be a plugin today in 1.3.X > > I recently developed a formEditor plugin that allows you to create a form > that has any number of fields from a wide array of field types. > I used one table to define the fields for all forms where fieldtype is just > a varchar that is one of the plugin defined types. > When I display the form, I either use a default layout or a custom template > if assigned. > > We can do the same and it's pretty flexible. > Fields would need to include: > - id > - field_type (varchar 32) > - field_attributes - if we are using a default layout, you need this > - field_order > - label (or linked to language independant feature) > - required_for_registration > - is_manditory > > > ----- Original Message ----- > From: "Tony Bibbs" > To: > Sent: Wednesday, December 15, 2004 5:41 PM > Subject: Re: [geeklog-devel] Custom user attributes in GL2 > > Your saying the same thing I am. I was bit confused by Vinny's response > which sounded a bit like (put everything in there) which I am guessing > he didn't mean but I wanted to be perfectly clear on. I think your > table will be more complicated...you'll probably want things like > min/max values, required indicators, etc. That's in addition to the > ability to choose from a finite set of values. > > The more I think about it, the more I think we might want to delay doing > anything with customer user attributes until we get to a point where the > kernel is up and plugins are being written. Thoughts? > > --Tony > > dwight at trumbower.com wrote: > > >Ok, I'm confused. I don't see username and password as custom attributes. > > > >Custom attributes are usually used to enhance the base package and allow > >customers to add a few fields of data to customize a screen. The old days, > >you just created 5-10 fields, called user1, user2,...user10. So every > >table had 10 extra fields. > > > >The new way puts only the fields you want in a combined table, just like > >your List Of Values(LOV) table. > > > >The hard part is displaying these fields. The easiest way is to have them > >all grouped together at the end of a screen. Know when people want to move > >them around in different places, it gets tricky. > > > >Also if you need to handle select option fields, radio fields and check > >box fields there will need some more supporting tables. > > > > > >Dwight > > > > > > > > > > > >>I'm fine with data driving the custom user stuff..l > >> > >>I would still say, though, you'd want real columns in the GL2 user table > >>for thing we know we need (i.e. username, password, etc) for performance > >>reasons alone, right? Regardless, going this route will make the use of > >>Propel a little bit messy as the user class generated by propel won't > >>know anything about the custom attributes in the database. > >> > >>Also, for clarity, are you suggesting we do this for all plugin specific > >>user attributes? I don't think you are and if you are we probably want > >>to discuss the pros/cons between that and having a plugins specific user > >>table with a one-to-one relationship with the kernel user table. > >> > >>--Tony > >> > >>Vincent Furia wrote: > >> > >> > >> > >>>I'm with Dwight. This way all user data is in one place (and the > >>>plugins can put user data there as well). > >>> > >>>-Vinny > >>> > >>> > >>>On Wed, 15 Dec 2004 16:16:44 -0500 (EST), dwight at trumbower.com > >>> wrote: > >>> > >>> > >>> > >>> > >>>>The easiest way I know of, one table. > >>>> > >>>>column name - String > >>>>column type - specifies, long, int, string ect > >>>>column data - data as a string > >>>> > >>>>Might need xref table to show where it is used. At least this is how > >>>>would > >>>>start. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>Anybody have any input on how to best address providing the community > >>>>>with fairly easy way to add custom attributes for users in GL2? > >>>>> > >>>>>I don't I have a good idea on how to do this. My hopes are that > >>>>>plugins > >>>>>would have their own one-to-one mapping from the core user table to > >>>>>their own user table with addition information. Assuming that is OK, > >>>>>how do we handle things the site admin simply wants to add (e.g. msn > >>>>>id, > >>>>>pgp key, etc). > >>>>> > >>>>>--Tony > >>>>>_______________________________________________ > >>>>>geeklog-devel mailing list > >>>>>geeklog-devel at lists.geeklog.net > >>>>>http://lists.geeklog.net/listinfo/geeklog-devel > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>_______________________________________________ > >>>>geeklog-devel mailing list > >>>>geeklog-devel at lists.geeklog.net > >>>>http://lists.geeklog.net/listinfo/geeklog-devel > >>>> > >>>> > >>>> > >>>> > >>>> > >>>_______________________________________________ > >>>geeklog-devel mailing list > >>>geeklog-devel at lists.geeklog.net > >>>http://lists.geeklog.net/listinfo/geeklog-devel > >>> > >>> > >>> > >>> > >>_______________________________________________ > >>geeklog-devel mailing list > >>geeklog-devel at lists.geeklog.net > >>http://lists.geeklog.net/listinfo/geeklog-devel > >> > >> > >> > > > >_______________________________________________ > >geeklog-devel mailing list > >geeklog-devel at lists.geeklog.net > >http://lists.geeklog.net/listinfo/geeklog-devel > > > > > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From vfuria at gmail.com Tue Dec 21 23:09:25 2004 From: vfuria at gmail.com (Vincent Furia) Date: Tue, 21 Dec 2004 23:09:25 -0500 Subject: [geeklog-devel] GL2 Login works In-Reply-To: <41C74959.8020104@tonybibbs.com> References: <41C74959.8020104@tonybibbs.com> Message-ID: <8319e2d604122120092db01a2c@mail.gmail.com> Tony, Slightly off topic, but do we plan to still use the PEAR::HTTP_Session2 class(es) for session management? -Vinny On Mon, 20 Dec 2004 15:51:21 -0600, Tony Bibbs wrote: > Pretty soon here I will be checking in a version of Geeklog 2 which > successfully authenticates a user. I have taken care to factor the code > in such a way that the means by which one manages a user account can be > changed by simply implementing one class and changing a setting in the > config file. > > Being that noone has looked into the code yet (hint, hint) I'll take > this time to discuss the basic design: > > The most basic part of the account management equation is the > Geeklog_AccountManager (in AccountManager.php). It's job is to read the > Account Manager it needs to create from a value in the configuration > file ($glConf['account_manager']), and generate an instance of that > class which is responsible for doing the work. > > All account managers must implement the Geeklog_AccountManagerInterface > (AccountManagerInterface.php) which provides methods for creating > accounts, deleting accounts, authenticating users and changing > passwords. Other method will probably be added to this interface (i.e. > update account, etc) but I won't bother with them until we establish the > need. > > As such, I have created default AccountManager...named > Geeklog_DefaultAccountManager in DefaultAccountManager.php (see the > pattern?). > > All this said, one could, for example, create a LDAPAccountManager, > IMAPAccountManager, etc to have GL2 authenticate to any datastore. I'd > like to see LDAP and IMAP bundled in with GL2 (any takers?). > > So, have a look in CVS and let me know what you do/don't like about what > I have so far. > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Tue Dec 21 23:55:26 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 21 Dec 2004 22:55:26 -0600 Subject: [geeklog-devel] Plugin layout In-Reply-To: <8319e2d604122119262125453b@mail.gmail.com> References: <41C8B152.9010404@tonybibbs.com> <8319e2d604122119262125453b@mail.gmail.com> Message-ID: <41C8FE3E.8040009@tonybibbs.com> Vincent Furia wrote: >Tony, > >The entire point of the "getPage" method in the plugin interface was >so that both procedural and MVCnPHP plugins could operate off the web >tree. Procedural plugins could generate their web pages from that >function (or functions called from their) and MVCnPHP plugins could >instantiate their controller from that point. > > That's fine, the only thing I want to try and honor is URL rewriting. Thus a URL like: http://www.example.com/index.php/article/PreSeasonDeer/ Should serve up fine. The 'getPage' idea is nearly in-line with what I was expecting, I just didn't see how it would work for procedural plugins. >That way everything except Geeklog-2's "index.php" will lie off the >web tree. Even images and files could be fetched via plugin so that >access to them can be restricted without resorting to obfuscated names >and such (which is bad security anyway, just ask gallery). > > I don't argue this at all, again, it was more an issue of thinking through the procedural plugins. I'm still fuzzy how this would work for them, though, I don't doubt it possible. We just have to "make it so". --Tony From vfuria at gmail.com Wed Dec 22 00:02:46 2004 From: vfuria at gmail.com (Vincent Furia) Date: Wed, 22 Dec 2004 00:02:46 -0500 Subject: [geeklog-devel] Plugin layout In-Reply-To: <41C8FE3E.8040009@tonybibbs.com> References: <41C8B152.9010404@tonybibbs.com> <8319e2d604122119262125453b@mail.gmail.com> <41C8FE3E.8040009@tonybibbs.com> Message-ID: <8319e2d604122121027d74a1a3@mail.gmail.com> Basically I was thinking that only index.php have an "echo" statement. Everything else should pass around HTML strings. That would allow us to do cool stuff like apply post-processing filters on all pages (or just some pages). URL rewriting should be easy, if we just let the plugins deal with it. Just so long as the first parameter in a rewritten URL is a plugin name so that index.php knows what to do. Implementing something more complex would (obviously) require more effort and complexity. -Vinny On Tue, 21 Dec 2004 22:55:26 -0600, Tony Bibbs wrote: > Vincent Furia wrote: > > >Tony, > > > >The entire point of the "getPage" method in the plugin interface was > >so that both procedural and MVCnPHP plugins could operate off the web > >tree. Procedural plugins could generate their web pages from that > >function (or functions called from their) and MVCnPHP plugins could > >instantiate their controller from that point. > > > > > That's fine, the only thing I want to try and honor is URL rewriting. > Thus a URL like: > > http://www.example.com/index.php/article/PreSeasonDeer/ > > Should serve up fine. > > The 'getPage' idea is nearly in-line with what I was expecting, I just > didn't see how it would work for procedural plugins. > > >That way everything except Geeklog-2's "index.php" will lie off the > >web tree. Even images and files could be fetched via plugin so that > >access to them can be restricted without resorting to obfuscated names > >and such (which is bad security anyway, just ask gallery). > > > > > I don't argue this at all, again, it was more an issue of thinking > through the procedural plugins. I'm still fuzzy how this would work for > them, though, I don't doubt it possible. We just have to "make it so". > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Wed Dec 22 00:03:01 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 21 Dec 2004 23:03:01 -0600 Subject: [geeklog-devel] GL2, Default Plugin In-Reply-To: <8319e2d604122120012111819c@mail.gmail.com> References: <41C62D49.40704@tonybibbs.com> <8319e2d604121918377e6c37d6@mail.gmail.com> <41C65637.4030503@tonybibbs.com> <8319e2d604122120012111819c@mail.gmail.com> Message-ID: <41C90005.8030205@tonybibbs.com> I think no-plugin scenarios will be far and few between. I think if a user does login during that setup, they are probably an admin. We should check if they are an admin and, if so, simply give them admin options Giving non-admins access to just the preferences makes sense. -Tony Vincent Furia wrote: >Tony, > >For a "no plugin" installation I'd suggest that we default to a user >preferences page (if logged in) or else a log in page. Since both >components need to be part of the core, there shouldn't be an issue in >having either one. Clearly we'll need a mechanism so that the default >could be changed (and even the shipped Geeklog-2 could/should have >different defaults set). > >-Vinny > > From tony at tonybibbs.com Wed Dec 22 00:05:37 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 21 Dec 2004 23:05:37 -0600 Subject: [geeklog-devel] Custom user attributes in GL2 In-Reply-To: <8319e2d6041221200812ecec23@mail.gmail.com> References: <41C0A386.4020804@tonybibbs.com> <18160.192.136.16.3.1103145404.squirrel@192.136.16.3> <8319e2d6041215135717910b51@mail.gmail.com> <41C0B989.6010900@tonybibbs.com> <41673.192.136.16.3.1103150161.squirrel@192.136.16.3> <41C0BD8B.9020208@tonybibbs.com> <006101c4e338$b9791350$650a10ac@XPBL2> <8319e2d6041221200812ecec23@mail.gmail.com> Message-ID: <41C900A1.4000502@tonybibbs.com> Vincent Furia wrote: >I just wanted to remark somewhere permanent that we need to keep in >mind that a plugin selected for uninstall may be depended upon by >other plugins. Before an uninstall is begun, we need to determine the >reverse dependencies for the plugin (what plugins, if any, rely on the >availability of the plugin to be uninstalled) and deal with those >appropriately. > > This is starting to beg the question if the plugin dependencies shouldn't be added to the datamodel. I think you could do it without having it in the database but it might be easier searching there. Just a thought. >This also suggests that, like PEAR packages, we allow a plugin to >specify requried dependencies, recommended dependencies, and optional >dependencies. > > Agreed. --Tony From tony at tonybibbs.com Wed Dec 22 00:06:43 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 21 Dec 2004 23:06:43 -0600 Subject: [geeklog-devel] GL2 Login works In-Reply-To: <8319e2d604122120092db01a2c@mail.gmail.com> References: <41C74959.8020104@tonybibbs.com> <8319e2d604122120092db01a2c@mail.gmail.com> Message-ID: <41C900E3.8030107@tonybibbs.com> Good question. I think so, so far I've simply been using file-based sessions. I should dust that code off...it's pretty small so I don't see a problem in using i. --Tony Vincent Furia wrote: >Tony, > >Slightly off topic, but do we plan to still use the >PEAR::HTTP_Session2 class(es) for session management? > >-Vinny > > >On Mon, 20 Dec 2004 15:51:21 -0600, Tony Bibbs wrote: > > >>Pretty soon here I will be checking in a version of Geeklog 2 which >>successfully authenticates a user. I have taken care to factor the code >>in such a way that the means by which one manages a user account can be >>changed by simply implementing one class and changing a setting in the >>config file. >> >>Being that noone has looked into the code yet (hint, hint) I'll take >>this time to discuss the basic design: >> >>The most basic part of the account management equation is the >>Geeklog_AccountManager (in AccountManager.php). It's job is to read the >>Account Manager it needs to create from a value in the configuration >>file ($glConf['account_manager']), and generate an instance of that >>class which is responsible for doing the work. >> >>All account managers must implement the Geeklog_AccountManagerInterface >>(AccountManagerInterface.php) which provides methods for creating >>accounts, deleting accounts, authenticating users and changing >>passwords. Other method will probably be added to this interface (i.e. >>update account, etc) but I won't bother with them until we establish the >>need. >> >>As such, I have created default AccountManager...named >>Geeklog_DefaultAccountManager in DefaultAccountManager.php (see the >>pattern?). >> >>All this said, one could, for example, create a LDAPAccountManager, >>IMAPAccountManager, etc to have GL2 authenticate to any datastore. I'd >>like to see LDAP and IMAP bundled in with GL2 (any takers?). >> >>So, have a look in CVS and let me know what you do/don't like about what >>I have so far. >> >>--Tony >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From tony at tonybibbs.com Wed Dec 22 00:11:33 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 21 Dec 2004 23:11:33 -0600 Subject: [geeklog-devel] Plugin layout In-Reply-To: <8319e2d604122121027d74a1a3@mail.gmail.com> References: <41C8B152.9010404@tonybibbs.com> <8319e2d604122119262125453b@mail.gmail.com> <41C8FE3E.8040009@tonybibbs.com> <8319e2d604122121027d74a1a3@mail.gmail.com> Message-ID: <41C90205.2000708@tonybibbs.com> Vincent Furia wrote: >Basically I was thinking that only index.php have an "echo" statement. > Everything else should pass around HTML strings. That would allow us >to do cool stuff like apply post-processing filters on all pages (or >just some pages). > > It'll need to be slightly more complicated than that since I see index.php holding the MVCnPHP controller for the admin and basic kernel stuff. We should be able to use a single MVCnPHP command for handling handing off control to both procedural and OO-based plugins. Essentially the same concept, though, as your getPage. >URL rewriting should be easy, if we just let the plugins deal with it. > Just so long as the first parameter in a rewritten URL is a plugin >name so that index.php knows what to do. Implementing something more >complex would (obviously) require more effort and complexity. > > No, I think that would be fine. Intuitive and simple. Question is would it work with PHP5/IIS? Last I check this sort of URL rewriting caused nasty errors. --Tony From tony at tonybibbs.com Wed Dec 22 00:20:41 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 21 Dec 2004 23:20:41 -0600 Subject: [geeklog-devel] GL2 Login works In-Reply-To: <8319e2d604122120092db01a2c@mail.gmail.com> References: <41C74959.8020104@tonybibbs.com> <8319e2d604122120092db01a2c@mail.gmail.com> Message-ID: <41C90429.9030400@tonybibbs.com> Oh, yeah. Only other issue with this is I'll need to refactor the existing code so I can include Creole support. Shouldn't be too hard but something I didn't want to forget. --Tony Vincent Furia wrote: >Tony, > >Slightly off topic, but do we plan to still use the >PEAR::HTTP_Session2 class(es) for session management? > >-Vinny > > >On Mon, 20 Dec 2004 15:51:21 -0600, Tony Bibbs wrote: > > >>Pretty soon here I will be checking in a version of Geeklog 2 which >>successfully authenticates a user. I have taken care to factor the code >>in such a way that the means by which one manages a user account can be >>changed by simply implementing one class and changing a setting in the >>config file. >> >>Being that noone has looked into the code yet (hint, hint) I'll take >>this time to discuss the basic design: >> >>The most basic part of the account management equation is the >>Geeklog_AccountManager (in AccountManager.php). It's job is to read the >>Account Manager it needs to create from a value in the configuration >>file ($glConf['account_manager']), and generate an instance of that >>class which is responsible for doing the work. >> >>All account managers must implement the Geeklog_AccountManagerInterface >>(AccountManagerInterface.php) which provides methods for creating >>accounts, deleting accounts, authenticating users and changing >>passwords. Other method will probably be added to this interface (i.e. >>update account, etc) but I won't bother with them until we establish the >>need. >> >>As such, I have created default AccountManager...named >>Geeklog_DefaultAccountManager in DefaultAccountManager.php (see the >>pattern?). >> >>All this said, one could, for example, create a LDAPAccountManager, >>IMAPAccountManager, etc to have GL2 authenticate to any datastore. I'd >>like to see LDAP and IMAP bundled in with GL2 (any takers?). >> >>So, have a look in CVS and let me know what you do/don't like about what >>I have so far. >> >>--Tony >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From geeklog at langfamily.ca Wed Dec 22 11:33:10 2004 From: geeklog at langfamily.ca (Blaine Lang) Date: Wed, 22 Dec 2004 11:33:10 -0500 Subject: [geeklog-devel] [Fwd: Re: [propel] Multiple DBMS's and date/time] References: <41C30D3E.806@tonybibbs.com> <8319e2d6041217091616d9aa54@mail.gmail.com> Message-ID: <009501c4e843$ec944790$650a10ac@XPBL2> Will we still not need Library functions then to compare dates in code as I think you need to convert the YY-MM-DD HH:MM:SS Date/time format strings to UNIX Timestamps for comparison in code - correct? Or did I read that you can request Propel to do this converstion when retrieving the field? Blaine ----- Original Message ----- From: "Vincent Furia" To: Sent: Friday, December 17, 2004 12:16 PM Subject: Re: [geeklog-devel] [Fwd: Re: [propel] Multiple DBMS's and date/time] TIMESTAMP in Propel == DATETIME in MySQL. So in mysql DDL you'd want to use DATETIME. -Vinny On Fri, 17 Dec 2004 10:45:50 -0600, Tony Bibbs wrote: > Seems like we should go with the timestamp data type. Read below. > > --Tony > > -------- Original Message -------- > Subject: Re: [propel] Multiple DBMS's and date/time > Date: Fri, 17 Dec 2004 11:36:17 -0500 (EST) > From: Hans Lellelid > Reply-To: users at propel.tigris.org > To: users at propel.tigris.org > References: <41C304F4.7020205 at tonybibbs.com> > <15195.69.17.56.162.1103300475.spork at webmail.hozn.net> > <41C308F8.2090905 at tonybibbs.com> > > Yeah, I'm quite sure you can set it at runtime, though you may need to set > it before opening the connection. I used to set it in Creole > MSSQLConnection class, but there was some reason that this wasn't always a > good idea. ... perhaps it was breaking when using freetds instead of MS > libs or something. > > -Hans > > > Cool. Is the MSSQL option you refer to in php.ini something I can set > > at runtime via ini_set()? > > > > --Tony > > > > Hans Lellelid wrote: > > > >>>I have a project that will be supported under multiple DBMS's (MySQL, > >>>Postgres and MS SQL). We are doing the general database design and we > >>>are to the topic of how to formate date/time values. All our values > >>>will be after 1970 so timestamps are an options. My question is > >>>whether > >>>or not to use the native date/time types in the DBMS via Propel. Does > >>>Propel handle this well or am I better of using a timestamp datatype or > >>>int? > >>> > >>> > >>> > >> > >>Propel handles this well and I would advise you to use TIMESTAMP rather > >>than INT. > >> > >>TIMESTAMP will be converted to the best representation (e.g. for MySQL > >>it > >>will use DATETIME) for the RDBMS. The only thing you'll probably want > >>to > >>fix is the MSSQL ini option (in php.ini) to have it use standard ISO > >>date > >>formats. > >> > >>The getter methods that are generated by Propel will actually allow you > >> to > >>specify date/time formatters: > >> > >>$myobj->getTimeCol("Y-m-d"); // date()-formatting > >> > >>or > >> > >>$myobj->getTimeCol("%c"); // strftime()-formatting > >> > >>or > >> > >>$myobj->getTimeCol(null); // native unix timestamp > >> > >>or > >> > >>$myobj->getTimeCol(); // default is ISO: Y-m-d H:i:s > >> > >>Hope that helps. > >> > >>-Hans > >> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: users-unsubscribe at propel.tigris.org > >>For additional commands, e-mail: users-help at propel.tigris.org > >> > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscribe at propel.tigris.org > > For additional commands, e-mail: users-help at propel.tigris.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe at propel.tigris.org > For additional commands, e-mail: users-help at propel.tigris.org > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > _______________________________________________ geeklog-devel mailing list geeklog-devel at lists.geeklog.net http://lists.geeklog.net/listinfo/geeklog-devel From tony at tonybibbs.com Wed Dec 22 11:46:57 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 22 Dec 2004 10:46:57 -0600 Subject: [geeklog-devel] [Fwd: Re: [propel] Multiple DBMS's and date/time] In-Reply-To: <009501c4e843$ec944790$650a10ac@XPBL2> References: <41C30D3E.806@tonybibbs.com> <8319e2d6041217091616d9aa54@mail.gmail.com> <009501c4e843$ec944790$650a10ac@XPBL2> Message-ID: <41C9A501.8070709@tonybibbs.com> Blaine Lang wrote: >Will we still not need Library functions then to compare dates in code as I >think you need to convert the YY-MM-DD HH:MM:SS Date/time format strings to >UNIX Timestamps for comparison in code - correct? > >Or did I read that you can request Propel to do this converstion when >retrieving the field? > > Right, when you pull a date out of a domain object you can do something like: $myObj->getSomeDateMember(' References: <41C30D3E.806@tonybibbs.com> <8319e2d6041217091616d9aa54@mail.gmail.com> <009501c4e843$ec944790$650a10ac@XPBL2> <41C9A501.8070709@tonybibbs.com> Message-ID: <8319e2d604122209464a190bea@mail.gmail.com> Propel functions that set date/time columns can commutate common string formats into dates. It's actually pretty cool how flexible it is. -Vinny On Wed, 22 Dec 2004 10:46:57 -0600, Tony Bibbs wrote: > Blaine Lang wrote: > > >Will we still not need Library functions then to compare dates in code as I > >think you need to convert the YY-MM-DD HH:MM:SS Date/time format strings to > >UNIX Timestamps for comparison in code - correct? > > > >Or did I read that you can request Propel to do this converstion when > >retrieving the field? > > > > > Right, when you pull a date out of a domain object you can do something > like: > > $myObj->getSomeDateMember(' > I wouldn't assume, though, that you don't have to convert them to a > date/time format when saving. It'll take some testing. > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From dirk at haun-online.de Thu Dec 23 03:09:54 2004 From: dirk at haun-online.de (Dirk Haun) Date: Thu, 23 Dec 2004 09:09:54 +0100 Subject: [geeklog-devel] Offline Message-ID: <20041223080954.122@smtp.haun-online.de> Just wanted to let you know that I'm offline until some time next week. Enjoy some (hopefully) quiet days with friends & family. bye, Dirk -- http://www.geeklog.net/ http://geeklog.info/ From tony at tonybibbs.com Mon Dec 27 18:14:21 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 27 Dec 2004 17:14:21 -0600 Subject: [geeklog-devel] [Fwd: Re: [W3B7V2D] Server activity] Message-ID: <41D0974D.3000808@tonybibbs.com> How's that for customer service? --Tony -------- Original Message -------- Subject: Re: [W3B7V2D] Server activity Date: Sat, 25 Dec 2004 15:51:14 EST From: QuickServe Support To: tony at tonybibbs.com Hello, Due to the activity on your server, I added an extra 512MB to your RAM total. The server was dipping into swap space quite a bit. Down time was less than 3 minutes. Thanks, Amon qs at pair.com From tony at tonybibbs.com Mon Dec 27 18:27:16 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 27 Dec 2004 17:27:16 -0600 Subject: [geeklog-devel] [Fwd: Re: [propel] Performance Benchmarks] Message-ID: <41D09A54.7080707@tonybibbs.com> Here you go. Results aren't the greatest. I've offered to do a detailed execution profile for the Creole developers so they might have an idea where to start looking should they decide to trim sometime off. I think ideally we'd at least get PEAR::DB-ish performance. --Tony -------- Original Message -------- Subject: Re: [propel] Performance Benchmarks Date: Sun, 26 Dec 2004 21:32:20 +0100 From: D?nes Szab? Reply-To: users at propel.tigris.org To: users at propel.tigris.org References: <41BEFBAA.3080602 at tonybibbs.com> <41C10D74.2020502 at velum.net> <41C112F0.4050706 at tonybibbs.com> <1c4a145c04121601161bcee6e0 at mail.gmail.com> <41C7323C.1000802 at tonybibbs.com> Hi! I forgot it. Sorry! I used the adodb's benchmark suite. (http://adodb.sourceforge.net/ -> http://phplens.com/lens/adodb/) I wrote a test case for creole: benchcreole.php _creole.inc.php: executeQuery('select productid,productname,unitsinstock,unitprice from products'); while ($rs->next()) { $id=$rs->getInt('productid'); $name=$rs->getString('productname'); $unitsinstock=$rs->getInt('unitsinstock'); $unitprice=$rs->getFloat('unitprice'); if ($debug) { print "$id, $name, $unitsinstock, $unitprice
"; } } $rs->close(); } // fetchRow is slower but superior API function QueryOnce2(&$db,$debug) { $rs = $db->query('select productid,productname,unitsinstock,unitprice from products'); while ($fields = $rs->fetchRow()) { $id=$fields[0]; $name=$fields[1]; $unitsinstock=$fields[2]; $unitprice=$fields[3]; if ($debug) { print "$id, $name, $unitsinstock, $unitprice
"; } } $rs->free(); } ?> My dir structure is: |-- adodb/ |-- pear | |-- DB | |-- creole | `-- jargon |-- _adodb.inc.php |-- _benchmark.inc.php |-- _creole.inc.php |-- _dbx.inc.php |-- _mdb.inc.php |-- _metabase.inc.php |-- _mysql.inc.php |-- _pear.inc.php |-- _phplib.inc.php |-- benchadodb.php |-- benchcreole.php |-- benchdbx.php |-- benchmdb.php |-- benchmetabase.php |-- benchmysql.php |-- benchpear.php |-- benchphplib.php |-- createproducts.sql `-- readme.txt I used mysql for test (createproducts.sql) My results are (with 2000 iteration!): CREOLE DB: Queried 2000 times for 12.62241601944 seconds PEAR DB: Queried 2000 times for 8.1311810016632 seconds ADODB: Queried 2000 times for 4.7065849304199 seconds MySQL: Queried 2000 times for 2.3287560939789 seconds The smallest is the best. It is sad but the creole is the slowest. But creole makes some plus goodies (getInt( ), getString( )). The adodb is a very good db layer. (I used to it a lot). On Mon, 20 Dec 2004 14:12:44 -0600, Tony Bibbs wrote: > D?nes, I never got this. Can you please post your results? > > --Tony -- [dt] --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe at propel.tigris.org For additional commands, e-mail: users-help at propel.tigris.org From vfuria at gmail.com Mon Dec 27 18:31:15 2004 From: vfuria at gmail.com (Vincent Furia) Date: Mon, 27 Dec 2004 18:31:15 -0500 Subject: [geeklog-devel] [Fwd: Re: [W3B7V2D] Server activity] In-Reply-To: <41D0974D.3000808@tonybibbs.com> References: <41D0974D.3000808@tonybibbs.com> Message-ID: <8319e2d6041227153124af399d@mail.gmail.com> Hey Tony, Still getting an SQL error from www.geeklog.net. -Vinny On Mon, 27 Dec 2004 17:14:21 -0600, Tony Bibbs wrote: > How's that for customer service? > > --Tony > > -------- Original Message -------- > Subject: Re: [W3B7V2D] Server activity > Date: Sat, 25 Dec 2004 15:51:14 EST > From: QuickServe Support > To: tony at tonybibbs.com > > Hello, > > Due to the activity on your server, I added an extra 512MB to your RAM > total. The server was dipping into swap space quite a bit. > > Down time was less than 3 minutes. > > Thanks, > > Amon > qs at pair.com > > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Mon Dec 27 18:37:18 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Mon, 27 Dec 2004 17:37:18 -0600 Subject: [geeklog-devel] [Fwd: Re: [W3B7V2D] Server activity] In-Reply-To: <8319e2d6041227153124af399d@mail.gmail.com> References: <41D0974D.3000808@tonybibbs.com> <8319e2d6041227153124af399d@mail.gmail.com> Message-ID: <41D09CAE.10509@tonybibbs.com> Yeah, I sent a note in. --Tony Vincent Furia wrote: >Hey Tony, > >Still getting an SQL error from www.geeklog.net. > >-Vinny > > >On Mon, 27 Dec 2004 17:14:21 -0600, Tony Bibbs wrote: > > >>How's that for customer service? >> >>--Tony >> >>-------- Original Message -------- >>Subject: Re: [W3B7V2D] Server activity >>Date: Sat, 25 Dec 2004 15:51:14 EST >>From: QuickServe Support >>To: tony at tonybibbs.com >> >>Hello, >> >>Due to the activity on your server, I added an extra 512MB to your RAM >>total. The server was dipping into swap space quite a bit. >> >>Down time was less than 3 minutes. >> >>Thanks, >> >>Amon >>qs at pair.com >> >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From tony at tonybibbs.com Tue Dec 28 09:51:54 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 28 Dec 2004 08:51:54 -0600 Subject: [geeklog-devel] [Fwd: Re: [W3B7V2D] Server activity] Message-ID: <41D1730A.6000208@tonybibbs.com> -------- Original Message -------- Subject: Re: [W3B7V2D] Server activity Date: Tue, 28 Dec 2004 02:02:43 EST From: QuickServe Support To: Tony Bibbs Hello, I traced the problem down to the "sessions" table in your geeklog_production database being marked as crashed. I was able to repair this table, and the site now appears to be working correctly again. Please let me know if you are still having any problems with it, I'll continue to check into it as well. Sorry for the problems. -Kevin O. pair Networks qs at pair.com > > Thanks, however, ever since this upgrade, our site > http://www.geeklog.net has been down getting a SQL error). We've made > no modifications to any of the code running up there in over a week. > > Ideas? > > --Tony > > QuickServe Support wrote: > > >Hello, > > > >Due to the activity on your server, I added an extra 512MB to your RAM > >total. The server was dipping into swap space quite a bit. > > > >Down time was less than 3 minutes. > > > >Thanks, > > > >Amon > >qs at pair.com > > > > From vfuria at gmail.com Tue Dec 28 12:14:23 2004 From: vfuria at gmail.com (Vincent Furia) Date: Tue, 28 Dec 2004 12:14:23 -0500 Subject: [geeklog-devel] Geeklog-2 CVS, To-do list In-Reply-To: <41C7576B.5080600@tonybibbs.com> References: <41C3D8E4.4010507@tonybibbs.com> <41C7576B.5080600@tonybibbs.com> Message-ID: <8319e2d60412280914620cde6d@mail.gmail.com> Question on 7: Should Geeklog_ActionManager.php actually be a child of the BaseActionlistenerPeer.php propel class? -Vinny On Mon, 20 Dec 2004 16:51:23 -0600, Tony Bibbs wrote: > Here's an update on this list: > > Tony Bibbs wrote: > > > Here's the to-do list, short term: > > > > 1) BaseViewFlexy needs the translation stuff ironed out > > Sorta done. Needs to be thought through completely as I'm sure I > haven't covered all our cases (not to mention I'm still fuzzy on how > Translation2 works). Also need to consider the possiblity of using the > xml translation2 support given all the dependencies for the gettext > implementation. > > > 2) Data model needs Dwights attention regarding the count fields (i.e. > > gl2_user.num_views) so we can make a final decision and get those > > changes in the data model. > > Dwight? > > > 3) Geeklog_LoginCommand.php needs to be implemented. This should log > > a user in, get the user object from the database (including > > privileges) and serialize it to the session. > > Rought draft is done. > > > 4) BaseViewFlexyUser.php needs to be updated to correctly deserialize > > the user object from the session. If the user object doesn't exist it > > should forward on to the Login page. Otherwise it should forward on > > to...well that's the million dollar question. Given we have the > > concept of plugins for everything, we probably need to allow the user > > to specify the default one to use for the homepage, no? > > Rough draft done. I'll build a kernel home page that will be the > default in the case that no plugins are installed. > > > 5) We need the filtering class defined. I know Blaine volunteered > > originally...can you still do it? > > Blaine was going to look into this since this would also benefit 1.3.x > > > 6) Plugin API needs to have dependency checking added to it > > Done > > > 7) Event Manager needs to be implemented. > > This will be my next project, I guess. > > --Tony > _______________________________________________ > geeklog-devel mailing list > geeklog-devel at lists.geeklog.net > http://lists.geeklog.net/listinfo/geeklog-devel > From tony at tonybibbs.com Tue Dec 28 13:53:07 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 28 Dec 2004 12:53:07 -0600 Subject: [geeklog-devel] Geeklog-2 CVS, To-do list In-Reply-To: <8319e2d60412280914620cde6d@mail.gmail.com> References: <41C3D8E4.4010507@tonybibbs.com> <41C7576B.5080600@tonybibbs.com> <8319e2d60412280914620cde6d@mail.gmail.com> Message-ID: <41D1AB93.6020808@tonybibbs.com> Dunno, I got that half coded already: http://cvs.geeklog.net/co.php/Geeklog-2/system/ActionManager.php Right now it doesn't because it simply uses the DAO. --Tony Vincent Furia wrote: >Question on 7: Should Geeklog_ActionManager.php actually be a child of >the BaseActionlistenerPeer.php propel class? > >-Vinny > > >On Mon, 20 Dec 2004 16:51:23 -0600, Tony Bibbs wrote: > > >>Here's an update on this list: >> >>Tony Bibbs wrote: >> >> >> >>>Here's the to-do list, short term: >>> >>>1) BaseViewFlexy needs the translation stuff ironed out >>> >>> >>Sorta done. Needs to be thought through completely as I'm sure I >>haven't covered all our cases (not to mention I'm still fuzzy on how >>Translation2 works). Also need to consider the possiblity of using the >>xml translation2 support given all the dependencies for the gettext >>implementation. >> >> >> >>>2) Data model needs Dwights attention regarding the count fields (i.e. >>>gl2_user.num_views) so we can make a final decision and get those >>>changes in the data model. >>> >>> >>Dwight? >> >> >> >>>3) Geeklog_LoginCommand.php needs to be implemented. This should log >>>a user in, get the user object from the database (including >>>privileges) and serialize it to the session. >>> >>> >>Rought draft is done. >> >> >> >>>4) BaseViewFlexyUser.php needs to be updated to correctly deserialize >>>the user object from the session. If the user object doesn't exist it >>>should forward on to the Login page. Otherwise it should forward on >>>to...well that's the million dollar question. Given we have the >>>concept of plugins for everything, we probably need to allow the user >>>to specify the default one to use for the homepage, no? >>> >>> >>Rough draft done. I'll build a kernel home page that will be the >>default in the case that no plugins are installed. >> >> >> >>>5) We need the filtering class defined. I know Blaine volunteered >>>originally...can you still do it? >>> >>> >>Blaine was going to look into this since this would also benefit 1.3.x >> >> >> >>>6) Plugin API needs to have dependency checking added to it >>> >>> >>Done >> >> >> >>>7) Event Manager needs to be implemented. >>> >>> >>This will be my next project, I guess. >> >>--Tony >>_______________________________________________ >>geeklog-devel mailing list >>geeklog-devel at lists.geeklog.net >>http://lists.geeklog.net/listinfo/geeklog-devel >> >> >> >_______________________________________________ >geeklog-devel mailing list >geeklog-devel at lists.geeklog.net >http://lists.geeklog.net/listinfo/geeklog-devel > > From tony at tonybibbs.com Tue Dec 28 16:49:00 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Tue, 28 Dec 2004 15:49:00 -0600 Subject: [geeklog-devel] [Fwd: [PEAR-DEV] PEAR 1.4.0 report - Major progress: 97% unit-tested] Message-ID: <41D1D4CC.6000702@tonybibbs.com> Here is an update on PEAR 1.4 below. One thing worth noting is 1.4 will support the notion of 'channels'. This will allow Geeklog to deploy software using PEAR from our own respository. This is significant for two reasons: 1) I didn't know they would have coded the channel support already...they did this pretty damned fast and 2) this could provide us the engine for managing Geeklog plugins. At the very least, Geeklog based libraries (i.e. MVCnPHP) can use this feature. Just a heads up, --Tony -------- Original Message -------- Subject: [PEAR-DEV] PEAR 1.4.0 report - Major progress: 97% unit-tested Date: Tue, 28 Dec 2004 00:49:47 -0500 From: Greg Beaver To: PEAR-dev , pear-qa Hello, I am in the process of testing PEAR_Installer/PEAR_Downloader's support of all the various options, including some obscure ones like --soft. Once this is finished, the only classes left to test are: PEAR_Command_Install finish PEAR_ChannelFile PEAR_REST/PEAR_Remote PEAR_Task_* makerpm/bundle commands PEAR_Builder I'm pretty confident that I can finish the tests by Jan. 1. All normal package.xml 1.0 stuff is fully tested EXCEPT for pecl package installation. Those who would like to help out with testing, please feel free to upgrade package-PEAR.xml, there will be very few changes to core functionality of PEAR between now and 1.4.0a1's release. The only untested features involve the new package.xml 2.0 features (bundle, ext releases) and some tasks that nobody uses yet. replacements is fully tested and working. Today, I committed tweaks to an exciting new feature that occurred to me yesterday. channel.xml has had support for mirrors, but this had not yet been implemented. As of today, mirroring is fully supported at the client level. This is controlled by the new preferred_mirror config variable. The server in this variable will be used as if it were the primary server. Soon, I will probably also implement a comma-delimited list of servers like some kind of server_path, but that is for the future. preferred_mirror can be used for more than just typical mirroring, it can be used to do the linking that Mika wanted (I think it was Mika). First, set up a channel server as channel.example.com then, set up channel.example.com/devel, channel.example.com/stable as mirrors. For production sites, set the preferred_mirror to channel.example.com/stable, and for development sites, set it to channel.example.com/devel. In this way, you can securely switch from one repository to another without the possibility of installing the wrong stuff, and it sidesteps the problem of channel name=channel server. It's actually equivalent to PEAR 1.3.x's ability to set master_server to a new value, but is much more structured, as the servers must be in the channel.xml as mirrors. I will definitely be using this feature for testing pearweb, as I can simply create a channel.xml here on my computer that has localhost as a mirror, and then simply set the preferred_mirror to localhost when testing new features. Switching back and forth is easy as pie. I'll be using this to fully implement REST-based remote information for 1.4.0a1 or a2. Greg -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php From tony at tonybibbs.com Wed Dec 29 12:12:22 2004 From: tony at tonybibbs.com (Tony Bibbs) Date: Wed, 29 Dec 2004 11:12:22 -0600 Subject: [geeklog-devel] [Fwd: please help me about geeklog] Message-ID: <41D2E576.2070203@tonybibbs.com> Marco, Questions like this are best suited for our Mailing Lists. Based on what you said, it sounds like your server does not have PEAR::Mail installed. So you will need to either get your server admin to install that PEAR package using "pear install Mail" from the command line or, if they won't do that for you, you will need to change $_CONF['have_pear'] to false and then manually put PEAR::Mail in the pear directory in your Geeklog 1.3.x tree. --Tony -------- Original Message -------- Subject: please help me about geeklog Date: Wed, 29 Dec 2004 17:56:14 +0100 (CET) From: Reply-To: To: tony at tonybibbs.com dear Tony Bibbs | I have a proble with the configuration of geeklog. I have installed geeklock on the server, but there is a proble when i try to change the password og administrator, this is the message of the server: Warning: com_isemail(Mail/RFC822.php): failed to open stream: No such file or directory in c:\programmi\easyphp1-7\www\mio\geeklog-1.3.10rc2\public_html\lib- common.php on line 3354 Fatal error: com_isemail(): Failed opening required 'Mail/RFC822.php' (include_path='.; C:\Programmi\EasyPHP1-7\php\pear\') in c:\programmi\easyphp1-7\www\mio\geeklog-1.3.10rc2\public_html\lib- common.php on line 3354 (this is on my personal server with Easyphp but is the same on the real server) The problem is that i can't agreed use PEAR the server automatically change the variables like this: $_CONF['have_pear'] = true; so, what can I do? Please help me ........ THANKS A LOT. MARCO From dirk at haun-online.de Thu Dec 30 04:00:11 2004 From: dirk at haun-online.de (Dirk Haun) Date: Thu, 30 Dec 2004 10:00:11 +0100 Subject: [geeklog-devel] New Santy worm and impact on Geeklog sites Message-ID: <20041230090011.6256@smtp.haun-online.de> As Tom pointed out in this thread: , geeklog.net has been going slow for the last few days. A quick peek at the logfile seems to point at that new variant of the Santy worm as the culprit. Yesterday's logfile has more than twice the amount of requests than on a normal day. If you can, do a "tail -f access_log" on your server, sit back and enjoy the show. It's amazing. Here's a tip from my web hoster's support forum: RewriteEngine On RewriteCond %{QUERY_STRING} ^(.*)wget\%20 [OR] RewriteCond %{QUERY_STRING} ^(.*)echr(.*) [OR] RewriteCond %{QUERY_STRING} ^(.*)esystem(.*) [OR] RewriteCond %{QUERY_STRING} ^(.*)highlight=\%2527 [OR] RewriteCond %{HTTP_COOKIE}% s:(.*):\%22test1\%22\%3b RewriteRule ^.*$ http://127.0.0.1/ [L,R=301] I'm using that on geeklog.net now. We'll see if it helps ... bye, Dirk -- http://www.haun-online.de/ http://www.macosx-faq.de/
{translate('Username')}: