Some DBIC::API changes in the pipe and other ranblings

I heart git. I really do. It enables a great development paradigm that allows for easy collaboration for projects with developers all over the world.

That said, there is a branch that you should be tracking for DBIC::API, specifically, the object_split branch. Apparently abraxxa needed some functionally that I had mostly written out when developing the 2.x release. He added it back in. And for the most part, it is clean. I still need to push my clean up changes up to the catagits repo, though.

Abraxxa also added the functionality to specify a data root for a single object. ExtJS specifically has that part of the Action.Form uncustomizable (which will likely be fixed at some point). That means it expects the result to always be in "data" which doesn't jive for being able to customize the result key for things like restful stores.

Also, rafl has been developing a better way to do the dispatching for multiple vs. single objects. Right now it pretty much forwards to objects, and then forwards on to the intended action. This is fail and breaks chaining (as in the case of single objects, and addressed by the object_split branch). Ideally, we'd like to implement a chain that works conditionally. A -> (B || C) -> D -> (E || F). This would allow us to keep the same singular functions in place (update_or_create) that operate on a list of objects, but the prep to get to that point would be dependent either captured args or whatever.

It isn't there yet, but we will make it work. We want this module to be as flexible as possible. And we are doing that.

DBIC::API is being used, right now, in production, for various applications including ExtJS (which is the biggest driver of our development right now). It should be more than suitable for your basic CRUD tasks. Ideally, we would like to gain more developer support for other systems that speak other dialects than REST and RPC. Your contributions would very much be welcome.

We have a lot of momentum at the moment in making this project the best we can. At some point, I'd very much like to push to have it included in various Task projects (Kensho any one?), but that is a little ways away.

In other news, it is starting to look like I will be attending YAPC::EU. It isn't final yet, but the finances are in place to execute. This means I need to get the ball rolling on writing abstracts, and doing talk submissions for both YAPC::NA and EU (of course, I am going to NA!).

If you have never attended a Perl workshop or conference, I highly recommend that you do. It is where the vast community gathers to share the latest and greatest in ideas. Some are more practical. Some are more theoretical. But all of them good. You can learn a lot about modern Perl practices, talk directly with core developers of key technologies such as Moose, Catalyst, POE, etc., and get a feel for the people that come together to solve these common problems. It is enlightening.