Re: [Catalyst] New version of InstantCRUD
I've already done a module I load in the ResultSource class of all my table classes which consists of a 'sub get_fvs_profile' which uses the dbic metadata to generate a FormValidator::Simple profile for use with DBIx::Class::Validation. I'd say that should go into DBIx::Class::Validation. - Alex Am Montag, den 23.02.2009, 11:33 +0100 schrieb Moritz Onken: Am 23.02.2009 um 10:53 schrieb Alexander Hartmaier: I'm currently patching the hell out of Controller::DBIC::API. Search by passing a json string and pagination is already in the repo, prefetch support is done but needs some sort of controller side restriction so that someone can't fetch the contents of the whole db by using the rels (api for that welcome). This should/could be the basis for ajax based LFB modules to load data instead of relying on an LFB internal API. What I'd like to see is a more split up LFB so I could use the (extjs) form generation on a per table (=controller) basis wherever I need it (for tables where a customized form isn't needed). - Alex Hi all, I'm following a different approach. My current project uses HTML::FormFu config files for both validating user input and generating json which contains the data of a resultset or result row. I do not use the html generation capabilities of FormFu, just validation, filters, transformers, inflators and deflators. I wrote http://search.cpan.org/~perler/DBIx-Class-AsObject-0.09_01/ which is far from being stable. But it generates a perl object from a result row using a HTML::FormFu configuration file. I think Controller::DBIC::API lacks of the ability to do proper validation. Maybe we can join forces on that one and add a configuration file to each controller. moritz ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ *** T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *** ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] New version of InstantCRUD
I'm currently patching the hell out of Controller::DBIC::API. Search by passing a json string and pagination is already in the repo, prefetch support is done but needs some sort of controller side restriction so that someone can't fetch the contents of the whole db by using the rels (api for that welcome). This should/could be the basis for ajax based LFB modules to load data instead of relying on an LFB internal API. What I'd like to see is a more split up LFB so I could use the (extjs) form generation on a per table (=controller) basis wherever I need it (for tables where a customized form isn't needed). - Alex Am Samstag, den 21.02.2009, 10:08 +0100 schrieb Oliver Gorwits: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Zbigniew, Zbigniew Lukasiak wrote: In short I am open for collaboration - but I found it difficult to express my expectations for the library without writing my own code. I (author of the ListFramework Builder CRUD - LFB) couldn't agree more. All these CRUD systems are lovely and go a great job but it is painful to see everyone developing in different directions. This is what has kept me from working on re-engineering LFB (I've done some bug fixes only, in the last six months). I know what needs factoring out, where there needs to be an API etc, but to be honest I suck at API design, I thought I'd better wait for someone else's DBIC API :-) And as an aside... At the moment I am happy with the niche LFB fills (i.e. not a scaffolder) and am working on a new user interface in something more lightweight than ExtJS. It might also get renamed to something like Catalyst::Plugin::AutoCRUD (well, or...?). If you are not familiar with LFB, see here (feedback welcome): http://tinyurl.com/listframework http://dragonstaff.co.uk/oliverg/ - -- Oliver Gorwits, Network and Telecommunications Group, Oxford University Computing Services -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJn8Sk2NPq7pwWBt4RAjGTAKC6wZwRm/JlLXioXGwBSScd319BWQCbBZVQ irNs/whuX90LqvKDvgJDYPI= =Wzug -END PGP SIGNATURE- ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ *** T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *** ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] New version of InstantCRUD
Am 23.02.2009 um 10:53 schrieb Alexander Hartmaier: I'm currently patching the hell out of Controller::DBIC::API. Search by passing a json string and pagination is already in the repo, prefetch support is done but needs some sort of controller side restriction so that someone can't fetch the contents of the whole db by using the rels (api for that welcome). This should/could be the basis for ajax based LFB modules to load data instead of relying on an LFB internal API. What I'd like to see is a more split up LFB so I could use the (extjs) form generation on a per table (=controller) basis wherever I need it (for tables where a customized form isn't needed). - Alex Hi all, I'm following a different approach. My current project uses HTML::FormFu config files for both validating user input and generating json which contains the data of a resultset or result row. I do not use the html generation capabilities of FormFu, just validation, filters, transformers, inflators and deflators. I wrote http://search.cpan.org/~perler/DBIx-Class-AsObject-0.09_01/ which is far from being stable. But it generates a perl object from a result row using a HTML::FormFu configuration file. I think Controller::DBIC::API lacks of the ability to do proper validation. Maybe we can join forces on that one and add a configuration file to each controller. moritz ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] New version of InstantCRUD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zbigniew Lukasiak wrote: Have you thought about a REST-like inteface? Yes, definitely going to use some kind of published API, probably REST-like. That way the javascript heavy frontend could be swapped out for a (possibly less feature rich) HTML version. - -- Oliver Gorwits, Network and Telecommunications Group, Oxford University Computing Services -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJoEWa2NPq7pwWBt4RAkK4AJ0WzDRWLVXdcIYBOTkqyJ/ErTrolQCgtuxq z6VVz/hT7JgX3vOylcgWYVc= =WRt0 -END PGP SIGNATURE- ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] New version of InstantCRUD
Just one more thought on collaboration in general: let's find some elements in each other work that we would like to collaborate on, let's not strive to steer the other project in full into the direction of our wishes. Let's divide the projects so that later each of us will be able to assemble his own ideal solution out of it. Zbigniew On Tue, Feb 17, 2009 at 7:48 PM, Alexander Hartmaier alexander.hartma...@t-systems.at wrote: Would be great if we could combine our efforts instead of creating even more choices for the users of cat in form of InstantCRUD, Controller::DBIC::API and so on (http://dev.catalyst.perl.org/wiki/crud). - Alex aka abraxxa Am Montag, den 16.02.2009, 21:44 +0100 schrieb Zbigniew Lukasiak: Looks like we are again discussing CRUD in Catalyst - so I decided to finally update InstantCRUD and release it to CPAN. It is still experimental. It is a 'scaffolding' - like the Rails one - it generates a CRUD application for a given dsn. Some more random thoughs: http://dev.catalystframework.org/wiki/crud/instantcrud and http://dev.catalystframework.org/wiki/crud/crud_and_rest (one caveat I completely disagree with the Preliminary URI naming guidelines). -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ *** T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *** ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] New version of InstantCRUD
Would be great if we could combine our efforts instead of creating even more choices for the users of cat in form of InstantCRUD, Controller::DBIC::API and so on (http://dev.catalyst.perl.org/wiki/crud). - Alex aka abraxxa Am Montag, den 16.02.2009, 21:44 +0100 schrieb Zbigniew Lukasiak: Looks like we are again discussing CRUD in Catalyst - so I decided to finally update InstantCRUD and release it to CPAN. It is still experimental. It is a 'scaffolding' - like the Rails one - it generates a CRUD application for a given dsn. Some more random thoughs: http://dev.catalystframework.org/wiki/crud/instantcrud and http://dev.catalystframework.org/wiki/crud/crud_and_rest (one caveat I completely disagree with the Preliminary URI naming guidelines). -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ *** T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *** ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] New version of InstantCRUD
On Tue, Feb 17, 2009 at 7:48 PM, Alexander Hartmaier alexander.hartma...@t-systems.at wrote: Would be great if we could combine our efforts instead of creating even more choices for the users of cat in form of InstantCRUD, Controller::DBIC::API and so on (http://dev.catalyst.perl.org/wiki/crud). Sure. Let me only point out that InstantCRUD was one of the first (published just after Enzyme). But this idea of combining efforts is what lead me when starting that wiki page. I am open for collaboration, I've already started figuring out what can be done with Peter Karman (of CatalystX::CRUD). For me his approach is a bit too heavy - it requires too much knowledge of his libraries to extend the controller using it - it wraps the model into it's own abstractions (CatalystX::CRUD::Iterator, CatalystX::CRUD::Model ) - while I believe that it should be possible to have the CRUD as an add-on and let the user work with his original Model. I updated my work to try out this - and also show the others what I really mean. I've also looked into other CRUDs - but I have not yet found one satisfying my requirements. For example CatalystX-ListFramework-Builder-0.41 is great - but it is not a scaffolding, CatalystX::ListFramework is nice but is not REST-like, Catalyst::Controller::DBIC::API is very close to what I need - and I plan base my future work on it but for now there is some problem with multiple inheritance in Catalyst Controllers that make it incompatible with my approach, I hope that when we get the Moose version of Catalyst this problem will go away. And I hope that then the base controller will become a Moose role instead for greater flexibility. In short I am open for collaboration - but I found it difficult to express my expectations for the library without writing my own code. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] New version of InstantCRUD
Zbigniew Lukasiak wrote on 02/17/2009 02:05 PM: On Tue, Feb 17, 2009 at 7:48 PM, Alexander Hartmaier alexander.hartma...@t-systems.at wrote: Would be great if we could combine our efforts instead of creating even more choices for the users of cat in form of InstantCRUD, Controller::DBIC::API and so on (http://dev.catalyst.perl.org/wiki/crud). Sure. Let me only point out that InstantCRUD was one of the first (published just after Enzyme). But this idea of combining efforts is what lead me when starting that wiki page. I am open for collaboration, I've already started figuring out what can be done with Peter Karman (of CatalystX::CRUD). For me his approach is a bit too heavy - it requires too much knowledge of his libraries to extend the controller using it - it wraps the model into it's own abstractions (CatalystX::CRUD::Iterator, CatalystX::CRUD::Model ) - while I believe that it should be possible to have the CRUD as an add-on and let the user work with his original Model. I updated my work to try out this - and also show the others what I really mean. And Zbigniew's feedback led to the development of http://search.cpan.org/dist/CatalystX-CRUD-ModelAdapter-DBIC/ for which I thank him. CatalystX::CRUD has different aims than InstantCRUD. It's an API rather than a scaffolding generator. All the projects on that wiki page are trying to solve specific problems. The problem CXCRUD was trying to solve was how to let RDBO, DBIC, modelX, etc, play nicely with RHTMLO, FormFu, etc. As for whether it is too heavy or complicated, I agree that the docs and examples could use work. But then, that seems to be a common complaint for even the most useful of CPAN code. -- Peter Karman . pe...@peknet.com . http://peknet.com/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
