New version of InstantCRUD

[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@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Alexander Hartmaier]

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@...
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@.../
> 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@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Zbigniew Lukasiak]

On Tue, Feb 17, 2009 at 7:48 PM, Alexander Hartmaier
<alexander.hartmaier@...> 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@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Peter Karman]

Zbigniew Lukasiak wrote on 02/17/2009 02:05 PM:

> On Tue, Feb 17, 2009 at 7:48 PM, Alexander Hartmaier
> <alexander.hartmaier@...> 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  .  peter@...  .  http://peknet.com/


_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Zbigniew Lukasiak]

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.hartmaier@...> 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@...
>> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
>> Searchable archive: http://www.mail-archive.com/catalyst@.../
>> 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@...
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@.../
> Dev site: http://dev.catalyst.perl.org/
>

--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[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@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Zbigniew Lukasiak]

On Sat, Feb 21, 2009 at 10:08 AM, Oliver Gorwits
<oliver.gorwits@...> wrote:

> -----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...?).

Have you thought about a REST-like inteface?  What do you think about
http://search.cpan.org/~lsaunders/Catalyst-Controller-DBIC-API-1.001000/lib/Catalyst/Controller/DBIC/API.pm
?  I would like to have something like that but more lightweight and I
am really waiting for the Moose port - so that instead of base
controller or plugin this could be a role.



--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

_______________________________________________
List: Catalyst@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Oliver Gorwits]

-----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@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[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


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@...
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@.../
> 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@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[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@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/

[Alexander Hartmaier]

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@...
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@.../
> 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@...
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@.../
Dev site: http://dev.catalyst.perl.org/