On Fri, Aug 14, 2009 at 11:45 AM, David Broudy<[email protected]> wrote:
>
>
> On Aug 13, 2009, at 8:32 PM, Jorge Vargas wrote:
>
>>
>> Umm this is interesting AssociationProxy is an extension that doesn't
>> follow the _sa_ convention. And I agree this is a rather simple patch.
>> In fact it should be as simple as adding a new function to
>> http://svn.turbogears.org/projects/TurboJson/trunk/turbojson/
>> jsonify.py
>> will you work on a patch + test for it? I don't have any models around
>> that use that extension.
>
> Yeah, I should be able to do that next week. Though looking at 2.1 (or
> 2.0 for that matter) I don't think it can be done in a function, but
> is a one line change to the existing conditional.:
>
> if not key.startswith('_sa_') and not
> key.startswith('_AssociationProxy_':
>
that will be the fix for TG2.1 for 2.0 you will need to add the
function to TurboJson I think you confused both implementations.

> Are there instructions to get a source environment for 2.1 anywhere,
> or is it just as simple as replacing subversion with mercurial from
> the 2.0 docs?
>
Right, that hasn't been updated yet. You could just do the mercurial
checkouts or you can fork and request for a pull later.

>> Now as I said that has been removed (although an equivalent
>> implementation could be set in place for 2.1, the question is do we
>> want it?) the proper way will be to subclass the Encoder here and (for
>> now monkey patch L39: _instance = GenericJSON()) to put in your
>> modified instance. Suggestions on how to make that better are welcome.
>
> I'm not familiar with what "monkey patch L39" references. As far as
> making is easier to subclass,
you need to tell TG to use your class currently there is no way of
doing that. Therefore you will have to do something like this in your
code.

tg.json._instance = YourJSONClass() <-- that is referred to as monkey
patching. Because you are changing the behavior of a module from
outside the module which in some cases could generate very bad things.
In this case it is safe but not nice coding.



> I think some additional callback to
> deal with relationships would be extremely helpful, and save the
> inheritor from having to reimplement the entire is_saobject(obj)
> condition, including filtering out of private SA attributes, which may
> be subject to change.

This is correct it has changed a lot (take a look at TurboJson) but
since TG2 depends on SA<0.5 we can safely ignore those for now. THe
check for SA will probably evolve if SA>0.6 changes the way we can
detect it's non-column attributes.

> Just implementing your own default won't do it,
> because the key is skipped before the value.

I'm sorry I don't get this? you mean is_saobject returns false for
your extension?

>  Actually, what about
> moving the startswith _sa_ check to it's own function that could then
> be overridden? That would allow derived classes to exclude at the
> field or relationship level, using the key, while still calling
> through to the super class that can implement the private key
> behavior. Is that what you meant by a new function above? If so, I
> guess it just took me a little while to get there :)
>
adding a callback could be a good idea. What we need to be careful is
that if you overwrite that call you won't overwrite everything else.

I suggest you start by coming up with a check to filter out the
AssociationProxy, then evolve that into something that will check for
SA too, with that we can figure out which is the best way to integrate
it back into json.py

>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"TurboGears" 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?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to