On Dec 16, 2006, at 11:37 PM, thesamet wrote:
>
> On the time being, I've had some time to play with FastDataGrid and
> DataController. I've tried to factor out the SQLObject-specific code
> from the widget and controller.
>
> Instead of accepting a sql_class in their constructor, they accept a
> data-adapter object. The role of this object is to provide the data
> and
> the metadata to the grid and the controller. This object implements
> select(), get_columns(), create(), update(), delete().
>
> I've written an adapter class around SQLAlchemy's mapper, and it's
> easy
> to do something similar for SO, based on the existing code in
> TGFastData.
>
> In my application, for instance, I inherit from SA_DataAdapter and
> override the select() method, because I want to restrict the query
> (not
> to display the whole dataset).
Sounds interesting for TGFastData 2.0... Have you thought about
contributing to this badly-needing-a-mockup TG component?
One suggestion that pops to mind... Have you thought about using
generic functions instead of adaptation?
For example, select(), get_columns(), create(), update(), delete()
could each be a generic function with a signature like:
select(class_obj, validated_query_params), update(object,
validated_query_params), delete(object), etc... These could be
specialized via rules to accept arbitrary objects (SA mapped classes,
SO classes, whatever classes/instances...) and provide the
flexibility of dispatching by the query parameters, environment data,
etc... RuleDispatch's implementation also offers an event handling
mechanism for free: update.after("hasattr(class_obj, '_cache')")
(flush_objects_cache)
I personally favor generic functions instead of adaptation because I
find it more flexible and usually results in less code.
I've been thinking about this lately because of lot's of code I have
repeated over many projects which could use a generic controller and
provide hook points to modify behaviour using this approach... I
haven't factored out controller methods to perform basic CRUD
operations yet, but have a similar mechanism implemented to register
widgets for different CRUD operations. For example:
register_widget(Book, action='edit', EditBookForm(....))
is a wrapper to register a default widget (via extending a gf) for
editing a Book. Controller code will call:
widget_for(Book, action='edit')
which would return the previously registered widget.
There are also default rules to provide widgets for unregistered
objects. For example, fo an unregistered SQLObject's it will generate
a form on the fly using formmaker, etc... By using generic functions
you can also return different widgets depending on other conditions,
for example, the currently logged user.
Well, just wanted to toss the idea of implementing this using generic
functions.... (I can already hear some people screaming... ;)
> (...)
> The implementation currently uses TG's DataGrid but it seems that it
> will be easy to make it work with ToscaWidgets' DataGrid.
Most probably.
> I'm interested in comments and suggestions.
Can we see some code? :)
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
-~----------~----~----~----~------~----~------~--~---
