On Dec 19, 2006, at 9:52 AM, thesamet wrote:
> > Sounds good. It would be great to see it reused in additional > framewords. Let me know how it progress. > We should continue development from this point over svn and make some > alpha-release soon. This kind of thing could be useful for many > projects even in its early stages. Sure. It's going to be useful to one of my projects already so it's enough motivation to keep on... :) > > I think we should supply standard controllers for the major web > frameworks in some way - so it would be really "plug and play" sort of > thing. Agreed. > > BTW, the current implementation of update() iterates over the query > arguments and does setattr over the given database object. This > practically allows a malicious user to set columns that wasn't in the > form. Maybe it it possible to do ever more terrible things this > way... > Is there a way to make this kind of query arguments not to validate? > For the time being, I've wrote a short hack (in the controller) that > removes query arguments which do not have a corresponding widget. Well. this is what I've got so far: svn co http://svn.toscat.net/FastData2 (FastData2 chosen for no particular reason... had to give it a name when "paster create"ing the egg ;) Some names have changed in the datahandler/adapter but the idea is the same: I have: do_create(self, controller, environ, **kw) do_retrieve(self, controller, environ, **kw) do_update(self, controller, obj, envrion, **kw) do_delete(self, controller, obj, envrion, **kw) which nicely spells CRUD ;) self is the datahandler, controller is... the controller, environ is the WSGI environ for the request and **kw are arbitrary keyword args which the hosting app/framework can use as needed. They're all generic functions. The DataController uses a metaclass to automatically make these methods generic and make the API sweeter (take a look at tests/test_meta.py if interested). Ideally the DataHandler should be state-less because, although Pylons would probably instantiate it once per request, TG's current implementation instantiates controllers only once. Some differences with your approach: Your "select" and "get_row_by_id" are both handled by "do_retrieve". The controller has no form_widget, etc, attributes. These will be fetched by "widget_for" so the view is decoupled from the controller. Some things I don't know how to "port": The rules to generate widgets for SA import turbogears' session. How could be generalize this to play nice with other frameworks which could implement session in many different ways (sessioncontext, create one once per-request...)? I'd rather move the session- requiring rules to an extension or let the developer implement them themselves. Tests cover more or less so far the controller.py module (which isn't really the controller but the DataHandler (sort of an adapter)) and the view.py module which defines the "widget_for" gf and the "register_widget_for" wrapper which aims to connect business/model objects and the widgets to view them. The idea I have in mind is that the default rule for an SO or SA mapped classes calls recursively "widget_for" (and only widget_for) on the object's attributes to generate the fields/child-widgets. These rules could be overridden at any time to have total control over the resulting widget. "Hints" could also be placed in the model to tell how their corresponding widgets should be generated (more or less a là Django-admin). The architecture I have in mind is that the (TG or Pylons) controller ideally should not be overridden likely (unless extra "exposed" methods are needed). The controller per-se should only take care of doing the boiler plate stuff of validating using the form, choosing the output template, set headers, etc... All the grunt work should be done by the DataHandler which can be extended via gfs. However, If no the user should not want to use gfs, any object that implements the IDataHandler interface can be plugged in. One controller should be able to handle CRUD operations on more than one model/business object at once. This should result in an "easily modifiable/extensible" CatWalk ideally (AJAXified in a near future) if my time machine is properly tuned ;) I'm also envisioning a nice plug point for access rules (via "before" decorators) using RuleDispatch based on PEAK security (TurboPeakSecurity2 ;). BTW, tgdatacontroller is half baked and will probably break in a thousand places... beware ;). Well, I'll try to finish more or less the tgdatacontroller later this evening and set up some sort of demo to see how all this glues together... If you (or anyone) want (s) to collaborate email privately for a commit account, though I rather host this (or whatever we end up cooking) at TG's SVN preparing it to be one of 2.0's components... Any feedback appreciated... Am I pushing too far the generic functions approach maybe? Anything way off track? Regards, Alberto --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
