Third post in a single day, is that a good or bad thing?
Finally finished the CRUD infrastructure, thanks to HTML::FormHandler. I felt like sharing some good news instead of pent up rage.
Now I can create CRUD methods that are not over 5 lines, finally.
Since most of my projects involve other designers and CMS for clients, I'll definitely be using this for them as well. So, I will be looking into making it as generic and concise as I can. If that will end up well, I might put it on CPAN. Two things trouble me with it though: 1. There's already a lot of CRUD modules there, which I'm sure are more generic than this one and have more functionality. Albeit I personally wasn't able to enjoy any of them, but they do exist so I'm guessing someone is. 2. There's already so much bad code on CPAN and things that don't work, I wouldn't want to add another one and give someone else another module that doesn't work for them 'cos it's not generic enough.
Re:Any news on this front?
xsawyerx on 2009-03-02T14:33:38
Not really. I still use what I wrote but haven't released it. I think it needs some work before I could. You're more than welcome to check the source, work with it, play with it and help to release it, obviously.
However, I have an idea that I wanted to propose and this might be a good place (or not). I want to create a layers model for a CRUD system. That would include scaffolding, form processing, etc. That way, we'll be able to use modules interchangeably and everything will work because they will converse using a known protocol between the layers. Also, that way things won't intermix into each other's roles.
Would you be interesting in working on something like that?
Re:Any news on this front?
zby on 2009-03-02T17:15:25
:) - sure. You can have a look at my Catalyst::Example::InstantCRUD module. It is a scaffolding. It does the CRUD part - and it works but I wanted to offload it to something more flexible and possibly RESTful (perhaps using Catalyst::Controller::REST and Catalyst::Request::REST::ForBrowsers).My form processing is currently done by Rose::HTMLx::DBIC - another of my modules, but I am not too much attached to Rose (it is a fine module - but I would rather have one object model - and since everyone goes with Moose here I would like to join the pack) so porting it to HTML::FormHandler should be OK with me. I've put a lot of work into DBIx::Class::ResultSet::RecursiveUpdate - where I've offloaded all the closely coupled DBIC code and I would like to leave it like that. Finally I'd rather avoid using Chained dispatching - as it really complicates usage. I really try to make InstantCRUD usage as simple as possible.
Yeah - I know that is a lot of requirements from my side - for my excuse please remember that I've been working on this projec for over 3 years now - so I've accumulated a lot of "I don't want to do it like that!". But if you only agree on a part of that litanny - I think we can always extract a common sub-project and collaborate on that part?
Actually...
xsawyerx on 2009-03-02T18:32:41
I'm all very for the "I don't want to do it like that!" attitude. It's a sum of years of experience and I think it could leverage us and make sure we do things better and not fall over the same things again.
With regards to your concerns: we don't have to use HTML::FormHandler specifically. The idea is that we figure out a protocol (or, something of that sort) for CRUD and CRUD implementations which will make it possible for users to use either HTML::FormHandler or Rose:HTMLx::DBIC or anything else they want. HTML::FormHandler is pretty straight forward so we can use that for the work meanwhile. DBIx::Class::ResultSet::RecursiveUpdate could come in handy, I don't see a point in reimplementing any of it. As for Chained, I agree with you here as well.
Basically I want to be able to say that HTML::FormHandler and Rose::HTMLx::DBIC can be changed without changing everything else I do. Or, that I could use HTML::FormHandler's simple renderer without having to change a lot. I want these to be layers that can be changed and that they have a clear way of working with each other. Perhaps that means writing some glue for them, perhaps not. It's something to think about and I'd love know what you say about it.
Basically we're talking about taking the concept of CRUD, and putting it into layers such as: data rendering, form processing, generic testing (if ID exists, etc.) to able to unify the different modules to provide a sane CRUD overall system. Now we just have to figure out where to start from
:) Re:Actually...
zby on 2009-03-02T21:26:39
OK - great! I am all for constructing interfaces between all the layers. There is just one thing - see CatalystX::CRUD - it is designed with the idea of interchangeable database layer - and I think the result is too complex. The reason for that is that the DBIC model is the schema - that is the whole database - while in RDBO the model is one table (at least in CatalystX::CRUD::Model::RDBO). In my opinion this creates too much friction between those two to hide it behind one interface. And by the way I don't like the model per table arrangement because then all the models become cut-and-paste repeated code. Aside that I think there is a lot to steal from CatalystX::CRUD - it has many things thought over.So I am for interfaces (and I've actually started the Form Processing page with the idea of nailing down the differences and similarities between the different form processing modules - and in the longer perspective abstracting them behind some interface). But I don't want to sacrifice the simplicity of the usage.
Enough talking. See InstantCRUD - I know it is quite a bit of work to digest all the details of a project like that - but only this will give us some more steady ground for discussion. Of course I promise to get acquinted with your code as well.
In the evenings I am also at the #formhandler IRC channel (at irc.perl.org) and at the Catalyst mailing list.
