Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • As an author of yet another CRUD framework I am interested in stealing your ideas and code.
    • 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 conve

      • :) - 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 wi

        • by xsawyerx (8978) on 2009.03.02 13:32 (#67667) Journal

          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 :)

          • 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