[geeklog-devtalk] geeklog-devel digest, Vol 1 #448 - 12 msgs

geeklog-devel-request at lists.geeklog.net geeklog-devel-request at lists.geeklog.net
Mon Dec 13 19:31:02 EST 2004


Send geeklog-devel mailing list submissions to
geeklog-devel at lists.geeklog.net

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.geeklog.net/listinfo/geeklog-devel
or, via email, send a message with subject or body 'help' to
geeklog-devel-request at lists.geeklog.net

You can reach the person managing the list at
geeklog-devel-admin at lists.geeklog.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of geeklog-devel digest..."


Today's Topics:

1. Re: Framework (Dirk Haun)
2. Re: Namespaces (Dirk Haun)
3. Re: GL2 Framework (Tony Bibbs)
4. Re: Look-up Tables in GL2 (Dirk Haun)
5. Re: Look-up Tables in GL2 (Tony Bibbs)
6. Re: Namespaces (Vincent Furia)
7. Re: Look-up Tables in GL2 (Vincent Furia)
8. Re: Look-up Tables in GL2 (Vincent Furia)
9. Re: Look-up Tables in GL2 (Dirk Haun)
10. Filtering in GL2 (Tony Bibbs)
11. Re: Filtering in GL2 (Blaine Lang)
12. Re: Filtering in GL2 (Tony Bibbs)

--__--__--

Message: 1
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Framework
Date: Mon, 13 Dec 2004 21:25:39 +0100
Organization: Terra Software Systems
Reply-To: geeklog-devel at lists.geeklog.net

Blaine wrote:


>I still had to modify your ini set line in the config.php to use a ; instead

>of a : as a path delimiter.


Windows, eh?

Tony, you may want to use PATH_SEPARATOR. See lib-common.php :-)

bye, Dirk


--
http://www.haun-online.de/
http://www.handful-of-sparks.de/


--__--__--

Message: 2
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Namespaces
Date: Mon, 13 Dec 2004 21:27:57 +0100
Organization: Terra Software Systems
Reply-To: geeklog-devel at lists.geeklog.net

Tony,


>All core Geeklog code would start with the Geeklog_ prefix in their

>class names.

[...]

>I wanted to throw this in for dicussion as this will need to be

>finalized and documented well early on.


Sounds okay to me.

I couldn't believe that PHP 5 doesn't support namespaces yet, but
apparently it doesn't. I wonder were I got the idea from ...

bye, Dirk


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


--__--__--

Message: 3
Date: Mon, 13 Dec 2004 14:37:37 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] GL2 Framework
Reply-To: geeklog-devel at lists.geeklog.net

Yeah, I'm making no assumptions on what people are doing with their free
time. It's obvious with my wife-and-two-kids-under-3 lifestyle that I
won't have the time to do a lot of day-to-day coding but I do have
enough time to do organize the general direction and help on critical
pieces of code.

My only hope is to build a somewhat devoted group for GL2. Being
devoted doesn't require a lot of time, just consistent amounts of time
on a week-by-week basis. Having Vinny is a start and I was just
contacted by someone else who got my message on the users lists that
sounds promising. I think ideally I'd have 5 people on the gl2
kernel...4 at a minumum to meet the Feb. 1 date.

I think if you can review code from time-to-time while you do your 1.3.x
work that is a good start. We can never have enough eyes on code. Thanks,

--Tony

Blaine Lang wrote:


>Tony,

>

>I have been contributing on the 1.3 support and development but with all my

>plugins the demand is very high on my time to maintain them. The codebase

>for the forum plugin alone very demanding. And the other core plugins need a

>lot more attention and they are used heavily by the current users.

>

>It's imperative that the 1.3.x code base continue the excellent support that

>Dirk and others of the team have been able to maintain and I don't think

>anyone is saying anything else. I am solidly behind GL2 but also am very

>dependant on 1.3 and it's become a very solid development framework for me.

>

>I definitely want to contribute on the API and Module area of development.

>

>>From what I've seen so far, it's not the team members and wana-be team

>members lack of desire and intent to contrbute it's that we have different

>cycles of available time.

>

>-- Blaine

>

>----- Original Message -----

>From: "Tony Bibbs" <tony at tonybibbs.com>

>To: <geeklog-devel at lists.geeklog.net>; <geeklog-users at lists.geeklog.net>

>Sent: Monday, December 13, 2004 11:07 AM

>Subject: [geeklog-devel] GL2 Framework

>

>

>I've yet to hear anything substantive since the original 12/2 email I

>sent on the topic. In the interest of time I'm going to move on but it

