DataMgr 2.1 Beta
DataMgr 2.1 is now in beta. Aside from fixing one or two small bugs, nothing has changed from the Alpha release.
It take this as a pretty good sign as I changed a fair bit of the inner workings of DataMgr in order to achieve the new features of 2.1. It has been running on several live sites for a few days now without any problems.
There is one new feature that I forgot to mention in my post about the alpha release. I have removed the restriction that the field names in a join table must match the associated fields in each table that it is joining (resolving bug #2).
A feature that I mentioned in the alpha, but bears mentioning again is the custom relation type. I have already gotten a good deal of mileage from this feature in the weeks since I released the Alpha of 2.1.
The tells DataMgr to include the results of a SQL statement (processed as a subquery) as a column in the resultset for a table. DataMgr will allow you to include it as a column and you can also filter by the value resulting from the SQL statement.
This basically allows you to create any kind of relation field that you want - including relationships that are much more complex than the ones built-into DataMgr.
The advantage of this is that it allows you to define a complex relationship in one place and then use it throughout your application without worrying about the complexities of the underlying logic.
This continues one of the main ideas of DataMgr - that it allows you to interact with the database as though it were set up to handle data in just the way you want it to.
If you have time, download DataMgr 2.1 Beta. It should be pretty stable, but let me know if you run into any problems.
I have wrestled with that idea a bit. Ultimately, I think that it would mean having DataMgr handle concerns that it is not meant to handle. Namely, it would then be involved in interacting with the file system instead of just the database.
I have my custom tag set handle that (something similar to your COOP framework). I could certainly create a component that would handle file uploads as well as interact with DataMgr, but cffile's dependence on the Form scope makes that an unattractive option to me right now.
That's right. Your co-processor acts much like a page controller. As such, it makes sense that it handles form-specific actions and translates data from a format for the form to one for the CFC.
In the case of a file upload, that means that it would upload the file and replace that form field value with the name of the uploaded file.
Ideally, cffile should be able to use another scope than form to allow us to upload files from a CFC, but that isn't how it works now.