Today while working on the updated dependencies ticket I found out something.
Currently we are using the buffet legacy plugin for json, you may know
it as TurboJson,
TurboJson, was ones used by TW/TGWidgets and other parts of TG1 to
apply generic rules to transform into json some objects, as you can
see from http://trac.turbogears.org/browser/projects/TurboJson/trunk/turbojson/jsonify.py
it used to support SO, SA and other small types in a very magical yet
useful way. Also note TJ uses simplejson as it's rendering engine.
Fast forward to the present, if you want to return json you will most
likely use a dict, and TJ will just kick in and transform your custom
classes into valid json.
So the questions are,
1- should we create a "render_json" function in tg.render.py (read:
build a "new style render")
if yes what it should do,
a- simply delegate to simplejson
b- implement the generic functions to display custom types?
2- should we bring TurboJson back into TG2 codebase?
3- ???
another benefit of going with 1 is that we can get rid of a lot of
dependencies, according to pip
Downloading/unpacking PEAK-Rules>=0.5a1.dev-r2555 (from TurboJson->TurboGears2)
Downloading/unpacking prioritized-methods>=0.2 (from TurboJson->TurboGears2)
Downloading/unpacking BytecodeAssembler>=0.3.dev-r2459 (from
PEAK-Rules>=0.5a1.dev-r2555->TurboJson->TurboGears2)
Downloading/unpacking DecoratorTools>=1.7dev-r2450 (from
PEAK-Rules>=0.5a1.dev-r2555->TurboJson->TurboGears2)
Downloading/unpacking AddOns>=0.6 (from
PEAK-Rules>=0.5a1.dev-r2555->TurboJson->TurboGears2)
Downloading/unpacking Extremes>=1.1 (from
PEAK-Rules>=0.5a1.dev-r2555->TurboJson->TurboGears2)
Downloading/unpacking SymbolType>=1.0 (from
BytecodeAssembler>=0.3.dev-r2459->PEAK-Rules>=0.5a1.dev-
>> 1- should we create a "render_json" function in tg.render.py (read:
>> build a "new style render")
>> if yes what it should do,
>> a- simply delegate to simplejson
>> b- implement the generic functions to display custom types?
maybe we should just keep it like it for the first release and aim to
eliminate the buffet interface afterwards. (keeping tj or removing it
in the process as we choose)
Florent.
Yea, this is what we should do. Anything else will break too many
people's TG2 apps.
--Mark
But it is extraordinarily likely that SQLAlchemy objects will be
returned by the controller, and those are not simple dictionaries.
> But it is extraordinarily likely that SQLAlchemy objects will be
> returned by the controller, and those are not simple dictionaries.
with time this will be grown into render_json, in fact I think it can
have that by default as well as the dict, and respect the __json__,
that should cover 80% of the use cases.
I'll write a patch for the above suggestion.
http://trac.turbogears.org/attachment/ticket/2212
I'll realllly like this to go in. I'm willing to code a flag
(use_turbojson) which will default to True, and keep it as a
dependency. But if we can get people to test most existing apps with
use_turbojson = False and get render_json well tested I'll like to
release tg2.0final with it turned off. pretty please :p