From tomw at pigstye.net  Thu Jul  1 10:35:29 2004
From: tomw at pigstye.net (Tom Willett)
Date: Thu, 1 Jul 2004 14:35:29 +0000
Subject: [geeklog-devel] Geeklog Documentation
Message-ID: <20040701143311.M47233@pigstye.net>

Tony,

I set up the Wiki to point to both the 1.3x Geeklog Documentation and added 
a new Geeklog 2x tree.  I did not enter a table of contents, but can clone 
the 1.3x tree if you like.

--
Tom Willett
tomw at pigstye.net



From tony at tonybibbs.com  Thu Jul  1 17:31:52 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Thu, 01 Jul 2004 16:31:52 -0500
Subject: [geeklog-devel] AEPasswordGenerator.class.php
Message-ID: <40E482C8.7070701@tonybibbs.com>

Vinny, just an FYI that I have finally updated the Auth_Enterprise 
password generator to use your code.  One noteable change is I moved 
all  the password rule configuration to their own file 
AEPasswordRules.php.  Doing so will keep AEServerConfig.php clean and 
yet allow real hacks to go in and change the password rule regex's 
whenever they want.

--Tony


From tony at tonybibbs.com  Fri Jul  2 17:29:25 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Fri, 02 Jul 2004 16:29:25 -0500
Subject: [geeklog-devel] Object Relational Mapping in PHP5
Message-ID: <40E5D3B5.8090701@tonybibbs.com>

Worth looking into for GL2

http://propel.phpdb.org/

We use something homegrown that does a much shittier job here at work.

--Tony




From tony at tonybibbs.com  Sat Jul  3 16:19:01 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Sat, 03 Jul 2004 15:19:01 -0500
Subject: [geeklog-devel] Auth_Enterprise Beta Released
Message-ID: <40E714B5.6060503@tonybibbs.com>

I was a little behind getting the Auth_Enterprise beta out but, finally, 
it is available for testing.  Keep in mind this was accepted as a PEAR 
package so you can simply use "pear install Auth_Enterprise-beta" to get 
a copy.  This currently requires PHP5 for both the client and server.  
Input and feedback is appreciated.

The next version will add the PHP4 client, Java client and Mono/.net 
client as well as SOAP support.

--Tony


From geeklog at langfamily.ca  Sat Jul  3 17:10:30 2004
From: geeklog at langfamily.ca (Blaine Lang)
Date: Sat, 3 Jul 2004 17:10:30 -0400
Subject: [geeklog-devel] Auth_Enterprise Beta Released
References: <40E714B5.6060503@tonybibbs.com>
Message-ID: <000901c46142$2bf886a0$650a10ac@XPBL2>

Congratulations Tony on this project being accepted as an official PEAR
class.

Blaine
----- Original Message ----- 
From: "Tony Bibbs" <tony at tonybibbs.com>
To: <geeklog-devel at lists.geeklog.net>
Sent: Saturday, July 03, 2004 4:19 PM
Subject: [geeklog-devel] Auth_Enterprise Beta Released


I was a little behind getting the Auth_Enterprise beta out but, finally,
it is available for testing.  Keep in mind this was accepted as a PEAR
package so you can simply use "pear install Auth_Enterprise-beta" to get
a copy.  This currently requires PHP5 for both the client and server.
Input and feedback is appreciated.

The next version will add the PHP4 client, Java client and Mono/.net
client as well as SOAP support.

--Tony
_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel



From tony at tonybibbs.com  Sat Jul  3 18:19:37 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Sat, 03 Jul 2004 17:19:37 -0500
Subject: [geeklog-devel] Auth_Enterprise Beta Released
In-Reply-To: <000901c46142$2bf886a0$650a10ac@XPBL2>
References: <40E714B5.6060503@tonybibbs.com> <000901c46142$2bf886a0$650a10ac@XPBL2>
Message-ID: <40E730F9.9060005@tonybibbs.com>

Lol, well, accepted but then quick rejected. There were a few minor 
coding standard things I had missed and the PEAR Quality Assurance folks 
caught them so I have a number of fixes to make, namely renaming all the 
classes and the files.  Other than that it is OK. 

Should someone try and install this and get some error about it not 
finding the package, it's because they are going to remove it until I 
get the fixes in (which should be sometime tomorrow).

Just a heads-up...

--Tony

Blaine Lang wrote:

>Congratulations Tony on this project being accepted as an official PEAR
>class.
>
>Blaine
>----- Original Message ----- 
>From: "Tony Bibbs" <tony at tonybibbs.com>
>To: <geeklog-devel at lists.geeklog.net>
>Sent: Saturday, July 03, 2004 4:19 PM
>Subject: [geeklog-devel] Auth_Enterprise Beta Released
>
>
>I was a little behind getting the Auth_Enterprise beta out but, finally,
>it is available for testing.  Keep in mind this was accepted as a PEAR
>package so you can simply use "pear install Auth_Enterprise-beta" to get
>a copy.  This currently requires PHP5 for both the client and server.
>Input and feedback is appreciated.
>
>The next version will add the PHP4 client, Java client and Mono/.net
>client as well as SOAP support.
>
>--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 Jul  6 17:38:54 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Tue, 06 Jul 2004 16:38:54 -0500
Subject: [geeklog-devel] Update on Auth_Enterprise
Message-ID: <40EB1BEE.30203@tonybibbs.com>

I've updated CVS back into a semi working state.  I was able to get the 
Authenticate method working with both the localhost and XMLRPC client 
providers.  Naturally I will have to test the other methods but at least 
I'm back to this point. 

--Tony


From tony at tonybibbs.com  Tue Jul  6 17:43:08 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Tue, 06 Jul 2004 16:43:08 -0500
Subject: [geeklog-devel] Update on Auth_Enterprise
In-Reply-To: <40EB1BEE.30203@tonybibbs.com>
References: <40EB1BEE.30203@tonybibbs.com>
Message-ID: <40EB1CEC.8010204@tonybibbs.com>

Sorry, for clarification this work was to make the file names and class 
names PEAR compliant.

--Tony

Tony Bibbs wrote:

> I've updated CVS back into a semi working state.  I was able to get 
> the Authenticate method working with both the localhost and XMLRPC 
> client providers.  Naturally I will have to test the other methods but 
> at least I'm back to this point.
> --Tony
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel



From slord at marelina.com  Wed Jul  7 00:59:20 2004
From: slord at marelina.com (Simon Lord)
Date: Wed, 7 Jul 2004 00:59:20 -0400
Subject: [geeklog-devel] Homeonly block
Message-ID: <67DDA972-CFD2-11D8-B78D-003065C030F2@marelina.com>

I just created a block for the right side and want it to appear in 
"Homeonly".  Nothing happens though, it works when set to any Topic or 
to "All" but not when set to "Homeonly".

This some kind of lingering bug?  I still have this problem with GL 
1.3.7 and was not expecting it to still be around in the current 
release.

Sincerely,
Simon



From slord at marelina.com  Wed Jul  7 01:09:25 2004
From: slord at marelina.com (Simon Lord)
Date: Wed, 7 Jul 2004 01:09:25 -0400
Subject: [geeklog-devel] Blocks again...
Message-ID: <D0812184-CFD3-11D8-B78D-003065C030F2@marelina.com>

Still on blocks, was there never an update that allowed us to make a 
block and assign it to multiple topics?  This would really cut down on 
the number of blocks I'll need to make to support the current "1 block 
= all topics/1 topic" model.

And my note that I can't assign a block to just the homepage stands.

Sincerely,
Simon



From tony at tonybibbs.com  Wed Jul  7 09:48:19 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Wed, 07 Jul 2004 08:48:19 -0500
Subject: [geeklog-devel] Blocks again...
In-Reply-To: <D0812184-CFD3-11D8-B78D-003065C030F2@marelina.com>
References: <D0812184-CFD3-11D8-B78D-003065C030F2@marelina.com>
Message-ID: <40EBFF23.5080202@tonybibbs.com>

No, this was never done.  I agree, at some point we should do that.

Simon Lord wrote:

> Still on blocks, was there never an update that allowed us to make a 
> block and assign it to multiple topics?  This would really cut down on 
> the number of blocks I'll need to make to support the current "1 block 
> = all topics/1 topic" model.
>
> And my note that I can't assign a block to just the homepage stands.
>
> Sincerely,
> Simon
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel



From vfuria at gmail.com  Wed Jul  7 10:32:22 2004
From: vfuria at gmail.com (Vincent Furia)
Date: Wed, 7 Jul 2004 10:32:22 -0400
Subject: [geeklog-devel] Blocks again...
In-Reply-To: <40EBFF23.5080202@tonybibbs.com>
References: <D0812184-CFD3-11D8-B78D-003065C030F2@marelina.com> <40EBFF23.5080202@tonybibbs.com>
Message-ID: <8319e2d604070707323d24dcc2@mail.gmail.com>

Before we go through and implement this (assigning blocks to multiple
topics) we should make sure that we have an idea for a decent user
interface.  Otherwise it could make the block admin page very
confusing.

As to your other block problem Simon: I have a normal block set to
display "home only" (on the right side) and it works correctly (with
geeklog-1.3.9sr1 and geeklog-1.3cvs).

-Vinny

On Wed, 07 Jul 2004 08:48:19 -0500, Tony Bibbs <tony at tonybibbs.com> wrote:
> No, this was never done.  I agree, at some point we should do that.
> 
> 
> 
> Simon Lord wrote:
> 
> > Still on blocks, was there never an update that allowed us to make a
> > block and assign it to multiple topics?  This would really cut down on
> > the number of blocks I'll need to make to support the current "1 block
> > = all topics/1 topic" model.
> >
> > And my note that I can't assign a block to just the homepage stands.
> >
> > 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
>


From slord at marelina.com  Wed Jul  7 11:18:02 2004
From: slord at marelina.com (Simon Lord)
Date: Wed, 7 Jul 2004 11:18:02 -0400
Subject: [geeklog-devel] Blocks again...
In-Reply-To: <8319e2d604070707323d24dcc2@mail.gmail.com>
References: <D0812184-CFD3-11D8-B78D-003065C030F2@marelina.com> <40EBFF23.5080202@tonybibbs.com> <8319e2d604070707323d24dcc2@mail.gmail.com>
Message-ID: <D6DB66B3-D028-11D8-B78D-003065C030F2@marelina.com>

Is this an sr1 fix?  I have 1.3.9 installed and it most definately does 
not work.  You can contact me off-list and I'll give you the site 
location and login to try it out yourself.



On Jul 7, 2004, at 10:32 AM, Vincent Furia wrote:

> As to your other block problem Simon: I have a normal block set to
> display "home only" (on the right side) and it works correctly (with
> geeklog-1.3.9sr1 and geeklog-1.3cvs).
>
Sincerely,
Simon



From slord at marelina.com  Wed Jul  7 11:19:44 2004
From: slord at marelina.com (Simon Lord)
Date: Wed, 7 Jul 2004 11:19:44 -0400
Subject: [geeklog-devel] Blocks again...
In-Reply-To: <8319e2d604070707323d24dcc2@mail.gmail.com>
References: <D0812184-CFD3-11D8-B78D-003065C030F2@marelina.com> <40EBFF23.5080202@tonybibbs.com> <8319e2d604070707323d24dcc2@mail.gmail.com>
Message-ID: <138A626A-D029-11D8-B78D-003065C030F2@marelina.com>

I'd suggest changing the drop down menu list of topics to a multiple 
select listbox.  The change is minor and should not impede any layout 
concerns other than adding a line below the description of that block 
to display the topic names it is assigned to.


On Jul 7, 2004, at 10:32 AM, Vincent Furia wrote:

> Before we go through and implement this (assigning blocks to multiple
> topics) we should make sure that we have an idea for a decent user
> interface.  Otherwise it could make the block admin page very
> confusing.
>
Sincerely,
Simon



From slord at marelina.com  Wed Jul  7 12:04:47 2004
From: slord at marelina.com (Simon Lord)
Date: Wed, 7 Jul 2004 12:04:47 -0400
Subject: [geeklog-devel] Blocks again...
In-Reply-To: <8319e2d604070707323d24dcc2@mail.gmail.com>
References: <D0812184-CFD3-11D8-B78D-003065C030F2@marelina.com> <40EBFF23.5080202@tonybibbs.com> <8319e2d604070707323d24dcc2@mail.gmail.com>
Message-ID: <5E5CB134-D02F-11D8-B78D-003065C030F2@marelina.com>

Vinny, I just updated my site to 1.3.9sr1 and I still cannot get any 
new or existing blocks to appear on the homepage only.  In fact, even 
the "Are you secure?" block simply does not appear.  This is with the 
shipping themes and with my theme in development.

I can see why you think this works, I tested it on geeklog.net and it 
does work there.  This is like magic to me as it simply does NOT work 
on my server.  I don't see how my setup would contribute to just this 
one setting not working but it is very frustrating to see it NOT work 
on a new install on my server while is does work for you and 
geeklog.net.

Thoughts?


On Jul 7, 2004, at 10:32 AM, Vincent Furia wrote:

> Before we go through and implement this (assigning blocks to multiple
> topics) we should make sure that we have an idea for a decent user
> interface.  Otherwise it could make the block admin page very
> confusing.
>
> As to your other block problem Simon: I have a normal block set to
> display "home only" (on the right side) and it works correctly (with
> geeklog-1.3.9sr1 and geeklog-1.3cvs).
>
> -Vinny
>
> On Wed, 07 Jul 2004 08:48:19 -0500, Tony Bibbs <tony at tonybibbs.com> 
> wrote:
>> No, this was never done.  I agree, at some point we should do that.
>>
>>
>>
>> Simon Lord wrote:
>>
>>> Still on blocks, was there never an update that allowed us to make a
>>> block and assign it to multiple topics?  This would really cut down 
>>> on
>>> the number of blocks I'll need to make to support the current "1 
>>> block
>>> = all topics/1 topic" model.
>>>
>>> And my note that I can't assign a block to just the homepage stands.
>>>
>>> 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
>>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>
>
Sincerely,
Simon



From slord at marelina.com  Wed Jul  7 12:53:54 2004
From: slord at marelina.com (Simon Lord)
Date: Wed, 7 Jul 2004 12:53:54 -0400
Subject: [geeklog-devel] Blocks again...
In-Reply-To: <5E5CB134-D02F-11D8-B78D-003065C030F2@marelina.com>
References: <D0812184-CFD3-11D8-B78D-003065C030F2@marelina.com> <40EBFF23.5080202@tonybibbs.com> <8319e2d604070707323d24dcc2@mail.gmail.com> <5E5CB134-D02F-11D8-B78D-003065C030F2@marelina.com>
Message-ID: <3B400956-D036-11D8-9188-003065C030F2@marelina.com>

Vinny, as an extra measure I just installed 1.3.9sr1 FRESH on my system 
*at home* and I cannot set any block to the homepage only.  Not do the 
ones set by default to appear just on the homepage actually appear.

Whatever fix was applied to solve this bug was a VERY specific fix that 
only works under whatever conditions the author was using.

My server runs RH 7.3 and at home I run OSX 10.3.

So that's two platforms where I cannot set a block to just the homepage 
using a default install with the shipping themes and with my 
development theme.

I'm eagerly awaiting any thoughts on this.



On Jul 7, 2004, at 12:04 PM, Simon Lord wrote:

> Vinny, I just updated my site to 1.3.9sr1 and I still cannot get any 
> new or existing blocks to appear on the homepage only.  In fact, even 
> the "Are you secure?" block simply does not appear.  This is with the 
> shipping themes and with my theme in development.
>
> I can see why you think this works, I tested it on geeklog.net and it 
> does work there.  This is like magic to me as it simply does NOT work 
> on my server.  I don't see how my setup would contribute to just this 
> one setting not working but it is very frustrating to see it NOT work 
> on a new install on my server while is does work for you and 
> geeklog.net.
>
> Thoughts?
>
>
> On Jul 7, 2004, at 10:32 AM, Vincent Furia wrote:
>
>> Before we go through and implement this (assigning blocks to multiple
>> topics) we should make sure that we have an idea for a decent user
>> interface.  Otherwise it could make the block admin page very
>> confusing.
>>
>> As to your other block problem Simon: I have a normal block set to
>> display "home only" (on the right side) and it works correctly (with
>> geeklog-1.3.9sr1 and geeklog-1.3cvs).
>>
>> -Vinny
>>
>> On Wed, 07 Jul 2004 08:48:19 -0500, Tony Bibbs <tony at tonybibbs.com> 
>> wrote:
>>> No, this was never done.  I agree, at some point we should do that.
>>>
>>>
>>>
>>> Simon Lord wrote:
>>>
>>>> Still on blocks, was there never an update that allowed us to make a
>>>> block and assign it to multiple topics?  This would really cut down 
>>>> on
>>>> the number of blocks I'll need to make to support the current "1 
>>>> block
>>>> = all topics/1 topic" model.
>>>>
>>>> And my note that I can't assign a block to just the homepage stands.
>>>>
>>>> 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
>>>
>> _______________________________________________
>> 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
>
>
Sincerely,
Simon



From tomw at pigstye.net  Wed Jul  7 13:56:36 2004
From: tomw at pigstye.net (Tom Willett)
Date: Wed, 7 Jul 2004 17:56:36 +0000
Subject: [geeklog-devel] Blocks again...
In-Reply-To: <3B400956-D036-11D8-9188-003065C030F2@marelina.com>
References: <D0812184-CFD3-11D8-B78D-003065C030F2@marelina.com> <40EBFF23.5080202@tonybibbs.com> <8319e2d604070707323d24dcc2@mail.gmail.com> <5E5CB134-D02F-11D8-B78D-003065C030F2@marelina.com> <3B400956-D036-11D8-9188-003065C030F2@marelina.com>
Message-ID: <20040707175221.M91183@pigstye.net>

As a software developer things like this drive me crazy, everyday.

Just for the record, homeonly blocks work on my sites (all upgrades since at 
least 1.3.6, perhaps the key?) My server is RH 7.2, Mysql 3.23.54, apache 
1.3.22, php 4.1.2.

--
Tom Willett
tomw at pigstye.net

---------- Original Message -----------
From: Simon Lord <slord at marelina.com>
To: geeklog-devel at lists.geeklog.net
Sent: Wed, 7 Jul 2004 12:53:54 -0400
Subject: Re: [geeklog-devel] Blocks again...

> Vinny, as an extra measure I just installed 1.3.9sr1 FRESH on my system 
> *at home* and I cannot set any block to the homepage only.  Not do the 
> ones set by default to appear just on the homepage actually appear.
> 
> Whatever fix was applied to solve this bug was a VERY specific fix that 
> only works under whatever conditions the author was using.
> 
> My server runs RH 7.3 and at home I run OSX 10.3.
> 
> So that's two platforms where I cannot set a block to just the homepage 
> using a default install with the shipping themes and with my 
> development theme.
> 
> I'm eagerly awaiting any thoughts on this.
> 
> On Jul 7, 2004, at 12:04 PM, Simon Lord wrote:
> 
> > Vinny, I just updated my site to 1.3.9sr1 and I still cannot get any 
> > new or existing blocks to appear on the homepage only.  In fact, even 
> > the "Are you secure?" block simply does not appear.  This is with the 
> > shipping themes and with my theme in development.
> >
> > I can see why you think this works, I tested it on geeklog.net and it 
> > does work there.  This is like magic to me as it simply does NOT work 
> > on my server.  I don't see how my setup would contribute to just this 
> > one setting not working but it is very frustrating to see it NOT work 
> > on a new install on my server while is does work for you and 
> > geeklog.net.
> >
> > Thoughts?
> >
> >
> > On Jul 7, 2004, at 10:32 AM, Vincent Furia wrote:
> >
> >> Before we go through and implement this (assigning blocks to multiple
> >> topics) we should make sure that we have an idea for a decent user
> >> interface.  Otherwise it could make the block admin page very
> >> confusing.
> >>
> >> As to your other block problem Simon: I have a normal block set to
> >> display "home only" (on the right side) and it works correctly (with
> >> geeklog-1.3.9sr1 and geeklog-1.3cvs).
> >>
> >> -Vinny
> >>
> >> On Wed, 07 Jul 2004 08:48:19 -0500, Tony Bibbs <tony at tonybibbs.com> 
> >> wrote:
> >>> No, this was never done.  I agree, at some point we should do that.
> >>>
> >>>
> >>>
> >>> Simon Lord wrote:
> >>>
> >>>> Still on blocks, was there never an update that allowed us to make a
> >>>> block and assign it to multiple topics?  This would really cut down 
> >>>> on
> >>>> the number of blocks I'll need to make to support the current "1 
> >>>> block
> >>>> = all topics/1 topic" model.
> >>>>
> >>>> And my note that I can't assign a block to just the homepage stands.
> >>>>
> >>>> 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
> >>>
> >> _______________________________________________
> >> 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
> >
> >
> Sincerely,
> Simon
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
------- End of Original Message -------



From dirk at haun-online.de  Wed Jul  7 14:01:48 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Wed, 7 Jul 2004 20:01:48 +0200
Subject: [geeklog-devel] Blocks again...
In-Reply-To: <3B400956-D036-11D8-9188-003065C030F2@marelina.com>
References: <3B400956-D036-11D8-9188-003065C030F2@marelina.com>
Message-ID: <20040707190148.3912@smtp.haun-online.de>

Simon,

>My server runs RH 7.3 and at home I run OSX 10.3.
>
>So that's two platforms where I cannot set a block to just the homepage 
>using a default install with the shipping themes and with my 
>development theme.

Works for me on MacOS X 10.3.4, btw.

Anyway, this is probably a server-side issue. As I mentioned on IRC the
other day, we're using some "dirty tricks" to figure out the current URL.
It's possible that your server(s) are configured somewhat differently and
don't supply all the information we use ...

I'm the first to admit that the code is ugly but there didn't seem to be
an easier way at the time it was written. I also remember a debugging
session on IRC with Blaine, trying to get this stuff working with the
Zeus webserver :-/

Can you upload a file with <?php phpinfo() ?> in it on one of those
servers and PM me the URL? I'll see what I can do ...

bye, Dirk


-- 
http://www.haun-online.de/
http://www.haun.info/



From dirk at haun-online.de  Wed Jul  7 14:05:35 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Wed, 7 Jul 2004 20:05:35 +0200
Subject: [geeklog-devel] Blocks again...
In-Reply-To: <8319e2d604070707323d24dcc2@mail.gmail.com>
References: <8319e2d604070707323d24dcc2@mail.gmail.com>
Message-ID: <20040707190535.18885@smtp.haun-online.de>

Vinny,

>Before we go through and implement this (assigning blocks to multiple
>topics) we should make sure that we have an idea for a decent user
>interface.  Otherwise it could make the block admin page very
>confusing.

Simon already mentioned multi-select listboxes. A list of checkboxes may
be another alternative.