>is worth noting one thing. The GL2 progress has been embarassingly

>slow. I take full accountablity for this. This latest effort to move

>forward on the codebase will be my last. ..if things stagnate again I

>will formally put my GL coding days behind me and leave the entire long

>term vision of GL to Dirk. To help keep things moving I am hoping to

>delegate as much work as possible to those with more time...however you

>might note that quality help is a rare commodity. The progress that can

>be made is directly tied the help I cant count on. I've had a number of

>nibbles from people willing to help but none of them panned out, nearly

>all sighting time commitments. So to expand on what I have already

>said, unless I can get other developers to devote some amount of time to

>GL2 I will need to officially kill the notion of GL2. To that end I am

>setting a Februrary 1st deadline for myself and any that choose to help

>on producing the complete GL2 framework code so that plugin development

>can begin. Anything short of that I will view as failure.

>

>I've cc'd the users mailing list in the hopes that some on that list

>might consider contributing to GL2.

>

>My apologies if this all sounded a bit dramatic...I simply wanted to,

>one last time, assert my hopes to get the project moving and my

>willingness to step aside for the lack of progress.

>

>--Tony

>_______________________________________________

>geeklog-devel mailing list

>geeklog-devel at lists.geeklog.net

>http://lists.geeklog.net/listinfo/geeklog-devel

>

>_______________________________________________

>geeklog-devel mailing list

>geeklog-devel at lists.geeklog.net

>http://lists.geeklog.net/listinfo/geeklog-devel

>

>



--__--__--

Message: 4
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Look-up Tables in GL2
Date: Mon, 13 Dec 2004 21:39:19 +0100
Organization: Terra Software Systems
Reply-To: geeklog-devel at lists.geeklog.net

Tony,


>In GL2 I'm proposing we use a single table to serve all those needs.


Makes sense.



>The issue I really

>wanted to discuss was one brought up by someone recently (name escapes

>me) on how to handle the translation of text stored in drop downs. I

>have been assuming we would pipe the text in the actual database table

>through our translation library...seems simple enough but I wanted to

>make sure I wasn't over looking anything.


Remind me again where GL2 will keep the translated text strings - in
language files or in the database?

Anyway, I seem to remember that when there's no translation for a string,
it would use the english text, so there's no problem with keeping things
consistent.

That would be okay then (and would get rid of one of the annoyances in
the 1.3 design).

bye, Dirk


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


--__--__--

Message: 5
Date: Mon, 13 Dec 2004 15:03:51 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Look-up Tables in GL2
Reply-To: geeklog-devel at lists.geeklog.net

Right now we plan on using Translation2 from PEAR. They support using
the database and gettext. I'm not sure which we plan to favor...I was
leaving that decision until Vinny finishes taking a look at it. Also I
think Translation2 will always use the default langauge in the case a
string was missing but I'd have to double check that.

Thanks,

--Tony

Dirk Haun wrote:


>Tony,

>

>

>

>>In GL2 I'm proposing we use a single table to serve all those needs.

>>

>>

>

>Makes sense.

>

>

>

>

>>The issue I really

>>wanted to discuss was one brought up by someone recently (name escapes

>>me) on how to handle the translation of text stored in drop downs. I

>>have been assuming we would pipe the text in the actual database table

>>through our translation library...seems simple enough but I wanted to

>>make sure I wasn't over looking anything.

>>

>>

>

>Remind me again where GL2 will keep the translated text strings - in

>language files or in the database?

>

>Anyway, I seem to remember that when there's no translation for a string,

>it would use the english text, so there's no problem with keeping things

>consistent.

>

>That would be okay then (and would get rid of one of the annoyances in

>the 1.3 design).

>

>bye, Dirk

>

>

>

>



--__--__--

Message: 6
Date: Mon, 13 Dec 2004 16:21:28 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Namespaces
Reply-To: geeklog-devel at lists.geeklog.net

I agree that this is the way to go. I'll try to update what
documentation we have on the wiki with this...

-Vinny


On Mon, 13 Dec 2004 21:27:57 +0100, Dirk Haun <dirk at haun-online.de> wrote:

> Tony,

>

> >All core Geeklog code would start with the Geeklog_ prefix in their

> >class names.

> [...]

> >I wanted to throw this in for dicussion as this will need to be

> >finalized and documented well early on.

>

> Sounds okay to me.

>

> I couldn't believe that PHP 5 doesn't support namespaces yet, but

> apparently it doesn't. I wonder were I got the idea from ...

>

> bye, Dirk

>

> --

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

> http://www.macosx-faq.de/

