Here's my vote: 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. On Sun, Apr 26, 2009 at 12:32 PM, Jorge Godoy <[email protected]> wrote: > If you're forking it, then I believe that SO support -- as well as support > for old versions of SA -- are interesting. > > 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 <[email protected]> > > > On Sun, Apr 26, 2009 at 5: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. >> >> > > > > > -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
