[geeklog-devtalk] geeklog-devel digest, Vol 1 #449 - 8 msgs

[geeklog-devel-request at lists.geeklog.net]

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. GL2 ACL (Tony Bibbs)
   2. Re: Filtering in GL2 (Blaine Lang)
   3. Re: Filtering in GL2 (Vincent Furia)
   4. Re: GL2 ACL (Vincent Furia)
   5. Re: Framework (Vincent Furia)
   6. Re: Filtering in GL2 (Tony Bibbs)
   7. Re: GL2 ACL (Tony Bibbs)
   8. Re: Framework (Tony Bibbs)

--__--__--

Message: 1
Date: Mon, 13 Dec 2004 19:54:25 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: [geeklog-devel] GL2 ACL
Reply-To: geeklog-devel at lists.geeklog.net

Ok, I did some digging around in the archives looking for what we had 
discussed for Access Control Lists (ACL) in Geeklog 2.  Vinny 
recommended this:

http://lists.geeklog.net/pipermail/geeklog-devel/2003-June/000688.html

Vinny, is this still the direction you are thinking of? If so I have a 
question:
- the acl table listed has an id field as the PK.  Right after that is 
an item field which, I assume is a foreign key to the item table.  So 
what's the relation between the acl table and item table?  1-to-1?  
1-to-many?
- So your goal, to be clear, is to be able to, on a user-by-user bases 
or group-by-group basis control access to an item.  What's the 
performance implication on this? 

For the others on the list, this has nothing to do with the 
Auth_Enterprise work that has been done.  Auth_Enterprise controls 
access to the application, the ACL's build on that by providing detailed 
item-level security.

--Tony


--__--__--

Message: 2
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 21:44:21 -0500
Reply-To: geeklog-devel at lists.geeklog.net

Tony wrote:

> Here I assume you mean the stuff the kses filter does along with stripping 

> of unwanted HTML, right?


Correct. Today we have a number of format related functions:
    COM_killJS,
    COM_checkHTML,
    COM_handleCode,
    COM_undoSpecialChars,
    COM_formatEmail,
    COM_stripslashes,
    COM_applyFilter,
    COM_makeClickableLinks,
    COM_highlightQuery,
    COM_santizeID

I think I got them all

There are also:
   COM_buildURL,
   COM_setArgNames,
   COM_getArgument

In addition, there is much more code inside the app that is adding or 
stripping.
These have been added over time to address common needs but a major task to 
replace and consolidate the core GL 1.3 codebase.

Still, it would be good to create a new OO based class and start to use it 
and slowing migrate scripts.
The 1.3.x platform and plugins could be used to test such a new common 
class.

I'd like to get more input but would be willing to take the lead on 
developing this.

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


Blaine Lang wrote:


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

>be more flexible and consistent.

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

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

>

>This class needs to have all the common dataoperations

>- filter

>

>

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


>- prepfordisplay - handles stripslashes and html entities

>- prepforSave  - handles quotes

>

>

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


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

>

>

What else is done here beside path delimiters?


>- censor

>

>

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

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


--__--__--

Message: 3
Date: Mon, 13 Dec 2004 23:43:35 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Filtering in GL2
Reply-To: geeklog-devel at lists.geeklog.net

I vote for Blaine. :)

One thing I'd really like to see is for this class to autodetect the
different php.ini settings (magic quotes, others?) as appropriate
(including OS) and react accordingly.  Also, if possible, it should be
able to do basic "sanitizing" of form input without needing an
explicit call by a plugin or function (basically, act directly on
$_REQUEST when the gl script is first called).

I know that is all obvious, but I thought it worth while to state it. 
Let us know if you need any help Blaine. ;)

-Vinny


On Mon, 13 Dec 2004 21:44:21 -0500, Blaine Lang <geeklog at langfamily.ca> wrote:

> Tony wrote:

> > Here I assume you mean the stuff the kses filter does along with stripping

> > of unwanted HTML, right?

> 

> Correct. Today we have a number of format related functions:

>     COM_killJS,

>     COM_checkHTML,

>     COM_handleCode,

>     COM_undoSpecialChars,

>     COM_formatEmail,

>     COM_stripslashes,

>     COM_applyFilter,

>     COM_makeClickableLinks,

>     COM_highlightQuery,

>     COM_santizeID

> 

> I think I got them all

> 

> There are also:

>    COM_buildURL,

>    COM_setArgNames,

>    COM_getArgument

> 

> In addition, there is much more code inside the app that is adding or

> stripping.

> These have been added over time to address common needs but a major task to

> replace and consolidate the core GL 1.3 codebase.

> 

> Still, it would be good to create a new OO based class and start to use it

> and slowing migrate scripts.

> The 1.3.x platform and plugins could be used to test such a new common

> class.

> 

> I'd like to get more input but would be willing to take the lead on