>

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devel

>


--__--__--

Message: 7
Date: Mon, 13 Dec 2004 16:29:45 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Look-up Tables in GL2
Reply-To: geeklog-devel at lists.geeklog.net

Right now I'm leaning toward using the Translation2's gettext for
doing all the translation. It's pretty smooth, very fast, and will
even work on PHP installs without gettext support (though obviously
not as quickly as with gettext support). Another advantage is that
we'll be able to modify the translation files online via a web-based
administration tool.

I didn't want to go with database for a couple reasons. If we went
the database root we'd have to do caching and other tricks for speed
or else performance would be really awful. Also Translation2 only
supports PEAR::DB, which would mean a hassle since Propel only
supports Creole. We'd either have to run with two DB abstraction
layers (really, really bad) or else port one or the other library to
the other DB layer (more work then I think any of us want to commit
two). Besides that I don't see any big advantages to using the DB
over gettext. If anyone knows of any please speak up now.

Also I encourage people to try out Translation2 if you get the chance.
Though its not necessary, I think you'll get a kick out of how easy
it will make things.

</$.02>

-Vinny


On Mon, 13 Dec 2004 15:03:51 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:

> Right now we plan on using Translation2 from PEAR. They support using

> the database and gettext. I'm not sure which we plan to favor...I was

> leaving that decision until Vinny finishes taking a look at it. Also I

> think Translation2 will always use the default langauge in the case a

> string was missing but I'd have to double check that.

>

> Thanks,

>

> --Tony

>

> Dirk Haun wrote:

>

> >Tony,

> >

> >

> >

> >>In GL2 I'm proposing we use a single table to serve all those needs.

> >>

> >>

> >

> >Makes sense.

> >

> >

> >

> >

> >>The issue I really

> >>wanted to discuss was one brought up by someone recently (name escapes

> >>me) on how to handle the translation of text stored in drop downs. I

> >>have been assuming we would pipe the text in the actual database table

> >>through our translation library...seems simple enough but I wanted to

> >>make sure I wasn't over looking anything.

> >>

> >>

> >

> >Remind me again where GL2 will keep the translated text strings - in

> >language files or in the database?

> >

> >Anyway, I seem to remember that when there's no translation for a string,

> >it would use the english text, so there's no problem with keeping things

> >consistent.

> >

> >That would be okay then (and would get rid of one of the annoyances in

> >the 1.3 design).

> >

> >bye, Dirk

> >

> >

> >

> >

>

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devel

>


--__--__--

Message: 8
Date: Mon, 13 Dec 2004 16:32:10 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Look-up Tables in GL2
Reply-To: geeklog-devel at lists.geeklog.net

Oh yeah, the lookup table looks good to me. Though I would suggest a
name change. :) "lov" seems a bit strong to me. ;)

-Vinny

Apologies to anyone injured by the really, really bad humor.

On Mon, 13 Dec 2004 13:31:10 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:

> Today in GL 1.3.x we have a number of look up tables (e.g. gl_postmodes,

> gl_cookiecodes, gl_featurecodes, etc). All nearly look exactly the same

> in terms of their structure but they serve wildly different needs. In

> GL2 I'm proposing we use a single table to serve all those needs. This

> isn't anything 'new' in concept but it is new to GL. Anyway I call this

> table the List_of_Values table and it would look roughly like this:

>

> CREATE TABLE list_of_values (

> lov_id int(10) unsigned NOT NULL auto_increment,

> group_name varchar (30) NOT NULL,

> short_name varchar(30) NOT NULL,

> description varchar(128),

> enabled tinyint(1) NOT NULL DEFAULT '1',

> sort_order mediumint(10) NOT NULL DEFAULT '0',

> PRIMARY KEY (lov_id),

> INDEX (group_name)

> ) TYPE=INNODB;

>

> I don't think there will be much argument over the structure but I

> wanted to make sure this made sense to everybody. The issue I really

> wanted to discuss was one brought up by someone recently (name escapes

> me) on how to handle the translation of text stored in drop downs. I

> have been assuming we would pipe the text in the actual database table

> through our translation library...seems simple enough but I wanted to

> make sure I wasn't over looking anything.

>

> --Tony

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

> http://lists.geeklog.net/listinfo/geeklog-devel

>


--__--__--

Message: 9
From: "Dirk Haun" <dirk at haun-online.de>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Look-up Tables in GL2
Date: Mon, 13 Dec 2004 22:48:45 +0100
Organization: Terra Software Systems
Reply-To: geeklog-devel at lists.geeklog.net

Vinny,


