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.

POE and its infinite awesomeness

For the past couple of years, I have been one of the very few to actually mention or discuss POE specific technologies at any of the various Perl conferences or workshops. This makes me sad.

POE is a fantastic framework with a very well defined and mature API. As a project it is... wise. It isn't old. It isn't dead. I would argue that POE is one of the longest lived, and thriving Perl projects on CPAN. And in fact, POE handles many mission critical apps on the backends for several companies. You just don't see it.

With the advent of newer modules that claim to be the messiah of asynchronous events, POE has developed a sort of marketing problem. POE doesn't release as often because of how mature the framework is. In addition, several other factors contribute to POE not grabbing the spot light. This leads people to believe POE is old school, or that it is too big to be used for their one off projects. I'd like to fix that. I'd like to educate people on why POE is very much still alive and what that means when you have asynchronous requirements for your heavy-lifting backends.

That said, this YAPC::NA, I am attempting to organize enough speakers to speak on the topic of POE (Intro, Core, Extentions, Next-Gen POE technologies, Application specific successes) that the conference organizers will have no choice but to give us a significant block of time on one of the tracks. This will involve a lot of work. There is a core group of us meeting in irc://irc.perl.org/#reflex to make this happen. We have a lot of code to write.

So please, if you use POE and have an interest in seeing the next evolution of POE work, come join us. We won't bite. Promise.

DBIC::API Update

Be prepared, folks. The next installment of DBIC::API will be backwards compatible breaking. This means if you were relying on the old behavior of manipulating the stash for large swaths customization, your customizations will no longer work. The version number will jump significantly in case this isn't warning enough.

So far, the Changes will look something like this:

• Merge create and update into update_or_create
• object is much advanced now:
  • Identifier can be omitted, and data_root in the request is interpreted
• Because of the above one object or several is now possible for update or create
• Create and Update object validation now happens iteratively
• Creates and Updates can be mixed inside a single bulk request
  
• All modifying actions on the database occur within an all-or-nothing transaction
• Much of the DBIC search parameter munging is properly moved to the RequestArguments Role in the form of a trigger on 'search' to populate 'search_parameters' and 'search_attributes' which correspond directly to ->search($parameters, $attributes);
  
• Error handling is now much more consistent, using Try::Tiny everywhere possible
• Tests are now modernized and use JSON::Any
• Extending is now explicitly done via Moose method modifiers
• The only portion of the stash in use is to allow runtime definition of create/update_allows
• list is now broken down into several steps:
  • list_munge_parameters
  • list_perform_search
  • list_format_output
  • row_format_output (which is just a passthrough per row)

There will likely be a couple of more bullet points, but as can be plainly seen, this is a BIG update. I hope to have the tests and the distribution ready to ship to CPAN tomorrow late in the day (it is still sitting in my local SVK repo)

This update will bring DBIC::API to the next level in terms of using it as a web service, with more functionality built into the core by default.

If you happen to be attending Frozen Perl 2010, I'll be giving a presentation on Catalyst datagrids, specifically my melding of ExtJS with DBIC::API and how dumb easy it is to hook the two together now (which makes my work life much simpler).

Anyhow, if you are still doing lots of heavy, custom CRUD exposed via web service, I hope this update will make it more appealing to switch to DBIC::API to handle the more mundane parts.