Actually, my main concern here is with the representation of this
information in the database. The topics have a topic id of up to 20
characters. Instead of one topic, we now need to store a list of topics.
Any suggestions?

The topics for the daily digest are currently stored in a VARCHAR(255) -
which means that you can have only around 10 topics there, before we run
out of space (and that case isn't even handled at the moment). So
whatever we come up with for the blocks should also be used there ...

bye, Dirk


-- 
http://www.haun-online.de/
http://mypod.de/



From slord at marelina.com  Wed Jul  7 14:17:53 2004
From: slord at marelina.com (Simon Lord)
Date: Wed, 7 Jul 2004 14:17:53 -0400
Subject: [geeklog-devel] Blocks again...
In-Reply-To: <20040707190148.3912@smtp.haun-online.de>
References: <3B400956-D036-11D8-9188-003065C030F2@marelina.com> <20040707190148.3912@smtp.haun-online.de>
Message-ID: <F6429CFA-D041-11D8-9188-003065C030F2@marelina.com>

Ahhh, I run ZEUS which could possibly be the conflicting nexus of my 
problems.  I'll get that phpinfo out to you now...



On Jul 7, 2004, at 2:01 PM, Dirk Haun wrote:

> Simon,
>
>> My server runs RH 7.3 and at home I run OSX 10.3.
>>
>> So that's two platforms where I cannot set a block to just the 
>> homepage
>> using a default install with the shipping themes and with my
>> development theme.
>
> Works for me on MacOS X 10.3.4, btw.
>
> Anyway, this is probably a server-side issue. As I mentioned on IRC the
> other day, we're using some "dirty tricks" to figure out the current 
> URL.
> It's possible that your server(s) are configured somewhat differently 
> and
> don't supply all the information we use ...
>
> I'm the first to admit that the code is ugly but there didn't seem to 
> be
> an easier way at the time it was written. I also remember a debugging
> session on IRC with Blaine, trying to get this stuff working with the
> Zeus webserver :-/
>
> Can you upload a file with <?php phpinfo() ?> in it on one of those
> servers and PM me the URL? I'll see what I can do ...
>
> bye, Dirk
>
>
> -- 
> 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
>
>
Sincerely,
Simon



From tony at tonybibbs.com  Wed Jul  7 14:49:01 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Wed, 07 Jul 2004 13:49:01 -0500
Subject: [geeklog-devel] Blocks again...
In-Reply-To: <20040707190535.18885@smtp.haun-online.de>
References: <8319e2d604070707323d24dcc2@mail.gmail.com> <20040707190535.18885@smtp.haun-online.de>
Message-ID: <40EC459D.8090205@tonybibbs.com>


Dirk Haun wrote:

>Actually, my main concern here is with the representation of this
>information in the database. The topics have a topic id of up to 20
>characters. Instead of one topic, we now need to store a list of topics.
>Any suggestions?
>  
>
You'd want an associative table called block_topic.  It would have the 
block_id and topic_id as the primary key. 

I think this might also be a good time to consider getting rid of the 
text-based primary key on the topic table and introduce a new 
auto_increment value.

Just a thought,

--Tony


From tony at tonybibbs.com  Wed Jul  7 14:49:36 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Wed, 07 Jul 2004 13:49:36 -0500
Subject: [geeklog-devel] Blocks again...
In-Reply-To: <F6429CFA-D041-11D8-9188-003065C030F2@marelina.com>
References: <3B400956-D036-11D8-9188-003065C030F2@marelina.com> <20040707190148.3912@smtp.haun-online.de> <F6429CFA-D041-11D8-9188-003065C030F2@marelina.com>
Message-ID: <40EC45C0.1020302@tonybibbs.com>

lol, sure, now he tells us.

Simon Lord wrote:

> Ahhh, I run ZEUS which could possibly be the conflicting nexus of my 
> problems.  I'll get that phpinfo out to you now...
>
>
>
> On Jul 7, 2004, at 2:01 PM, Dirk Haun wrote:
>
>> Simon,
>>
>>> My server runs RH 7.3 and at home I run OSX 10.3.
>>>
>>> So that's two platforms where I cannot set a block to just the homepage
>>> using a default install with the shipping themes and with my
>>> development theme.
>>
>>
>> Works for me on MacOS X 10.3.4, btw.
>>
>> Anyway, this is probably a server-side issue. As I mentioned on IRC the
>> other day, we're using some "dirty tricks" to figure out the current 
>> URL.
>> It's possible that your server(s) are configured somewhat differently 
>> and
>> don't supply all the information we use ...
>>
>> I'm the first to admit that the code is ugly but there didn't seem to be
>> an easier way at the time it was written. I also remember a debugging
>> session on IRC with Blaine, trying to get this stuff working with the
>> Zeus webserver :-/
>>
>> Can you upload a file with <?php phpinfo() ?> in it on one of those
>> servers and PM me the URL? I'll see what I can do ...
>>
>> bye, Dirk
>>
>>
>> -- 
>> 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
>>
>>
> Sincerely,
> Simon
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel



From dirk at haun-online.de  Wed Jul  7 17:05:30 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Wed, 7 Jul 2004 23:05:30 +0200
Subject: [geeklog-devel] Topics again (was: Blocks again...)
In-Reply-To: <40EC459D.8090205@tonybibbs.com>
References: <40EC459D.8090205@tonybibbs.com>
Message-ID: <20040707220530.18286@smtp.haun-online.de>

Tony,

>I think this might also be a good time to consider getting rid of the 
>text-based primary key on the topic table and introduce a new 
>auto_increment value.

Remind me again what the problem was with the topic id?

I actually think that http://www.geeklog.net/index.php?topic=Geeklog
looks much nicer than http://www.geeklog.net/index.php?topic=42. With
some URL rewriting, this could look even nicer (and probably help a bit
with search engines, too).

We do need to filter the characters for the topic id more thoroughly, though.

bye, Dirk


-- 
http://www.haun-online.de/
http://mypod.de/



From dirk at haun-online.de  Wed Jul  7 17:10:01 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Wed, 7 Jul 2004 23:10:01 +0200
Subject: [geeklog-devel] Blocks again...
In-Reply-To: <20040707190148.3912@smtp.haun-online.de>
References: <20040707190148.3912@smtp.haun-online.de>
Message-ID: <20040707221001.25238@smtp.haun-online.de>

>Anyway, this is probably a server-side issue.

For the record: Geeklog relies on $HTTP_SERVER_VARS['SCRIPT_NAME']
containing the relative URL of the current PHP script (e.g. /index.php).
On Simon's server, however, it always contained /fcgi-bin/php (whatever
that is - looks like the path to the PHP executable).

Using $HTTP_SERVER_VARS['PATH_INFO'] instead fixed it for him. We'll have
to check for that variable, too, then.

Actually, all that code for guessing the current URL could probably
benefit from some refactoring :-/

bye, Dirk


-- 
http://www.haun-online.de/
http://www.haun.info/



From tony at tonybibbs.com  Wed Jul  7 17:51:20 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Wed, 07 Jul 2004 16:51:20 -0500
Subject: [geeklog-devel] Topics again
In-Reply-To: <20040707220530.18286@smtp.haun-online.de>
References: <40EC459D.8090205@tonybibbs.com> <20040707220530.18286@smtp.haun-online.de>
Message-ID: <40EC7058.1070405@tonybibbs.com>

Well, the first big problem is I don't like the idea of using a 
text-based primary key.  Of course, granted that nearly all of GL 
1.3.x's ID's are text based I'd say at least we are consistent ;-)

The other thing I don't like, assuming you can get over text-based ID's, 
is the fact that we allow the value of a primary key to be hand-keyed by 
users.  Another big no-no in my book but all the things I am complaining 
about are legacy things decided before even I was invovled.

As far as URL's, I could care less if they are 'pretty' in a URL.  That, 
come to think of it, is the only benefit of a text-based primary key. 

--Tony

Dirk Haun wrote:

>Tony,
>
>  
>
>>I think this might also be a good time to consider getting rid of the 
>>text-based primary key on the topic table and introduce a new 
>>auto_increment value.
>>    
>>
>
>Remind me again what the problem was with the topic id?
>
>I actually think that http://www.geeklog.net/index.php?topic=Geeklog
>looks much nicer than http://www.geeklog.net/index.php?topic=42. With
>some URL rewriting, this could look even nicer (and probably help a bit
>with search engines, too).
>
>We do need to filter the characters for the topic id more thoroughly, though.
>
>bye, Dirk
>
>
>  
>


From tony at tonybibbs.com  Thu Jul  8 17:48:22 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Thu, 08 Jul 2004 16:48:22 -0500
Subject: [geeklog-devel] Bug Squashing for Hire
Message-ID: <40EDC126.1040204@tonybibbs.com>

This has been done with other projects and mentioned a few times here 
and there but is there any interest in allowing people to bid on bugs.  
The idea is someone finds a bug/issue/feature they need addressed in 
Geeklog and they can go ahead and put a price they are willing to pay to 
get the bug fixed.  I'm only asking about whether people are interested 
in this now, as implementation could have issues (when is payment sent, 
what if payment is never sent, what if payment is sent but issue never 
addressed, etc).

Comments, questions or concerns?

--Tony


From slord at marelina.com  Thu Jul  8 23:10:18 2004
From: slord at marelina.com (Simon Lord)
Date: Thu, 8 Jul 2004 23:10:18 -0400
Subject: [geeklog-devel] Bug Squashing for Hire
In-Reply-To: <40EDC126.1040204@tonybibbs.com>
References: <40EDC126.1040204@tonybibbs.com>
Message-ID: <81994F06-D155-11D8-8CAE-003065C030F2@marelina.com>

I'm all for it.  Been paying you guys to fix bugs for 3 years now...  :)



On Jul 8, 2004, at 5:48 PM, Tony Bibbs wrote:

> This has been done with other projects and mentioned a few times here 
> and there but is there any interest in allowing people to bid on bugs. 
>  The idea is someone finds a bug/issue/feature they need addressed in 
> Geeklog and they can go ahead and put a price they are willing to pay 
> to get the bug fixed.  I'm only asking about whether people are 
> interested in this now, as implementation could have issues (when is 
> payment sent, what if payment is never sent, what if payment is sent 
> but issue never addressed, etc).
>
> Comments, questions or concerns?
>
> --Tony
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>
>
Sincerely,
Simon



From dirk at haun-online.de  Sat Jul 10 04:09:53 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Sat, 10 Jul 2004 10:09:53 +0200
Subject: [geeklog-devel] Bug Squashing for Hire
In-Reply-To: <40EDC126.1040204@tonybibbs.com>
References: <40EDC126.1040204@tonybibbs.com>
Message-ID: <20040710090953.5398@smtp.haun-online.de>

Tony wrote:

>This has been done with other projects and mentioned a few times here 
>and there but is there any interest in allowing people to bid on bugs.  

Obviously, this should not mean that people would now have to pay for
simple bug fixes. Instead, it seems useful (IMHO) for the following scenarios:

1) A bug has been acknowledged but deemed too complicated / too much work
to fix now.

2) Someone needs a fix urgently (and not with the next release in x
months time).

For these cases, I can see this working (and, yes, details like payment
etc. need to be worked out).

