[consulting] CiviCRM / Zend Framework / DBTNG

[Matt Chapman]

I'm currently reviewing the Entity API module as the possible missing piece:

http://drupal.org/project/entity

All the Best,

Matt Chapman
Ninjitsu Web Development

--
The contents of this message should be assumed to be Confidential, and
may not be disclosed without permission of the sender.



On Fri, May 7, 2010 at 10:42 AM, Joe Murray
<joe.murray at jmaconsulting.biz> wrote:
> Just speculating still, but if DBTNG has a fairly cleanly severable
> interface, and CiviCRM core were to use it, there would be little bloat for
> CiviCRM for Joomla. CiviCRM for Joomla doesn't really get used as a
> development framework in the way that CiviCRM for Drupal does, just because
> of what the CMSes are good for. I get that there is an unnecessary new layer
> for CiviCRM which is a drag. I'm still unclear if there might be an upside
> in terms of making CiviCRM integrated with Fields, Views, etc as 'native'
> objects rather than as external objects with 'plug-ins' written for them.
>
> Joe Murray, PhD
> President, JMA Consulting
> joe.murray at jmaconsulting.biz
> skype JosephPMurray twitter JoeMurray
> 416.466.1281
>
>
> On Fri, May 7, 2010 at 1:32 PM, Sami Khan <sami at etopian.net> wrote:
>>
>> There are plenty of well defined PHP ORM projects out there; also
>> another abstraction layer over PDO which is already a database
>> abstraction layer just to do it the Drupal way doesn't make sense to me.
>>
>> Sami
>>
>> On Fri, 2010-05-07 at 09:56 -0700, Michael Prasuhn wrote:
>> > Well, what the database layer in Drupal 7 does and doesn't do is a
>> > little blurry sometimes. For the most part it functions as primarily a query
>> > builder and abstraction layer (now supporting 5 databases!*). It is not
>> > however, an ORM. In that sense DBTNG isn't really suited for any type of
>> > data structure over any other type. Drupal 7 is focusing some of the
>> > functionality of an ORM at the entity level, with it's Field API. At this
>> > point, the line between easily removed library and tightly coupled code is
>> > crossed, and that functionality isn't possible without moving most of the
>> > functionality into Drupal.
>> >
>> > Could a simple ORM be built on top of DBTNG? I don't see why not, but at
>> > that point it's not really a 'Drupal like API' anymore, and you'd be back to
>> > where you started, although the ORM code would look more familiar to Drupal
>> > developers.
>> >
>> > -Mike
>> >
>> > *MySQL, PostgreSQL, SQLite, Oracle, and MS SQL Server
>> > __________________
>> > Michael Prasuhn
>> > mike at mikeyp.net
>> > http://mikeyp.net
>> >
>> > On May 7, 2010, at 6:12 AM, Joe Murray wrote:
>> >
>> > > I'm trying to get my head around architectural options for CiviCRM 4.0
>> > > that might allow one to more easily leverage of 'Drupal as a developer
>> > > framework' as opposed to 'Drupal as user CMS'. This would IMHO meet a
>> > > CiviCRM goal of increasing its developer community.
>> > >
>> > > I just want to talk about the database layer right now to keep things
>> > > focussed. One of the frameworks being consider as a replacement for the PEAR
>> > > library (DBDataObject and HTML Quickform in particular) is the Zend
>> > > Framework. It uses PDO libraries. DBTNG for Drupal 7, as I understand it,
>> > > also sits on top of PDO. I find Mike Prasuhn's information about the
>> > > modularity of the Drupal 7 db layer to be very interesting. For those who
>> > > don't know, CiviCRM currently uses a fairly traditional tiered architecture,
>> > > and generates its data layer code from an XML representation of its data
>> > > schema for the most part (some business layer logic bypasses the Data
>> > > Application Object (DAO) layer by reading directly from the MySQL tables for
>> > > optimization purposes, for example). I imagine that the DBTNG layer is
>> > > focussed on supporting Drupal data structures, but I believe it has some
>> > > support for creating access to arbitrary non-Drupal data stores as well,
>> > > which CiviCRM might qualify as.
>> > >
>> > > Is it remotely feasible to think of using DBTNG as the primary
>> > > database layer for CiviCRM 4.0? What is the overhead of using for non-Drupal
>> > > sites? Or is it better to imagine setting up access to the couple hundred
>> > > tables in CiviCRM via DBTNG's external datasource structure, and then using
>> > > that as a good way to integrate with fields, views and that good stuff?
>> > >
>> > > Just trying to explore whether there is some common ground here.
>> > >
>> > > Joe Murray, PhD
>> > > President, JMA Consulting
>> > > joe.murray at jmaconsulting.biz
>> > > skype JosephPMurray twitter JoeMurray
>> > > 416.466.1281
>> >
>> > _______________________________________________
>> > consulting mailing list
>> > consulting at drupal.org
>> > http://lists.drupal.org/mailman/listinfo/consulting
>>
>>
>
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>
>