On 10/20/05, Daniel <[EMAIL PROTECTED]> wrote:
>
> This evening I wrote a review of TurboGears. Read it here:
> http://www.openpolitics.com/pieces/archives/001763.html
>
> Keep up the good work.
Thanks for the review! Thanks also for the positive comments about the
docs. I seem to see alternating good and bad reviews of the docs. I
think there's a ways to go yet, but they are shaping up.
You're correct that the automatic JSON may expose information that you
don't want to expose. This is particularly true once you can serialize
SQLObjects directly. Elvelind fixed this for 0.9.
As for the raise HTTPRedirect construct, we had some discussion about
that earlier on. In CherryPy 2.0, you called a function to do a
redirect, which was very unpleasant because it didn't reflect that
you're done with the request and should not do anything else. The
raise takes care of that.
I'd also be fine with
return cherrypy.HTTPRedirect(...)
The nice thing about raise is something like this:
@turbogears.expose()
def mypublicmethod(self, arg):
someval = self.dosomething(arg)
return self.process(someval)
def dosomething(self, arg):
# oops, something isn't in the right state...
raise cherrypy.HTTPRedirect(...)
Of course, that is an exceptional condition, so maybe that makes perfect sense.
As far as the whole notion of using redirects, you're right that
you're not locked into this with TurboGears, you can just shift to
another view. But, I personally think redirects solve problems: they
make the URLs in the location bar more consistent with the view and
the alleviate the need to introduce tokens to solve the multiple
posting of a form problem. But, that's a matter of taste and
application requirement, and TurboGears certainly supports returning
some view other than the one listed in expose.
Thanks again for posting the review!
Kevin
--
Kevin Dangoor
Author of the Zesty News RSS newsreader
email: [EMAIL PROTECTED]
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com
