<meta charset="utf-8"><div>Is the goal of 4.0 really to make Drupal a requirement? I'm a fan of being CMS agnostic, I mean lets be real here Drupal is awesome (and our CMS of choice) but it still has many less installs than Wordpress or Joomla.</div>
<div><br></div><div>My understanding is the main reason Drupal 7 is slower is the PDO/DBTNG so I would be reluctant to add more processing to the system, we already have a reputation for slowing things down. </div><br><div class="gmail_quote">
On Fri, May 7, 2010 at 2:07 PM, Matt Chapman <span dir="ltr"><<a href="mailto:matt@ninjitsuweb.com">matt@ninjitsuweb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I'm currently reviewing the Entity API module as the possible missing piece:<br>
<br>
<a href="http://drupal.org/project/entity" target="_blank">http://drupal.org/project/entity</a><br>
<br>
All the Best,<br>
<br>
Matt Chapman<br>
Ninjitsu Web Development<br>
<font color="#888888"><br>
--<br>
The contents of this message should be assumed to be Confidential, and<br>
may not be disclosed without permission of the sender.<br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
On Fri, May 7, 2010 at 10:42 AM, Joe Murray<br>
<<a href="mailto:joe.murray@jmaconsulting.biz">joe.murray@jmaconsulting.biz</a>> wrote:<br>
> Just speculating still, but if DBTNG has a fairly cleanly severable<br>
> interface, and CiviCRM core were to use it, there would be little bloat for<br>
> CiviCRM for Joomla. CiviCRM for Joomla doesn't really get used as a<br>
> development framework in the way that CiviCRM for Drupal does, just because<br>
> of what the CMSes are good for. I get that there is an unnecessary new layer<br>
> for CiviCRM which is a drag. I'm still unclear if there might be an upside<br>
> in terms of making CiviCRM integrated with Fields, Views, etc as 'native'<br>
> objects rather than as external objects with 'plug-ins' written for them.<br>
><br>
> Joe Murray, PhD<br>
> President, JMA Consulting<br>
> <a href="mailto:joe.murray@jmaconsulting.biz">joe.murray@jmaconsulting.biz</a><br>
> skype JosephPMurray twitter JoeMurray<br>
> 416.466.1281<br>
><br>
><br>
> On Fri, May 7, 2010 at 1:32 PM, Sami Khan <<a href="mailto:sami@etopian.net">sami@etopian.net</a>> wrote:<br>
>><br>
>> There are plenty of well defined PHP ORM projects out there; also<br>
>> another abstraction layer over PDO which is already a database<br>
>> abstraction layer just to do it the Drupal way doesn't make sense to me.<br>
>><br>
>> Sami<br>
>><br>
>> On Fri, 2010-05-07 at 09:56 -0700, Michael Prasuhn wrote:<br>
>> > Well, what the database layer in Drupal 7 does and doesn't do is a<br>
>> > little blurry sometimes. For the most part it functions as primarily a query<br>
>> > builder and abstraction layer (now supporting 5 databases!*). It is not<br>
>> > however, an ORM. In that sense DBTNG isn't really suited for any type of<br>
>> > data structure over any other type. Drupal 7 is focusing some of the<br>
>> > functionality of an ORM at the entity level, with it's Field API. At this<br>
>> > point, the line between easily removed library and tightly coupled code is<br>
>> > crossed, and that functionality isn't possible without moving most of the<br>
>> > functionality into Drupal.<br>
>> ><br>
>> > Could a simple ORM be built on top of DBTNG? I don't see why not, but at<br>
>> > that point it's not really a 'Drupal like API' anymore, and you'd be back to<br>
>> > where you started, although the ORM code would look more familiar to Drupal<br>
>> > developers.<br>
>> ><br>
>> > -Mike<br>
>> ><br>
>> > *MySQL, PostgreSQL, SQLite, Oracle, and MS SQL Server<br>
>> > __________________<br>
>> > Michael Prasuhn<br>
>> > <a href="mailto:mike@mikeyp.net">mike@mikeyp.net</a><br>
>> > <a href="http://mikeyp.net" target="_blank">http://mikeyp.net</a><br>
>> ><br>
>> > On May 7, 2010, at 6:12 AM, Joe Murray wrote:<br>
>> ><br>
>> > > I'm trying to get my head around architectural options for CiviCRM 4.0<br>
>> > > that might allow one to more easily leverage of 'Drupal as a developer<br>
>> > > framework' as opposed to 'Drupal as user CMS'. This would IMHO meet a<br>
>> > > CiviCRM goal of increasing its developer community.<br>
>> > ><br>
>> > > I just want to talk about the database layer right now to keep things<br>
>> > > focussed. One of the frameworks being consider as a replacement for the PEAR<br>
>> > > library (DBDataObject and HTML Quickform in particular) is the Zend<br>
>> > > Framework. It uses PDO libraries. DBTNG for Drupal 7, as I understand it,<br>
>> > > also sits on top of PDO. I find Mike Prasuhn's information about the<br>
>> > > modularity of the Drupal 7 db layer to be very interesting. For those who<br>
>> > > don't know, CiviCRM currently uses a fairly traditional tiered architecture,<br>
>> > > and generates its data layer code from an XML representation of its data<br>
>> > > schema for the most part (some business layer logic bypasses the Data<br>
>> > > Application Object (DAO) layer by reading directly from the MySQL tables for<br>
>> > > optimization purposes, for example). I imagine that the DBTNG layer is<br>
>> > > focussed on supporting Drupal data structures, but I believe it has some<br>
>> > > support for creating access to arbitrary non-Drupal data stores as well,<br>
>> > > which CiviCRM might qualify as.<br>
>> > ><br>
>> > > Is it remotely feasible to think of using DBTNG as the primary<br>
>> > > database layer for CiviCRM 4.0? What is the overhead of using for non-Drupal<br>
>> > > sites? Or is it better to imagine setting up access to the couple hundred<br>
>> > > tables in CiviCRM via DBTNG's external datasource structure, and then using<br>
>> > > that as a good way to integrate with fields, views and that good stuff?<br>
>> > ><br>
>> > > Just trying to explore whether there is some common ground here.<br>
>> > ><br>
>> > > Joe Murray, PhD<br>
>> > > President, JMA Consulting<br>
>> > > <a href="mailto:joe.murray@jmaconsulting.biz">joe.murray@jmaconsulting.biz</a><br>
>> > > skype JosephPMurray twitter JoeMurray<br>
>> > > 416.466.1281<br>
>> ><br>
>> > _______________________________________________<br>
>> > consulting mailing list<br>
>> > <a href="mailto:consulting@drupal.org">consulting@drupal.org</a><br>
>> > <a href="http://lists.drupal.org/mailman/listinfo/consulting" target="_blank">http://lists.drupal.org/mailman/listinfo/consulting</a><br>
>><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> consulting mailing list<br>
> <a href="mailto:consulting@drupal.org">consulting@drupal.org</a><br>
> <a href="http://lists.drupal.org/mailman/listinfo/consulting" target="_blank">http://lists.drupal.org/mailman/listinfo/consulting</a><br>
><br>
><br>
_______________________________________________<br>
consulting mailing list<br>
<a href="mailto:consulting@drupal.org">consulting@drupal.org</a><br>
<a href="http://lists.drupal.org/mailman/listinfo/consulting" target="_blank">http://lists.drupal.org/mailman/listinfo/consulting</a><br>
</div></div></blockquote></div><br>