On Tue, Aug 24, 2010 at 11:32, Bill Moseley <[email protected]> wrote: > > > On Wed, Aug 11, 2010 at 4:08 PM, Dan Horne <[email protected]> wrote: >> >> The recent discussion on read only objects has got me wondering. Say one >> has an app which basically sends result sets to TT templates. What stops a >> malicious designer from doing DB updates in the templates since they have >> the RS objects? I could mimic the DBI solution of returning arrayrefs of >> hashrefs, but that doesn't allow for the chaining of methods to get related >> resultsets, Nor would it give me access to pagination info. > > This has come up a few times on the Catalyst list. You might check the > archives there. > One option, which is what the java people at work promote, is to copy all > the data that the view needs to a separate structure and pass that to the > view instead of the objects.
The Controller should be declaring an API that the various View(s) can consume. Even if you never use it outside a test suite, it is highly instructive and helpful to build a second view that transforms hashes into JSON. Not only is this very testable without going into the HTML parsing, but it forces you to think about what your views are supposed to be consuming. Rob _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[email protected]
