Hi JP In the matter-of-fact - datasource agnostic model is M in *proper* MVC. Look at Agavi frameworks' approach. Their initial model is simple PHP object with some framework tie-in's (of course it is possible to loose those tie-in and work with POPO). It gives developers the posibility to design models based on their needs (or project demands - anyways you don't think about DB schema at that stage) from top to bottom. Models, I'm writing about, are called domain models.
For instance: some time ago one of my Agavi projects had some issues with Propel objects. The domain models were using Propel objects inernally -- completely hiding them -- so I could *transparently* switch Propel to simple mysql_* or PDO. From the outside models API was intact. My answer for your question is: Make your own models, because It is more powerfull solution than you think. Especially when Symfony is still good framework even without Propel/Doctrine generators. On Tue, Aug 4, 2009 at 12:36 PM, Andrei Dziahel <trickster...@gmail.com>wrote: > > Hi. > > Take my +1 too. > > Regards. > > 2009/7/31, JP <jph...@gmail.com>: > > > > Hi, > > > > In symfony 1.2, I can only create models using one of the 2 ORMs > > Doctrine or Propel. Each of the 2 plugins implements some tasks for > > generating an admin backend, creating fixture data, some input > > validation. > > > > Now let's say I want to use a different data source, that is not a > > database covered by the ORMs, for example: > > - a web API (twitter, last.fm, flickr, salesforce.com ...) > > - a SOAP web service > > - a datastore like CouchDB > > > > I believe that if I want to use one of those, I'll have to build or > > find a plugin similar to sfPropelPlugin or sfDoctrinePlugin to access > > the data source. In case my datasource provides CRUD functionnality, I > > might want to generate an admin interface, which means creating a > > generator and maybe duplicating code with the default ORMs admin > > generator. > > > > Another approach would be to have a set of datasource agnostic model > > classes that will provide feature such as an admin generator, input > > validation, fixture import and an interface to the datasource. This > > will allow developers to create custom models for various datasource > > and not be restricted to databases. > > > > I believe this feature is similar to DataSources in CakePHP or to the > > ActiveModel planned for Rails 3. I've also been using that pattern > > other the past couple years in a custom PHP framework that is used for > > a web app using a SOAP backend. I work on daily basis with SOAP > > developers (on new features for instance), where I need to start > > building my webapp sometimes before the web service is ready. In this > > case I create my model class and use a datasource yaml (which will be > > a simple yaml file with dummy data) and when the web service is ready, > > I just have to switch the datasource. This allows me to not wait and > > be able to develop features in parallel with the backend. > > > > So, I was wondering what is the approach taken by symfony for this > > particular use case? Is there any plan on the roadmap for 1.3 or 2.0 > > to provide a unified model layer that will allow developers to use > > custom data sources? > > > > Thanks! > > > > > > > > > > > -- > Отправлено с моего мобильного устройства > > With the best regards, Andy. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
