On Sun, May 4, 2008 at 1:28 PM, luke saunders <[EMAIL PROTECTED]> wrote: > > > > I think we can still make it compatible, if we agree on some kind of > > internal API. > > > > As in make this module compatible with your new module? Perhaps as a > base class without form generation?
Yes - I am thinking about something where you have a separate methods for validating the parameters and updating/creating the object in the database - so that I could override them in my sub-class. > > > > It is I think quite common convention to use '.' dot for that: > > > > param1.some_relation.field_value > > > > or > > > > some_param.some_multi_relation.1.field_value > > > > Makes sense. I prefer that to the add_to_rel action, especially if > this is to remain a REST module rather than an RPC module. > It does not bother me if you leave those actions. > The piece of functionality I always wanted but didn't see a clean > solution to was specifying complex conditions to the 'list' action, > for example only CDs which have a track called 'Badgers', which > requires specifying a join and a related condition. I wonder if it > makes sense to represent that this way too. > Well - this is in my plans as well - as search in InstantCRUD :) I am thinking to base it on the technique I described in my Advent article: http://catalyst.perl.org/calendar/2007/16 -- Zbigniew Lukasiak http://brudnopis.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/