I put some more time into this today and this is my conclusion I'm splitting my patch in 2 parts and will work this in several stages.
Keep in mind I'm ditching the idea of a new package as it all boils down to one class. 1- remove the buffet interface (patch 1) this is done and pushed if I had push access! 2- create a TurboJson branch with my patch (http://svn.turbogears.org/projects/TurboJson/branches/peak-rules-removal/) 3- remove TurboJson from TG2 (patch 2) and include the TurboJson Branch as a buildin (if in the future it needs to be decoupled so be it). This is done and committed in my local repo, I just need to port over the tests I believe this makes everyone happy as - It keeps tg1.x intact - I don't have to maintain and release a package - I don't have to code for stuff I don't use My only remaining issue is how to support @jsonify.when rules in TG2.1. Those rules are in two groups. a- jsonify.when('instance,SomeType') This is a migration item where you need to replace those rules with a __json__ object. b- complex rules I strongly suggest we just drop it and tell people how to build their own JSONEncoder to translate those rules. To be honest I asked a lot of people at pycon and IRC if they used b and most didn't even knew what it was. So far I have only 2 reports of people using that feature. I really think TG2.1 should be 100% TurboJson free as it not worth it to pull in 7 dependencies even if it's optional. On Sun, Apr 26, 2009 at 4:54 AM, Jorge Vargas <[email protected]> wrote: > Hello Everyone > > here is an update on my work, and at this point I need feedback, to > see where we are going to end up. > > First of all a quick summary. > > TurboJson provides the following > 1- a buffet API > 2- a JSONEncoder subclass that implements methods for > 3- any object with __json__ > 4- date and datetime objects > 5- decimal.Decimal > 6- SQLObject > 7- SQLAlchemy (0.5, 0.4 and 0.3) > 8- SQLAlchemy ResultProxy and RowProxy (the objects used by sqlalchemy.sql) > 9- any third party object with the @jsonify.when() decorator. > 10 - priority overrides > > 11- TG2 currently still uses the is still using the buffet rendering API. > > Therefore at this point we could get rid of TurboJson and incorporate > that functionality directly into TG2 (tg/json.py for example) but I > think this extra library is good as standalone as it could provide a > default set of types for use outside TG, so I think it should live on > as a tiny api (like webflash), although by this point I think it > should be renamed. > > The patches. technically it's 2 patches one for tg2.1 and another for > TurboJson although the second is pretty much a complete rewrite. > $ cat jsonify.py jsonsupport.py | wc -l > 93 > $ svn diff jsonify.py jsonsupport.py | wc -l > 200 > > The state of my patch, > What is ok > - it removes 1 and 11 from tg2.1 > - It provides 2 but without rule dispatch, it simply uses a subclass > with a default method that tests the object for types and return the > proper conversion. > - it provides conversions for 3,4,5, 8 and 7 for SA0.5 > > What is missing? > SO (6) > - There is no implementation* for SQLObject, but could be added back in easily > > SA 0.4 and SA 0.3 support (7) > - I haven't tested this code with older version of SA > > Third Party Object (9) > - This is not implemented yet* > > priority overrides (10) > - It is my understanding this is a rule-dispatch extension to allow > resolution of conflicting rules. > > * This could be easily implemented I'm just not sure if it's worth it > but the procedure will be simply to extend GenericJSON to provide SO > and expose that class inside TurboJson and to write some documentation > on how to do this. And then provide a hook for replacing the default > implementation or simply change the public api from TurboJson to be > more flexible > > in the TG2 part I'm having only 2 test failing. > 1- Should be totally unrelated and seems to me like a bug I uncovered > with this change test_template_override > 2- This is really important what should render_json do when the > objects in template_vars are not valid JSON? currently the test fails > with a generic simplejson encoding error (TypeError) which if run on a > real server should send a 500 error, but it is not happening. > > So in general I think we should either > a- fork TurboJson into another package (names welcome) which will only > support what it supports now (with the extending pending, but with a > small change in the API, that will probably make it equal to > simplejson.dumps) how about VargasJson hehe j/k > b- patch TurboJson with my code and add a TG1 compatibility layer. > > IMO my patch/fork covers 95% of the interesting use cases and with the > API change for extending it. it should over that 5% missing, since we > should drop support for SO, SA4 and SA3 since TG2 doesn't supports > them. > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
