Hi Dennis,
On Jan 23, 2008 9:19 PM, Dennis <[EMAIL PROTECTED]> wrote:
> follow up here though. Once this is implemented you end up with the
> redirect URL looking something like this:
>
> http://mygreatwebsite.com/django_app/process/?newcontext=22
>
> Which seems okay, but I also have a couple of other fields I'd like to
> default, so when we add in more fields, the URL can become unwieldy:
>
> http://mygreatwebsite.com/django_app/process/?newcontext=22&newname=new%20string
>
It's not really necessary to send all the values back in the query
string. You only need to send the id which you can use to fetch the
object in your view and access all of its fields.
For example, revisiting your process_task view:
def process_task(request):
if request.method == 'POST':
....
.... I'm skipping this part
....
else:
if request.GET.get('newcontext'):
# If there is a "newcontext" in the querystring,
# we fetch it and use it to set up the initial
# form values.
context = get_object_or_404(Context, pk=request.GET['newcontext'])
form = ProcessForm(initial={
'context_id': context.id,
'context_name': context.name,
'context_foo': context.foo,
'context_bar': context.bar,
})
else:
# There were no new context
# use a form without initial values.
form = ProcessForm()
return render_to_response('process.html', {'form': form})
If you haven't used "get_object_or_404" before, take a look here:
http://www.djangoproject.com/documentation/shortcuts/
>
> Which doesn't seem to be in line with django principles of readable
> URL's. Thinking about this a little longer I thought it might be a
> good idea to take a urls.py approach to the problem and create a new
> entry such as:
>
Even though you could do that, personally I wouldn't. I think that an
action or resource should be represented by a single URI. Your
"process task" view is an action, which can accept different
parameters to use as initial values but still, it is the same action.
You would be unnecessarily duplicating code and complicating your
urls.py file.
Of course you might have seen URIs like these:
/blog/entry/1/
/blog/entry/2/
/blog/entry/3/
Which makes sense because every blog entry is an unique resource which
should be represented by a unique URI. Also, a blog is a public facing
site and you would be interested in search engines indexing all your
entries. Plus it makes it easier to tell someone over the phone how to
get to a specific entry.
In your case I'm guessing you are developing an application which
requires a log-in before using it. Your application will be
controlling the work flow from page to page, and you won't dictate
someone over the phone to enter a long and confusing URI and
parameters in their browser.
Regards,
- Jorge
P.D. I noticed that your code is not consistently indented. Make sure
you use the same number of spaces for each indentation level,
preferably four, otherwise you will encounter problems in the future
and it could be difficult to locate them if your indentation is all
mixed up.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
