[geeklog-devel] Propel revisit

[Tony Bibbs]

FYI, the XSLT requirement is only for the build process...not for all 
application using it.

--Tony

Vincent Furia wrote:

>I just noticed this about propel (pre-installation requirements):
>
>#  PHP >= 5.0.0 with XSLT support (--with-xsl on *nix, or enable
>php_xsl.dll on Windows)
>
>Is XSLT a commonly supported item?  Can we depend on it being compiled
>in on most PHP5 installations at ISPs?
>
>-Vinny
>
>
>On Mon, 02 Aug 2004 09:13:03 -0500, Tony Bibbs <tony at tonybibbs.com> wrote:
>  
>
>>Well, as far as other DB connections go, that is up to the coder,
>>obviously.  GL2 should only worry about talking to the GL2 database so
>>if you want to access another database you should, without much hassle,
>>be able to open connections using the Creole DB layer that Propel uses:
>>
>>http://creole.phpdb.org/wiki/
>>
>>Obviously you can still do your own with PEAR::DB or raw MySQL in your
>>code.  The DAO layer simply provides a slick way to prevent the
>>developer from issuing raw SQL in the code...sometimes that can't be
>>avoided and I'm sure there is probably way to issue raw SQL in unique
>>scenarios (I need to verify that).
>>
>>--Tony
>>
>>
>>
>>Blaine Lang wrote:
>>
>>    
>>
>>>It does look interesting and like many new libraries or models, it may be
>>>able to improve code readability, reduce code size, and improve
>>>re-useability but I do wonder if
>>>1) There are any SQL usage restrictions or more complex SQL queries that
>>>will not work.
>>>2) Will you still be able to use another DB access method and direct mysql_
>>>calls using PHP
>>>3) Making GL2 too complex to understand for developers will effect it's
>>>support
>>>
>>>I have had reason on several occasions to need to access another mysql
>>>database when doing application integration. I just used the direct php
>>>mysql_ calls and created a 2nd DBlink. The current mysql library in GL1.x
>>>does not support this. We should consider this need in GL2
>>>
>>>Blaine
>>>----- Original Message -----
>>>From: "Vincent Furia" <vfuria at gmail.com>
>>>To: <geeklog-devel at lists.geeklog.net>
>>>Sent: Saturday, July 31, 2004 11:17 PM
>>>Subject: Re: [geeklog-devel] Is this rocking the boat?
>>>
>>>
>>>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
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>_______________________________________________
>>>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
>  
>