TurboJson, json and @expose

[jorge.vargas]

Hello,

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- ???

[jorge.vargas]

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-

[Florent Aide]

On Fri, Feb 13, 2009 at 9:54 PM, jorge.vargas <jorge....@gmail.com> wrote:
>
> On Fri, Feb 13, 2009 at 4:10 PM, jorge.vargas <jorge....@gmail.com> wrote:
>> Hello,
>>
>> Today while working on the updated dependencies ticket I found out something.

>> 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.

[Mark Ramm]

> 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)

Yea, this is what we should do. Anything else will break too many
people's TG2 apps.

--Mark

[percious]

Personally I think we should default to SimpleJson, and then if the
user has TurboJson installed, we should
default to that. It should be simple enough to put a switch in
config.

try:
import turbojson
except:
import simplejson

or such.

I feel that for simple jsonifications (dictionaries) SJ will be
enough.

I also agree that waiting until after the release is prudent, but 7
deps. is a lot. Does TG care about the number of dependencies in
general?

cheers.
-chris

[Mark Ramm]

On Fri, Feb 13, 2009 at 11:35 PM, percious <ch...@percious.com> wrote:
>
> Personally I think we should default to SimpleJson, and then if the
> user has TurboJson installed, we should
> default to that. It should be simple enough to put a switch in
> config.
>
> try:
> import turbojson
> except:
> import simplejson
>
> or such.
>
> I feel that for simple jsonifications (dictionaries) SJ will be
> enough.

But it is extraordinarily likely that SQLAlchemy objects will be
returned by the controller, and those are not simple dictionaries.

[Jorge Vargas]

On Sat, Feb 14, 2009 at 8:45 AM, Mark Ramm <mark.mch...@gmail.com> wrote:
>
> On Fri, Feb 13, 2009 at 11:35 PM, percious <ch...@percious.com> wrote:
>>
>> Personally I think we should default to SimpleJson, and then if the
>> user has TurboJson installed, we should
>> default to that. It should be simple enough to put a switch in
>> config.
>>
>> try:
>> import turbojson
>> except:
>> import simplejson
>>
>> or such.
>>
>> I feel that for simple jsonifications (dictionaries) SJ will be
>> enough.
>

I think a better solution, given our time constraints and backwards
compatibility, is to create a new config flag 'use_turbojson' which
defaults to True with a comment that False will be the default in
tg2.1, then in the code, build a new render_json function and replace
the check for legacy renders. So in practice we'll have the same
legacy renders but only the json legacy render will be on by default.

> 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.

[Jorge Vargas]

OK I made a ticket and I have a rough first version of this. (1 error
and 1 failure in tests) but i haven't tested it with SA classes.

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