It would be nice if our bug tracking software would support this somehow.
FWIW, I've submitted this as a feature request for both GForge and
Mantis. Mantis 0.19 (alpha 1 just came out) will support this now
(haven't looked into it).

The feature request for GForge is still open:
<http://gforge.org/tracker/index.php?func=detail&aid=787&group_id=1&atid=119>

bye, Dirk


-- 
http://www.haun-online.de/
http://www.macosx-faq.de/




From slord at marelina.com  Mon Jul 12 00:44:09 2004
From: slord at marelina.com (Simon Lord)
Date: Mon, 12 Jul 2004 00:44:09 -0400
Subject: [geeklog-devel] ATTN: Dirk
Message-ID: <1D77706D-D3BE-11D8-8CAE-003065C030F2@marelina.com>

Dirk, sometime back you were working on a bug submission module for 
Geeklog (if I remember correctly).  You seemed pretty much done last 
time I saw it and I was wondering where it is and what it's named.  I 
can't find it.

Sincerely,
Simon



From dirk at haun-online.de  Mon Jul 12 02:01:18 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Mon, 12 Jul 2004 08:01:18 +0200
Subject: [geeklog-devel] ATTN: Dirk
In-Reply-To: <1D77706D-D3BE-11D8-8CAE-003065C030F2@marelina.com>
References: <1D77706D-D3BE-11D8-8CAE-003065C030F2@marelina.com>
Message-ID: <20040712070118.5267@smtp.haun-online.de>

Simon,

>Dirk, sometime back you were working on a bug submission module for 
>Geeklog (if I remember correctly).

It's a plugin for support tickets (think help desk), not bug reports. For
bug reports, have a look at Vinny's Mantis integration.


>You seemed pretty much done last 
>time I saw it and I was wondering where it is and what it's named.  I 
>can't find it.

I haven't released it yet. And I'm in the process of rewriting large
portions of it, although I'm pretty much done with "phase 1" now. It's
back in a working state now, although I have more ideas that I want to
implement. Email me if you're interested ...

bye, Dirk


-- 
http://www.haun-online.de/
http://mypod.de/



From vfuria at gmail.com  Mon Jul 12 02:18:57 2004
From: vfuria at gmail.com (Vincent Furia)
Date: Mon, 12 Jul 2004 02:18:57 -0400
Subject: [geeklog-devel] ATTN: Dirk
In-Reply-To: <20040712070118.5267@smtp.haun-online.de>
References: <1D77706D-D3BE-11D8-8CAE-003065C030F2@marelina.com> <20040712070118.5267@smtp.haun-online.de>
Message-ID: <8319e2d604071123184225b1d9@mail.gmail.com>

Just a warning:
The Mantis integration has a few problems scaling when there are
thousands of users (on the order of the geeklog.net or larger).  I'm
working on fixing that, but don't expect anything soon. :)

-Vinny

P.S.  Dirk, nice catch on that bug in the Plugin cache.

On Mon, 12 Jul 2004 08:01:18 +0200, Dirk Haun <dirk at haun-online.de> wrote:
> Simon,
> 
> >Dirk, sometime back you were working on a bug submission module for
> >Geeklog (if I remember correctly).
> 
> It's a plugin for support tickets (think help desk), not bug reports. For
> bug reports, have a look at Vinny's Mantis integration.
> 
> 
> >You seemed pretty much done last
> >time I saw it and I was wondering where it is and what it's named.  I
> >can't find it.
> 
> I haven't released it yet. And I'm in the process of rewriting large
> portions of it, although I'm pretty much done with "phase 1" now. It's
> back in a working state now, although I have more ideas that I want to
> implement. Email me if you're interested ...
> 
> bye, Dirk
> 
> 
> --
> http://www.haun-online.de/
> http://mypod.de/
> 
> 
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>


From vfuria at gmail.com  Mon Jul 12 02:18:57 2004
From: vfuria at gmail.com (Vincent Furia)
Date: Mon, 12 Jul 2004 02:18:57 -0400
Subject: [geeklog-devel] ATTN: Dirk
In-Reply-To: <20040712070118.5267@smtp.haun-online.de>
References: <1D77706D-D3BE-11D8-8CAE-003065C030F2@marelina.com> <20040712070118.5267@smtp.haun-online.de>
Message-ID: <8319e2d604071123184225b1d9@mail.gmail.com>

Just a warning:
The Mantis integration has a few problems scaling when there are
thousands of users (on the order of the geeklog.net or larger).  I'm
working on fixing that, but don't expect anything soon. :)

-Vinny

P.S.  Dirk, nice catch on that bug in the Plugin cache.

On Mon, 12 Jul 2004 08:01:18 +0200, Dirk Haun <dirk at haun-online.de> wrote:
> Simon,
> 
> >Dirk, sometime back you were working on a bug submission module for
> >Geeklog (if I remember correctly).
> 
> It's a plugin for support tickets (think help desk), not bug reports. For
> bug reports, have a look at Vinny's Mantis integration.
> 
> 
> >You seemed pretty much done last
> >time I saw it and I was wondering where it is and what it's named.  I
> >can't find it.
> 
> I haven't released it yet. And I'm in the process of rewriting large
> portions of it, although I'm pretty much done with "phase 1" now. It's
> back in a working state now, although I have more ideas that I want to
> implement. Email me if you're interested ...
> 
> bye, Dirk
> 
> 
> --
> http://www.haun-online.de/
> http://mypod.de/
> 
> 
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>


From tomw at pigstye.net  Mon Jul 12 10:02:07 2004
From: tomw at pigstye.net (Tom Willett)
Date: Mon, 12 Jul 2004 14:02:07 +0000
Subject: [geeklog-devel] Spam Plugin
Message-ID: <20040712135801.M45336@pigstye.net>

Just a note to let you know that since the introduction of the SpamX plugin, 
it appears that the comment spam problem has stopped.  I can't believe that 
we have scared them away so easily, but for now I would put the problem on 
the back burner and would not recommend a lot of effort in including the 
functionality in Geeklog.  

I only had one visit after installing the plugin and that is the experience 
of most.  Downloads of the plugin have almost stopped.

--
Tom Willett
tomw at pigstye.net



From tony at tonybibbs.com  Mon Jul 12 10:20:56 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Mon, 12 Jul 2004 09:20:56 -0500
Subject: [geeklog-devel] Spam Plugin
In-Reply-To: <20040712135801.M45336@pigstye.net>
References: <20040712135801.M45336@pigstye.net>
Message-ID: <40F29E48.6070807@tonybibbs.com>


Tom Willett wrote:

>I would put the problem on 
>the back burner and would not recommend a lot of effort in including the 
>functionality in Geeklog.  
>  
>
Aren't we just delaying the inevitable.  All indications are this will 
get worse before it gets better.  Granted we may not have that many 
targetting Geeklog specifically but I think including this is still a 
good idea.  I realize you aren't saying drop it but to simply put it on 
the back burner.  I figured the effort (little) is worth the gain.

Dirk, your thoughts?  I you are still agreeable, I may take a swag at 
integrating it into the default GL installation.

--Tony



From tomw at pigstye.net  Mon Jul 12 11:59:03 2004
From: tomw at pigstye.net (Tom Willett)
Date: Mon, 12 Jul 2004 15:59:03 +0000
Subject: [geeklog-devel] Spam Plugin
In-Reply-To: <40F29E48.6070807@tonybibbs.com>
References: <20040712135801.M45336@pigstye.net> <40F29E48.6070807@tonybibbs.com>
Message-ID: <20040712155744.M10767@pigstye.net>

Wouldn't you know it -- Since I wrote that last email, the spam commenters 
hit me again, course didn't get through.

--
Tom Willett
tomw at pigstye.net

---------- Original Message -----------
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Sent: Mon, 12 Jul 2004 09:20:56 -0500
Subject: Re: [geeklog-devel] Spam Plugin

> Tom Willett wrote:
> 
> >I would put the problem on 
> >the back burner and would not recommend a lot of effort in including the 
> >functionality in Geeklog.  
> >  
> >
> Aren't we just delaying the inevitable.  All indications are this will 
> get worse before it gets better.  Granted we may not have that many 
> targetting Geeklog specifically but I think including this is still a 
> good idea.  I realize you aren't saying drop it but to simply put it on 
> the back burner.  I figured the effort (little) is worth the gain.
> 
> Dirk, your thoughts?  I you are still agreeable, I may take a swag at 
> integrating it into the default GL installation.
> 
> --Tony
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
------- End of Original Message -------



From dirk at haun-online.de  Mon Jul 12 14:02:09 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Mon, 12 Jul 2004 20:02:09 +0200
Subject: [geeklog-devel] Spam Plugin
In-Reply-To: <40F29E48.6070807@tonybibbs.com>
References: <40F29E48.6070807@tonybibbs.com>
Message-ID: <20040712190209.16715@smtp.haun-online.de>

Tony,

>Aren't we just delaying the inevitable.  All indications are this will 
>get worse before it gets better.

I'm with you on this one. When it comes to spam, it can't hurt to prepare
for the worst-case scenario.


>Dirk, your thoughts?  I you are still agreeable, I may take a swag at 
>integrating it into the default GL installation.

My only gripe with the SpamX plugin is that it requires additional files
to be writable. If you can solve that one, then by all means integrate it.

bye, Dirk


-- 
http://www.haun-online.de/
http://geeklog.info/



From tony at tonybibbs.com  Mon Jul 12 14:22:15 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Mon, 12 Jul 2004 13:22:15 -0500
Subject: [geeklog-devel] Spam Plugin
In-Reply-To: <20040712190209.16715@smtp.haun-online.de>
References: <40F29E48.6070807@tonybibbs.com> <20040712190209.16715@smtp.haun-online.de>
Message-ID: <40F2D6D7.4090700@tonybibbs.com>

Funny thing is I havne't even used it.  I've looked into the blacklist 
used and was generally impressed so I will work with Tom to see if we 
can't get rid of the file-write dependency.

Tom, if you get any time, jump into IRC and we can chat.

--Tony

Dirk Haun wrote:

>Tony,
>
>  
>
>>Aren't we just delaying the inevitable.  All indications are this will 
>>get worse before it gets better.
>>    
>>
>
>I'm with you on this one. When it comes to spam, it can't hurt to prepare
>for the worst-case scenario.
>
>
>  
>
>>Dirk, your thoughts?  I you are still agreeable, I may take a swag at 
>>integrating it into the default GL installation.
>>    
>>
>
>My only gripe with the SpamX plugin is that it requires additional files
>to be writable. If you can solve that one, then by all means integrate it.
>
>bye, Dirk
>
>
>  
>


From tony at tonybibbs.com  Mon Jul 12 14:37:24 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Mon, 12 Jul 2004 13:37:24 -0500
Subject: [geeklog-devel] GL2 Article Plugin.  Speak now or forever hold your peace
Message-ID: <40F2DA64.6050103@tonybibbs.com>

FYI, I have posted a request for feature on the GL2 article plugin.

Go here to participate:

http://www.geeklog.net/article.php?story=20040712142246310

--Tony


From dirk at haun-online.de  Mon Jul 12 15:48:33 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Mon, 12 Jul 2004 21:48:33 +0200
Subject: [geeklog-devel] Brainstorming: Admin Toolbox?
Message-ID: <20040712204833.17909@smtp.haun-online.de>

Gentlemen,

I see a need for a set of scripts to do maintenance tasks and such (for
example, I just wrote a tiny script that does an OPTIMIZE TABLE on all
the  tables). It would be nice if there was a simple way to plug these
sorts of scripts into Geeklog without having to make them full-blown plugins.

Ideally, I would like to be able to just drop my script into some
predefined location and have Geeklog pick it up automatically. An admin-
only plugin "lite", so to speak.

I could imagine a link, say, "Site Maintenance" or "Admin Toolbox" (Hi
Tom), in the Admin block, which then presents a list of all the availble
mini-plugins (with a short description?).

I'd like this to be
- easy to install (one file per mini-plugin, one location)
- admin only
- the "wrapper" script could do the actual permission checks, so they
don't have to be coded again in each file

Any good ideas for an API, anyone?

bye, Dirk

P.S. As for the "Admin Toolbox" name: I think Tom's collection of scripts
under that name would also fit nicely into this.


-- 
http://www.haun-online.de/
http://mypod.de/



From tony at tonybibbs.com  Mon Jul 12 16:40:50 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Mon, 12 Jul 2004 15:40:50 -0500
Subject: [geeklog-devel] Brainstorming: Admin Toolbox?
In-Reply-To: <20040712204833.17909@smtp.haun-online.de>
References: <20040712204833.17909@smtp.haun-online.de>
Message-ID: <40F2F752.4020708@tonybibbs.com>

Dirk Haun wrote:

>Gentlemen,
>
>I see a need for a set of scripts to do maintenance tasks and such (for
>example, I just wrote a tiny script that does an OPTIMIZE TABLE on all
>the  tables). It would be nice if there was a simple way to plug these
>sorts of scripts into Geeklog without having to make them full-blown plugins.
>
>Ideally, I would like to be able to just drop my script into some
>predefined location and have Geeklog pick it up automatically. An admin-
>only plugin "lite", so to speak.
>
>I could imagine a link, say, "Site Maintenance" or "Admin Toolbox" (Hi
>Tom), in the Admin block, which then presents a list of all the availble
>mini-plugins (with a short description?).
>  
>
K, I think an simple interface should be implemented.  Also, I'm a bit 
partial to an OO-design so how is this as a stubbed out class:

<?php

class GeeklogScriptlet {
    var $_author = null;
    var $_shortDesc = null;
    var $_longDesc = null;
    var $_version = null;
 
    function userCanRunScript() 
    {
        if (!SEC_inGroup('Root')) {
            return false;
        }
        return true;
    }

    function GeeklogScriptlet()
    {
        $_author = 'John or Jane Doe';
        $_shortDesc = 'Short Description goes here';
        $_longDesc = 'Long Description goes here';
    }

    function getAuthor()
    {
        return $this->_author;
    }

    function getShortDesc()
    {
        return $this->_shortDesc;
    }

    function getLongDesc()
    {
        return $this->_longDesc;
    }
   
    function getVersion()
    {
        return $this-_version;
    }

    function runScript()
    {
        // All the work of the script goes here.
    }
}

?>

>I'd like this to be
>- easy to install (one file per mini-plugin, one location)
>  
>
Using the class above, you could put all scripts in one directory 
outside the webtree or in a database.  Then you would create an main 
admin page e.g. /admin/runScriptlet.php?name=GeeklogScriptlet.  
Naturally the class above is meant to be abstract so people would 
inherit from it and change as needed.  This
will allow the security to be done once, etc.

My vote would be to put the contents of the script in a database to 
avoid permission issues on the files.  Plus by doing this we do advanced 
security checks.  For example, given this sort of stuff can potentially 
do harm, we should notice if this is the first time the script has been 
called and ask if they are sure they want to enable the script. We 
should also give them a chance to review the code at that time. 

--Tony


From dirk at haun-online.de  Mon Jul 12 16:58:29 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Mon, 12 Jul 2004 22:58:29 +0200
Subject: [geeklog-devel] Brainstorming: Admin Toolbox?
In-Reply-To: <40F2F752.4020708@tonybibbs.com>
References: <40F2F752.4020708@tonybibbs.com>
Message-ID: <20040712215829.7348@smtp.haun-online.de>

Tony,

>K, I think an simple interface should be implemented.  Also, I'm a bit 
>partial to an OO-design so how is this as a stubbed out class:

No problem with OO - I've actually expected this to be implemented as a class.


>class GeeklogScriptlet {

First impression is good.


>    function runScript()
>    {
>        // All the work of the script goes here.
>    }

Not sure about this one, but do we want to support more than one function
per scriptlet? Or would those go into separate scriptlets?

Also, what about POST requests? How do they come back into the scriptlet?


>Using the class above, you could put all scripts in one directory 
>outside the webtree or in a database. 

Outside of the webtree makes sense. Not sure about the database, as it
also beats the "simple installation" idea.


>My vote would be to put the contents of the script in a database to 
>avoid permission issues on the files.

I don't really see any file permission issues. The scriptlets are
probably included(?) or they're simple .php files.

Anyway, not bad for a first draft.

bye, Dirk


-- 
http://www.haun-online.de/
http://mypod.de/



From tomw at pigstye.net  Mon Jul 12 17:18:28 2004
From: tomw at pigstye.net (Tom Willett)
Date: Mon, 12 Jul 2004 21:18:28 +0000
Subject: [geeklog-devel] Brainstorming: Admin Toolbox?
In-Reply-To: <40F2F752.4020708@tonybibbs.com>
References: <20040712204833.17909@smtp.haun-online.de> <40F2F752.4020708@tonybibbs.com>
Message-ID: <20040712211102.M87365@pigstye.net>

Looks good to me.

My vote would be to just place the scripts in a specific location.  

The only suggestion that I would make is to make the permissions more 
flexible.  That way if root delegated authority to someone, they too could 
access the script.  Of course this would require either some sort of 
database table to manage the permissions or editing of the script file to 
add them.  The latter is the easiest way.

--
Tom Willett
tomw at pigstye.net

---------- Original Message -----------
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Sent: Mon, 12 Jul 2004 15:40:50 -0500
Subject: Re: [geeklog-devel] Brainstorming: Admin Toolbox?

> Dirk Haun wrote:
> 
> >Gentlemen,
> >
> >I see a need for a set of scripts to do maintenance tasks and such (for
> >example, I just wrote a tiny script that does an OPTIMIZE TABLE on all
> >the  tables). It would be nice if there was a simple way to plug these
> >sorts of scripts into Geeklog without having to make them full-blown 
plugins.
> >
> >Ideally, I would like to be able to just drop my script into some
> >predefined location and have Geeklog pick it up automatically. An admin-
> >only plugin "lite", so to speak.
> >
> >I could imagine a link, say, "Site Maintenance" or "Admin Toolbox" (Hi
> >Tom), in the Admin block, which then presents a list of all the availble
> >mini-plugins (with a short description?).
> >  
> >
> K, I think an simple interface should be implemented.  Also, I'm a bit 
> partial to an OO-design so how is this as a stubbed out class:
> 
> <?php
> 
> class GeeklogScriptlet {
>     var $_author = null;
>     var $_shortDesc = null;
>     var $_longDesc = null;
>     var $_version = null;
> 
>     function userCanRunScript() 
>     {
>         if (!SEC_inGroup('Root')) {
>             return false;
>         }
>         return true;
>     }
> 
>     function GeeklogScriptlet()
>     {
>         $_author = 'John or Jane Doe';
>         $_shortDesc = 'Short Description goes here';
>         $_longDesc = 'Long Description goes here';
>     }
> 
>     function getAuthor()
>     {
>         return $this->_author;
>     }
> 
>     function getShortDesc()
>     {
>         return $this->_shortDesc;
>     }
> 
>     function getLongDesc()
>     {
>         return $this->_longDesc;
>     }
> 
>     function getVersion()
>     {
>         return $this-_version;
>     }
> 
>     function runScript()
>     {
>         // All the work of the script goes here.
>     }
> }
> 
> ?>
> 
> >I'd like this to be
> >- easy to install (one file per mini-plugin, one location)
> >  
> >
> Using the class above, you could put all scripts in one directory 
> outside the webtree or in a database.  Then you would create an main 
> admin page e.g. /admin/runScriptlet.php?name=GeeklogScriptlet.  
> Naturally the class above is meant to be abstract so people would 
> inherit from it and change as needed.  This
> will allow the security to be done once, etc.
> 
> My vote would be to put the contents of the script in a database to 
> avoid permission issues on the files.  Plus by doing this we do advanced 
> security checks.  For example, given this sort of stuff can potentially 
> do harm, we should notice if this is the first time the script has been 
> called and ask if they are sure they want to enable the script. We 
> should also give them a chance to review the code at that time.
> 
> --Tony
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
------- End of Original Message -------



From tomw at pigstye.net  Mon Jul 12 17:22:24 2004
From: tomw at pigstye.net (Tom Willett)
Date: Mon, 12 Jul 2004 21:22:24 +0000
Subject: [geeklog-devel] Brainstorming: Admin Toolbox?
In-Reply-To: <20040712215829.7348@smtp.haun-online.de>
References: <40F2F752.4020708@tonybibbs.com> <20040712215829.7348@smtp.haun-online.de>
Message-ID: <20040712211930.M70293@pigstye.net>

Dirk,

> Not sure about this one, but do we want to support more than one function
> per scriptlet? Or would those go into separate scriptlets?
> 
> Also, what about POST requests? How do they come back into the scriptlet?
> 

No problem with either of these issues -- you can have single or multiple 
scripts in a class -- this is how the spamx plugin is implemented if you 
would like to see an example.

TomW


From dirk at haun-online.de  Mon Jul 12 17:17:08 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Mon, 12 Jul 2004 23:17:08 +0200
Subject: [geeklog-devel] Brainstorming: Admin Toolbox?
In-Reply-To: <20040712211102.M87365@pigstye.net>
References: <20040712211102.M87365@pigstye.net>
Message-ID: <20040712221708.3861@smtp.haun-online.de>

Tom,

>The only suggestion that I would make is to make the permissions more 
>flexible.  That way if root delegated authority to someone, they too could 
>access the script.

I think this function already handles this nicely:

>>     function userCanRunScript() 
>>     {
>>         if (!SEC_inGroup('Root')) {
>>             return false;
>>         }
>>         return true;
>>     }

The scriptlet could implement any authentication it wants here.

bye, Dirk


-- 
http://www.haun-online.de/
http://www.tinyweb.de/



From tomw at pigstye.net  Mon Jul 12 17:38:18 2004
From: tomw at pigstye.net (Tom Willett)
Date: Mon, 12 Jul 2004 21:38:18 +0000
Subject: [geeklog-devel] Brainstorming -- Spam Comment API
Message-ID: <20040712212231.M81090@pigstye.net>

Talking to Tony on irc about the API needed to make the spamx comment plugin 
and related plugins work.  Here are some issues which it should address.

Some background -- I implemented the spamx plugin by renaming the savecomment
() function in comment.php to savecomment1 and implementing the savecomment 
function in the functions inc, thus hijacking the call to savecomment.  The 
question is how to implement a plugin API to address this and other possible 
plugins.

Issue 1:  Since spamx was the only plugin access the savecomment function I 
did not bother to return to the function if I wanted to simply drop the 
comment.  A well behaved plugin should not do this.  It should return some 
error code to the core code for the core code to decide what to do with it.

Issue 2: What about plugins that might want to alter the comment text and 
return it to the savecomment function?

Issue 3: What about a plugin that might want to do something with the 
comment (like moderation) depending on what other plugins had found.

This may be two different APIs depending on how its handled.

By the way the same issues could apply to stories and we may want to 
consider a similiar api for stories.  One plugin that might implement both 
the comment and story APIs would be a smiley plugin.

Thoughts?


--
Tom Willett
tomw at pigstye.net



From tomw at pigstye.net  Mon Jul 12 17:39:52 2004
From: tomw at pigstye.net (Tom Willett)
Date: Mon, 12 Jul 2004 21:39:52 +0000
Subject: [geeklog-devel] Brainstorming: Admin Toolbox?
In-Reply-To: <20040712221708.3861@smtp.haun-online.de>
References: <20040712211102.M87365@pigstye.net> <20040712221708.3861@smtp.haun-online.de>
Message-ID: <20040712213859.M8804@pigstye.net>

I understood that function as part of the base class.

--
Tom Willett
tomw at pigstye.net

---------- Original Message -----------
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Sent: Mon, 12 Jul 2004 23:17:08 +0200
Subject: Re: [geeklog-devel] Brainstorming: Admin Toolbox?

> Tom,
> 
> >The only suggestion that I would make is to make the permissions more 
> >flexible.  That way if root delegated authority to someone, they too 
could 
> >access the script.
> 
> I think this function already handles this nicely:
> 
> >>     function userCanRunScript() 
> >>     {
> >>         if (!SEC_inGroup('Root')) {
> >>             return false;
> >>         }
> >>         return true;
> >>     }
> 
> The scriptlet could implement any authentication it wants here.
> 
> 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
------- End of Original Message -------



From tony at tonybibbs.com  Mon Jul 12 17:47:21 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Mon, 12 Jul 2004 16:47:21 -0500
Subject: [geeklog-devel] Brainstorming: Admin Toolbox?
In-Reply-To: <20040712215829.7348@smtp.haun-online.de>
References: <40F2F752.4020708@tonybibbs.com> <20040712215829.7348@smtp.haun-online.de>
Message-ID: <40F306E9.60700@tonybibbs.com>

>Not sure about this one, but do we want to support more than one function
>per scriptlet? Or would those go into separate scriptlets?
>  
>
runScriptlet() can act as a proxy method.  It is the starting point for 
processing so you could have:

function runScriptlet()
{
    global $HTTP_POST_VARS;

    if (isset($HTTP_POST_VARS['someVariable'])) {
        $this->_runFunctionA();
    } else {
        $this->_runFunctionB();
    }
}

function _runFunctionA()
{
    // Custom process for handling POST data
}

function _runFunctionB()
{
    // Default (i.e. non-POST) processing
}

>Also, what about POST requests? How do they come back into the scriptlet?
>  
>
Above example should address this too.

>Outside of the webtree makes sense. Not sure about the database, as it
>also beats the "simple installation" idea.
>  
>
Uh, I don't agree.  The only attributes in a database table would be:
script_id(auto_increment)
script_className
script_version
script_author
script_long_desc
script_short_desc
been_ran (bit) -> this indicates the script has been ran at least once
enabled_flag (bit)
[insert security fields here]

All that stuff would come right out of the class definition so the 
installation would be easy:

<?php

// Get tmp file location
$fileToInclude = [..];

// Include it
require_once $fileToInclude;

// Get class name
$className = [...];

// Instantiate class
$myObj = new $className();

// Delete scriptlet if it already exists
DB_query("DELETE FROM {$_TABLES['scriptlet']} WHERE script_className = 
'$className');

//Add it to scriptlet table:
$sql = sprintf("INSERT INTO ? (script_className, script_version, 
script_author, script_long_desc, script_short_desc, been_ran, enabled) 
values ('?','?','?','?','?',?,?)",
    $_TABLES['scriptlet'], $className, $myObj->getVersion(), 
$myObj->getAuthor(), $myObj->getLongDesc(), $myObj->getShortDesc(), 0, 1);
DB_query($sql);

?>

>I don't really see any file permission issues. The scriptlets are
>probably included(?) or they're simple .php files.
>  
>
Well, the directory they'd go in would need to be writeable.  Again, I'd 
prefer the database if for no other than to make upgrades easier, but 
that's just my to cents.

--Tony



From tony at tonybibbs.com  Mon Jul 12 17:50:14 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Mon, 12 Jul 2004 16:50:14 -0500
Subject: [geeklog-devel] Brainstorming: Admin Toolbox?
In-Reply-To: <20040712213859.M8804@pigstye.net>
References: <20040712211102.M87365@pigstye.net> <20040712221708.3861@smtp.haun-online.de> <20040712213859.M8804@pigstye.net>
Message-ID: <40F30796.2090102@tonybibbs.com>

Right, so (and, yes, I'm stating the obvious) if child scriptlets don't 
implement that method then Root is required.  If a child scriptlet wants 
to handle security in a different way they simply override that.

--Tony

Tom Willett wrote:

>I understood that function as part of the base class.
>
>--
>Tom Willett
>tomw at pigstye.net
>
>---------- Original Message -----------
>From: "Dirk Haun" <dirk at haun-online.de>
>To: <geeklog-devel at lists.geeklog.net>
>Sent: Mon, 12 Jul 2004 23:17:08 +0200
>Subject: Re: [geeklog-devel] Brainstorming: Admin Toolbox?
>
>  
>
>>Tom,
>>
>>    
>>
>>>The only suggestion that I would make is to make the permissions more 
>>>flexible.  That way if root delegated authority to someone, they too 
>>>      
>>>
>could 
>  
>
>>>access the script.
>>>      
>>>
>>I think this function already handles this nicely:
>>
>>    
>>
>>>>    function userCanRunScript() 
>>>>    {
>>>>        if (!SEC_inGroup('Root')) {
>>>>            return false;
>>>>        }
>>>>        return true;
>>>>    }
>>>>        
>>>>
>>The scriptlet could implement any authentication it wants here.
>>
>>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
>>    
>>
>------- End of Original Message -------
>
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>  
>


From dirk at haun-online.de  Wed Jul 14 15:04:05 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Wed, 14 Jul 2004 21:04:05 +0200
Subject: [geeklog-devel] FYI: Geeklog and PHP 5.0.0
Message-ID: <20040714200405.19377@smtp.haun-online.de>

Just wanted to mention that I've installed Geeklog 1.3.9sr1 on my old
iBook, running PHP 5.0.0 and MySQL 4.1.3-beta. Haven't done much with it
yet, but so far no apparent problems :-)

bye, Dirk


-- 
http://www.haun-online.de/
http://www.haun.info/



From tony at tonybibbs.com  Wed Jul 14 15:30:34 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Wed, 14 Jul 2004 14:30:34 -0500
Subject: [geeklog-devel] FYI: Geeklog and PHP 5.0.0
In-Reply-To: <20040714200405.19377@smtp.haun-online.de>
References: <20040714200405.19377@smtp.haun-online.de>
Message-ID: <40F589DA.6050704@tonybibbs.com>

Yeah, I think this confirms an earlier message from Vinny.  I too 
haven't had any problems.  Problems can, however, occur if E_STRICT is 
the reporting level.

--Tony

Dirk Haun wrote:

>Just wanted to mention that I've installed Geeklog 1.3.9sr1 on my old
>iBook, running PHP 5.0.0 and MySQL 4.1.3-beta. Haven't done much with it
>yet, but so far no apparent problems :-)
>
>bye, Dirk
>
>
>  
>


From slord at marelina.com  Thu Jul 15 09:42:21 2004
From: slord at marelina.com (Simon Lord)
Date: Thu, 15 Jul 2004 09:42:21 -0400
Subject: [geeklog-devel] Search result...
Message-ID: <CBEF7BB2-D664-11D8-8CAE-003065C030F2@marelina.com>

Does anyone have the code which displays the search results in Geeklog  
as they do on macfixit.com?  I like the fact that it grabs a few lines  
of the result in question etc.  macosxhints.com uses the same  
formatting so I'm assuming this is a hack/edit being passed around from  
one site admin to another and not actually in CVS.  A link to the  
desirable search result *formatting* I'm looking for is below.

http://www.macfixit.com/search.php? 
query=Transmit&mode=search&type=stories&keyType=all&platform=Mac+OSX

Sincerely,
Simon



From dwight at trumbower.com  Thu Jul 15 11:58:35 2004
From: dwight at trumbower.com (dwight at trumbower.com)
Date: Thu, 15 Jul 2004 10:58:35 -0500 (EST)
Subject: [geeklog-devel] Search result...
In-Reply-To: <CBEF7BB2-D664-11D8-8CAE-003065C030F2@marelina.com>
References: <CBEF7BB2-D664-11D8-8CAE-003065C030F2@marelina.com>
Message-ID: <4829.192.136.16.3.1089907115.squirrel@trumbower.com>

I know at one time macosxhints.com was paying someone to create a better
search. Don't know if this is the result. You might want to contact Rob,
though I believe he is on this list.

Dwight

> Does anyone have the code which displays the search results in Geeklog
> as they do on macfixit.com?  I like the fact that it grabs a few lines
> of the result in question etc.  macosxhints.com uses the same
> formatting so I'm assuming this is a hack/edit being passed around from
> one site admin to another and not actually in CVS.  A link to the
> desirable search result *formatting* I'm looking for is below.
>
> http://www.macfixit.com/search.php?
> query=Transmit&mode=search&type=stories&keyType=all&platform=Mac+OSX
>
> Sincerely,
> Simon
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>



From mvonahn at techtracker.com  Thu Jul 15 12:31:52 2004
From: mvonahn at techtracker.com (Marc Von Ahn)
Date: Thu, 15 Jul 2004 09:31:52 -0700
Subject: [geeklog-devel] Search result...
In-Reply-To: <4829.192.136.16.3.1089907115.squirrel@trumbower.com>
References: <CBEF7BB2-D664-11D8-8CAE-003065C030F2@marelina.com> <4829.192.136.16.3.1089907115.squirrel@trumbower.com>
Message-ID: <7A773E32-D67C-11D8-A819-003065C6D1F8@techtracker.com>

The main thing he needed to overcome with the search code was the 
highlighting for search terms.  The Code I provided changed the case of 
the highlighted phrases.  This was a result of a nested regext used to 
prevent adding the highlight span inside of an href tag on the url.  It 
would be interesting to see what Rob's consultant came up with.  The 
bug can be worked around by turning off the highlighting code in the 
story.

Marc

On Jul 15, 2004, at 8:58 AM, dwight at trumbower.com wrote:

> I know at one time macosxhints.com was paying someone to create a 
> better
> search. Don't know if this is the result. You might want to contact 
> Rob,
> though I believe he is on this list.
>
> Dwight
>
>> Does anyone have the code which displays the search results in Geeklog
>> as they do on macfixit.com?  I like the fact that it grabs a few lines
>> of the result in question etc.  macosxhints.com uses the same
>> formatting so I'm assuming this is a hack/edit being passed around 
>> from
>> one site admin to another and not actually in CVS.  A link to the
>> desirable search result *formatting* I'm looking for is below.
>>
>> http://www.macfixit.com/search.php?
>> query=Transmit&mode=search&type=stories&keyType=all&platform=Mac+OSX
>>
>> 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



From slord at marelina.com  Thu Jul 15 12:58:06 2004
From: slord at marelina.com (Simon Lord)
Date: Thu, 15 Jul 2004 12:58:06 -0400
Subject: [geeklog-devel] Search result...
In-Reply-To: <7A773E32-D67C-11D8-A819-003065C6D1F8@techtracker.com>
References: <CBEF7BB2-D664-11D8-8CAE-003065C030F2@marelina.com> <4829.192.136.16.3.1089907115.squirrel@trumbower.com> <7A773E32-D67C-11D8-A819-003065C6D1F8@techtracker.com>
Message-ID: <24CB9D9A-D680-11D8-B6B4-003065C030F2@marelina.com>

Geeklog now highlights the search term as well, no idea how long that's 
been in there though.  All I really need is the sql query to return the 
first few sentences of the result like these two sites do.

