On Jul 6, 9:57 am, neebone <[EMAIL PROTECTED]> wrote:
> On Jul 6, 9:46 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
>
>
>
> > On Fri, 2007-07-06 at 08:26 +0000, neebone wrote:
>
> > [...]
>
> > > Ok, I've got a page which uses a generic view to load the article into
> > > the template. All good so far. I've then created two template tags,
> > > list_comments and comment_form.
> > > list_comments is displayed first. The tag grabs the comments
> > > associated with article and returns a rendered template.
> > > comment_form does the same expect returns a rendered form. Now,
> > > because the article page sends the request context to its template,
> > > all the tags within the template can read the request variable too.
> > > This means, the form tag can also detect if a POST action has taken
> > > place, and add a comment (which is how it works).
>
> > > So this poses the problem - am I using the tag for the wrong thing? I
> > > dont want to send the post request off to a different url which will
> > > handle adding the comment....however I could, instead of using a
> > > generic view, use a custom article view to detect a post request and
> > > load a different view to add the comment - redirecting back to article
> > > which solves my problem.
>
> > This is a very unusual way of coding, I suspect. You seem to be trying
> > to put the logic that would normally be part of a view (which is
> > basically the business logic and request handling side of an app) into
> > the template rendering phase instead (presentation logic). So, yes,
> > there are going to be some request handling things you can't do, at
> > least not easily.
>
> > If I were you, I would just use normal views to do this. I can't see
> > that you are saving yourself any code doing it the current way -- you
> > still have to write all the POST processing code, but you've put it in
> > the tag instead of another function.
>
> > Certainly trying to do any acting on the request using redirection or
> > anything like that is inappropriate for the rendering phase. You're
> > already into the "produce output" phase by that point and have gone past
> > the point of controlling where the output goes.
>
> > Regards,
> > Malcolm
>
> > --
> > I don't have a solution, but I admire your
> > problem.http://www.pointy-stick.com/blog/
>
> Yeh, I see what your saying. I was trying to emulate, to a degree, how
> the django comment stuff works (without actually looking at the code).
> The tag itself is basic - it just calls a comment function which
> handles adding the comment.
>
> I wanted the comments to be dropped into any page (using generic
> relations to any given model). If anything, the main reason I needed
> the redirect was because the comments get listed first, then the form
> gets processed. But obviously when the new comment has been added, the
> list has already been rendered - meaning the new comment wont appear
> until the page is refreshed!
>
> Ok, back to the drawing board... Thanks Malcom.
Just to update, I'm getting the form to post to a different url which
handles the logic of creating the comment then redirects back to the
article page on success. All good. My only problem is what to do if
the form contains missing fields - I need to get back to the article
page and re-populate the form with the entered information _plus_
error messages (field required etc).
Any way to send a POST request from a view to a given url similar to
the way Client works in django.test.client?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