> developing this.

> 

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

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

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

> Sent: Monday, December 13, 2004 7:29 PM

> Subject: Re: [geeklog-devel] Filtering in GL2

> 

> Blaine Lang wrote:

> 

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

> >be more flexible and consistent.

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

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

> >

> >This class needs to have all the common dataoperations

> >- filter

> >

> >

> Here I assume you mean the stuff the kses filter does along with

> stripping of unwanted HTML, right?

> 

> >- prepfordisplay - handles stripslashes and html entities

> >- prepforSave  - handles quotes

> >

> >

> Quote handling in GL2 should be transparent to the developer.   Recall

> that all custom SQL goes into a named query file and that the SQL that

> goes in there should use prepared SQL as opposed to the kind of SQL

> found in 1.3.x.  Similarly, Propel handles the retrieval of the data

> into objects so that should be transparent as well.

> 

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

> >

> >

> What else is done here beside path delimiters?

> 

> >- censor

> >

> >

> Sounds good.  Anyone want to take a stab at defining the function

> prototypes of the oo-based class?  I'm not sure of all the things we are

> talking about here.

> 

> --Tony

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

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

> 

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

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

>


--__--__--

Message: 4
Date: Mon, 13 Dec 2004 23:54:37 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] GL2 ACL
Reply-To: geeklog-devel at lists.geeklog.net

On Mon, 13 Dec 2004 19:54:25 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:

> Vinny, is this still the direction you are thinking of? If so I have a

> question:

Yes, I'll do my best to answer.


> - the acl table listed has an id field as the PK.  Right after that is

> an item field which, I assume is a foreign key to the item table.  So

> what's the relation between the acl table and item table?  1-to-1?

> 1-to-many?

1 item can have many rows in the acl table.


> - So your goal, to be clear, is to be able to, on a user-by-user bases

> or group-by-group basis control access to an item.  What's the

> performance implication on this?

Actually I don't think performance will be a problem.  All that needs
to be done is a single SQL call with a straight join or two DB calls. 
I suspect that Propel will do the latter.  In any case the select
(and/or join) will be on table indices so it will be very fast.  When
I first started out with this idea I did a sample using 1.3.x's
article table and making a basic acl table.  The difference between
getting the permissions via 1.3.x methods vs. with acls was not
noticible until I was selecting hundreds of articles and even then I
wouldn't call the difference a huge performance hit.  Unfortunately I
think I lost that code...


> For the others on the list, this has nothing to do with the

> Auth_Enterprise work that has been done.  Auth_Enterprise controls

> access to the application, the ACL's build on that by providing detailed

> item-level security.

Yes, though I still will argue that Geeklog should keep a
"permissions" table (story.edit, etc) internally and ACLs should be
kept against that as well.  But I bet Tony and I will talk about that
later. :)

And so people know where I got most of these ideas: I did a lot of
work with the Andrew File System (AFS) in school, and grew to really
like the granularity of its permissions system.  Heres a web site that
goes into the basics of that:
http://www.psc.edu/general/filesys/afs/setpermissions.html.  Hopefully
you'll be able to see what I was shooting for.

-Vinny

--__--__--

Message: 5
Date: Tue, 14 Dec 2004 00:15:39 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Framework
Reply-To: geeklog-devel at lists.geeklog.net

Tony (and everyone),

This response was a long time in coming but hopefully it will be worth
it.  I now know more than I really ever wanted to about what Tony
would like to see in a Hunting Log. :)

Most everything looks to be on the up and up.  I really liked how
Propel and the MVCnPHP interact to make an application really easy to
put together.  I'm even starting to get used to the idea of having a
central store to keep SQL queries (though it still seems a bit
strange).  We're going to need to expand it though to be able to
handle different queries for different databases (hopefully a rare
occurrence, but something I could easily see happening).

Concerns: Creole.  I'm sure its good, and everything I've read about
it seems positive but it isn't in wide spread use and I have yet to
see a performance benchmark with it compared to some of the other DB
abstraction layers.  The only reason I'm worried is that a slow
abstraction layer can hamstring the speed of the entire program.  This
was seen a couple years ago when ADODB was 2-3x faster than PEAR::DB. 
I know a few projects that were using PEAR and suffered as a result (I
understand that PEAR::DB has improved a lot since then, this was just
an example).

Dislikes: I don't like using the DAO to abstract past the Propel
classes.  It seems silly and $dao->save($hunt) makes less sense to me
than $hunt->save().  I understand you want to abstact in case we
decide to replace Propel (or Creole, or something) some time in the
distant future, but I think we could do that just as easily by
changing the $hunt class, or inheriting it and overloading the
necessary functions.

