On Dec 17, 2006, at 1:44 AM, thesamet wrote:
>
>> Sounds interesting for TGFastData 2.0... Have you thought about
>> contributing to this badly-needing-a-mockup TG component?
> Yes. That's the intent.
Great :)
>> 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.
You can pass the controller instance as an argument and dispatch on
it. For example, if those functions were methods of the controller
(by being in a mixin class) you could do:
select.when("self in FooController and ....")(function)
Inheritance will work as expected if extending because if B extends
A, then "self in B" would be more specific than "self in A" so the
function attached to "self in B" would kick in. ToscaWidgets uses
this technique in the "pre_init", "post_init" and "adapt_value"
widget methods.
>
>> 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.
Or logging, or whatever... :) Definetively something useful to have
IMO, and it comes for free ;)
>
> 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.
Fortunately RD can be wrapped in utility functions to hide most of
the details . The utility function can be called passsing explicit
parameters to handle the most common cases while still providing an
optional "rule" argument to expose the full power of arbitrary
expressions. This is what turbogears.errorhandling.{error,exception}
_handler do.
>
>> 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).
Ok. I've started tinkering with a FastData2 egg taking ideas from
QuickData and implementing the adapter's methods using generic
functions and using ToscaWidgets for the widgets. I'm trying to make
it controller agnostic so a controller class can be a TG controller
or a Pylons controller (or any kind of controller ideally). I'll post
back as soon as I have something working... (*hopefully* later today).
BTW, should we start a FastData2 project in TG's "projects" svn
directory for this? I've intentionally left the "TG" part out as I
believe we should try and make it independent of TG so it can easily
be reused in other frameworks. For the moment it's only dependancy is
ToscaWidgetsForms and RuleDispatch.
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
-~----------~----~----~----~------~----~------~--~---
