DataMgr 2.1 Beta

Posted At : May 29, 2007 10:41 AM | Posted By : Steve
Related Categories: DataMgr

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. 

Comments (5) | Print | del.icio.us | Digg It! | Linking Blogs | 1983 Views
Comments (Comment Moderation is enabled. Your comment will not appear until approved.)
[Add Comment]
It would be great if we could add to the XML for a data field that it was a "file" field. Thus when the content was loaded in it would be able to handle the content appropriately. I was thinking we could even pass in [fieldname]_file on the form, and create some sort of handler for it. Then upon the existance of a change we could pass it to the dataset as [fieldname] with the actual filename that we are storing.
# Posted By John Farrar | 6/5/07 2:27 AM
John,

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.
# Posted By Steve Bryant | 6/5/07 1:30 PM
So in my case you would just let the co-processor handle the file uploads from forms.
# Posted By John Farrar | 6/6/07 11:59 AM
John,

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.
# Posted By Steve Bryant | 6/6/07 12:20 PM
Stay tuned for version 0.4, it seems to work fine in COOP to send a file to the co-processor. File upload seems to work just fine. More challenging was figuring out how to pass the upload directory to the page. Yet, once resolved it was simple and logical.
# Posted By John Farrar | 6/6/07 8:24 PM
[Add Comment]
BlogCFC was created by Raymond Camden. This blog is running version 5.8.001.