And a note, I haven't actually looked at the code inside Propel or
Creole.  Unless someone (Tony) has taken a look, it might be a small
risk that the code may be unmaintainable (though I doubt it).  While
Tony pointed out all this code is supported.  If any of these projects
one day die we may have to pick it up just to keep GL2 working...  We
really shouldn't depend on code that we would not be willing to
maintain if push came to shove.

-Vinny

On Fri, 10 Dec 2004 16:15:15 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:

> I know you are all busy and that some of you still hope to review the

> code I sent over.  In the interest of getting some sort of feedback I

> have released the code on geeklog.net:

> 

> http://www.geeklog.net/article.php/GL2FrameworkCode

> 

> Just an FYI

> 

> --Tony

> _______________________________________________

> geeklog-devel mailing list

> geeklog-devel at lists.geeklog.net

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

>


--__--__--

Message: 6
Date: Tue, 14 Dec 2004 08:25:58 -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

Vinny, this is all good for the 1.3.x version of the class.  The 2.0 
version, though, need not worry about magic quotes as Propel should take 
care of that.

--Tony

Vincent Furia wrote:


>I vote for Blaine. :)

>

>One thing I'd really like to see is for this class to autodetect the

>different php.ini settings (magic quotes, others?) as appropriate

>(including OS) and react accordingly.  Also, if possible, it should be

>able to do basic "sanitizing" of form input without needing an

>explicit call by a plugin or function (basically, act directly on

>$_REQUEST when the gl script is first called).

>

>I know that is all obvious, but I thought it worth while to state it. 

>Let us know if you need any help Blaine. ;)

>

>-Vinny

>

>

>On Mon, 13 Dec 2004 21:44:21 -0500, Blaine Lang <geeklog at langfamily.ca> wrote:

>  

>

>>Tony wrote:

>>    

>>

>>>Here I assume you mean the stuff the kses filter does along with stripping

>>>of unwanted HTML, right?

>>>      

>>>

>>Correct. Today we have a number of format related functions:

>>    COM_killJS,

>>    COM_checkHTML,

>>    COM_handleCode,

>>    COM_undoSpecialChars,

>>    COM_formatEmail,

>>    COM_stripslashes,

>>    COM_applyFilter,

>>    COM_makeClickableLinks,

>>    COM_highlightQuery,

>>    COM_santizeID

>>

>>I think I got them all

>>

>>There are also:

>>   COM_buildURL,

>>   COM_setArgNames,

>>   COM_getArgument

>>

>>In addition, there is much more code inside the app that is adding or

>>stripping.

>>These have been added over time to address common needs but a major task to

>>replace and consolidate the core GL 1.3 codebase.

>>

>>Still, it would be good to create a new OO based class and start to use it

>>and slowing migrate scripts.

>>The 1.3.x platform and plugins could be used to test such a new common

>>class.

>>

>>I'd like to get more input but would be willing to take the lead on

>>developing this.

>>

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

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

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

>>Sent: Monday, December 13, 2004 7:29 PM

>>Subject: Re: [geeklog-devel] Filtering in GL2

>>

>>Blaine Lang wrote:

>>

>>    

>>

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

>>>be more flexible and consistent.

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

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

>>>

>>>This class needs to have all the common dataoperations

>>>- filter

>>>

>>>

>>>      

>>>

>>Here I assume you mean the stuff the kses filter does along with

>>stripping of unwanted HTML, right?

>>

>>    

>>

>>>- prepfordisplay - handles stripslashes and html entities

>>>- prepforSave  - handles quotes

>>>

>>>

>>>      

>>>

>>Quote handling in GL2 should be transparent to the developer.   Recall

>>that all custom SQL goes into a named query file and that the SQL that

>>goes in there should use prepared SQL as opposed to the kind of SQL

>>found in 1.3.x.  Similarly, Propel handles the retrieval of the data

>>into objects so that should be transparent as well.

>>

>>    

>>

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

>>>

>>>

>>>      

>>>

>>What else is done here beside path delimiters?

>>

>>    

>>

>>>- censor

>>>

>>>

>>>      

>>>

>>Sounds good.  Anyone want to take a stab at defining the function

>>prototypes of the oo-based class?  I'm not sure of all the things we are

>>talking about here.

>>

>>--Tony

>>_______________________________________________

>>geeklog-devel mailing list

>>geeklog-devel at lists.geeklog.net

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

>>

>>_______________________________________________

>>geeklog-devel mailing list

>>geeklog-devel at lists.geeklog.net

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

>>

>>    

>>

>_______________________________________________

>geeklog-devel mailing list

>geeklog-devel at lists.geeklog.net

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

>  

>



--__--__--

Message: 7
Date: Tue, 14 Dec 2004 08:30:47 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] GL2 ACL
Reply-To: geeklog-devel at lists.geeklog.net

Vincent Furia wrote:


>Actually I don't think performance will be a problem.  All that needs

>to be done is a single SQL call with a straight join or two DB calls. 

