> Sounds interesting for TGFastData 2.0... Have you thought about
> contributing to this badly-needing-a-mockup TG component?
Yes. That's the intent.
> One suggestion that pops to mind... Have you thought about using
> generic functions instead of adaptation?
Yes. This should be definitely considered. I'm fairly new to
RuleDispatch so I might be missing some features. How would you handle
this scenario using RuleDispatch:
A user may want to have several fastdata controllers for the same SA
class, each having a different select() method. So by what rule the
right instance of select() function should be determined? It seems that
only the URL or the call trace hold this information. Or maybe should
be passed somehow through a hidden field.
> mechanism for free: update.after("hasattr(class_obj, '_cache')")
> (flush_objects_cache)
Sounds useful. update.before() can be used to do some security checks
which maybe beyond
form validation.
I imagine TGFastData as something newbies would just do 2 minutes after
writing their first model to have something to play with. And 5 minutes
after that they'll have to confront RuleDispatch to change the way
select() is working or to add post-update event. So I am a bit
concerned about using RuleDispatch so close to the front-end.
> Can we see some code? :)
Sure.
http://www.thesamet.com/blog/wp-content/uploads/2006/12/TGQuickData-0.1.zip
(it's called QuickData to make it easy to install it side-by-side with
the original FastData - I use them both).
Nadav
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
