>
> On Mon, Jul 7, 2008 at 11:02 PM, Jonathan LaCour
> <[EMAIL PROTECTED]> wrote:
>>
>> I am upgrading my application to TurboGears 2.0, and in the process
>> am having an absolute *fit* with TurboJSON after the switch to
>> PEAK-Rules. I don't want to use any of the default jsonify rules,
>> and before with the older version of TurboJSON, I was able to call
>> `jsonify.clear()` so that I wouldn't have any conflicts. It now
>> appears that this capability is gone, and the documentation for PEAK
>> Rules is essentially non-existent.
>>
>> So, now I have a massive set of rules that are all blowing up with
>> `AmbiguousMethod` exceptions and no way that I can determine a way
>> to fix them.
>
> I'm on the fence on that one but I must admit I have been bothered by
> this too. I had no preexisting rules so just went the __json__ way but
> I see your point...
>
> Anyone?
I think this could be solved in two ways which would allow default rules
to be bundled (after all, TG2 is all about providing sane defaults to make
simple things simple, right?)
1) Implement a custom Method that honors a "priority" (optional, default
to 0) argument to the when/around decorators which will be used to
disambiguate. This is what I had in TW when it used rule dispatch and used
in many projects of mine and worked like a charm. Default rules in
turbojson would have a priority=1000 (for example) so when an ambiguous
methods situation emerges from user code extending jsonify the user would
just need to raise his/hers implementation's priority.
I will probably implement this soon for my gsoc project so if interested I
could make it a standalone egg (unless PJE wants to include it in PEAK
itself :)
2) Add context to jsonify so it can be dispatched on. This can be achieved
by implementing jsonify as a method of GenericEncoder, example:
class GenericEncoder(JSONEncoder):
@generic()
def jsonify(self, value):
....
When generic functions live inside a class peak rules also uses 'self' to
dispatch on giving preference to extensions declared inside the class body
when the instance method is called (I'm not 100% sure though, only 95%.
RuleDispatch did and the little I've played with peak-rules makes me
believe it does too but I haven't any unittest to prove it yet)
Users could then subclass turbojson's encoder and extend jsonify from there:
jsonify = GenericEncoder.jsonify.im_func
class MyEncoder(GenericEncoder):
@jsonify.when("obj is an SA mapped instance")
def _my_sa_jsonifier(self, value):
return something useful
Instances of this encoder will use _my_sa_jsonifier to encode SA instances
overriding any rule declared en GenericEncoder. Rules declared outside of
the class body will still affect all GenericEncoder subclasses (unless one
does isinstance(self, Foo) of course).
I believe 2 is the "correct" way to do it but the change might not be
transparent enough. Besides that, some mechanism should be implemented to
tell TG2 which encoder it should use.
1, however, is 100% backwards compatible (but needs someone to implement
it :), as I've said, I'll probably do it but I first need to study
peak-rules internals in more detail)
To sum up, I strongly believe turbojson should ship with default rules as
it has always done since it saves developer time by providing sane
defaults which is what TG is about. Introspecting SA classes, heck, even
extending generic functions, is not something someone new to python would
like to face too soon IMHO
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
-~----------~----~----~----~------~----~------~--~---