So marc, how do you do that?  ;)

> The main thing he needed to overcome with the search code was the 
> highlighting for search terms.  The Code I provided changed the case 
> of the highlighted phrases.  This was a result of a nested regext used 
> to prevent adding the highlight span inside of an href tag on the url. 
>  It would be interesting to see what Rob's consultant came up with.  
> The bug can be worked around by turning off the highlighting code in 
> the story.
>
> Marc
>
> On Jul 15, 2004, at 8:58 AM, dwight at trumbower.com wrote:
>
>> I know at one time macosxhints.com was paying someone to create a 
>> better
>> search. Don't know if this is the result. You might want to contact 
>> Rob,
>> though I believe he is on this list.
>>
>> Dwight
>>
>>> Does anyone have the code which displays the search results in 
>>> Geeklog
>>> as they do on macfixit.com?  I like the fact that it grabs a few 
>>> lines
>>> of the result in question etc.  macosxhints.com uses the same
>>> formatting so I'm assuming this is a hack/edit being passed around 
>>> from
>>> one site admin to another and not actually in CVS.  A link to the
>>> desirable search result *formatting* I'm looking for is below.
>>>
>>> http://www.macfixit.com/search.php?
>>> query=Transmit&mode=search&type=stories&keyType=all&platform=Mac+OSX
>>>
>>> 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
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>
>
Sincerely,
Simon



From tony at tonybibbs.com  Thu Jul 15 13:47:19 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Thu, 15 Jul 2004 12:47:19 -0500
Subject: [geeklog-devel] Search result...
In-Reply-To: <24CB9D9A-D680-11D8-B6B4-003065C030F2@marelina.com>
References: <CBEF7BB2-D664-11D8-8CAE-003065C030F2@marelina.com> <4829.192.136.16.3.1089907115.squirrel@trumbower.com> <7A773E32-D67C-11D8-A819-003065C6D1F8@techtracker.com> <24CB9D9A-D680-11D8-B6B4-003065C030F2@marelina.com>
Message-ID: <40F6C327.6050305@tonybibbs.com>

There was the concept of 'expanded search results' in the work from 
Marc.  I took that out because I wanted to get the highlighting working 
first (last I knew I thought a few minor bugs related to highlighting 
existed).  Adding expanded search would also require notice to plugin 
developers as it would require them to add code if they want to utilize 
that feature.

--Tony

Simon Lord wrote:

> Geeklog now highlights the search term as well, no idea how long 
> that's been in there though.  All I really need is the sql query to 
> return the first few sentences of the result like these two sites do.
>
> So marc, how do you do that?  ;)
>
>> The main thing he needed to overcome with the search code was the 
>> highlighting for search terms.  The Code I provided changed the case 
>> of the highlighted phrases.  This was a result of a nested regext 
>> used to prevent adding the highlight span inside of an href tag on 
>> the url.  It would be interesting to see what Rob's consultant came 
>> up with.  The bug can be worked around by turning off the 
>> highlighting code in the story.
>>
>> Marc
>>
>> On Jul 15, 2004, at 8:58 AM, dwight at trumbower.com wrote:
>>
>>> I know at one time macosxhints.com was paying someone to create a 
>>> better
>>> search. Don't know if this is the result. You might want to contact 
>>> Rob,
>>> though I believe he is on this list.
>>>
>>> Dwight
>>>
>>>> Does anyone have the code which displays the search results in Geeklog
>>>> as they do on macfixit.com?  I like the fact that it grabs a few lines
>>>> of the result in question etc.  macosxhints.com uses the same
>>>> formatting so I'm assuming this is a hack/edit being passed around 
>>>> from
>>>> one site admin to another and not actually in CVS.  A link to the
>>>> desirable search result *formatting* I'm looking for is below.
>>>>
>>>> http://www.macfixit.com/search.php?
>>>> query=Transmit&mode=search&type=stories&keyType=all&platform=Mac+OSX
>>>>
>>>> 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
>>
>>
>> _______________________________________________
>> 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  Thu Jul 15 13:58:43 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Thu, 15 Jul 2004 12:58:43 -0500
Subject: [geeklog-devel] Search result...
In-Reply-To: <40F6C327.6050305@tonybibbs.com>
References: <CBEF7BB2-D664-11D8-8CAE-003065C030F2@marelina.com> <4829.192.136.16.3.1089907115.squirrel@trumbower.com> <7A773E32-D67C-11D8-A819-003065C6D1F8@techtracker.com> <24CB9D9A-D680-11D8-B6B4-003065C030F2@marelina.com> <40F6C327.6050305@tonybibbs.com>
Message-ID: <40F6C5D3.9020806@tonybibbs.com>

Also, for performance reasons, I'd recommend any expanded searches (when 
implemented) to be turned off by default.

--Tony

Tony Bibbs wrote:

> There was the concept of 'expanded search results' in the work from 
> Marc.  I took that out because I wanted to get the highlighting 
> working first (last I knew I thought a few minor bugs related to 
> highlighting existed).  Adding expanded search would also require 
> notice to plugin developers as it would require them to add code if 
> they want to utilize that feature.
>
> --Tony
>
> Simon Lord wrote:
>
>> Geeklog now highlights the search term as well, no idea how long 
>> that's been in there though.  All I really need is the sql query to 
>> return the first few sentences of the result like these two sites do.
>>
>> So marc, how do you do that?  ;)
>>
>>> The main thing he needed to overcome with the search code was the 
>>> highlighting for search terms.  The Code I provided changed the case 
>>> of the highlighted phrases.  This was a result of a nested regext 
>>> used to prevent adding the highlight span inside of an href tag on 
>>> the url.  It would be interesting to see what Rob's consultant came 
>>> up with.  The bug can be worked around by turning off the 
>>> highlighting code in the story.
>>>
>>> Marc
>>>
>>> On Jul 15, 2004, at 8:58 AM, dwight at trumbower.com wrote:
>>>
>>>> I know at one time macosxhints.com was paying someone to create a 
>>>> better
>>>> search. Don't know if this is the result. You might want to contact 
>>>> Rob,
>>>> though I believe he is on this list.
>>>>
>>>> Dwight
>>>>
>>>>> Does anyone have the code which displays the search results in 
>>>>> Geeklog
>>>>> as they do on macfixit.com?  I like the fact that it grabs a few 
>>>>> lines
>>>>> of the result in question etc.  macosxhints.com uses the same
>>>>> formatting so I'm assuming this is a hack/edit being passed around 
>>>>> from
>>>>> one site admin to another and not actually in CVS.  A link to the
>>>>> desirable search result *formatting* I'm looking for is below.
>>>>>
>>>>> http://www.macfixit.com/search.php?
>>>>> query=Transmit&mode=search&type=stories&keyType=all&platform=Mac+OSX
>>>>>
>>>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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



From mvonahn at techtracker.com  Thu Jul 15 09:52:29 2004
From: mvonahn at techtracker.com (Marc)
Date: Thu, 15 Jul 2004 06:52:29 -0700
Subject: [geeklog-devel] Search result...
In-Reply-To: <CBEF7BB2-D664-11D8-8CAE-003065C030F2@marelina.com>
References: <CBEF7BB2-D664-11D8-8CAE-003065C030F2@marelina.com>
Message-ID: <3695B0DC-D666-11D8-BF1C-003065C8311C@techtracker.com>

I might have that somewhere.  Though I thought it had been checked into  
cvs a while ago as an option in the config file, something like  
advancedsearchformatting
On Jul 15, 2004, at 6:42 AM, Simon Lord wrote:

> Does anyone have the code which displays the search results in Geeklog  
> as they do on macfixit.com?  I like the fact that it grabs a few lines  
> of the result in question etc.  macosxhints.com uses the same  
> formatting so I'm assuming this is a hack/edit being passed around  
> from one site admin to another and not actually in CVS.  A link to the  
> desirable search result *formatting* I'm looking for is below.
>
> http://www.macfixit.com/search.php? 
> query=Transmit&mode=search&type=stories&keyType=all&platform=Mac+OSX
>
> Sincerely,
> Simon
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel



From slord at marelina.com  Thu Jul 15 21:26:11 2004
From: slord at marelina.com (Simon Lord)
Date: Thu, 15 Jul 2004 21:26:11 -0400
Subject: [geeklog-devel] Search result...
In-Reply-To: <3695B0DC-D666-11D8-BF1C-003065C8311C@techtracker.com>
References: <CBEF7BB2-D664-11D8-8CAE-003065C030F2@marelina.com> <3695B0DC-D666-11D8-BF1C-003065C8311C@techtracker.com>
Message-ID: <1F425E03-D6C7-11D8-B6B4-003065C030F2@marelina.com>

Ahh, I bet it has to do with my template file, I think I may be missing 
a variable which carries the expanded results.  Thanks for the tip.


On Jul 15, 2004, at 9:52 AM, Marc wrote:

> advancedsearchformatting
Sincerely,
Simon



From slord at marelina.com  Thu Jul 15 21:35:31 2004
From: slord at marelina.com (Simon Lord)
Date: Thu, 15 Jul 2004 21:35:31 -0400
Subject: [geeklog-devel] Search result...
In-Reply-To: <1F425E03-D6C7-11D8-B6B4-003065C030F2@marelina.com>
References: <CBEF7BB2-D664-11D8-8CAE-003065C030F2@marelina.com> <3695B0DC-D666-11D8-BF1C-003065C8311C@techtracker.com> <1F425E03-D6C7-11D8-B6B4-003065C030F2@marelina.com>
Message-ID: <6CB71BF3-D6C8-11D8-B6B4-003065C030F2@marelina.com>

Well so much for that.  I was hoping I had improperly updated set of  
thtmls but they are identical.  I also have this in CVS:

//////////////////////////////////////////////////////////
// Indicates if we should expand search results or not.
//     true = show title with summary
//     false = title date author hits on one line
$_CONF['expanded_search_results']  =  true;

// 0: use users max stories per page
// 1: Show all
// any other number is the # of results per page
$_CONF['max_search_results']  =  1;

// maximum length for the summary text for search results should be
$_CONF['summary_length']  =  250;
//////////////////////////////////////////////////////////

... but I don't get any expanded results at all.

Here's a link to see for yourself:

http://www.karbonized.com/max-t/search.php? 
query=Management&type=all&mode=search



On Jul 15, 2004, at 9:26 PM, Simon Lord wrote:

> Ahh, I bet it has to do with my template file, I think I may be  
> missing a variable which carries the expanded results.  Thanks for the  
> tip.
>
>
> On Jul 15, 2004, at 9:52 AM, Marc wrote:
>
>> advancedsearchformatting
> Sincerely,
> Simon
>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>
>
Sincerely,
Simon



From dirk at haun-online.de  Fri Jul 16 02:16:08 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Fri, 16 Jul 2004 08:16:08 +0200
Subject: [geeklog-devel] Search result...
In-Reply-To: <6CB71BF3-D6C8-11D8-B6B4-003065C030F2@marelina.com>
References: <6CB71BF3-D6C8-11D8-B6B4-003065C030F2@marelina.com>
Message-ID: <20040716071608.20680@smtp.haun-online.de>

Simon,

>... but I don't get any expanded results at all.

Your must have overlooked this:

// +---------------------------------
------------------------------------------+
// | SEARCH SETTINGS                                                    
      |
// |                                                                    
      |
// | These aren't really used at the moment - leave as is ...           
      |
// +---------------------------------
------------------------------------------+

bye, Dirk


-- 
http://www.haun-online.de/
http://www.tinyweb.de/




From slord at marelina.com  Fri Jul 16 08:35:56 2004
From: slord at marelina.com (Simon Lord)
Date: Fri, 16 Jul 2004 08:35:56 -0400
Subject: [geeklog-devel] Search result...
In-Reply-To: <20040716071608.20680@smtp.haun-online.de>
References: <6CB71BF3-D6C8-11D8-B6B4-003065C030F2@marelina.com> <20040716071608.20680@smtp.haun-online.de>
Message-ID: <AF646D34-D724-11D8-B6B4-003065C030F2@marelina.com>

Ahh, got it.  Ok.  Thanks big D.



On Jul 16, 2004, at 2:16 AM, Dirk Haun wrote:

> Simon,
>
>> ... but I don't get any expanded results at all.
>
> Your must have overlooked this:
>
> // +---------------------------------
> ------------------------------------------+
> // | SEARCH SETTINGS
>       |
> // |
>       |
> // | These aren't really used at the moment - leave as is ...
>       |
> // +---------------------------------
> ------------------------------------------+
>
> 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
>
>
Sincerely,
Simon



From dirk at haun-online.de  Sat Jul 17 05:53:11 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Sat, 17 Jul 2004 11:53:11 +0200
Subject: [geeklog-devel] Re: Fwd: Expanded Search
Message-ID: <20040717105311.6262@smtp.haun-online.de>

[moving this back here from private email]

Tony wrote:

>Basically, all the work is left on it.  All I have started is the 
>config.php option....

I don't really care if the "expanded search" makes it into CVS any time
soon or not. If anybody wants to do some work on it, feel free, but
otherwise, I don't mind.


>Incidently, if this gets done or  not, the performance of the GL 1.3.x 
>search needs scrutiny.  I can, without much trouble, force the search to 
>error out for taking too long to run on Iowa Outdoors.

Yep, this is much more urgent to fix, as it is pretty embarrassing. IMO,
the solution would be to do paging, i.e. return only a certain amount of
results. I see there's already some code for paging in the search class,
but it probably doesn't do too much yet (or does it)?


>Honestly, I have some clean up on the PDF feature left so given it and 
>the fact I'm working on GL2 stuff I doubt I find the desire to implement 
>the feature.

There are some oddities with the HTML during creation of the PDFs (not
the HTML that goes into the PDF but what's displayed on the site when you
click on the PDF icon). I'll need to collect my thoughts on this and make
a separate post later ...

bye, Dirk


-- 
http://www.haun-online.de/
http://geeklog.info/





From dirk at haun-online.de  Sat Jul 17 08:56:15 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Sat, 17 Jul 2004 14:56:15 +0200
Subject: [geeklog-devel] FYI: Geeklog and PHP 5.0.0
In-Reply-To: <40F589DA.6050704@tonybibbs.com>
References: <40F589DA.6050704@tonybibbs.com>
Message-ID: <20040717135615.1108@smtp.haun-online.de>

Tony wrote:

>Problems can, however, occur if E_STRICT is the reporting level.

Hmm, where exactly? I've just switched to error_reporting = E_STRICT and
have yet to see a single warning message.

Another trap I fell for, though, is the default setting for the "long"
arrays from the php.ini-recommended. It has to be on:

; Whether or not to register the old-style input arrays, HTTP_GET_VARS
; and friends.  If you're not using them, it's recommended to turn them off,
; for performance reasons.
register_long_arrays = On

bye, Dirk


-- 
http://www.haun-online.de/
http://geeklog.info/



From tony at tonybibbs.com  Mon Jul 19 17:06:32 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Mon, 19 Jul 2004 16:06:32 -0500
Subject: [geeklog-devel] Translation stuff for GL2
Message-ID: <40FC37D8.7070803@tonybibbs.com>

Vinny,

Per your request I'm outlining what remains for for GL2's translation 
engine.  First a recap. 

First, I wrote the translation engine from scratch mainly because the 
one in PEAR didn't, at the time, make upgrading to new releases easy on 
translators.  Basically, with each new release, as with 1.3.x, the 
translators have to manually update the new file OR hack a way to merge 
them.  It is probably worth looking at what is in PEAR again to see if 
merging of translation files is supported.  If it is, I could be 
compelled to simply use it.

However, assuming it still doesn't work that way here is what I have done:
1) The combination of getstrings and StringExtractor.class.php currently 
work in PHP5 and parse anything of the form "->translate('[some 
string]')" OR "->translate('[some other string]', '[some section name]]);
2) The data is collected in an array and is outputted to an xml file 
with the following basic structure
<application name="" version="">
    <translator name="" email=""/>
    <translation language="">
        <section name="">
            <entry>
                <string_id></string_id>
                <string></string>
            </entry>
        </section>
    </translation>
A couple of notes about the format.  the section and entry tags can 
repeat.  Also, the string_id is the native language string and the 
string tag is the translated version

Here is what is left:
1) The big issue to iron out is how to incorporate plugins.  My original 
thought was that plugins would each have their own XML file and would 
not share the main Geeklog
     file but given our plugin-centric approach this may not make sense 
anymore.  We may want to consider inserting <plugin> tags around the 
section tags.   Just a though, regardless
     this probably needs some talking outload.  Dirk, any suggestions 
here since you are a big user of the translation stuff?
2) mergeversions needs to be ported to PHP5 and should honor the new 
section tags. Furthermore, it should be written to use the new PHP5 XML 
features
3) We should add optional support of storing the strings in a database.  
To that end, we should add the ability to import the xml files into a 
database table.  Not sure of the best way to do this as there are a few 
options. 
4) similarly Translator.class.php should be ported to PHP5 and use the 
new PHP5 XML parsing features
5) Build an xml schema we can use in mergeversions and in getstrings to 
validate the XML of the translation file.  PHP5 has a built in XML 
validator to help do most of this work.
6) As mentioned, look at StringExtractor.class.php for performance 
improvements.
7) We should look into PEAR::Cache and how it might make the translation 
process faster.  You might want to ask JellyBob (Jon Wood) how 
PEAR::Cache works exactly...while he hasn't committed any time to GL2 
persay, I'm sure he'd be willing to explain it abit.

Anything else?

--Tony



From vfuria at gmail.com  Tue Jul 20 14:04:50 2004
From: vfuria at gmail.com (Vincent Furia)
Date: Tue, 20 Jul 2004 14:04:50 -0400
Subject: [geeklog-devel] Translation stuff for GL2
In-Reply-To: <40FC37D8.7070803@tonybibbs.com>
References: <40FC37D8.7070803@tonybibbs.com>
Message-ID: <8319e2d604072011045c2fdd48@mail.gmail.com>

Tony, JellyBob, and I discussed some possibilities concerning the
translation stuff on IRC today.  We discussed a couple of possible
alternatives to using a custom built translation class.

1.  Use GNU gettext.  We could use gettext to support user selectable
languages for installations that support gettext.  For installations
that don't support gettext we can simply support a single language
decided on during installation (this would not be user selectable).

Things to do: We would have to write a custom script to convert the
default english strings in the php files to the desired, supported
language using the gettext files.  Hence the replacement language
would become the default language in the converted files.  We could
then either have the installer run this conversion script, or else
create downloads for each language (which can be automated).  Since
installations without gettext will already support the default
language (english I presume), we can make the creation of the
translation script a low priority.

Possible problems: upgrades and security releases would need some
planning as non-gettext installs would need files configured for their
language.  A good auto-update system might be able to handle this.

2. Use PEAR::Translation2
This class does most of what we want, include support DB.  

Possible Problems: The downside is it doesn't support merging of
translation versions and is large and cumbersome.

Personally, I like option 1.  If no one agrees that that is a viable
alternative than I think we should skip the PEAR::Translation2 class
(at least for the time being) and use the custom version.

Any feedback?
-Vinny

On Mon, 19 Jul 2004 16:06:32 -0500, Tony Bibbs <tony at tonybibbs.com> wrote:
> Vinny,
> 
> Per your request I'm outlining what remains for for GL2's translation
> engine.  First a recap.
> 
> First, I wrote the translation engine from scratch mainly because the
> one in PEAR didn't, at the time, make upgrading to new releases easy on
> translators.  Basically, with each new release, as with 1.3.x, the
> translators have to manually update the new file OR hack a way to merge
> them.  It is probably worth looking at what is in PEAR again to see if
> merging of translation files is supported.  If it is, I could be
> compelled to simply use it.
> 
> However, assuming it still doesn't work that way here is what I have done:
> 1) The combination of getstrings and StringExtractor.class.php currently
> work in PHP5 and parse anything of the form "->translate('[some
> string]')" OR "->translate('[some other string]', '[some section name]]);
> 2) The data is collected in an array and is outputted to an xml file
> with the following basic structure
> <application name="" version="">
>     <translator name="" email=""/>
>     <translation language="">
>         <section name="">
>             <entry>
>                 <string_id></string_id>
>                 <string></string>
>             </entry>
>         </section>
>     </translation>
> A couple of notes about the format.  the section and entry tags can
> repeat.  Also, the string_id is the native language string and the
> string tag is the translated version
> 
> Here is what is left:
> 1) The big issue to iron out is how to incorporate plugins.  My original
> thought was that plugins would each have their own XML file and would
> not share the main Geeklog
>      file but given our plugin-centric approach this may not make sense
> anymore.  We may want to consider inserting <plugin> tags around the
> section tags.   Just a though, regardless
>      this probably needs some talking outload.  Dirk, any suggestions
> here since you are a big user of the translation stuff?
> 2) mergeversions needs to be ported to PHP5 and should honor the new
> section tags. Furthermore, it should be written to use the new PHP5 XML
> features
> 3) We should add optional support of storing the strings in a database.
> To that end, we should add the ability to import the xml files into a
> database table.  Not sure of the best way to do this as there are a few
> options.
> 4) similarly Translator.class.php should be ported to PHP5 and use the
> new PHP5 XML parsing features
> 5) Build an xml schema we can use in mergeversions and in getstrings to
> validate the XML of the translation file.  PHP5 has a built in XML
> validator to help do most of this work.
> 6) As mentioned, look at StringExtractor.class.php for performance
> improvements.
> 7) We should look into PEAR::Cache and how it might make the translation
> process faster.  You might want to ask JellyBob (Jon Wood) how
> PEAR::Cache works exactly...while he hasn't committed any time to GL2
> persay, I'm sure he'd be willing to explain it abit.
> 
> Anything else?
> 
> --Tony
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>


From tony at tonybibbs.com  Tue Jul 20 14:53:22 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Tue, 20 Jul 2004 13:53:22 -0500
Subject: [geeklog-devel] Translation stuff for GL2
In-Reply-To: <8319e2d604072011045c2fdd48@mail.gmail.com>
References: <40FC37D8.7070803@tonybibbs.com> <8319e2d604072011045c2fdd48@mail.gmail.com>
Message-ID: <40FD6A22.8070208@tonybibbs.com>

I think option 2 is out.  I've peaked at the code and, frankly, I'm not 
impressed. 

I'd be interested to hear from those of you who regularly do 
translations on how option #1 sounds.  Basically what he is saying is 
using option 1 you might have code like this:

gettext('some english string');
gettext('som other english string');

Then you would create the english (en) translation file using xgettext.  
We would then distribute the file to translators.  This is fine and 
dandy for those who have gettext support compiled into PHP.  The first 
issue is is the general adoption of gettext support in PHP such that we 
should just assume it is included?  If so, this is the clear winner.  If 
not then what Vinny was eluding to is we would write a script that would 
take another language file, say german, and we would replace all the 
english based gettext() calls in the .php files and insert the user's 
language of choice.  In otherwords a script would change:

