Sorry, the above post was meant to say I followed the idea that
Heigler presented.
On Dec 6, 1:56 pm, jwpeddle wrote:
> I followed this type of thinking and have a result I'm happy with. I
> have a view that accepts render_to_response args as well as an
> additional forms dict. Rather than call r
I followed this type of thinking and have a result I'm happy with. I
have a view that accepts render_to_response args as well as an
additional forms dict. Rather than call render_to_response, I call my
custom view, which looks for results from a number of forms, processes
if required, then returns
You can use a hidden input in the for as a way of holding the link or
id/ct of an object so you can determine where to redirect to. If the
action is repetitive and you have a pretty good idea of where you to
redirect to, I would think that is a simple solution.
This is what django's comment app do
I got the same need and wrote up a FormView wich handles all the
repetitive process of a form.
In your case, you could build your view like this: http://dpaste.com/129827/
You will find basic example (and explanations) here:
http://www.obviews.com/form/simplest/.
Hope this helps,
Manu
--
You re
On Dec 4, 6:43 pm, jwpeddle wrote:
> Not having any luck with this. Surely there's a simple example out
> there somewhere of view agnostic DRY form logic.
The old thread you point to still makes sense.
A redirect can only happen in response to a request
a request is handled by a view
It soun
Maybe this code can help you about the approach, is just an example
based on your previous templatetag (i haven't tested it):
http://dpaste.com/129361/
The view isn't really generic, but i probablly would follow that
approach to solve this problem.
--
You received this message because you are su
Not having any luck with this. Surely there's a simple example out
there somewhere of view agnostic DRY form logic.
On Dec 4, 10:43 am, jwpeddle wrote:
> That is definitely one approach I hadn't considered, and just might
> work in my situation.
>
> On Dec 4, 10:13 am, Heigler wrote:
>
> > I thi
That is definitely one approach I hadn't considered, and just might
work in my situation.
On Dec 4, 10:13 am, Heigler wrote:
> I think the way is build your own generic view if you have customized
> things like that comment tag.
--
You received this message because you are subscribed to the Goo
I think the way is build your own generic view if you have customized
things like that comment tag.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this grou
I am currently trying to write a custom generic comment app and
growing increasingly frustrated with template tags. As far as I can
tell, template tags are the only mechanism provided that allow pieces
of logic to be shared across templates. Nonetheless, you cannot treat
them like a view, and canno
10 matches
Mail list logo
