Drupal core compatibility

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
Xano's picture

With Drupal 6 being widely used and Drupal 7 on the way I believe we need to discuss what core version DROM should be compatible with. There are certain things that should be taken into account before jumping to conclusions:
- This is a rather large project. Perhaps not because it requires enormous amounts of coding, but at least because of its complexity. If it takes us long to finalise it, will Drupal 6 still be used for new projects at the time of DROM's release?
- Drupal 6 may lack certain features to support such a system and/or Drupal 7 may contain features that could greatly benefit coding speed or reduce complexity.
- Our aim is not to build a solution, but to build a tool which can only be used through solutions (other modules implementing it). Even if we do finish this project in time, it may never be used in combination with Drupal 6, because no module will implement it anymore.

Drupal 7 will probably be released early 2010. Seeing that the idea of an object model has been discussed for quite some time now and that in the near future a lot of people will be busy finishing Drupal 7 and porting contrib we may very well not be able to release DROM before Drupal 7 comes out. At that time developers will start to use Drupal 7 for their new or upgraded sites. If we develop for Drupal 6, we need to port everything to Drupal 7 again and then wait for other developers to implement DROM, which, considering that at least some of the modules that want to implement it are quite large, will take another few months.

If Standarize all entity loading (nodes, users, taxonomy, files) gets in, this would make things a lot easier for us, since we know what entities can be put in the model through hook_entity_info() and we can load them using the accompanying API. This means we no longer need hooks of our own (and cache the information they return using ugly methods). It's a little easier for us, but it saved developers who want to implement DROM a load of time and hassle.

The above two pragraphs illustrate why I would choose to start developing DROM for Drupal 7, but since this is a group effort I would very much like to know your opinion.

Comments

Xano, I agree to you. As in

derhasi's picture

Xano, I agree to you. As in D7 an entity is much more a generalization than different types of data in D6, building DROM would be easier and more efficient. Also because of a better affinity to RDF, Drupal 7 is more capable of dealing with a complex data structure.

For further work I'd suggest to first set some main goals/features DROM should provide.

I'm not sure how DROM should

fago's picture

I'm not sure how DROM should really look like, but perhaps it's similar to the entity metadata module I just created? Have a look at http://drupal.org/project/entity

It looks like there are some

Xano's picture

It looks like there are some similarities. The main difference is that DROM is supposed to handle data storage and retrieval based on relationships as well. Imagine this as comments, terms and fields being handled by DROM.

I have used parts of this

Xano's picture

I have used parts of this idea as the basis for a new element API for Drupal 8. This API serves as a basis for a new renderable element API, which in turn is the basis for a new FAPI. See http://github.com/bartfeenstra/fapitng, Form API: the next generation and FAPI TNG: how and why it works. Not that those two blog posts were written before I added proper support for object models.