The ORM is good. Being able to link a database table, fieldsets, forms and validation together in one model, with observers to add functionality, is handy.
Now, it would be great to be able to set up a model that is more-or-less compatible with the ORM interface, but is not locked to a database. For example, I have contacts (essentially people) in a CRM that I need to interact with. The FuelPHP application is linked to the CRM through a SOAP or REST interface. You can still do all the appropriate operations on the contacts that you would be able to do if the contacts were local, through that interface - get, save, find etc.
So, the question is, what is the best way to do this? The ORM appears to be pretty much locked to a local database to operate. Ideally, the ORM would be built in layers, with the database layer (a "driver"?) at the bottom and storage-agnostic layers to interact with the application above. That way there is some code reuse by being able to switch out the database storage layer for a SOAP API layer. If I am not mistaken, it is not built like that, so what I have been doing is replicating the ORM API as best I can, but there is a lot to replicate.
So, has anyone here done something similar? Should the ORM be split into layers that can be replaced as needed? Do we need a "remote_orm" package to provide an ORM-interface compatible model than can be built upon? Is there already one I simply have not found yet? Does any of that make the slightest bit of sense?
-- Jason
PS This is FuelPHP 1.2 - not sure if 2.x changes all that anyway. Not sure if this should be posted to the ORM forum - this is kind of about a model that looks like an ORM to the application, but actually has a different storage mechanism.
The ORM model uses the query class to run the queries, which in turn uses the DB class to pass them to the driver which passes them to the RDBMS engine.
If you want to do something like this, probably your best bet is to replace the Query class. Currently it's referenced hard-coded, so you might have to think about how to approach this issue.
As to the future, Jelmer decided not to develop the ORM any further. It will be supported in 2.0 as a legacy package to provide compatibility with existing 1.x applications.
The reason for this decision is simple: designing, building and maintaining an ORM is very complex and time consuming (I've could have told him that, as I maintain CI's Datamapper). There are plenty of good and well maintained generic ORM's available for use, so we've decided 2.0 will get interfaces to those, which frees Jelmer to work at his new job of being Fuel's architect and 2.0 core designer.
If someone will come forward to keep maintaining or improving the current ORM, we will provide all support needed to do that.
Okay, so looking for a third-party supported package may be one approach.
So, the whole approach to building forms and the validation object - is that all going with the orm, i.e. do we need to learn a whole new set of classes, functionality and model configuration for 2.0 new apps? I'm just wondering for stuff I'm doing now in 1.2, whether learning how to use the orm package to its full extent is a skill I can carry forward, or a waste of time if 2.0 goes down a different path.
Difficult to judge at the moment.
We are committed to providing backward compatibility to make the transition from 1.x to 2.0 as painless as possible. I don't want to face a rewrite for all my apps either.
Under the hood it will definitely look quite different, not sure yet what the final impact will be. You can see how validation is developing here: https://github.com/fuelphp/validation
So validation is now a separate library. Nice.
I'll have to get 2.0 installed and have a play with it.
I've got a request for validation anyway, something I found immensely useful on other projects: the ability to chain validations together, so that they can call each other up hierarchically. For example, a validation rule may validate an input as an array, then pass each element (or key) of the array on to a child validation rule that may validate the values as integers. So instead of a validation rule called "list of emails" (as there is now), you could chain two rules together: "comma-separated list of values" feeding each value into "valid_email". On the Xaraya project, that turned out to be immensely powerful by allowing complex structures to be validated by chaining the validation rule primitives. I'm wondering how easy that would be to implement here? Not all validation rules can have child rules, but those involving lists often can.
Just looking at the Xaraya pre-process rule I wrote many moons ago, I've just realised how similar it is to the valid_string_rule.
Anyway, just an idea to throw out there...
Just as a quick "me too" on this conversation, I am in a similar situation right now.
I have an app that runs entirely off ORM based models, and we have just decided that the fuel app will no longer be integrating with the database. Because it no longer integrates with the database, I will be replacing all these functions with API calls.
Originally I was trying to re-use my models for this - adding functions to each model to replace core functions, etc. Either way, it didn't work out as I had hoped, so I guess I will be making the API calls from the Controllers.
I'm excited to see what fuel 2.0 brings us for in these areas - it sounds much more flexible in that area.
Donate
