[geeklog-devtalk] geeklog-devel digest, Vol 1 #495 - 4 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. Re: GL2 DataAccess Class (Tony Bibbs)
   2. Re: Autoincrement on Items (Tony Bibbs)
   3. Links to-do (Tony Bibbs)
   4. Re: Links to-do (Vincent Furia)

--__--__--

Message: 1
Date: Thu, 27 Jan 2005 21:01:39 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] GL2 DataAccess Class
Reply-To: geeklog-devel at lists.geeklog.net

Vinny, finally getting back to addressing some issues. You are right 
here. However, 95% of the inserts, updates and deletes should come 
through the use of the domain objects themselves, right? For the 
remaining 5%, I think they should just use raw SQL in the named query file.

So to be clear you'd use the PropelDAO::save to do the inserts and 
updates and the PropelDAO::delete to delete an object.

Correct me if I am missing something.

--Tony

Vincent Furia wrote:


>I guess I should have been more specific...

>

>There is no way to use criteria to do UPDATEs or DELETEs (criteria

>with INSERTs doesn't make much sense).

>

>It is not clear if what behavior specifying the SQL for UDPATEs,

>DELETEs and INSERTs will be.  From reading the code it looks like the

>SQL will be executed, I'm just not sure if the program will stop with

>an error afterwards or throw an exception or just return an empty

>result set.

>

>I haven't tested the DAO code under these conditions, but it looks

>like something that needs be corrected.

>

>-Vinny

>

>

>On Mon, 17 Jan 2005 11:41:21 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:

>  

>

>>You sure?  It's an easy fix to get around that...but seems the

>>updates/deletes should work.

>>

>>--Tony

>>

>>Vincent Furia wrote:

>>

>>    

>>

>>>Tony,

>>>

>>>Another issue with the DAO class is that it seems catered to providing

>>>support only for SELECT's.  It won't work for doing INSERT's,

>>>UPDATE's, or DELETE's (etc...).

>>>

>>>-Vinny

>>>

>>>

>>>On Mon, 17 Jan 2005 09:39:04 -0500, Vincent Furia <vfuria at gmail.com> wrote:

>>>

>>>

>>>      

>>>

>>>>Tony,

>>>>

>>>>Caching between page calls would be great.  But even having a static

>>>>variable or something similar to persist between calls to the "find"

>>>>method would be a good start (and probably sufficient for most sites).

>>>>

>>>>-Vinny

>>>>

>>>>

>>>>On Mon, 17 Jan 2005 08:32:53 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:

>>>>

>>>>

>>>>        

>>>>

>>>>>You mean cache it to memory or to a file.  I'd love to cache it to

>>>>>memory but, afaik, it would require php's shared memory which isn't

>>>>>enabled by default.

>>>>>

>>>>>I s'pose if the xml parsing itself if that bad, would could cache a

>>>>>php-friendly data structure to a file.

>>>>>

>>>>>I'm open to this.  I just learned how to profile PHP applications this

>>>>>past week so finding poor performing code shouldn't be a problem.

>>>>>

>>>>>--Tony

>>>>>

>>>>>Vincent Furia wrote:

>>>>>

>>>>>

>>>>>

>>>>>          

>>>>>

>>>>>>Tony,

>>>>>>

>>>>>>Just looking through the DAO to understand everything it is doing

>>>>>>better.  I noticed that the "find" method (and the other methods)

>>>>>>reloads the named queries from the xml file on every call.  We should

>>>>>>look for a way to work around this (i.e. somehow cache the DOMXPath

>>>>>>object) so as not to suffer huge penalties for parsing the XML file on

>>>>>>every DB call.

>>>>>>

>>>>>>-Vinny

>>>>>>_______________________________________________

>>>>>>geeklog-devel mailing list

>>>>>>geeklog-devel at lists.geeklog.net

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

>>>>>>

>>>>>>

>>>>>>

>>>>>>

>>>>>>            

>>>>>>

>>>>>_______________________________________________

>>>>>geeklog-devel mailing list

>>>>>geeklog-devel at lists.geeklog.net

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

>>>>>

>>>>>

>>>>>

>>>>>          

>>>>>

>>>_______________________________________________

>>>geeklog-devel mailing list

>>>geeklog-devel at lists.geeklog.net

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

>>>

>>>

>>>      

>>>

>>_______________________________________________

>>geeklog-devel mailing list

>>geeklog-devel at lists.geeklog.net

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

>>

>>    

>>

>_______________________________________________

>geeklog-devel mailing list

>geeklog-devel at lists.geeklog.net

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

>  

>



--__--__--

Message: 2
Date: Thu, 27 Jan 2005 21:10:29 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: [geeklog-devel] Re: Autoincrement on Items
Reply-To: geeklog-devel at lists.geeklog.net

So you're saying to keep the 'security by obscurity' we get by using the 
sid's?  Sounds good, only gripe is what do you do if you are running 
Geeklog-2 under more than one webserver?  

This is a great question though. Do you depend a bit on obscurity or 
depend on your code to do the appropriate security checking.  If we want 
to stick with some obscurity, is there something beside timestamps we 
could do it with?

FYI, I moved this to the -devel list

--Tony

Vincent Furia wrote:


>Tony,

>

>Just was thinking about one concern about allowing visibility

>to/access by the auto increment column of the item table.  Currently

>in Geeklog with the pseudo random story ids or manually set ids there

>is no chance of a person knowing that another item exists that they

>might have access to.

>

>But if you can see item ids in Gl2 (auto incrementing), and they can

>see story 5 and link 7 they know that there must be (or have been at

>some point) an item 6.

>

>Just something to keep in mind.  Especially if we Gl2 to have the same

>reputation as 1.x.

>

>-Vinny

>  

>



--__--__--

Message: 3
Date: Thu, 27 Jan 2005 21:28:07 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: [geeklog-devel] Links to-do
Reply-To: geeklog-devel at lists.geeklog.net

Here are some things the links plugin needs to do (in no particular 
order).  The first thing are things addressed across plugins and should 
be addressed in the framework of the 'item' concept.  The second list 
are things specific to the link plugin.

- allow security defaults to be set for plugins
- email notification when items get accepted, denied, etc
- Disable items
- Rating of items (possibly a seperate plugin)

- Ability to report a broken or inappropriate link
- links give ownership to the submiter.  Should work just like stories 
in 1.3.x
- Nested categories (handled by current data model)
- Count click-thru's. Should be configurable to turn this off
- Automatic checking that links work (optional cron script or something)

More anybody?  Trying to get this all articulate for Kevin.  It's worth 
noting that I did go through the 1.3.x feature list to generate some of 
this.  I need to double check it that I didn't miss something.

--Tony


--__--__--

Message: 4
Date: Fri, 28 Jan 2005 11:32:11 -0500
From: Vincent Furia <vfuria at gmail.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Links to-do
Reply-To: geeklog-devel at lists.geeklog.net

An addition for "accross all plugins":

- submission moderation


> - links give ownership to the submiter.  Should work just like stories

> in 1.3.x

I think authorship should always go to the submitter, default
"ownership" in the sense of the ability to control the item (edit,
delete, change permissions) should be configurable in some way (and
probably should not default to the submitter).

-Vinny

On Thu, 27 Jan 2005 21:28:07 -0600, Tony Bibbs <tony at tonybibbs.com> wrote:

> Here are some things the links plugin needs to do (in no particular

> order).  The first thing are things addressed across plugins and should

> be addressed in the framework of the 'item' concept.  The second list

> are things specific to the link plugin.

> 

> - allow security defaults to be set for plugins

> - email notification when items get accepted, denied, etc

> - Disable items

> - Rating of items (possibly a seperate plugin)

> 

> - Ability to report a broken or inappropriate link

> - links give ownership to the submiter.  Should work just like stories

> in 1.3.x

> - Nested categories (handled by current data model)

> - Count click-thru's. Should be configurable to turn this off

> - Automatic checking that links work (optional cron script or something)

> 

> More anybody?  Trying to get this all articulate for Kevin.  It's worth

> noting that I did go through the 1.3.x feature list to generate some of

> this.  I need to double check it that I didn't miss something.

> 

> --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


End of geeklog-devel Digest