On Sat, 29 Jul 2006 19:18:50 -0700 "Yves-Eric Martin" <[EMAIL PROTECTED]> wrote:
>
> Thoughts from a newbie: sorry but -1 for @view, alternative way to
> introduce "view" in the TG terminology. Explanations below.
>
>
> Kevin Dangoor wrote:
> > The view for a given request is really represented by the @expose
> > decorator.
>
> Hmmm... is it really so? Take this pretty common web development
> pattern: to prevent multiple form submission by a user reloading the
> results page, a form submits to a submission script (logic only), that
> then does a redirect to a results page (view). From my newbie
> perspective, if the decorator was called @view, then here is how I
> would have coded this on my first try:
>
>
> def saveFoo(self, *args, **kw):
> # Logic to save foo here...
> # ...
> raise turbogears.redirect('/results')
>
> @view(template='foo.templates.results')
> def results(self):
> return "Thank you!"
>
>
> Of course that would not work... But then I'd have to ask: why do I
> need the @view decorator on the saveFoo() method, since in the MVC
> sense, this method does not have a view? On the other hand, I find
> @expose much easier to grasp, since it simply says what it actually
> does: expose the method to the outside.
>
> So, even if we keep @expose for compatibility, simply calling the
> decorator @view, and in particular marketing it as "@view" in the
> documentation, would have caused me some unnecessary newbie
> frustration. So I say let's call a duck a duck: -1 for @view, +1 for
> @expose.
>
>
> Now, if we want to introduce "view" in the TG terminology, my
> understanding (again, newbie alert, please correct me if I am out to
> lunch ^^; ) is that it is the templates that represent the "V" in MVC.
> So how about renaming the "template" argument of the expose decorator
> to "view", along with the "templates" folder to "views":
>
> @expose(view='foo.views.results')
>
> Yes, that would probably be a more involved change. But again, I think
> that @view is a bad idea. So, what do you guys think?
I think Yves (Yves-Eric? Eric?) makes some good points that need to be
addressed before any change should be made.
I too figured that the methods of a controller covered the C part of
MVC, not the V part. I thought the V part was mostly template.
A method that handles form submission and then redirects isn't really
something that's viewed, but it does update model data and we all know
from our MVC classes that the view isn't allowed to touch the model,
it's only supposed to be talked to by the controller.
How does a JSON exposed method fit in to the whole thing? It doesn't
display anything, but it'd still have to be @view'ed.
Jason
signature.asc
Description: PGP signature