gettext('some english string'); to gettext('some german string');

 In addition to his drawbacks, an additional drawback would be that in 
this instance user's couldn't have their own custom language setting.

--Tony

Vincent Furia wrote:

>Tony, JellyBob, and I discussed some possibilities concerning the
>translation stuff on IRC today.  We discussed a couple of possible
>alternatives to using a custom built translation class.
>
>1.  Use GNU gettext.  We could use gettext to support user selectable
>languages for installations that support gettext.  For installations
>that don't support gettext we can simply support a single language
>decided on during installation (this would not be user selectable).
>
>Things to do: We would have to write a custom script to convert the
>default english strings in the php files to the desired, supported
>language using the gettext files.  Hence the replacement language
>would become the default language in the converted files.  We could
>then either have the installer run this conversion script, or else
>create downloads for each language (which can be automated).  Since
>installations without gettext will already support the default
>language (english I presume), we can make the creation of the
>translation script a low priority.
>
>Possible problems: upgrades and security releases would need some
>planning as non-gettext installs would need files configured for their
>language.  A good auto-update system might be able to handle this.
>
>2. Use PEAR::Translation2
>This class does most of what we want, include support DB.  
>
>Possible Problems: The downside is it doesn't support merging of
>translation versions and is large and cumbersome.
>
>Personally, I like option 1.  If no one agrees that that is a viable
>alternative than I think we should skip the PEAR::Translation2 class
>(at least for the time being) and use the custom version.
>
>Any feedback?
>-Vinny
>
>On Mon, 19 Jul 2004 16:06:32 -0500, Tony Bibbs <tony at tonybibbs.com> wrote:
>  
>
>>Vinny,
>>
>>Per your request I'm outlining what remains for for GL2's translation
>>engine.  First a recap.
>>
>>First, I wrote the translation engine from scratch mainly because the
>>one in PEAR didn't, at the time, make upgrading to new releases easy on
>>translators.  Basically, with each new release, as with 1.3.x, the
>>translators have to manually update the new file OR hack a way to merge
>>them.  It is probably worth looking at what is in PEAR again to see if
>>merging of translation files is supported.  If it is, I could be
>>compelled to simply use it.
>>
>>However, assuming it still doesn't work that way here is what I have done:
>>1) The combination of getstrings and StringExtractor.class.php currently
>>work in PHP5 and parse anything of the form "->translate('[some
>>string]')" OR "->translate('[some other string]', '[some section name]]);
>>2) The data is collected in an array and is outputted to an xml file
>>with the following basic structure
>><application name="" version="">
>>    <translator name="" email=""/>
>>    <translation language="">
>>        <section name="">
>>            <entry>
>>                <string_id></string_id>
>>                <string></string>
>>            </entry>
>>        </section>
>>    </translation>
>>A couple of notes about the format.  the section and entry tags can
>>repeat.  Also, the string_id is the native language string and the
>>string tag is the translated version
>>
>>Here is what is left:
>>1) The big issue to iron out is how to incorporate plugins.  My original
>>thought was that plugins would each have their own XML file and would
>>not share the main Geeklog
>>     file but given our plugin-centric approach this may not make sense
>>anymore.  We may want to consider inserting <plugin> tags around the
>>section tags.   Just a though, regardless
>>     this probably needs some talking outload.  Dirk, any suggestions
>>here since you are a big user of the translation stuff?
>>2) mergeversions needs to be ported to PHP5 and should honor the new
>>section tags. Furthermore, it should be written to use the new PHP5 XML
>>features
>>3) We should add optional support of storing the strings in a database.
>>To that end, we should add the ability to import the xml files into a
>>database table.  Not sure of the best way to do this as there are a few
>>options.
>>4) similarly Translator.class.php should be ported to PHP5 and use the
>>new PHP5 XML parsing features
>>5) Build an xml schema we can use in mergeversions and in getstrings to
>>validate the XML of the translation file.  PHP5 has a built in XML
>>validator to help do most of this work.
>>6) As mentioned, look at StringExtractor.class.php for performance
>>improvements.
>>7) We should look into PEAR::Cache and how it might make the translation
>>process faster.  You might want to ask JellyBob (Jon Wood) how
>>PEAR::Cache works exactly...while he hasn't committed any time to GL2
>>persay, I'm sure he'd be willing to explain it abit.
>>
>>Anything 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 Jul 20 15:01:17 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Tue, 20 Jul 2004 14:01:17 -0500
Subject: [geeklog-devel] Translation stuff for GL2
In-Reply-To: <40FD6A22.8070208@tonybibbs.com>
References: <40FC37D8.7070803@tonybibbs.com> <8319e2d604072011045c2fdd48@mail.gmail.com> <40FD6A22.8070208@tonybibbs.com>
Message-ID: <40FD6BFD.6000500@tonybibbs.com>

If it helps at all, --with-gettext is *not* included in a php build by 
default.

--Tony

Tony Bibbs wrote:

> I think option 2 is out.  I've peaked at the code and, frankly, I'm 
> not impressed.
> I'd be interested to hear from those of you who regularly do 
> translations on how option #1 sounds.  Basically what he is saying is 
> using option 1 you might have code like this:
>
> gettext('some english string');
> gettext('som other english string');
>
> Then you would create the english (en) translation file using 
> xgettext.  We would then distribute the file to translators.  This is 
> fine and dandy for those who have gettext support compiled into PHP.  
> The first issue is is the general adoption of gettext support in PHP 
> such that we should just assume it is included?  If so, this is the 
> clear winner.  If not then what Vinny was eluding to is we would write 
> a script that would take another language file, say german, and we 
> would replace all the english based gettext() calls in the .php files 
> and insert the user's language of choice.  In otherwords a script 
> would change:
>
> gettext('some english string'); to gettext('some german string');
>
> In addition to his drawbacks, an additional drawback would be that in 
> this instance user's couldn't have their own custom language setting.
>
> --Tony
>
> Vincent Furia wrote:
>
>> Tony, JellyBob, and I discussed some possibilities concerning the
>> translation stuff on IRC today.  We discussed a couple of possible
>> alternatives to using a custom built translation class.
>>
>> 1.  Use GNU gettext.  We could use gettext to support user selectable
>> languages for installations that support gettext.  For installations
>> that don't support gettext we can simply support a single language
>> decided on during installation (this would not be user selectable).
>>
>> Things to do: We would have to write a custom script to convert the
>> default english strings in the php files to the desired, supported
>> language using the gettext files.  Hence the replacement language
>> would become the default language in the converted files.  We could
>> then either have the installer run this conversion script, or else
>> create downloads for each language (which can be automated).  Since
>> installations without gettext will already support the default
>> language (english I presume), we can make the creation of the
>> translation script a low priority.
>>
>> Possible problems: upgrades and security releases would need some
>> planning as non-gettext installs would need files configured for their
>> language.  A good auto-update system might be able to handle this.
>>
>> 2. Use PEAR::Translation2
>> This class does most of what we want, include support DB. 
>> Possible Problems: The downside is it doesn't support merging of
>> translation versions and is large and cumbersome.
>>
>> Personally, I like option 1.  If no one agrees that that is a viable
>> alternative than I think we should skip the PEAR::Translation2 class
>> (at least for the time being) and use the custom version.
>>
>> Any feedback?
>> -Vinny
>>
>> On Mon, 19 Jul 2004 16:06:32 -0500, Tony Bibbs <tony at tonybibbs.com> 
>> wrote:
>>  
>>
>>> Vinny,
>>>
>>> Per your request I'm outlining what remains for for GL2's translation
>>> engine.  First a recap.
>>>
>>> First, I wrote the translation engine from scratch mainly because the
>>> one in PEAR didn't, at the time, make upgrading to new releases easy on
>>> translators.  Basically, with each new release, as with 1.3.x, the
>>> translators have to manually update the new file OR hack a way to merge
>>> them.  It is probably worth looking at what is in PEAR again to see if
>>> merging of translation files is supported.  If it is, I could be
>>> compelled to simply use it.
>>>
>>> However, assuming it still doesn't work that way here is what I have 
>>> done:
>>> 1) The combination of getstrings and StringExtractor.class.php 
>>> currently
>>> work in PHP5 and parse anything of the form "->translate('[some
>>> string]')" OR "->translate('[some other string]', '[some section 
>>> name]]);
>>> 2) The data is collected in an array and is outputted to an xml file
>>> with the following basic structure
>>> <application name="" version="">
>>>    <translator name="" email=""/>
>>>    <translation language="">
>>>        <section name="">
>>>            <entry>
>>>                <string_id></string_id>
>>>                <string></string>
>>>            </entry>
>>>        </section>
>>>    </translation>
>>> A couple of notes about the format.  the section and entry tags can
>>> repeat.  Also, the string_id is the native language string and the
>>> string tag is the translated version
>>>
>>> Here is what is left:
>>> 1) The big issue to iron out is how to incorporate plugins.  My 
>>> original
>>> thought was that plugins would each have their own XML file and would
>>> not share the main Geeklog
>>>     file but given our plugin-centric approach this may not make sense
>>> anymore.  We may want to consider inserting <plugin> tags around the
>>> section tags.   Just a though, regardless
>>>     this probably needs some talking outload.  Dirk, any suggestions
>>> here since you are a big user of the translation stuff?
>>> 2) mergeversions needs to be ported to PHP5 and should honor the new
>>> section tags. Furthermore, it should be written to use the new PHP5 XML
>>> features
>>> 3) We should add optional support of storing the strings in a database.
>>> To that end, we should add the ability to import the xml files into a
>>> database table.  Not sure of the best way to do this as there are a few
>>> options.
>>> 4) similarly Translator.class.php should be ported to PHP5 and use the
>>> new PHP5 XML parsing features
>>> 5) Build an xml schema we can use in mergeversions and in getstrings to
>>> validate the XML of the translation file.  PHP5 has a built in XML
>>> validator to help do most of this work.
>>> 6) As mentioned, look at StringExtractor.class.php for performance
>>> improvements.
>>> 7) We should look into PEAR::Cache and how it might make the 
>>> translation
>>> process faster.  You might want to ask JellyBob (Jon Wood) how
>>> PEAR::Cache works exactly...while he hasn't committed any time to GL2
>>> persay, I'm sure he'd be willing to explain it abit.
>>>
>>> Anything 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
>>  
>>
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel



From vfuria at gmail.com  Tue Jul 20 14:57:35 2004
From: vfuria at gmail.com (Vincent Furia)
Date: Tue, 20 Jul 2004 14:57:35 -0400
Subject: [geeklog-devel] Translation stuff for GL2
In-Reply-To: <40FD6BFD.6000500@tonybibbs.com>
References: <40FC37D8.7070803@tonybibbs.com> <8319e2d604072011045c2fdd48@mail.gmail.com> <40FD6A22.8070208@tonybibbs.com> <40FD6BFD.6000500@tonybibbs.com>
Message-ID: <8319e2d6040720115778d32bb7@mail.gmail.com>

Also recall this article from a while back:
http://www.geeklog.net/article.php?story=20030121174254562&query=gettext

Most ISPs in the surrvey had it installed.  Not scientific, but interesting.

-Vinny

On Tue, 20 Jul 2004 14:01:17 -0500, Tony Bibbs <tony at tonybibbs.com> wrote:
> If it helps at all, --with-gettext is *not* included in a php build by
> default.
> 
> --Tony
> 
> 
> 
> Tony Bibbs wrote:
> 
> > I think option 2 is out.  I've peaked at the code and, frankly, I'm
> > not impressed.
> > I'd be interested to hear from those of you who regularly do
> > translations on how option #1 sounds.  Basically what he is saying is
> > using option 1 you might have code like this:
> >
> > gettext('some english string');
> > gettext('som other english string');
> >
> > Then you would create the english (en) translation file using
> > xgettext.  We would then distribute the file to translators.  This is
> > fine and dandy for those who have gettext support compiled into PHP.
> > The first issue is is the general adoption of gettext support in PHP
> > such that we should just assume it is included?  If so, this is the
> > clear winner.  If not then what Vinny was eluding to is we would write
> > a script that would take another language file, say german, and we
> > would replace all the english based gettext() calls in the .php files
> > and insert the user's language of choice.  In otherwords a script
> > would change:
> >
> > gettext('some english string'); to gettext('some german string');
> >
> > In addition to his drawbacks, an additional drawback would be that in
> > this instance user's couldn't have their own custom language setting.
> >
> > --Tony
> >
> > Vincent Furia wrote:
> >
> >> Tony, JellyBob, and I discussed some possibilities concerning the
> >> translation stuff on IRC today.  We discussed a couple of possible
> >> alternatives to using a custom built translation class.
> >>
> >> 1.  Use GNU gettext.  We could use gettext to support user selectable
> >> languages for installations that support gettext.  For installations
> >> that don't support gettext we can simply support a single language
> >> decided on during installation (this would not be user selectable).
> >>
> >> Things to do: We would have to write a custom script to convert the
> >> default english strings in the php files to the desired, supported
> >> language using the gettext files.  Hence the replacement language
> >> would become the default language in the converted files.  We could
> >> then either have the installer run this conversion script, or else
> >> create downloads for each language (which can be automated).  Since
> >> installations without gettext will already support the default
> >> language (english I presume), we can make the creation of the
> >> translation script a low priority.
> >>
> >> Possible problems: upgrades and security releases would need some
> >> planning as non-gettext installs would need files configured for their
> >> language.  A good auto-update system might be able to handle this.
> >>
> >> 2. Use PEAR::Translation2
> >> This class does most of what we want, include support DB.
> >> Possible Problems: The downside is it doesn't support merging of
> >> translation versions and is large and cumbersome.
> >>
> >> Personally, I like option 1.  If no one agrees that that is a viable
> >> alternative than I think we should skip the PEAR::Translation2 class
> >> (at least for the time being) and use the custom version.
> >>
> >> Any feedback?
> >> -Vinny
> >>
> >> On Mon, 19 Jul 2004 16:06:32 -0500, Tony Bibbs <tony at tonybibbs.com>
> >> wrote:
> >>
> >>
> >>> Vinny,
> >>>
> >>> Per your request I'm outlining what remains for for GL2's translation
> >>> engine.  First a recap.
> >>>
> >>> First, I wrote the translation engine from scratch mainly because the
> >>> one in PEAR didn't, at the time, make upgrading to new releases easy on
> >>> translators.  Basically, with each new release, as with 1.3.x, the
> >>> translators have to manually update the new file OR hack a way to merge
> >>> them.  It is probably worth looking at what is in PEAR again to see if
> >>> merging of translation files is supported.  If it is, I could be
> >>> compelled to simply use it.
> >>>
> >>> However, assuming it still doesn't work that way here is what I have
> >>> done:
> >>> 1) The combination of getstrings and StringExtractor.class.php
> >>> currently
> >>> work in PHP5 and parse anything of the form "->translate('[some
> >>> string]')" OR "->translate('[some other string]', '[some section
> >>> name]]);
> >>> 2) The data is collected in an array and is outputted to an xml file
> >>> with the following basic structure
> >>> <application name="" version="">
> >>>    <translator name="" email=""/>
> >>>    <translation language="">
> >>>        <section name="">
> >>>            <entry>
> >>>                <string_id></string_id>
> >>>                <string></string>
> >>>            </entry>
> >>>        </section>
> >>>    </translation>
> >>> A couple of notes about the format.  the section and entry tags can
> >>> repeat.  Also, the string_id is the native language string and the
> >>> string tag is the translated version
> >>>
> >>> Here is what is left:
> >>> 1) The big issue to iron out is how to incorporate plugins.  My
> >>> original
> >>> thought was that plugins would each have their own XML file and would
> >>> not share the main Geeklog
> >>>     file but given our plugin-centric approach this may not make sense
> >>> anymore.  We may want to consider inserting <plugin> tags around the
> >>> section tags.   Just a though, regardless
> >>>     this probably needs some talking outload.  Dirk, any suggestions
> >>> here since you are a big user of the translation stuff?
> >>> 2) mergeversions needs to be ported to PHP5 and should honor the new
> >>> section tags. Furthermore, it should be written to use the new PHP5 XML
> >>> features
> >>> 3) We should add optional support of storing the strings in a database.
> >>> To that end, we should add the ability to import the xml files into a
> >>> database table.  Not sure of the best way to do this as there are a few
> >>> options.
> >>> 4) similarly Translator.class.php should be ported to PHP5 and use the
> >>> new PHP5 XML parsing features
> >>> 5) Build an xml schema we can use in mergeversions and in getstrings to
> >>> validate the XML of the translation file.  PHP5 has a built in XML
> >>> validator to help do most of this work.
> >>> 6) As mentioned, look at StringExtractor.class.php for performance
> >>> improvements.
> >>> 7) We should look into PEAR::Cache and how it might make the
> >>> translation
> >>> process faster.  You might want to ask JellyBob (Jon Wood) how
> >>> PEAR::Cache works exactly...while he hasn't committed any time to GL2
> >>> persay, I'm sure he'd be willing to explain it abit.
> >>>
> >>> Anything 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
> >>
> >>
> > _______________________________________________
> > 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 seanmcunningham at comcast.net  Wed Jul 21 13:56:04 2004
From: seanmcunningham at comcast.net (Sean M. Cunningham)
Date: Wed, 21 Jul 2004 11:56:04 -0600
Subject: [geeklog-devel] Re: Translation stuff for GL2
In-Reply-To: <20040721170002.6601.78287.Mailman@internal.iowaoutdoors.org>
References: <20040721170002.6601.78287.Mailman@internal.iowaoutdoors.org>
Message-ID: <40FEAE34.9080402@comcast.net>

Hi All,
I was thinking that it might be kind of nice to have the translations 
incorporated with the themes. XSilver_en, XSilver_fr, XSilver_sp, and so 
on. Designing in my native language seems only natural and I would 
imagine that most designers are designing in their native languages 
also. A site that requires multiple languages would have to have the 
translator and designer working together though.
I feel that this could streamline the base code and simplify the themes, 
although it would increase the quantity of themes.
The trade off would be ok for me. What do you think?

-Sean



From tony at tonybibbs.com  Wed Jul 21 17:31:57 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Wed, 21 Jul 2004 16:31:57 -0500
Subject: [geeklog-devel] GL2 event model
Message-ID: <40FEE0CD.9000901@tonybibbs.com>

The plugin API for GL2 that Vinny has drafted if surprisingly small 
because we are introducing an event based model.  Essentially, the GL2 
and all plugins have the option to register events that others can 
listen to.  To implement this I recommend an observer/observable design 
pattern similar to the example below.  A few things that need 
discussion.  First, the example below allows listening only at the 
object level.  The alternative is the force listening at the event level 
(in otherwords, addListener would take as a second arg an array of 
events the object listens to).  Any preference?  General questions?:

class MySubjectObserverClass {
   private $listeners = array();
   private $listernerNextID  =  0;

   // Alternative names: register, subscribe...
   public function addListerner(&$obj)
   {
       $this->_listerners[] =& $obj;
      return $this->listernerNextID++;
   }

   // Alternative name: unregister, unsubscribe...
   public function removeListerner($id,'even't)
   {
        unset($this->listerners[$id]);
   }

   // Alternative name: broadcast...
   public function notifyAll($event)
   {
       foreach ($this->listerners as $id => $obj)
       {
           $this->listerners[$id]->notify($event, $this);
       }
   }

   // Alternative name: listen...
   function notify($event, &$obj)
   {
        switch (get_class($obj)) {
            case 'blah':
               ...
       }
   }
}



From tomw at pigstye.net  Wed Jul 21 18:10:55 2004
From: tomw at pigstye.net (Tom Willett)
Date: Wed, 21 Jul 2004 22:10:55 +0000
Subject: [geeklog-devel] GL2 event model
In-Reply-To: <40FEE0CD.9000901@tonybibbs.com>
References: <40FEE0CD.9000901@tonybibbs.com>
Message-ID: <20040721220312.M50280@pigstye.net>

Let me get this straight.

GL2 Core would make the MySubjectObserverClass

$obs = new MySubjectObserverClass;

then the plugin would register by somehow getting the reference to the 
MySubjectOvserverClass and register itself as a listener

$obs->addListner($MyPlugin);
or
$obs->addListener($MyPlugin, $events);
etc

Then when a event happened GL2 Core or a plugin could notify the plugins

$obs->notifyAll($event)

Do I have this about right?

--
Tom Willett
tomw at pigstye.net

---------- Original Message -----------
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Sent: Wed, 21 Jul 2004 16:31:57 -0500
Subject: [geeklog-devel] GL2 event model

> The plugin API for GL2 that Vinny has drafted if surprisingly small 
> because we are introducing an event based model.  Essentially, the GL2 
> and all plugins have the option to register events that others can 
> listen to.  To implement this I recommend an observer/observable design 
> pattern similar to the example below.  A few things that need 
> discussion.  First, the example below allows listening only at the 
> object level.  The alternative is the force listening at the event level 
> (in otherwords, addListener would take as a second arg an array of 
> events the object listens to).  Any preference?  General questions?:
> 
> class MySubjectObserverClass {
>    private $listeners = array();
>    private $listernerNextID  =  0;
> 
>    // Alternative names: register, subscribe...
>    public function addListerner(&$obj)
>    {
>        $this->_listerners[] =& $obj;
>       return $this->listernerNextID++;
>    }
> 
>    // Alternative name: unregister, unsubscribe...
>    public function removeListerner($id,'even't)
>    {
>         unset($this->listerners[$id]);
>    }
> 
>    // Alternative name: broadcast...
>    public function notifyAll($event)
>    {
>        foreach ($this->listerners as $id => $obj)
>        {
>            $this->listerners[$id]->notify($event, $this);
>        }
>    }
> 
>    // Alternative name: listen...
>    function notify($event, &$obj)
>    {
>         switch (get_class($obj)) {
>             case 'blah':
>                ...
>        }
>    }
> }
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
------- End of Original Message -------



From vfuria at gmail.com  Wed Jul 21 21:23:51 2004
From: vfuria at gmail.com (Vincent Furia)
Date: Wed, 21 Jul 2004 21:23:51 -0400
Subject: [geeklog-devel] GL2 event model
In-Reply-To: <20040721220312.M50280@pigstye.net>
References: <40FEE0CD.9000901@tonybibbs.com> <20040721220312.M50280@pigstye.net>
Message-ID: <8319e2d604072118231fa09b79@mail.gmail.com>

Here is what I had envisioned when I penned the Plugin API
documentation.  It is a class that would be instantiated only once by
GL2 core and available globally.  I prefer the per event registration
as it will reduce the calls the "PluginEventHanlder" will have to make
to listening plugins.

-Vinny

class PluginEventHandler {

    /**
    * Array containing event keys and listener (arrays as) values
    * @access private
    * @var array
    */
    private $listeners = array();

