Chris Travers wrote:
3) Each database-based object should have a number of different constructors including one from a "flat representation," one that copies internal representation elements passed in the arg string, and one which retrieves from the database via the appropriate keys.I still feel this is a really, really bad idea - implicitly pulling data from the arg string and treating DB instances as partial representations of the request object is A Bad Idea. Even when dealing with very long incoming POSTs, directly creating DB objects from the request strikes me as ill-advised. I think further discussion on this is definitely warranted.Regardless of where we automate such a transformation, I think it would be helpful to automate it. Is there a specific objection to automating the movement from a flat representation to a native representation? Or do you think there is a better place to put such automation?
At the moment, I'm agreeing with Aurynn. But, I also don't see the point of such an automated transformation. What benefit would this provide?
My gut reaction (without a use case, anyway) is that this sounds neat on paper but potentially opens up bad-data injection problems. If someone really wants, say, a RESTful interface to GL transactions that supplies text/plain format CSV data, that should be easily added - as an addon. The converse should hold true for custom import functionality, no?
-- -Adam Thompson <..hidden..> (204) 291-7950