[geeklog-devel] Is this rocking the boat?

Vincent Furia vfuria at gmail.com
Mon Aug 2 12:01:03 EDT 2004


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
>



More information about the geeklog-devel mailing list