expose('json'), TurboJson and TG2.1
Jorge Vargas
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.
Jorge Godoy
If you're keeping it tied to TG2, then I don't see a reason to fork it into a separate package.
What I mean is: if decoupled, then maintaining current features is needed -- even though they are not supported by TG2; if not decoupled then lets not create a new dependency.
--
Jorge Godoy <jgo...@gmail.com>
Mark Ramm
1) Create a new package with a new name.
2) use that package with the new name by default in tg 2.1
continue to use TurboJson in tg 2.0 and 1.x and allow 2.1 to use
TurboJson for backwards compatability if people want.
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
Daniel Fetchinson
>
> 1) Create a new package with a new name.
> 2) use that package with the new name by default in tg 2.1
>
> continue to use TurboJson in tg 2.0 and 1.x and allow 2.1 to use
> TurboJson for backwards compatability if people want.
+1
Whatever you do Jorge, please think about tg 1.x users. This means
TurboJson should not evolve in a way that suddenly it stops supporting
tg 1.x or get into a state where "tg 1.x compatibility can now be
added back". It's fine to come up with cool new features for tg 2.0 or
tg 2.1 but if this implies lost support for tg 1.x then this new code
should be given a new name and correspondingly a new package.
Cheers,
Daniel
--
Psss, psss, put it down! - http://www.cafepress.com/putitdown
Jorge Vargas
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.