    /**
    * PluginEventHandler Constructor
    *
    * @access public
    *
    */
    function __construct() {
        // fetch registered listeners from database, populate $listeners
    }

    /**
    * Register a plugin to listen for an event
    *
    * @access public
    * @param  mixed   $event  event(s) to listen for (string or array)
    * @param  string  $plugin plugin to be registered as listener
    * @return boolean true on success
    *
    */
    function registerListener($event, $plugin) {
        // add the listener to the $listeners variable and the database
    }

    /**
    * Unregister a plugin from listening for an event
    *
    * @access public
    * @param  mixed   $event  event(s) to unregister (string or array)
    * @param  string  $plugin plugin to be unregistered as listener
    * @return boolean true on success
    *
    */
    function unregisterListener($event, $plugin) {
       // remove the listener for the specified events from $listeners
       //   and the database.
    }

    /**
    * Get all the listeners for a specific event
    *
    * @access public
    * @param  string $event  event to get listeners of
    * @return array  array of listeners to event $event
    *
    */
    function getListeners($event) {
       // remove the listener for the specified events from $listeners
       //   and the database.
    }

    /**
    * Notify all listeners that an event has occurred
    *
    * @access public
    * @param  mixed $event  event requiring notification
    * @param  mixed $vars   event specific variables
    * @param  mixed $plugin NOTIFY_ALL, specific plugin, or array of plugins
    * @return mixed event specific return values (or array of)
    *
    */
    function notify($event, $vars, $plugin = NOTIFY_ALL) {

    }

}



On Wed, 21 Jul 2004 22:10:55 +0000, Tom Willett <tomw at pigstye.net> wrote:
> Let me get this straight.
> 
> GL2 Core would make the MySubjectObserverClass
> 
> $obs = new MySubjectObserverClass;
> 
> then the plugin would register by somehow getting the reference to the
> MySubjectOvserverClass and register itself as a listener
> 
> $obs->addListner($MyPlugin);
> or
> $obs->addListener($MyPlugin, $events);
> etc
> 
> Then when a event happened GL2 Core or a plugin could notify the plugins
> 
> $obs->notifyAll($event)
> 
> Do I have this about right?
> 
> --
> Tom Willett
> tomw at pigstye.net
> 
> 
> 
> ---------- Original Message -----------
> From: Tony Bibbs <tony at tonybibbs.com>
> To: geeklog-devel at lists.geeklog.net
> Sent: Wed, 21 Jul 2004 16:31:57 -0500
> Subject: [geeklog-devel] GL2 event model
> 
> > The plugin API for GL2 that Vinny has drafted if surprisingly small
> > because we are introducing an event based model.  Essentially, the GL2
> > and all plugins have the option to register events that others can
> > listen to.  To implement this I recommend an observer/observable design
> > pattern similar to the example below.  A few things that need
> > discussion.  First, the example below allows listening only at the
> > object level.  The alternative is the force listening at the event level
> > (in otherwords, addListener would take as a second arg an array of
> > events the object listens to).  Any preference?  General questions?:
> >
> > class MySubjectObserverClass {
> >    private $listeners = array();
> >    private $listernerNextID  =  0;
> >
> >    // Alternative names: register, subscribe...
> >    public function addListerner(&$obj)
> >    {
> >        $this->_listerners[] =& $obj;
> >       return $this->listernerNextID++;
> >    }
> >
> >    // Alternative name: unregister, unsubscribe...
> >    public function removeListerner($id,'even't)
> >    {
> >         unset($this->listerners[$id]);
> >    }
> >
> >    // Alternative name: broadcast...
> >    public function notifyAll($event)
> >    {
> >        foreach ($this->listerners as $id => $obj)
> >        {
> >            $this->listerners[$id]->notify($event, $this);
> >        }
> >    }
> >
> >    // Alternative name: listen...
> >    function notify($event, &$obj)
> >    {
> >         switch (get_class($obj)) {
> >             case 'blah':
> >                ...
> >        }
> >    }
> > }
> >
> > _______________________________________________
> > geeklog-devel mailing list
> > geeklog-devel at lists.geeklog.net
> > http://lists.geeklog.net/listinfo/geeklog-devel
> ------- End of Original Message -------
> 
> 
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>


From vfuria at gmail.com  Wed Jul 21 21:36:38 2004
From: vfuria at gmail.com (Vincent Furia)
Date: Wed, 21 Jul 2004 21:36:38 -0400
Subject: [geeklog-devel] Re: Translation stuff for GL2
In-Reply-To: <40FEAE34.9080402@comcast.net>
References: <20040721170002.6601.78287.Mailman@internal.iowaoutdoors.org> <40FEAE34.9080402@comcast.net>
Message-ID: <8319e2d604072118363f63ac6@mail.gmail.com>

The big down side to this method is that every theme will have to be
translated into every desired language.  So if a site wants 7 themes
(as comes with geeklog today) and 36 languages (as comes with geeklog
today) under this scheme they'd have to translate each theme 36 times.
 That's 252 themes and a whole lot of extra work for translators.

-Vinny

On Wed, 21 Jul 2004 11:56:04 -0600, Sean M. Cunningham
<seanmcunningham at comcast.net> wrote:
> Hi All,
> I was thinking that it might be kind of nice to have the translations
> incorporated with the themes. XSilver_en, XSilver_fr, XSilver_sp, and so
> on. Designing in my native language seems only natural and I would
> imagine that most designers are designing in their native languages
> also. A site that requires multiple languages would have to have the
> translator and designer working together though.
> I feel that this could streamline the base code and simplify the themes,
> although it would increase the quantity of themes.
> The trade off would be ok for me. What do you think?
> 
> -Sean
> 
> 
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>


From tony at tonybibbs.com  Thu Jul 22 09:35:27 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Thu, 22 Jul 2004 08:35:27 -0500
Subject: [geeklog-devel] Re: Translation stuff for GL2
In-Reply-To: <8319e2d604072118363f63ac6@mail.gmail.com>
References: <20040721170002.6601.78287.Mailman@internal.iowaoutdoors.org> <40FEAE34.9080402@comcast.net> <8319e2d604072118363f63ac6@mail.gmail.com>
Message-ID: <40FFC29F.904@tonybibbs.com>

Yeah, this isn't very realistic.

--Tony

Vincent Furia wrote:

>The big down side to this method is that every theme will have to be
>translated into every desired language.  So if a site wants 7 themes
>(as comes with geeklog today) and 36 languages (as comes with geeklog
>today) under this scheme they'd have to translate each theme 36 times.
> That's 252 themes and a whole lot of extra work for translators.
>
>-Vinny
>
>On Wed, 21 Jul 2004 11:56:04 -0600, Sean M. Cunningham
><seanmcunningham at comcast.net> wrote:
>  
>
>>Hi All,
>>I was thinking that it might be kind of nice to have the translations
>>incorporated with the themes. XSilver_en, XSilver_fr, XSilver_sp, and so
>>on. Designing in my native language seems only natural and I would
>>imagine that most designers are designing in their native languages
>>also. A site that requires multiple languages would have to have the
>>translator and designer working together though.
>>I feel that this could streamline the base code and simplify the themes,
>>although it would increase the quantity of themes.
>>The trade off would be ok for me. What do you think?
>>
>>-Sean
>>
>>
>>
>>_______________________________________________
>>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 Jul 26 11:58:51 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Mon, 26 Jul 2004 17:58:51 +0200
Subject: [geeklog-devel] 1.3.10 to do list
Message-ID: <20040726165851.26236@smtp.haun-online.de>

Okay, I think I have pretty much implemented everything that I wanted to
go into 1.3.10. Now it's on to the usual stuff (bug fixes, documentation
and language file updates, testing, ...).

Not sure if I'll have a go at the Admin Toolbox we've talked about or
leave it for the next version. I may give it a try if I have a mood swing
or something ...

Then there are a few other open issues:

Inclusion of the SpamX plugin - what's the status here? We probably need
a new plugin API function so that plugins can filter or reject comments
before they will be saved. Also, a method to make it easier to package
plugins with Geeklog would be nice, e.g. by making the install script
read the SQL for the plugin from some predefined directory (if we do
that, it also needs to be able to handle plugin updates).

Vinny, you wanted to do some work on the comment bar. What's the status /
plan here?

PDF: Currently, the PDF-related files all produce XHTML, which is
inconsistent with the rest of Geeklog which produces plain ol' HTML. From
the documentation, the PDF add-on doesn't understand XHTML either (but
only HTML 3.2), so I don't see the need for this. Tony? Anything else
that needs to be done on the PDF support?

A few features have been mentioned in the past as being possibly ready to
go into the next release. Most notably spell checking and archiving of
old stories. Tony, Blaine - any updates?

Anything else?

bye, Dirk


-- 
http://www.haun-online.de/
http://www.tinyweb.de/



From tony at tonybibbs.com  Mon Jul 26 12:51:00 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Mon, 26 Jul 2004 11:51:00 -0500
Subject: [geeklog-devel] 1.3.10 to do list
In-Reply-To: <20040726165851.26236@smtp.haun-online.de>
References: <20040726165851.26236@smtp.haun-online.de>
Message-ID: <41053674.9080805@tonybibbs.com>


Dirk Haun wrote:

>Inclusion of the SpamX plugin - what's the status here? We probably need
>a new plugin API function so that plugins can filter or reject comments
>before they will be saved. Also, a method to make it easier to package
>plugins with Geeklog would be nice, e.g. by making the install script
>read the SQL for the plugin from some predefined directory (if we do
>that, it also needs to be able to handle plugin updates).
>  
>
I say add something like the following:
PLG_preSaveComment_<pluginName>
PLG_postSaveComment_<pluginName>
PLG_preSaveStory_<pluginName>
PLG_postSaveStory_<pluginName>

The first one is the one we needed the most.  I figured adding a 
postSaveComment would complete the cycle, though, I can't think of an 
immediate use for it now.  I also added the two story-related methods as 
I don't think it would be a stretch to think someone may want those at 
some point.  Just a suggestion...we can simply add the one and worry 
about the rest as needed...I just figured we might try being a bit more 
proactive by adding a few more.

>PDF: Currently, the PDF-related files all produce XHTML, which is
>inconsistent with the rest of Geeklog which produces plain ol' HTML. From
>the documentation, the PDF add-on doesn't understand XHTML either (but
>only HTML 3.2), so I don't see the need for this. Tony? Anything else
>that needs to be done on the PDF support?
>  
>
Agreed, I misunderstood that much.  With that, nothing else is really 
needed then.

>A few features have been mentioned in the past as being possibly ready to
>go into the next release. Most notably spell checking and archiving of
>old stories. Tony, Blaine - any updates?
>  
>
Count the spellchecker out.  I've dusted it off and have a few fairly 
big bugs that will take some time...not worth holding off the .10 release.

--Tony


From geeklog at langfamily.ca  Mon Jul 26 12:57:41 2004
From: geeklog at langfamily.ca (Blaine Lang)
Date: Mon, 26 Jul 2004 12:57:41 -0400
Subject: [geeklog-devel] 1.3.10 to do list
References: <20040726165851.26236@smtp.haun-online.de>
Message-ID: <00e801c47331$aa157060$650a10ac@XPBL2>

I would like to add the Story Archive and can do so this week.
- Option to set a date where the story will be moved to a "defined" archive
topic or delete automatically.
- It's also possible to use a new set of template files for the archive
topic

I also have a similar feature for Blocks - where you can set the show until
time then it gets disabled.

Another item I have is a change to the advanced search results. I just need
to complete a bit more testing on that one.
I will aim for this week as well to get that in.

Blaine
----- Original Message ----- 
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Sent: Monday, July 26, 2004 11:58 AM
Subject: [geeklog-devel] 1.3.10 to do list


Okay, I think I have pretty much implemented everything that I wanted to
go into 1.3.10. Now it's on to the usual stuff (bug fixes, documentation
and language file updates, testing, ...).

Not sure if I'll have a go at the Admin Toolbox we've talked about or
leave it for the next version. I may give it a try if I have a mood swing
or something ...

Then there are a few other open issues:

Inclusion of the SpamX plugin - what's the status here? We probably need
a new plugin API function so that plugins can filter or reject comments
before they will be saved. Also, a method to make it easier to package
plugins with Geeklog would be nice, e.g. by making the install script
read the SQL for the plugin from some predefined directory (if we do
that, it also needs to be able to handle plugin updates).

Vinny, you wanted to do some work on the comment bar. What's the status /
plan here?

PDF: Currently, the PDF-related files all produce XHTML, which is
inconsistent with the rest of Geeklog which produces plain ol' HTML. From
the documentation, the PDF add-on doesn't understand XHTML either (but
only HTML 3.2), so I don't see the need for this. Tony? Anything else
that needs to be done on the PDF support?

A few features have been mentioned in the past as being possibly ready to
go into the next release. Most notably spell checking and archiving of
old stories. Tony, Blaine - any updates?

Anything else?

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 geeklog at langfamily.ca  Mon Jul 26 12:58:38 2004
From: geeklog at langfamily.ca (Blaine Lang)
Date: Mon, 26 Jul 2004 12:58:38 -0400
Subject: [geeklog-devel] 1.3.10 to do list
References: <20040726165851.26236@smtp.haun-online.de> <41053674.9080805@tonybibbs.com>
Message-ID: <00ee01c47331$cc1d4ac0$650a10ac@XPBL2>

I say add something like the following:
PLG_preSaveComment_<pluginName>
PLG_postSaveComment_<pluginName>
PLG_preSaveStory_<pluginName>
PLG_postSaveStory_<pluginName>

I like these API's as it would be a good way to add any custom tags that may
provide advanced formatting control.

Blaine
----- Original Message ----- 
From: "Tony Bibbs" <tony at tonybibbs.com>
To: <geeklog-devel at lists.geeklog.net>
Sent: Monday, July 26, 2004 12:51 PM
Subject: Re: [geeklog-devel] 1.3.10 to do list




Dirk Haun wrote:

>Inclusion of the SpamX plugin - what's the status here? We probably need
>a new plugin API function so that plugins can filter or reject comments
>before they will be saved. Also, a method to make it easier to package
>plugins with Geeklog would be nice, e.g. by making the install script
>read the SQL for the plugin from some predefined directory (if we do
>that, it also needs to be able to handle plugin updates).
>
>
I say add something like the following:
PLG_preSaveComment_<pluginName>
PLG_postSaveComment_<pluginName>
PLG_preSaveStory_<pluginName>
PLG_postSaveStory_<pluginName>

The first one is the one we needed the most.  I figured adding a
postSaveComment would complete the cycle, though, I can't think of an
immediate use for it now.  I also added the two story-related methods as
I don't think it would be a stretch to think someone may want those at
some point.  Just a suggestion...we can simply add the one and worry
about the rest as needed...I just figured we might try being a bit more
proactive by adding a few more.

>PDF: Currently, the PDF-related files all produce XHTML, which is
>inconsistent with the rest of Geeklog which produces plain ol' HTML. From
>the documentation, the PDF add-on doesn't understand XHTML either (but
>only HTML 3.2), so I don't see the need for this. Tony? Anything else
>that needs to be done on the PDF support?
>
>
Agreed, I misunderstood that much.  With that, nothing else is really
needed then.

>A few features have been mentioned in the past as being possibly ready to
>go into the next release. Most notably spell checking and archiving of
>old stories. Tony, Blaine - any updates?
>
>
Count the spellchecker out.  I've dusted it off and have a few fairly
big bugs that will take some time...not worth holding off the .10 release.

--Tony
_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel



From vfuria at gmail.com  Mon Jul 26 13:00:55 2004
From: vfuria at gmail.com (Vincent Furia)
Date: Mon, 26 Jul 2004 13:00:55 -0400
Subject: [geeklog-devel] 1.3.10 to do list
In-Reply-To: <20040726165851.26236@smtp.haun-online.de>
References: <20040726165851.26236@smtp.haun-online.de>
Message-ID: <8319e2d604072610007bae1842@mail.gmail.com>

I've just started work on the comment bar.  I still need to work on
design and dig a bit into the code before I know how much work it will
take.  This is a pretty low priority, and only important from an
ascetics perspective when viewing comments from comment.php.  I would
not cry if this got pushed off to a later release.

Here is a list of things that we had discussed or I made up (some
going back pretty far) as things to consider for 1.3.10:
* Improve search engine speed
* Improve general performance (read: reduce page generation time)
* Clean up usage of $_GROUPS, $_RIGHTS
   - basically these aren't' being used consistently, I have an idea
to clean this up, but at this point it should probably be pushed back
to the next release.
* Replace use of $topicsql with COM_getTopicSQL (a new function by Dirk)
   - Many places in geekog generate "topic sql" for topic permissions.
 From a maintainability perspective using Dirk's function is much
better.  Again, this can (and probably should) be pushed off a release
* Fix the comment bar
   - In work, see note above

Also, if people could spend some time testing the new comment system
to make sure there aren't any bugs.  Also, test the upload script and
make sure it doesn't take a ridiculous amount of time.

Also, if anyone can install 1.3.9 and the current cvs side by side and
do some performance comparisons it would be appreciated.  I'm curious
as to how big a performance difference some of the optimizations I
made (quite a while ago now) has caused.

I think that's it for me,
Vinny

On Mon, 26 Jul 2004 17:58:51 +0200, Dirk Haun <dirk at haun-online.de> wrote:
> Okay, I think I have pretty much implemented everything that I wanted to
> go into 1.3.10. Now it's on to the usual stuff (bug fixes, documentation
> and language file updates, testing, ...).
> 
> Not sure if I'll have a go at the Admin Toolbox we've talked about or
> leave it for the next version. I may give it a try if I have a mood swing
> or something ...
> 
> Then there are a few other open issues:
> 
> Inclusion of the SpamX plugin - what's the status here? We probably need
> a new plugin API function so that plugins can filter or reject comments
> before they will be saved. Also, a method to make it easier to package
> plugins with Geeklog would be nice, e.g. by making the install script
> read the SQL for the plugin from some predefined directory (if we do
> that, it also needs to be able to handle plugin updates).
> 
> Vinny, you wanted to do some work on the comment bar. What's the status /
> plan here?
> 
> PDF: Currently, the PDF-related files all produce XHTML, which is
> inconsistent with the rest of Geeklog which produces plain ol' HTML. From
> the documentation, the PDF add-on doesn't understand XHTML either (but
> only HTML 3.2), so I don't see the need for this. Tony? Anything else
> that needs to be done on the PDF support?
> 
> A few features have been mentioned in the past as being possibly ready to
> go into the next release. Most notably spell checking and archiving of
> old stories. Tony, Blaine - any updates?
> 
> Anything else?
> 
> 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 tomw at pigstye.net  Mon Jul 26 16:33:00 2004
From: tomw at pigstye.net (Tom Willett)
Date: Mon, 26 Jul 2004 20:33:00 +0000
Subject: [geeklog-devel] 1.3.10 to do list
In-Reply-To: <41053674.9080805@tonybibbs.com>
References: <20040726165851.26236@smtp.haun-online.de> <41053674.9080805@tonybibbs.com>
Message-ID: <20040726203113.M77149@pigstye.net>

I was supposed to change the spamx plugin to use sql tables rather than 
files.  I am almost done with that and will get it to Tony in the next 
couple of days.

--
Tom Willett
tomw at pigstye.net

---------- Original Message -----------
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Sent: Mon, 26 Jul 2004 11:51:00 -0500
Subject: Re: [geeklog-devel] 1.3.10 to do list

> Dirk Haun wrote:
> 
> >Inclusion of the SpamX plugin - what's the status here? We probably need
> >a new plugin API function so that plugins can filter or reject comments
> >before they will be saved. Also, a method to make it easier to package
> >plugins with Geeklog would be nice, e.g. by making the install script
> >read the SQL for the plugin from some predefined directory (if we do
> >that, it also needs to be able to handle plugin updates).
> >  
> >
> I say add something like the following:
> PLG_preSaveComment_<pluginName>
> PLG_postSaveComment_<pluginName>
> PLG_preSaveStory_<pluginName>
> PLG_postSaveStory_<pluginName>
> 
> The first one is the one we needed the most.  I figured adding a 
> postSaveComment would complete the cycle, though, I can't think of an 
> immediate use for it now.  I also added the two story-related methods as 
> I don't think it would be a stretch to think someone may want those at 
> some point.  Just a suggestion...we can simply add the one and worry 
> about the rest as needed...I just figured we might try being a bit more 
> proactive by adding a few more.
> 
> >PDF: Currently, the PDF-related files all produce XHTML, which is
> >inconsistent with the rest of Geeklog which produces plain ol' HTML. From
> >the documentation, the PDF add-on doesn't understand XHTML either (but
> >only HTML 3.2), so I don't see the need for this. Tony? Anything else
> >that needs to be done on the PDF support?
> >  
> >
> Agreed, I misunderstood that much.  With that, nothing else is really 
> needed then.
> 
> >A few features have been mentioned in the past as being possibly ready to
> >go into the next release. Most notably spell checking and archiving of
> >old stories. Tony, Blaine - any updates?
> >  
> >
> Count the spellchecker out.  I've dusted it off and have a few fairly 
> big bugs that will take some time...not worth holding off the .10 release.
> 
> --Tony
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
------- End of Original Message -------



From tony at tonybibbs.com  Mon Jul 26 16:45:24 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Mon, 26 Jul 2004 15:45:24 -0500
Subject: [geeklog-devel] 1.3.10 to do list
In-Reply-To: <20040726203113.M77149@pigstye.net>
References: <20040726165851.26236@smtp.haun-online.de> <41053674.9080805@tonybibbs.com> <20040726203113.M77149@pigstye.net>
Message-ID: <41056D64.6000302@tonybibbs.com>

I'll get it in as soon as I get it.

--Tony

Tom Willett wrote:

>I was supposed to change the spamx plugin to use sql tables rather than 
>files.  I am almost done with that and will get it to Tony in the next 
>couple of days.
>
>--
>Tom Willett
>tomw at pigstye.net
>
>---------- Original Message -----------
>From: Tony Bibbs <tony at tonybibbs.com>
>To: geeklog-devel at lists.geeklog.net
>Sent: Mon, 26 Jul 2004 11:51:00 -0500
>Subject: Re: [geeklog-devel] 1.3.10 to do list
>
>  
>
>>Dirk Haun wrote:
>>
>>    
>>
>>>Inclusion of the SpamX plugin - what's the status here? We probably need
>>>a new plugin API function so that plugins can filter or reject comments
>>>before they will be saved. Also, a method to make it easier to package
>>>plugins with Geeklog would be nice, e.g. by making the install script
>>>read the SQL for the plugin from some predefined directory (if we do
>>>that, it also needs to be able to handle plugin updates).
>>> 
>>>
>>>      
>>>
>>I say add something like the following:
>>PLG_preSaveComment_<pluginName>
>>PLG_postSaveComment_<pluginName>
>>PLG_preSaveStory_<pluginName>
>>PLG_postSaveStory_<pluginName>
>>
>>The first one is the one we needed the most.  I figured adding a 
>>postSaveComment would complete the cycle, though, I can't think of an 
>>immediate use for it now.  I also added the two story-related methods as 
>>I don't think it would be a stretch to think someone may want those at 
>>some point.  Just a suggestion...we can simply add the one and worry 
>>about the rest as needed...I just figured we might try being a bit more 
>>proactive by adding a few more.
>>
>>    
>>
>>>PDF: Currently, the PDF-related files all produce XHTML, which is
>>>inconsistent with the rest of Geeklog which produces plain ol' HTML. From
>>>the documentation, the PDF add-on doesn't understand XHTML either (but
>>>only HTML 3.2), so I don't see the need for this. Tony? Anything else
>>>that needs to be done on the PDF support?
>>> 
>>>
>>>      
>>>
>>Agreed, I misunderstood that much.  With that, nothing else is really 
>>needed then.
>>
>>    
>>
>>>A few features have been mentioned in the past as being possibly ready to
>>>go into the next release. Most notably spell checking and archiving of
>>>old stories. Tony, Blaine - any updates?
>>> 
>>>
>>>      
>>>
>>Count the spellchecker out.  I've dusted it off and have a few fairly 
>>big bugs that will take some time...not worth holding off the .10 release.
>>
>>--Tony
>>_______________________________________________
>>geeklog-devel mailing list
>>geeklog-devel at lists.geeklog.net
>>http://lists.geeklog.net/listinfo/geeklog-devel
>>    
>>
>------- End of Original Message -------
>
>_______________________________________________
>geeklog-devel mailing list
>geeklog-devel at lists.geeklog.net
>http://lists.geeklog.net/listinfo/geeklog-devel
>  
>


From dirk at haun-online.de  Mon Jul 26 17:04:53 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Mon, 26 Jul 2004 23:04:53 +0200
Subject: [geeklog-devel] 1.3.10 to do list
In-Reply-To: <41053674.9080805@tonybibbs.com>
References: <41053674.9080805@tonybibbs.com>
Message-ID: <20040726220453.29784@smtp.haun-online.de>

Tony,

just noticed that the PDF conversion isn't even listed in the changelog
yet. Could you add a word or two, please?

Also, do we need some additional documentation for this? I guess the
various settings (like TTL, Tidy support, ...) aren't always too obvious
and could benefit from some explanations.

bye, Dirk


-- 
http://www.haun-online.de/
http://geeklog.info/



From tony at tonybibbs.com  Mon Jul 26 17:23:54 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Mon, 26 Jul 2004 16:23:54 -0500
Subject: [geeklog-devel] 1.3.10 to do list
In-Reply-To: <20040726220453.29784@smtp.haun-online.de>
References: <41053674.9080805@tonybibbs.com> <20040726220453.29784@smtp.haun-online.de>
Message-ID: <4105766A.3000709@tonybibbs.com>

Sure, will do.  Give me a few days.

--Tony

Dirk Haun wrote:

>Tony,
>
>just noticed that the PDF conversion isn't even listed in the changelog
>yet. Could you add a word or two, please?
>
>Also, do we need some additional documentation for this? I guess the
>various settings (like TTL, Tidy support, ...) aren't always too obvious
>and could benefit from some explanations.
>
>bye, Dirk
>
>
>  
>


From vfuria at gmail.com  Tue Jul 27 13:17:04 2004
From: vfuria at gmail.com (Vincent Furia)
Date: Tue, 27 Jul 2004 13:17:04 -0400
Subject: [geeklog-devel] 1.3.10 to do list
In-Reply-To: <4105766A.3000709@tonybibbs.com>
References: <41053674.9080805@tonybibbs.com> <20040726220453.29784@smtp.haun-online.de> <4105766A.3000709@tonybibbs.com>
Message-ID: <8319e2d604072710177f7055cb@mail.gmail.com>

We should update the minimum requirements for Geeklog as well.  Since
we've started using $_REQUEST in the core code in several places we'll
need to require PHP 4.1.0 or higher (at a minimum).

-Vinny

On Mon, 26 Jul 2004 16:23:54 -0500, Tony Bibbs <tony at tonybibbs.com> wrote:
> Sure, will do.  Give me a few days.
> 
> --Tony
> 
> 
> 
> Dirk Haun wrote:
> 
> >Tony,
> >
> >just noticed that the PDF conversion isn't even listed in the changelog
> >yet. Could you add a word or two, please?
> >
> >Also, do we need some additional documentation for this? I guess the
> >various settings (like TTL, Tidy support, ...) aren't always too obvious
> >and could benefit from some explanations.
> >
> >bye, Dirk
> >
> >
> >
> >
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>


From tony at tonybibbs.com  Tue Jul 27 13:34:59 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Tue, 27 Jul 2004 12:34:59 -0500
Subject: [geeklog-devel] 1.3.10 to do list
In-Reply-To: <8319e2d604072710177f7055cb@mail.gmail.com>
References: <41053674.9080805@tonybibbs.com> <20040726220453.29784@smtp.haun-online.de> <4105766A.3000709@tonybibbs.com> <8319e2d604072710177f7055cb@mail.gmail.com>
Message-ID: <41069243.8000301@tonybibbs.com>

Use of $_REQUEST, $_POST and $_GET should be encouraged in the developer 
and plugin documentation as well.

--Tony

Vincent Furia wrote:

>We should update the minimum requirements for Geeklog as well.  Since
>we've started using $_REQUEST in the core code in several places we'll
>need to require PHP 4.1.0 or higher (at a minimum).
>
>-Vinny
>
>On Mon, 26 Jul 2004 16:23:54 -0500, Tony Bibbs <tony at tonybibbs.com> wrote:
>  
>
>>Sure, will do.  Give me a few days.
>>
>>--Tony
>>
>>
>>
>>Dirk Haun wrote:
>>
>>    
>>
>>>Tony,
>>>
>>>just noticed that the PDF conversion isn't even listed in the changelog
>>>yet. Could you add a word or two, please?
>>>
>>>Also, do we need some additional documentation for this? I guess the
>>>various settings (like TTL, Tidy support, ...) aren't always too obvious
>>>and could benefit from some explanations.
>>>
>>>bye, Dirk
>>>
>>>
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>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 Jul 27 14:42:43 2004
From: vfuria at gmail.com (Vincent Furia)
Date: Tue, 27 Jul 2004 14:42:43 -0400
Subject: [geeklog-devel] 1.3.10 to do list
In-Reply-To: <20040726165851.26236@smtp.haun-online.de>
References: <20040726165851.26236@smtp.haun-online.de>
Message-ID: <8319e2d604072711421571d672@mail.gmail.com>

OK, I finally have checked in the a major update to the comment bar. 
While I have tested it pretty thoroughly, it is going to need some
major additional testing to make sure the changes haven't had any side
effects.

A side affect of some of my fixes is to view/display a comment you no
longer need the sid, title or type.

i.e.  
--NOW--
http://siteurl/comment.php?mode=display&pid=1234
http://siteurl/comment.php?mode=view&cid=1234
--BEFORE--
http://siteurl/comment.php?mode=display&sid=XXXXXXXXXXXX&title=Story+Title&type=article&pid=1234

The sid, title, type options are now disregarded but won't hurt to be
there.  Is it worth it to update the themes (and where ever else there
are links in this format)?

-Vinny

On Mon, 26 Jul 2004 17:58:51 +0200, Dirk Haun <dirk at haun-online.de> wrote:
> Okay, I think I have pretty much implemented everything that I wanted to
> go into 1.3.10. Now it's on to the usual stuff (bug fixes, documentation
> and language file updates, testing, ...).
> 
> Not sure if I'll have a go at the Admin Toolbox we've talked about or
> leave it for the next version. I may give it a try if I have a mood swing
> or something ...
> 
> Then there are a few other open issues:
> 
> Inclusion of the SpamX plugin - what's the status here? We probably need
> a new plugin API function so that plugins can filter or reject comments
> before they will be saved. Also, a method to make it easier to package
> plugins with Geeklog would be nice, e.g. by making the install script
> read the SQL for the plugin from some predefined directory (if we do
> that, it also needs to be able to handle plugin updates).
> 
> Vinny, you wanted to do some work on the comment bar. What's the status /
> plan here?
> 
> PDF: Currently, the PDF-related files all produce XHTML, which is
> inconsistent with the rest of Geeklog which produces plain ol' HTML. From
> the documentation, the PDF add-on doesn't understand XHTML either (but
> only HTML 3.2), so I don't see the need for this. Tony? Anything else
> that needs to be done on the PDF support?
> 
> A few features have been mentioned in the past as being possibly ready to
> go into the next release. Most notably spell checking and archiving of
> old stories. Tony, Blaine - any updates?
> 
> Anything else?
> 
> 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 dirk at haun-online.de  Tue Jul 27 16:08:04 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Tue, 27 Jul 2004 22:08:04 +0200
Subject: [geeklog-devel] 1.3.10 to do list
In-Reply-To: <8319e2d604072711421571d672@mail.gmail.com>
References: <8319e2d604072711421571d672@mail.gmail.com>
Message-ID: <20040727210804.20584@smtp.haun-online.de>

Vinny,

>OK, I finally have checked in the a major update to the comment bar. 
>While I have tested it pretty thoroughly, it is going to need some
>major additional testing to make sure the changes haven't had any side
>effects.

Will do.


>Is it worth it to update the themes

Can't hurt.


>(and where ever else there are links in this format)?

I don't think there aren't any other places they were used (although I'm
not entirely sure either).

bye, Dirk


-- 
http://www.haun-online.de/
http://mypod.de/



From dirk at haun-online.de  Wed Jul 28 01:54:58 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Wed, 28 Jul 2004 07:54:58 +0200
Subject: [geeklog-devel] New default theme
Message-ID: <20040728065458.30493@smtp.haun-online.de>

We've discussed the idea of picking a new default theme before. My
candidate would be the Professional theme by Victor B. Gonzalez (who's
also running aeonserv.com). I've already asked Victor for permission to
use it, should we decide to go with it, and he was happy with this.

So, what do you think?

The Professional theme is currently the default theme on <http://
aeonserv.com/> and is also installed on the Geeklog demo site, <http://
demo.geeklog.net/>.

It would need some minor adjustments (a new logo [Simon?], localisation
issues), but that shouldn't be too much work.

bye, Dirk


-- 
http://www.haun-online.de/
http://geeklog.info/



From tomw at pigstye.net  Wed Jul 28 08:58:48 2004
From: tomw at pigstye.net (Tom Willett)
Date: Wed, 28 Jul 2004 12:58:48 +0000
Subject: [geeklog-devel] New default theme
In-Reply-To: <20040728065458.30493@smtp.haun-online.de>
References: <20040728065458.30493@smtp.haun-online.de>
Message-ID: <20040728125820.M89273@pigstye.net>

I think it is time.  And the Professional would be a good choice.

--
Tom Willett
tomw at pigstye.net

---------- Original Message -----------
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Sent: Wed, 28 Jul 2004 07:54:58 +0200
Subject: [geeklog-devel] New default theme

> We've discussed the idea of picking a new default theme before. My
> candidate would be the Professional theme by Victor B. Gonzalez (who's
> also running aeonserv.com). I've already asked Victor for permission to
> use it, should we decide to go with it, and he was happy with this.
> 
> So, what do you think?
> 
> The Professional theme is currently the default theme on <http://
> aeonserv.com/> and is also installed on the Geeklog demo site, <http://
> demo.geeklog.net/>.
> 
> It would need some minor adjustments (a new logo [Simon?], localisation
> issues), but that shouldn't be too much work.
> 
> bye, Dirk
> 
> -- 
> http://www.haun-online.de/
> http://geeklog.info/
> 
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
------- End of Original Message -------



From tony at tonybibbs.com  Wed Jul 28 09:27:54 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Wed, 28 Jul 2004 08:27:54 -0500
Subject: [geeklog-devel] New default theme
In-Reply-To: <20040728065458.30493@smtp.haun-online.de>
References: <20040728065458.30493@smtp.haun-online.de>
Message-ID: <4107A9DA.3060508@tonybibbs.com>

That's fine.  I also say you take the time to nix all the other themes.  
We've discussed this before but I think we should only work with one 
theme in CVS...keeping the rest up-to-date should be delegated to the 
community.  Thoughts?

--Tony

Dirk Haun wrote:

>We've discussed the idea of picking a new default theme before. My
>candidate would be the Professional theme by Victor B. Gonzalez (who's
>also running aeonserv.com). I've already asked Victor for permission to
>use it, should we decide to go with it, and he was happy with this.
>
>So, what do you think?
>
>The Professional theme is currently the default theme on <http://
>aeonserv.com/> and is also installed on the Geeklog demo site, <http://
>demo.geeklog.net/>.
>
>It would need some minor adjustments (a new logo [Simon?], localisation
>issues), but that shouldn't be too much work.
>
>bye, Dirk
>
>
>  
>


From dirk at haun-online.de  Wed Jul 28 14:45:24 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Wed, 28 Jul 2004 20:45:24 +0200
Subject: [geeklog-devel] New default theme
In-Reply-To: <4107A9DA.3060508@tonybibbs.com>
References: <4107A9DA.3060508@tonybibbs.com>
Message-ID: <20040728194524.21620@smtp.haun-online.de>

Tony,

>I also say you take the time to nix all the other themes.  
>We've discussed this before but I think we should only work with one 
>theme in CVS...keeping the rest up-to-date should be delegated to the 
>community.  Thoughts?

I'd say we ship the old themes as a separate download for 1.3.10 and
remove them from CVS after the release.

bye, Dirk


-- 
http://www.haun-online.de/
http://mypod.de/



From tony at tonybibbs.com  Wed Jul 28 15:36:35 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Wed, 28 Jul 2004 14:36:35 -0500
Subject: [geeklog-devel] New default theme
In-Reply-To: <20040728194524.21620@smtp.haun-online.de>
References: <4107A9DA.3060508@tonybibbs.com> <20040728194524.21620@smtp.haun-online.de>
Message-ID: <41080043.9070908@tonybibbs.com>

K...at the very least when you announce .10 we should add a note saying 
this will be the last time we will be package the themes.  If you don't 
want to get rid of CVS completely we can create a Geeklog_Themes project 
too.

I'll be glad when they are gone, nothing like adding one template 
variable substitution and having to modify 20 .thtmls.

--Tony

Dirk Haun wrote:

>Tony,
>
>  
>
>>I also say you take the time to nix all the other themes.  
>>We've discussed this before but I think we should only work with one 
>>theme in CVS...keeping the rest up-to-date should be delegated to the 
>>community.  Thoughts?
>>    
>>
>
>I'd say we ship the old themes as a separate download for 1.3.10 and
>remove them from CVS after the release.
>
>bye, Dirk
>
>
>  
>


From tony at tonybibbs.com  Fri Jul 30 16:50:35 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Fri, 30 Jul 2004 15:50:35 -0500
Subject: [geeklog-devel] GL2 event model
In-Reply-To: <8319e2d604072118231fa09b79@mail.gmail.com>
References: <40FEE0CD.9000901@tonybibbs.com> <20040721220312.M50280@pigstye.net> <8319e2d604072118231fa09b79@mail.gmail.com>
Message-ID: <410AB49B.6070609@tonybibbs.com>

To fill in the blanks more I offer up the attached version.  Only 
difference is I show how the plugins are actually called.  Also, we 
might want to consider a 'priority' field for events that plugins listen 
to.  Using priorities would allow plugins to get called in some sort of 
priorty fashion.  I say that we come up with a standard set of 
priorities that plugins can use.  This make sense?

--Tony

Vincent Furia wrote:

>Here is what I had envisioned when I penned the Plugin API
>documentation.  It is a class that would be instantiated only once by
>GL2 core and available globally.  I prefer the per event registration
>as it will reduce the calls the "PluginEventHanlder" will have to make
>to listening plugins.
>
>-Vinny
>
>class PluginEventHandler {
>
>    /**
>    * Array containing event keys and listener (arrays as) values
>    * @access private
>    * @var array
>    */
>    private $listeners = array();
>
>    /**
>    * PluginEventHandler Constructor
>    *
>    * @access public
>    *
>    */
>    function __construct() {
>        // fetch registered listeners from database, populate $listeners
>    }
>
>    /**
>    * Register a plugin to listen for an event
>    *
>    * @access public
>    * @param  mixed   $event  event(s) to listen for (string or array)
>    * @param  string  $plugin plugin to be registered as listener
>    * @return boolean true on success
>    *
>    */
>    function registerListener($event, $plugin) {
>        // add the listener to the $listeners variable and the database
>    }
>
>    /**
>    * Unregister a plugin from listening for an event
>    *
>    * @access public
>    * @param  mixed   $event  event(s) to unregister (string or array)
>    * @param  string  $plugin plugin to be unregistered as listener
>    * @return boolean true on success
>    *
>    */
>    function unregisterListener($event, $plugin) {
>       // remove the listener for the specified events from $listeners
>       //   and the database.
>    }
>
>    /**
>    * Get all the listeners for a specific event
>    *
>    * @access public
>    * @param  string $event  event to get listeners of
>    * @return array  array of listeners to event $event
>    *
>    */
>    function getListeners($event) {
>       // remove the listener for the specified events from $listeners
>       //   and the database.
>    }
>
>    /**
>    * Notify all listeners that an event has occurred
>    *
>    * @access public
>    * @param  mixed $event  event requiring notification
>    * @param  mixed $vars   event specific variables
>    * @param  mixed $plugin NOTIFY_ALL, specific plugin, or array of plugins
>    * @return mixed event specific return values (or array of)
>    *
>    */
>    function notify($event, $vars, $plugin = NOTIFY_ALL) {
>
>    }
>
>}
>
>
>
>On Wed, 21 Jul 2004 22:10:55 +0000, Tom Willett <tomw at pigstye.net> wrote:
>  
>
>>Let me get this straight.
>>
>>GL2 Core would make the MySubjectObserverClass
>>
>>$obs = new MySubjectObserverClass;
>>
>>then the plugin would register by somehow getting the reference to the
>>MySubjectOvserverClass and register itself as a listener
>>
>>$obs->addListner($MyPlugin);
>>or
>>$obs->addListener($MyPlugin, $events);
>>etc
>>
>>Then when a event happened GL2 Core or a plugin could notify the plugins
>>
>>$obs->notifyAll($event)
>>
>>Do I have this about right?
>>
>>--
>>Tom Willett
>>tomw at pigstye.net
>>
>>
>>
>>---------- Original Message -----------
>>From: Tony Bibbs <tony at tonybibbs.com>
>>To: geeklog-devel at lists.geeklog.net
>>Sent: Wed, 21 Jul 2004 16:31:57 -0500
>>Subject: [geeklog-devel] GL2 event model
>>
>>    
>>
>>>The plugin API for GL2 that Vinny has drafted if surprisingly small
>>>because we are introducing an event based model.  Essentially, the GL2
>>>and all plugins have the option to register events that others can
>>>listen to.  To implement this I recommend an observer/observable design
>>>pattern similar to the example below.  A few things that need
>>>discussion.  First, the example below allows listening only at the
>>>object level.  The alternative is the force listening at the event level
>>>(in otherwords, addListener would take as a second arg an array of
>>>events the object listens to).  Any preference?  General questions?:
>>>
>>>class MySubjectObserverClass {
>>>   private $listeners = array();
>>>   private $listernerNextID  =  0;
>>>
>>>   // Alternative names: register, subscribe...
>>>   public function addListerner(&$obj)
>>>   {
>>>       $this->_listerners[] =& $obj;
>>>      return $this->listernerNextID++;
>>>   }
>>>
>>>   // Alternative name: unregister, unsubscribe...
>>>   public function removeListerner($id,'even't)
>>>   {
>>>        unset($this->listerners[$id]);
>>>   }
>>>
>>>   // Alternative name: broadcast...
>>>   public function notifyAll($event)
>>>   {
>>>       foreach ($this->listerners as $id => $obj)
>>>       {
>>>           $this->listerners[$id]->notify($event, $this);
>>>       }
>>>   }
>>>
>>>   // Alternative name: listen...
>>>   function notify($event, &$obj)
>>>   {
>>>        switch (get_class($obj)) {
>>>            case 'blah':
>>>               ...
>>>       }
>>>   }
>>>}
>>>
>>>_______________________________________________
>>>geeklog-devel mailing list
>>>geeklog-devel at lists.geeklog.net
>>>http://lists.geeklog.net/listinfo/geeklog-devel
>>>      
>>>
>>------- End of Original Message -------
>>
>>
>>
>>_______________________________________________
>>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
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aptenoPluginFactory.class.php
Type: application/x-php
Size: 3463 bytes
Desc: not available
URL: <https://pairlist8.pair.net/pipermail/geeklog-devel/attachments/20040730/95ca7e64/attachment.bin>

From dirk at haun-online.de  Fri Jul 30 17:14:23 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Fri, 30 Jul 2004 23:14:23 +0200
Subject: [geeklog-devel] GL2 and Unicode?
Message-ID: <20040730221423.32442@smtp.haun-online.de>

Looking through the existing bugreports for 1.3, I see a few dealing with
problems when using unicode and/or multi-byte character sets. Has any
thought been given to these things for GL2?

bye, Dirk


-- 
http://www.haun-online.de/
http://mypod.de/



From tony at tonybibbs.com  Fri Jul 30 17:38:26 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Fri, 30 Jul 2004 16:38:26 -0500
Subject: [geeklog-devel] Is this rocking the boat?
Message-ID: <410ABFD2.1070801@tonybibbs.com>

Ok, I think I sent this link here, but the more I read what I see, the 
more I like it.  Please take some time to read about Propel:

http://propel.phpdb.org

And read the user guide:

http://propel.phpdb.org/docs/user_guide/

The long and short of it is this.  We could implement Data Acces Objects 
that our code uses to interact with the database.  DAO is a good idea no 
matter what DB abstraction layer we use and regardless if we use a tool 
like Propel.  Essentially it hides the data access specifics from the 
developers.  Instead developers will call simple methods on the data 
access objects and let the DAO layer do the grunt work.

We could essentially use DAO to wrap the use of Propel for data acess.

That said there are some pros and cons:

Pros:
1) Clean API, developers no longer have to write SQL except in really 
rare instances.
2) Object oriented...right in line with GL2
3) Database changes are easier, now developers don't have to find all 
SQL effected by a database change.  We simply change things at the 
Propel level (wrapped by DAO), modify our HTML templates and we are off 
to the race.

Cons:
1) It is conceptionally more complicated.  Requires some ramp up.
2) Uses it's own DB abstraction layer (i.e. you can't use PEAR::DB even 
if you wanted to).
3) It's in Beta.