>I suspect that Propel will do the latter.  

>

We can force Propel to do it the way we ask.  If it natively wants to do 
2 calls we can use a named query and force a join instead.  There may 
even be a way to do the joins with the Propel models themselves but this 
I haven't tried yet.


>Yes, though I still will argue that Geeklog should keep a

>"permissions" table (story.edit, etc) internally and ACLs should be

>kept against that as well.  But I bet Tony and I will talk about that

>later. :)

>  

>

Right, the system privileges would go in Auth_Enterprise.  The 
item-level settings would go in the gl-database.  Of course, we will 
combine the data structures of the two so we are really talking about 
the same database.


>And so people know where I got most of these ideas: I did a lot of

>work with the Andrew File System (AFS) in school, and grew to really

>like the granularity of its permissions system.  Heres a web site that

>goes into the basics of that:

>http://www.psc.edu/general/filesys/afs/setpermissions.html.  Hopefully

>you'll be able to see what I was shooting for.

>  

>

Didn't know that.  I'll have to take a gander.

--Tony

--__--__--

Message: 8
Date: Tue, 14 Dec 2004 08:53:05 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Framework
Reply-To: geeklog-devel at lists.geeklog.net

Vincent Furia wrote:


>I now know more than I really ever wanted to about what Tony

>would like to see in a Hunting Log. :)

>  

>

Lol!


>Most everything looks to be on the up and up.  I really liked how

>Propel and the MVCnPHP interact to make an application really easy to

>put together.  I'm even starting to get used to the idea of having a

>central store to keep SQL queries (though it still seems a bit

>strange).  We're going to need to expand it though to be able to

>handle different queries for different databases (hopefully a rare

>occurrence, but something I could easily see happening).

>  

>

Yeah, good point.  There are probably two ways to do this:

1) Each named_query file could be tied to specific database (read: dsn)
2) Modify the non-existent (but soon to be created) xml schema (i.e. 
.xsd) to wrap the <query> tags in a <database> tag.  Only issue there is 
do we care to support queries that pull data across more than one 
database?  I vote for no...that's too complicated and I think in that 
case you should just get a handle to the database connections you need 
and go to work yourself.  As much as I would like to keep our 
commands/views free of SQL there will always be exceptions.


>Concerns: Creole.  I'm sure its good, and everything I've read about

>it seems positive but it isn't in wide spread use and I have yet to

>see a performance benchmark with it compared to some of the other DB

>abstraction layers.  The only reason I'm worried is that a slow

>abstraction layer can hamstring the speed of the entire program.  This

>was seen a couple years ago when ADODB was 2-3x faster than PEAR::DB. 

>I know a few projects that were using PEAR and suffered as a result (I

>understand that PEAR::DB has improved a lot since then, this was just

>an example).

>

>Dislikes: I don't like using the DAO to abstract past the Propel

>classes.  It seems silly and $dao->save($hunt) makes less sense to me

>than $hunt->save().  I understand you want to abstact in case we

>decide to replace Propel (or Creole, or something) some time in the

>distant future, but I think we could do that just as easily by

>changing the $hunt class, or inheriting it and overloading the

>necessary functions.

>  

>

I'll tackle both of these at the same time.  Using the DAO layer should 
address your concerns about Creole both from a performance view and a 
shelf-life perspective.  It may seem like an un-needed layer of 
abstraction but it builds just the sort of buffer we need so that if we 
needed to make drastic changes to our data access layer that our 
commands/views/etc wouldn't have to change much. 

I can see your points on the using, for example, the save() method right 
on the model object but I argue that this is actually a design flaw of 
Propel as it breaks the rule of encapsulation.  Domain objects, IMHO, 
shouldn't need to know how to persist themselves to the database.  The 
persistence mechanism should be its own atomic bit of code and it should 
know how to save any domain object. 

I've sent a note to the propel-users list in hopes of having one of them 
address the performance concerns.  I'd like to think they have done some 
benchmarking already...but you never know.


>And a note, I haven't actually looked at the code inside Propel or

>Creole.  Unless someone (Tony) has taken a look, it might be a small

>risk that the code may be unmaintainable (though I doubt it).  While

>Tony pointed out all this code is supported.  If any of these projects

>one day die we may have to pick it up just to keep GL2 working...  We

>really shouldn't depend on code that we would not be willing to

>maintain if push came to shove.

>  

>

I've looked at some of the code.  AFAICT, it's in pretty good shape with 
a fairly good design.  The model objects generate by Propel are actually 
quite straightforward...the most complicated code is the lazy loading of 
child objects for a given domain object and even that stuff isn't too 
bad.  But don't take my word for it...others should give it a gander and 
tell me what they think.  Oh, and I haven't looked at the Creole code at 
all.

--Tony


--__--__--

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


End of geeklog-devel Digest