>Right now I'm leaning toward using the Translation2's gettext for

>doing all the translation. It's pretty smooth, very fast, and will

>even work on PHP installs without gettext support


Good point. GL2's requirements are already pretty steep, and gettext
doesn't seem to be widely available.



>Also I encourage people to try out Translation2 if you get the chance.


Right, I remember another of Tony's emails that I didn't respond to
[hangs head in shame]

bye, Dirk


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


--__--__--

Message: 10
Date: Mon, 13 Dec 2004 16:25:00 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: [geeklog-devel] Filtering in GL2
Reply-To: geeklog-devel at lists.geeklog.net

Dirk,

You have done a lot of work building the filtering functions in 1.3.x.
They are quite new to me (I don't think any code I have written ever
used them). I think you have gotten to a point where you are pretty
happy with how all that works. I was thinking of simply pulling those
functions out into a class for GL2 as I don't see our needs for this in
GL2 changing. I have a couple of questions assuming that is true:

1) is all the code minus the kses code yours? I'm thinking about the
dual license issue here so if I have to 'rewrite' them enough to make
them ours I will. If they are yours I won't need to touch them...if you
think contributions came from elsewhere I will.

2) are there any missing features in the current filtering scheme you
can think of? Any limitations (speed, etc) worth discussing?

--Tony

--__--__--

Message: 11
From: "Blaine Lang" <geeklog at langfamily.ca>
To: <geeklog-devel at lists.geeklog.net>
Subject: Re: [geeklog-devel] Filtering in GL2
Date: Mon, 13 Dec 2004 18:02:35 -0500
Reply-To: geeklog-devel at lists.geeklog.net

Tony,

The filtering of input parms as you know is very important and an area that
has really improved since GL 1.3.8 but I would like to suggest we need to
rethink the method used as we have had to extend and add COM functions to do
various filtering an now there are too many that at times conflict with each
other.

Dirk and I have talked on and off about the need for a OO class that would
be more flexible and consistent.
Also we need to be able to pass an array of parms so that we don't have to
make 10 function calls at times with larger forms for example.

This class needs to have all the common dataoperations
- filter
- prepfordisplay - handles stripslashes and html entities
- prepforSave - handles quotes
- prepforOS -- handles directory path delimiters for example.
- censor

There is more but my headcold is effecting my neural network ;)


----- Original Message -----
From: "Tony Bibbs" <tony at tonybibbs.com>
To: <geeklog-devel at lists.geeklog.net>
Sent: Monday, December 13, 2004 5:25 PM
Subject: [geeklog-devel] Filtering in GL2


Dirk,

You have done a lot of work building the filtering functions in 1.3.x.
They are quite new to me (I don't think any code I have written ever
used them). I think you have gotten to a point where you are pretty
happy with how all that works. I was thinking of simply pulling those
functions out into a class for GL2 as I don't see our needs for this in
GL2 changing. I have a couple of questions assuming that is true:

1) is all the code minus the kses code yours? I'm thinking about the
dual license issue here so if I have to 'rewrite' them enough to make
them ours I will. If they are yours I won't need to touch them...if you
think contributions came from elsewhere I will.

2) are there any missing features in the current filtering scheme you
can think of? Any limitations (speed, etc) worth discussing?

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


--__--__--

Message: 12
Date: Mon, 13 Dec 2004 18:29:42 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Filtering in GL2
Reply-To: geeklog-devel at lists.geeklog.net

Blaine Lang wrote:


>Dirk and I have talked on and off about the need for a OO class that would

>be more flexible and consistent.

>Also we need to be able to pass an array of parms so that we don't have to

>make 10 function calls at times with larger forms for example.

>

>This class needs to have all the common dataoperations

>- filter

>

>

Here I assume you mean the stuff the kses filter does along with
stripping of unwanted HTML, right?


>- prepfordisplay - handles stripslashes and html entities

>- prepforSave - handles quotes

>

>

Quote handling in GL2 should be transparent to the developer. Recall
that all custom SQL goes into a named query file and that the SQL that
goes in there should use prepared SQL as opposed to the kind of SQL
found in 1.3.x. Similarly, Propel handles the retrieval of the data
into objects so that should be transparent as well.


>- prepforOS -- handles directory path delimiters for example.

>

>

What else is done here beside path delimiters?


>- censor

>

>

Sounds good. Anyone want to take a stab at defining the function
prototypes of the oo-based class? I'm not sure of all the things we are
talking about here.

--Tony


--__--__--

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


End of geeklog-devel Digest



More information about the geeklog-devtalk mailing list