I think this tool could really save a ton of time.  Please give this a 
gander and try using it against a very simply table and let me know your 
thoughts.

--Tony


From tony at tonybibbs.com  Fri Jul 30 17:42:26 2004
From: tony at tonybibbs.com (Tony Bibbs)
Date: Fri, 30 Jul 2004 16:42:26 -0500
Subject: [geeklog-devel] GL2 and Unicode?
In-Reply-To: <20040730221423.32442@smtp.haun-online.de>
References: <20040730221423.32442@smtp.haun-online.de>
Message-ID: <410AC0C2.1080001@tonybibbs.com>

None, and I am ignorant on the subject.   What are the key issues? I 
assume this is related to internationalization, right?

--Tony

Dirk Haun wrote:

>Looking through the existing bugreports for 1.3, I see a few dealing with
>problems when using unicode and/or multi-byte character sets. Has any
>thought been given to these things for GL2?
>
>bye, Dirk
>
>
>  
>


From dirk at haun-online.de  Fri Jul 30 17:50:37 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Fri, 30 Jul 2004 23:50:37 +0200
Subject: [geeklog-devel] GL2 and Unicode?
In-Reply-To: <410AC0C2.1080001@tonybibbs.com>
References: <410AC0C2.1080001@tonybibbs.com>
Message-ID: <20040730225037.16184@smtp.haun-online.de>

Tony,

>None, and I am ignorant on the subject.

I'm not exactly an expert either :-/


>What are the key issues? I 
>assume this is related to internationalization, right?

The problem is that you need to be careful when doing string manipulation
on multi-byte strings. To quote from <http://www.php.net/mbstring>:

"When you manipulate (trim, split, splice, etc.) strings encoded in a
multibyte encoding, you need to use special functions since two or more
consecutive bytes may represent a single character in such encoding
schemes. Otherwise, if you apply a non-multibyte-aware string function to
the string, it probably fails to detect the beginning or ending of the
multibyte character and ends up with a corrupted garbage string that most
likely loses its original meaning."

bye, Dirk


-- 
http://www.haun-online.de/
http://geeklog.info/



From geeklog at langfamily.ca  Fri Jul 30 23:34:13 2004
From: geeklog at langfamily.ca (Blaine Lang)
Date: Fri, 30 Jul 2004 23:34:13 -0400
Subject: [geeklog-devel] 1.3.10 to do list
References: <20040726165851.26236@smtp.haun-online.de> <00e801c47331$aa157060$650a10ac@XPBL2>
Message-ID: <000f01c476af$3fe08690$650a10ac@XPBL2>

I have just submitted to CVS the changes to support the Story Archive
Feature.
I updated the themes, mysql update script and associated docs.

Dirk, I need to add one fix. I have used Javascript to disable the extra
fields in the story editor "Edit" screen if this option is disabled. The
default is for this option to be disabled unless toggled on per story. It's
a nice touch but I may have to disable it or find a quick way to leave these
new fields enabled if JS is disabled in the browser. Just about everyone has
JS enabled don't they :)

This is a topic for another day but maybe we assume JS is enabled for
Admin's and start to use JS to improve the UI.
I'd love to see a nice Tab'ed interface for some of these large admin pages.

If the user has not set the new $_CONF parm - then even if the arvhive
feature is enabled for a story and the expiry time is reached, the story
will not be effected.
$_CONF['archivetopic']          = 'archive';   // Topic ID to Auto-Archived
topics after expire date

Blaine
----- Original Message ----- 
From: "Blaine Lang" <geeklog at langfamily.ca>
To: <geeklog-devel at lists.geeklog.net>
Sent: Monday, July 26, 2004 12:57 PM
Subject: Re: [geeklog-devel] 1.3.10 to do list


I would like to add the Story Archive and can do so this week.
- Option to set a date where the story will be moved to a "defined" archive
topic or delete automatically.
- It's also possible to use a new set of template files for the archive
topic

I also have a similar feature for Blocks - where you can set the show until
time then it gets disabled.

Another item I have is a change to the advanced search results. I just need
to complete a bit more testing on that one.
I will aim for this week as well to get that in.

Blaine
----- Original Message ----- 
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Sent: Monday, July 26, 2004 11:58 AM
Subject: [geeklog-devel] 1.3.10 to do list


Okay, I think I have pretty much implemented everything that I wanted to
go into 1.3.10. Now it's on to the usual stuff (bug fixes, documentation
and language file updates, testing, ...).

Not sure if I'll have a go at the Admin Toolbox we've talked about or
leave it for the next version. I may give it a try if I have a mood swing
or something ...

Then there are a few other open issues:

Inclusion of the SpamX plugin - what's the status here? We probably need
a new plugin API function so that plugins can filter or reject comments
before they will be saved. Also, a method to make it easier to package
plugins with Geeklog would be nice, e.g. by making the install script
read the SQL for the plugin from some predefined directory (if we do
that, it also needs to be able to handle plugin updates).

Vinny, you wanted to do some work on the comment bar. What's the status /
plan here?

PDF: Currently, the PDF-related files all produce XHTML, which is
inconsistent with the rest of Geeklog which produces plain ol' HTML. From
the documentation, the PDF add-on doesn't understand XHTML either (but
only HTML 3.2), so I don't see the need for this. Tony? Anything else
that needs to be done on the PDF support?

A few features have been mentioned in the past as being possibly ready to
go into the next release. Most notably spell checking and archiving of
old stories. Tony, Blaine - any updates?

Anything else?

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

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel



From dirk at haun-online.de  Sat Jul 31 04:57:27 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Sat, 31 Jul 2004 10:57:27 +0200
Subject: [geeklog-devel] 1.3.10 to do list
In-Reply-To: <000f01c476af$3fe08690$650a10ac@XPBL2>
References: <000f01c476af$3fe08690$650a10ac@XPBL2>
Message-ID: <20040731095728.24354@smtp.haun-online.de>

Blaine,

>I have just submitted to CVS the changes to support the Story Archive
>Feature.

Nice work. A couple of comments:

I'm not happy with the $_CONF['archivetopic'] variable. Topic IDs should
be kept out of the config.php, IMO. I can think of 2 better ways to do this:

1) Add an "Archive" flag to the topics table, similar to the default
topic flag.

2) Even more flexible: Add the archive topic id to the story table, so
that stories can be archived in different topics.

I'm open to other ideas, but please keep the topic ID out of config.php.


The user interface for that option is a bit clumsy. First you have to
enable archiving and then you have to select whether you want Auto
Archive or Auto Delete. I would assume that Auto Archive is the option
you'll want in most cases, so could you make that one selected
automatically when enabling the option?


>I have used Javascript to disable the extra
>fields in the story editor "Edit" screen if this option is disabled. The
>default is for this option to be disabled unless toggled on per story. It's
>a nice touch but I may have to disable it or find a quick way to leave these
>new fields enabled if JS is disabled in the browser. Just about everyone has
>JS enabled don't they :)

Thanks to Mozilla's fine-grained Javascript options, I do have Javascript
enabled most of the time. But I do use Lynx on occasion ...


>This is a topic for another day but maybe we assume JS is enabled for
>Admin's and start to use JS to improve the UI.
>I'd love to see a nice Tab'ed interface for some of these large admin pages.

I not opposed to using Javascript to make things easier / more
comfortable, but every option should also be available without Javascript. 

bye, Dirk


-- 
http://www.haun-online.de/
http://geeklog.info/



From geeklog at langfamily.ca  Sat Jul 31 15:30:55 2004
From: geeklog at langfamily.ca (Blaine Lang)
Date: Sat, 31 Jul 2004 15:30:55 -0400
Subject: [geeklog-devel] 1.3.10 to do list
References: <000f01c476af$3fe08690$650a10ac@XPBL2> <20040731095728.24354@smtp.haun-online.de>
Message-ID: <000a01c47734$e64fca10$650a10ac@XPBL2>

Thanks for the feedback Dirk - all good points.

Item 1: The archivetopioc setting. No Problem I was just trying to not add
too many new fields.
- Adding a arhive flag is no issue.
- If I add a archivetopic field then we have to have another selectbox for
this in the editform.
Do we think users will need that extra flexibilty ?

Item2: My thinking was to make it a deliberate 2-step or 2-click process to
ensure the user was not enabling this by mistake. But have made the
suggested changed to the setting the options. Only concern is by enabling it
via the checkbox, the archive option is now also checked and the default
date is now. So - with one click if this is in error, the story will be
auto-archived upon saving.

Item3: Making this still work even with JS disabled. Well I had to think
about that one for a bit but have a nice solution (IMHO) and maybe we can
use this elseware. I added this logic to the bottom of the form and set the
template variable {showarchivedisabled} if the form area for this feature
and its controls should be disabled. Only if JS is enabled will this code
execute. I'm sure this could be enhanced or made more flexible as a
function.

   <script>
    <!-- This code will only be executed by a browser that suppports
Javascript -->
    var jstest = {showarchivedisabled}
    if (jstest) {
        document.frmstory.expire_month.disabled=true;
        .. and any other form fields
   </script>

Let me know if there is a preference for Item1
I'll hold off submitting these changes until them as it will effect the
package.

Blaine

----- Original Message ----- 
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Sent: Saturday, July 31, 2004 4:57 AM
Subject: Re: [geeklog-devel] 1.3.10 to do list


Blaine,

>I have just submitted to CVS the changes to support the Story Archive
>Feature.

Nice work. A couple of comments:

I'm not happy with the $_CONF['archivetopic'] variable. Topic IDs should
be kept out of the config.php, IMO. I can think of 2 better ways to do this:

1) Add an "Archive" flag to the topics table, similar to the default
topic flag.

2) Even more flexible: Add the archive topic id to the story table, so
that stories can be archived in different topics.

I'm open to other ideas, but please keep the topic ID out of config.php.


The user interface for that option is a bit clumsy. First you have to
enable archiving and then you have to select whether you want Auto
Archive or Auto Delete. I would assume that Auto Archive is the option
you'll want in most cases, so could you make that one selected
automatically when enabling the option?


>I have used Javascript to disable the extra
>fields in the story editor "Edit" screen if this option is disabled. The
>default is for this option to be disabled unless toggled on per story. It's
>a nice touch but I may have to disable it or find a quick way to leave
these
>new fields enabled if JS is disabled in the browser. Just about everyone
has
>JS enabled don't they :)

Thanks to Mozilla's fine-grained Javascript options, I do have Javascript
enabled most of the time. But I do use Lynx on occasion ...


>This is a topic for another day but maybe we assume JS is enabled for
>Admin's and start to use JS to improve the UI.
>I'd love to see a nice Tab'ed interface for some of these large admin
pages.

I not opposed to using Javascript to make things easier / more
comfortable, but every option should also be available without Javascript.

bye, Dirk


-- 
http://www.haun-online.de/
http://geeklog.info/

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel



From dirk at haun-online.de  Sat Jul 31 16:06:55 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Sat, 31 Jul 2004 22:06:55 +0200
Subject: [geeklog-devel] 1.3.10 to do list
In-Reply-To: <000a01c47734$e64fca10$650a10ac@XPBL2>
References: <000a01c47734$e64fca10$650a10ac@XPBL2>
Message-ID: <20040731210655.29477@smtp.haun-online.de>

Blaine,

>- Adding a arhive flag is no issue.
>- If I add a archivetopic field then we have to have another selectbox for
>this in the editform.
>Do we think users will need that extra flexibilty ?

I'm fine with either option. What do the others think?


>So - with one click if this is in error, the story will be
>auto-archived upon saving.

I see your point now and have to agree. So better leave it as it was.


>Only if JS is enabled will this code execute.

Cool. Nice solution.

bye, Dirk


-- 
http://www.haun-online.de/
http://geeklog.info/



From dirk at haun-online.de  Sat Jul 31 17:26:36 2004
From: dirk at haun-online.de (Dirk Haun)
Date: Sat, 31 Jul 2004 23:26:36 +0200
Subject: [geeklog-devel] How's the PDF generation supposed to work?
Message-ID: <20040731222636.9779@smtp.haun-online.de>

Hmm, I thought the problems I had with the PDF generation where mostly
due to the lack of a PDF plugin for MacOS X (yes, Simon, I know there's
an unofficial one), but on closer inspection, that doesn't seem to be all ...

So I have
$_CONF['pdf_enabled'] = 1;
$_CONF['pdf_adhoc_enabled'] = 0;

Normal users get the PDF icon and when they click on it, they are being
told that "The PDF feature has been disabled". So why is that icon there
in the first place?

For Admins, clicking on the PDF icon creates a new PDF file. Every time.
So after 5 clicks, I have 5 identical PDFs (for the same story). Why?

After setting

$_CONF['pdf_adhoc_enabled'] = 1;

the same thing (multiple creation of identical PDFs) happens for normal
users, too. Again: Why?

That I only get an empty browser window once pdfgenerator.php redirects
to pdfgenerator.php?cmd=getPDF&pdfFile=20040731232336946.pdf may be due
to local setup issues - still investigating that one.

bye, Dirk


-- 
http://www.haun-online.de/
http://www.haun.info/



From vfuria at gmail.com  Sat Jul 31 23:11:51 2004
From: vfuria at gmail.com (Vincent Furia)
Date: Sat, 31 Jul 2004 23:11:51 -0400
Subject: [geeklog-devel] GL2 event model
In-Reply-To: <410AB49B.6070609@tonybibbs.com>
References: <40FEE0CD.9000901@tonybibbs.com> <20040721220312.M50280@pigstye.net> <8319e2d604072118231fa09b79@mail.gmail.com> <410AB49B.6070609@tonybibbs.com>
Message-ID: <8319e2d604073120117cdc5d86@mail.gmail.com>

No problem with the addition that Tony made.  I also agree that we
should add a 'precedence' (what Tony call priority) field.  I think
this is as easy as changing one function in the class:

public function registerListener($events, $plugin)
--to--
public function registerListener($events, $plugin, $precedence = 100)

And when the $listeners field is loaded, the array of events should be
populate in order lower precedence to higher precedence.

Where $precedence is an integer that we recommend goes from 0 - 255. 
The Geeklog core then could potentially use precedence values > 255 or
< 0 if it needs to operate before or after all the other plugins. 
Really, I don't think it matters what numbers we use, so any
suggestions that are more logical from a plugin developers standpoint
would be great.

-Vinny

On Fri, 30 Jul 2004 15:50:35 -0500, Tony Bibbs <tony at tonybibbs.com> wrote:
> To fill in the blanks more I offer up the attached version.  Only
> difference is I show how the plugins are actually called.  Also, we
> might want to consider a 'priority' field for events that plugins listen
> to.  Using priorities would allow plugins to get called in some sort of
> priorty fashion.  I say that we come up with a standard set of
> priorities that plugins can use.  This make sense?
> 
> --Tony
> 
> 
> 
> Vincent Furia wrote:
> 
> >Here is what I had envisioned when I penned the Plugin API
> >documentation.  It is a class that would be instantiated only once by
> >GL2 core and available globally.  I prefer the per event registration
> >as it will reduce the calls the "PluginEventHanlder" will have to make
> >to listening plugins.
> >
> >-Vinny
> >
> >class PluginEventHandler {
> >
> >    /**
> >    * Array containing event keys and listener (arrays as) values
> >    * @access private
> >    * @var array
> >    */
> >    private $listeners = array();
> >
> >    /**
> >    * PluginEventHandler Constructor
> >    *
> >    * @access public
> >    *
> >    */
> >    function __construct() {
> >        // fetch registered listeners from database, populate $listeners
> >    }
> >
> >    /**
> >    * Register a plugin to listen for an event
> >    *
> >    * @access public
> >    * @param  mixed   $event  event(s) to listen for (string or array)
> >    * @param  string  $plugin plugin to be registered as listener
> >    * @return boolean true on success
> >    *
> >    */
> >    function registerListener($event, $plugin) {
> >        // add the listener to the $listeners variable and the database
> >    }
> >
> >    /**
> >    * Unregister a plugin from listening for an event
> >    *
> >    * @access public
> >    * @param  mixed   $event  event(s) to unregister (string or array)
> >    * @param  string  $plugin plugin to be unregistered as listener
> >    * @return boolean true on success
> >    *
> >    */
> >    function unregisterListener($event, $plugin) {
> >       // remove the listener for the specified events from $listeners
> >       //   and the database.
> >    }
> >
> >    /**
> >    * Get all the listeners for a specific event
> >    *
> >    * @access public
> >    * @param  string $event  event to get listeners of
> >    * @return array  array of listeners to event $event
> >    *
> >    */
> >    function getListeners($event) {
> >       // remove the listener for the specified events from $listeners
> >       //   and the database.
> >    }
> >
> >    /**
> >    * Notify all listeners that an event has occurred
> >    *
> >    * @access public
> >    * @param  mixed $event  event requiring notification
> >    * @param  mixed $vars   event specific variables
> >    * @param  mixed $plugin NOTIFY_ALL, specific plugin, or array of plugins
> >    * @return mixed event specific return values (or array of)
> >    *
> >    */
> >    function notify($event, $vars, $plugin = NOTIFY_ALL) {
> >
> >    }
> >
> >}
> >
> >
> >
> >On Wed, 21 Jul 2004 22:10:55 +0000, Tom Willett <tomw at pigstye.net> wrote:
> >
> >
> >>Let me get this straight.
> >>
> >>GL2 Core would make the MySubjectObserverClass
> >>
> >>$obs = new MySubjectObserverClass;
> >>
> >>then the plugin would register by somehow getting the reference to the
> >>MySubjectOvserverClass and register itself as a listener
> >>
> >>$obs->addListner($MyPlugin);
> >>or
> >>$obs->addListener($MyPlugin, $events);
> >>etc
> >>
> >>Then when a event happened GL2 Core or a plugin could notify the plugins
> >>
> >>$obs->notifyAll($event)
> >>
> >>Do I have this about right?
> >>
> >>--
> >>Tom Willett
> >>tomw at pigstye.net
> >>
> >>
> >>
> >>---------- Original Message -----------
> >>From: Tony Bibbs <tony at tonybibbs.com>
> >>To: geeklog-devel at lists.geeklog.net
> >>Sent: Wed, 21 Jul 2004 16:31:57 -0500
> >>Subject: [geeklog-devel] GL2 event model
> >>
> >>
> >>
> >>>The plugin API for GL2 that Vinny has drafted if surprisingly small
> >>>because we are introducing an event based model.  Essentially, the GL2
> >>>and all plugins have the option to register events that others can
> >>>listen to.  To implement this I recommend an observer/observable design
> >>>pattern similar to the example below.  A few things that need
> >>>discussion.  First, the example below allows listening only at the
> >>>object level.  The alternative is the force listening at the event level
> >>>(in otherwords, addListener would take as a second arg an array of
> >>>events the object listens to).  Any preference?  General questions?:
> >>>
> >>>class MySubjectObserverClass {
> >>>   private $listeners = array();
> >>>   private $listernerNextID  =  0;
> >>>
> >>>   // Alternative names: register, subscribe...
> >>>   public function addListerner(&$obj)
> >>>   {
> >>>       $this->_listerners[] =& $obj;
> >>>      return $this->listernerNextID++;
> >>>   }
> >>>
> >>>   // Alternative name: unregister, unsubscribe...
> >>>   public function removeListerner($id,'even't)
> >>>   {
> >>>        unset($this->listerners[$id]);
> >>>   }
> >>>
> >>>   // Alternative name: broadcast...
> >>>   public function notifyAll($event)
> >>>   {
> >>>       foreach ($this->listerners as $id => $obj)
> >>>       {
> >>>           $this->listerners[$id]->notify($event, $this);
> >>>       }
> >>>   }
> >>>
> >>>   // Alternative name: listen...
> >>>   function notify($event, &$obj)
> >>>   {
> >>>        switch (get_class($obj)) {
> >>>            case 'blah':
> >>>               ...
> >>>       }
> >>>   }
> >>>}
> >>>
> >>>_______________________________________________
> >>>geeklog-devel mailing list
> >>>geeklog-devel at lists.geeklog.net
> >>>http://lists.geeklog.net/listinfo/geeklog-devel
> >>>
> >>>
> >>------- End of Original Message -------
> >>
> >>
> >>
> >>_______________________________________________
> >>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  Sat Jul 31 23:17:17 2004
From: vfuria at gmail.com (Vincent Furia)
Date: Sat, 31 Jul 2004 23:17:17 -0400
Subject: [geeklog-devel] Is this rocking the boat?
In-Reply-To: <410ABFD2.1070801@tonybibbs.com>
References: <410ABFD2.1070801@tonybibbs.com>
Message-ID: <8319e2d604073120177a01fc81@mail.gmail.com>

I haven't had enough time to read up on this extensively, but it looks
promising.  We just have to make sure that it fulfills all our needs
completely and won't cause any problems down the road.  Also, we have
to be able to support it on the off chance that the current developers
drop the project.

My one worry is possible performance penalties.  I think we should
check how much overhead Propel requires.

Most importantly:  I want to see GL2 get moving really soon. So a
decision on this has to happen soon.  Can we get enough research done
on this topic that we're not causing more delays?

I'll spend some more time reading the Propel docs. If nothing else the
idea sounds pretty interesting.

-Vinny

On Fri, 30 Jul 2004 16:38:26 -0500, Tony Bibbs <tony at tonybibbs.com> wrote:
> Ok, I think I sent this link here, but the more I read what I see, the
> more I like it.  Please take some time to read about Propel:
> 
> http://propel.phpdb.org
> 
> And read the user guide:
> 
> http://propel.phpdb.org/docs/user_guide/
> 
> The long and short of it is this.  We could implement Data Acces Objects
> that our code uses to interact with the database.  DAO is a good idea no
> matter what DB abstraction layer we use and regardless if we use a tool
> like Propel.  Essentially it hides the data access specifics from the
> developers.  Instead developers will call simple methods on the data
> access objects and let the DAO layer do the grunt work.
> 
> We could essentially use DAO to wrap the use of Propel for data acess.
> 
> That said there are some pros and cons:
> 
> Pros:
> 1) Clean API, developers no longer have to write SQL except in really
> rare instances.
> 2) Object oriented...right in line with GL2
> 3) Database changes are easier, now developers don't have to find all
> SQL effected by a database change.  We simply change things at the
> Propel level (wrapped by DAO), modify our HTML templates and we are off
> to the race.
> 
> Cons:
> 1) It is conceptionally more complicated.  Requires some ramp up.
> 2) Uses it's own DB abstraction layer (i.e. you can't use PEAR::DB even
> if you wanted to).
> 3) It's in Beta.
> 
> I think this tool could really save a ton of time.  Please give this a
> gander and try using it against a very simply table and let me know your
> thoughts.
> 
> --Tony
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://lists.geeklog.net/listinfo/geeklog-devel
>