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.
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.
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.
Best,
Nadav
Alberto Valverde wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
