Re: How to format string on I18n

[rskm1]

On Dec 5, 6:05 am, Tsung-Hsien  wrote:
> I have been delete the "#, fuzzy" and remain the "#, python-format",
> but the string still show English.

You do need to remove the ", fuzzy" in order for the translations to
be used.
But you also need to recompile the .mo files after you make any
changes to the .po files.
https://docs.djangoproject.com/en/1.3/topics/i18n/localization/#compiling-message-files

-- 
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 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Redirect to html file

[rskm1]

> Hi! If I have some html file somewhere (i.e. /var/file), how to
> redirect user to it? It is not a template and not in a template
> folder. Thanks :)

"Redirect" probably isn't the word you wanted there.  If you really
meant "How do I make my view function display the contents of an
arbitrary HTML file?", the answer is:

def showvarfile(request):
  return HttpResponse(open('/var/file').read())

As you can see, it's your own Python code reading the file's contents
and sending it back to the browser.  So this works even if '/var/file'
isn't in a directory that your webserver is serving.  That comes with
some caveats, of course -- it's usually not the best way to do things,
and is not as efficient as just letting the webserver serve it -- but
I think that's what you were asking for...

--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: makemessages .. not all translations found or commented out

[rskm1]

> when I use this command
> ./manage.py makemessages -l nl  -e=html,txt,py --
> pythonpath=apps_pinax,templates_pinax
>
> It finds also text in the txt files.. but it also comments out parts
> of translations I found with the first command like
>
> #~ msgid "Discussion Topics for Tribe"
> #~ msgstr "Discussies van groep"

That "commenting-out" behavior is normal for strings that aren't in-
use anymore.  Which means, makemessages didn't find "Discussion Topics
for Tribe".  Your syntax looks fine, judging by the latest docs, so I
can only think of two possible explanations:
  1. There's a bug in makemessages' handling of the "-e=" parameter,
-OR-
  2. You ran makemessages with some of those options missing.

#2 seems most likely.  If you'd accidentally mis-typed the
makemessages command once on a previous attempt, that would've caused
some strings to be commented-out.  I'm pretty sure that running
makemessages again with the CORRECT options won't magically UN-comment
those entries.

Does your django.po file have a new entry for templates_pinax/tribes/
topics.html:11 "Discussion Topics for Tribe" that ISN'T commented out?

(Sorry, I can't attempt to reproduce the behavior myself -- I'm still
using 0.97 which predates the integration into manage.py AND the -e
option =)

--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Help a noob with a stupid question - forms

[rskm1]

On May 12, 6:47 am, zachp  wrote:
> ... I need the user who does this to be able to select a
> month (and possibly a year) for the drawing she wants to run. I need
> django to convert those two data points into a datetime object for me,
> but it's not readily obvious how to do that.

Are you SURE you need a datetime object?  I'm guessing you will
actually end up needing TWO datetime objects if you continue down that
line of thought (one for the beginning of the month, one for the end
of the month, eh?).

I solved the same problem you're describing, like so:
(paraphrased and may contain typos.  It's also from my Very First
python/django project, so it's far from "optimal".  I don't remember
why I zero-padded the month :-)

class ThingyForm(forms.Form):
  year = forms.ChoiceField(choices=[('2006',"2006"), ('2007',"2007"),
('2008',"2008"), ('2009',"2009"), ('2010',"2010"),])
  month = forms.ChoiceField(choices=[('01',"Jan"), ('02',"Feb"),
('03',"Mar"),
('04',"Apr"), ('05',"May"), ('06',"Jun"), ('07',"Jul"),
('08',"Aug"), ('09',"Sep"),
('10',"Oct"), ('11',"Nov"), ('12',"Dec"), ('all',"ANNUAL")])

def thingyview(httpreq):
  today = datetime.now()
  year = str(today.year)
  month = ("0"+ str(today.month))[-2:]
  if httpreq.method=="POST":
thingyform = ThingyForm(httpreq.POST)
if thingyform.is_valid():
  year = thingyform.cleaned_data['year']
  month = thingyform.cleaned_data['month']
  else:
thingyform = ThingyForm(initial={'year':year, 'month':month})
  #

Ultimately, I needed the year and month to limit the selections I got
from the database (via django's ORM), and in my case I also wanted the
option to select ALL months for that year.  So here's where the cool
part is, where I do that without needing any datetime objects:

  thingylist = Thingies.objects.filter(funtime__year=year)
  if not month=='all':
thingylist = thingylist.filter(funtime__month=month)

It's so easy that it didn't even jump out at me on my first read of
the docs.  It's definitely easier than coming up with TWO datetime
objects and filtering Thingies with a funtime between them.

--Rob

--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Random locale strings translated

[rskm1]

On May 11, 3:47 am, phred78  wrote:
> I've specified translation string, got the translations done and
> compiled.
>
> It's working for the most part, but some of the strings don't show up
> correctly translated, where others do.
> What could be causing this? Has anyone come across a similar problem?
> I'm pretty sure the translations are in the correct .po files.

Some things to check:
* make sure the latest .po files have been compiled into .mo files.
(django/bin/compile-messages.py)
* check the .po-file lines that aren't working, and make sure they
don't say "#, fuzzy".

The fuzzy matches can be a big help to your translators when minor
changes to the code and templates are made, but they WON'T be used
unless you remove that ", fuzzy" attribute (and recompile the .mo
files).

--Rob

--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Html inside {% blocktrans %} tags

[rskm1]

On May 8, 8:06 pm, Stephen Sundell  wrote:
> Can I wrap something like : "Click here to go
> back." inside a blocktrans tag?

Certainly!  The only caveat is that the person doing the translation
work (often a hired contractor, sometimes from outside of the Computer-
Science field) will need to understand HTML markup and ensure that
they don't mess up or misplace or omit the tags.

HTML is straightforward enough that you can explain it to a rookie in
a few paragraphs (e.g. "don't translate the text between the "<" and
">".  "" marks where the style ends, so make sure the tags are in
equivalent spots in the translated text.  Etc etc.)

--Rob

--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Admin site I18n - ForeignKeys, app names questions

[rskm1]

> Also, what does 'fuzzy' mean in my .po file?

I'm not an authority on the subject but have dealt with translations
and .po files quite a bit.

The term "fuzzy" in this context means it's not an EXACT match, but
it's very similar; i.e. a "fuzzy match".

The "fuzzy" usually shows up when the original text (in the template
marked with {%trans/blocktrans%} or in the code marked with
ugettext_lazy/_()) has been MODIFIED slightly since the translations
were first written.

It can also show up when a new piece of text appears in the original
text, which doesn't have its own translation yet, but is a pretty
close match for another piece of text that DOES have a translation.

It's *very important* that you find and evaluate them, because the
"fuzzy" matcher isn't too smart;  "don't start a fire" and "go start a
fire" would probably count as a fuzzy match even though they
ultimately mean the opposite thing, for example.  If the fuzzy matcher
got lucky and it's a good match, manually remove the ", fuzzy" from
the comment in the .po.  If it was wrong, fix the translation and
remove the ", fuzzy" from the comment in the .po.

(I didn't find documentation for this back when I first started using
it, so those are just my unofficial instructions derived through
trial).

--~--~-~--~~~---~--~~
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 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Dictionary Issue in Django Template (Beginner)

[rskm1]

> {% for machine in web %}
>   {% for status_message in  status.machine %}
> ...
> So, i want to be able to do something like status.machine..

If there's a BETTER way, I'd love to hear it too, but this is usually
accomplished with a custom filter.
It's commonly named "getattr", and your template would change like so:

{% load myfilters %}
{% for machine in web %}
  {% for status_message in  status|getattr:machine %}
...

You don't need to name it "myfilters.py", but the custom "getattr"
filter code MUST be in a directory named "templatetags/".  Mine is a
little different (I didn't bother with the "default value"
capability), but I used the same basic concepts as:
http://www.djangosnippets.org/snippets/38/ (Read RichardBronosky's
comment too!)
http://www.djangosnippets.org/snippets/411/ (if you want to get a
little fancier)

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: modify select widget

[rskm1]

On Jul 13, 9:58 am, "Nikolay Panov" <[EMAIL PROTECTED]> wrote:
> You should create your custom widget for this.

Also see the thread from a couple weeks ago titled "choices",
http://groups.google.com/group/django-users/browse_thread/thread/d373794afef19e39/0009b671ebd91ac1

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: choices

[rskm1]

On Jul 3, 8:13 am, urukay <[EMAIL PROTECTED]> wrote:
> no, no i mean it otherway, just like Rajesh Dhawan wrote (link he sent).

I will rephrase your original question; it's not obvious to everyone
that the REASON you want two of your six choices to be "not
selectable" is because they are CATEGORIES or HEADERS intended to
separate the choices, NOT actual choices themselves.

But you DO still want them to appear in the dropdown as visual
separators, which Rajesh's link (http://www.w3schools.com/tags/
tag_optgroup.asp) illustrates nicely.

To that end, it would be better to reorganize your choices
hierarchically:

CHOICES = [
 ('0', "Black"),
 ('255', "White"),
 ('Basic Colors', [
   ('1', "Red"),
   ('2', "Green"),
   ('3', "Blue") ] ),
 ('Other Colors', [
   ('5', "Brown"),
. ] )
]

Now your question becomes,
"Is the select-dropdown widget in Django sophisticated enough to
realize that if an element in the choices list contains a list or
tuple (rather than a string) value, it should render that as an
 and recurse into the NESTED list?"

The answer is "no", but it doesn't choke on it either.
This would be an excellent candidate for a custom widget & renderer, I
think.

http://www.djangoproject.com/documentation/newforms/#custom-widgets

You could subclass the renderer methods of the default selection-
dropdown renderer and add "smarts" to make it generate  tags
and recurse appropriately, when it detected a nested list or tuple.

Not exactly trivial, but it's not as difficult as you might think,
once you start snooping around in the Django source code.

I'm a novice myself and have only written a renderer subclass to put
radio-button labels to the left of the button instead of to the right,
so I won't be much help if you run into trouble...
but hopefully my suggestion will open up an avenue of exploration that
might not have occurred to you.  Here's a snippet to show how easy it
was:


from django.newforms.widgets import RadioInput, RadioFieldRenderer

class PrelabelRadioInput(RadioInput):
def __unicode__(self):
  ...

class PrelabelRadioFieldRenderer(RadioFieldRenderer):
def __iter__(self):
for i, choice in enumerate(self.choices):
yield PrelabelRadioInput(self.name, self.value,
self.attrs.copy(), choice, i)

def __getitem__(self, idx):
choice = self.choices[idx]
return PrelabelRadioInput(self.name, self.value,
self.attrs.copy(), choice, idx)

class MyForm(forms.Form):
mything =
forms.ChoiceField(widget=RadioSelect(renderer=PrelabelRadioFieldRenderer), ...)
...

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: how to get form fields to show

[rskm1]

> urlpatterns = patterns('',
> (r'/step-1.html', 'billpay.views.DoPayDetailForm'),
> )
>
> Wouldn't this call the dopaydetailform view if you went to  the page /
> step-1.html ?

At this stage, while you're still learning, I would AVOID making URL
mappings that "appear" to be HTML files, because you'll end up
confusing yourself.  (Django will let you do stuff like that later, if
you have some compelling *reason* for it).

But the way it works is the urlpatterns map a URL to a Python "views"
function, and this mapping has NOTHING to do with the name of your
template.

This would work equally well and be less confusing:
| # urls.py
| urlpatterns = patterns('',
| (r'/step-1/$', 'billpay.views.DoPayDetailForm'),
| )

Visiting "http://yoursite/step-1/; will call the DoPayDetailForm()
function in your billpay/views.py and pass it an HTTP Request
parameter.  Simple.

The TEMPLATE (which you named step-1.html) doesn't come into the
picture until that code returns an HTTP Response object.  The first
parameter of render_to_response() is the template name, which has
_nothing_ to do with the URL mapping.

You can map the URL "/step-1/" and name the template step-1.html if
you want, but that's merely a coincidence for your own convenience;
there's no ACTUAL direct relationship between those names.

I'm probably overemphasizing a simple point, but it seems like you
might've assumed there is some "connection" where there isn't one,
since you put that unusual ".html" into your URL mapping.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Do you code django with Komodo?

[rskm1]

On Jun 24, 4:22 pm, Tye <[EMAIL PROTECTED]> wrote:
> Semi-off-topic:
> Does anybody know how to get notepad to save as UTF-8 by default? It
> keeps trying ANSI, and I keep hating.

Unlikely; Notepad is REALLY lightweight.
Wordpad is MUCH better; it handles files >64K, files with UNIX-style
linebreaks, and files with foreign characters.  So if you're stuck
with Windows and don't want to install any third-party stuff, just use
Wordpad and forget that Notepad even exists.

Personally, I'm running Linux with KDE, and "kwrite" and "kdevelop"
both have pretty good Python syntax recognition builtin.  "kdevelop"
even has tabs and a navigator like the Eclipse IDE, but seems to be
less "bloated".  (haven't tried Komodo; freeIDE>$IDE =)

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: forms.form_for_model

[rskm1]

Ahh!  That helps.  Sorry, I haven't ever used form_for_model() and
didn't recognize that IssueEntryForm in the original post was NOT a
form instance.  Corrections embedded below.


On Dec 21, 8:48 am, mike <[EMAIL PROTECTED]> wrote:
> Sorry if I was unclean, I just discovered this and I am still learning
> newforms, I am using forms.form_for_model and trying to get two form
> to display in my template, only 1 is a foreign key that I used
> edit_inline with my model, I am trying to get the 'customer' field of
> my issue to be hidden and automatically be given the 'name' field of
> my customer model, when I did what you suggested I get the error
> below, my view is below, thx for the suggestion
>
> type object 'IssueForm' has no attribute 'initial'
>
> @staff_member_required
> def add_edit_customer(request, id=None):
>if id is None:
> CustomerEntryForm = forms.form_for_model(Customer)
>else:
> entry = get_object_or_404(Customer, pk=id)
> IssueEntryForm = forms.form_for_model(Issue,
> fields=('issue''customer'))
> issues = Issue.objects.filter(name=entry.name)
> CustomerEntryForm = forms.form_for_instance(entry)
> cust1 = Customer.objects.get(pk=id)
> issues = Issue.objects.filter(customer=cust1)
> IssueEntryForm.base_fields['customer'].widget =
> widgets.HiddenInput()
> IssueEntryForm.initial['customer'] = "Blah, Inc."

Sorry, my initial example was completely wrong; initial[] is part of
the form *instance*, not *class* (I'm a Python novice, so forgive me
if I botched the teminology there).
Remove that line and see correction below.

>
>if request.method == 'POST':
> form = CustomerEntryForm(request.POST)
> if form.is_valid():
> form.save()
> return HttpResponseRedirect('/customers')
>if request.method == 'POST':
> form1 = IssueEntryForm(request.POST)
> if form1.is_valid():
>  form1 = form1.save(commit=False)
>  form1.customer = entry.name
>  form1.save()
> return HttpResponseRedirect('/customers/')
>else:
> form = CustomerEntryForm()
> form1 = IssueEntryForm()

Add here:
  form1.initial['customer'] = "Blah, Inc."

Assuming your Issue model has a field named 'customer' (and it's a
text field), that will cause "Blah, Inc." to appear pre-filled-in when
the unbound form is rendered.

Taking a wild guess about your models, though, if the Issue model's
'customer' field is actually a ForeignKey to a Customer object, change
that line to:
  form1.initial['customer'] = cust1

(I'm getting a bit out of my depth here, but I think that should
work.)

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: How to make fields with editable=False visible in the Admin interface

[rskm1]

On Dec 21, 2:59 am, brian corrigan <[EMAIL PROTECTED]> wrote:
> try using
>
> 

Seems like a good idea, but remember that a DISABLED field's value
does _not_ get sent back with the HttpRequest submission, and will
therefore be flagged as missing input if the form's field definition
doesn't have "required=False"!

Making the field READONLY (rather than DISABLED) avoids this problem,
but unfortunately READONLY only works on a very limited subset of
 types.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: forms.form_for_model

[rskm1]

On Dec 20, 2:58 pm, mike <[EMAIL PROTECTED]> wrote:
> anyone know how to auto assign a variable to my form field?
>
> IssueEntryForm.base_fields['customer'].widget = widgets.HiddenInput()
> IssueEntryForm.base_fields['customer'].widget = HELP

I'm not sure I understand the question; what exactly do you mean by
"auto assign a variable"?

If you're looking for a way to set the value of a field in an un-bound
form, just do the usual:
  IssueEntryForm.initial['customer'] = "Blah, Inc."

Since there was no visibly editable field, the *bound* form you create
after the HttpRequest.POST submission comes back will have an
unmolested "Blah, Inc." value in
IssueEntryForm.cleaned_data['customer']


(If that's not what you were after, you may want to elaborate.  Your
example code looks like you want to dynamically determine what the
widget for the field will be, but that doesn't match the question you
asked...)

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Limit Spam

[rskm1]

> On Sun, 2007-12-16 at 10:56 -0500, Tim Riley wrote:
> > Is there a way that the admins can limit the amount of spam coming
> > from this mailing list?

I've never moderated a google group, but it seems like a nice feature
would be the ability to require moderator approval of the FIRST post
made by any new subscriber.  Full moderation would be ridiculous for a
list with this much traffic, but clearly the current automated
screening process for new subscribers isn't good enough to
keep spammers out.

But forcing the *first* post from any new subscriber to be approved by
a moderator would be the best of both worlds.  I know I should
probably submit the idea to the google-group folks, but I doubt they'd
pay any heed to suggestions coming from someone who wasn't even a
moderator of one of their groups.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Stupid template question

[rskm1]

On Dec 14, 1:03 am, Steve Freitas <[EMAIL PROTECTED]> wrote:
> Only, it doesn't work. It seems like . lookups
> require the argument to be a literal, not a variable.

Grindizer addresses your specific problem of enumerating key/value
pairs in a template (piece of cake!), but if you still wanted to
reference attributes with a "dynamic" name, here's an old thread where
I asked the same thing, and got some good suggestions.  (You can do it
with a custom tag OR a custom filter)

http://groups.google.com/group/django-users/browse_thread/thread/2f7c88a386ac5d59/0a53f94e28937dbe?hl=en=gst

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Request data is lost between two views

[rskm1]

On Oct 16, 5:35 am, Divan Roulant <[EMAIL PROTECTED]> wrote:
> I loose request data when I call a view with reverse from a previous
> view. Here is what I do:
>
> def my_first_view(request):
> # Processing here
> return HttpResponseRedirect(reverse('my_second_view,
> args=(request,)))
>
> def my_second_view(request):
> # I would like to processing request data from the previous view,
> but request is empty
> return render_to_response('results.html', ...)

Kinda pointing out the obvious, but the views ARE, after all, just
Python functions.
USUALLY you want to redirect after processing a form, for example, but
maybe in your case you don't?

Note that there are some caveats to doing this (like, what happens if
a user hits [Reload] on the second page, which will still have the
"original" URL), but in your case you might be able to skip all the
reverse-lookups and url evaluation, and simply:

def my_first_view(request):
  # Processing here
  # Don't send a response from here, just pass control to
my_second_view's implementation
  return my_second_view(request, parmsInADict)

def my_second_view(request, parmsFromFirstView=None):
  # also look in the parmsFromFirstView dict, not just request.POST...
  return render_to_response('results.html', ...)

If you MUST redirect in your situation, well nevermind, see the other
responses.


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Check box form

[rskm1]

On Oct 17, 1:52 pm, jacoberg2 <[EMAIL PROTECTED]> wrote:
> I am trying to create a checkbox form so that the user can delete a
> large number of
> registrations at once. I am wondering how I should set up the view in
> order to deal with
> the incoming data. Any suggestions?

The template can generate its own HTML easily enough without using a
forms.Form, e.g.

  
{% for t in thingylist %}
  
  {{ t.longname|escape }}
{% endfor %}
  

Then, when you're processing the POST form data, it's absolutely vital
that you call the POST.getlist('thingies') method rather than just
dereferencing POST['thingies'] !

  if httpreq.POST.has_key('thingies'):
selectedthingies = httpreq.POST.getlist('thingies')

I struggled with that for quite a while when I made my first checkbox
form in Django; I was expecting a list or tuple to be right there in
the POST for me to grab directly.  But nope, you gotta use the
getlist() method.


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Contact Form not Rendering Properly

[rskm1]

> The html code isn't being rendered properly.

I'm assuming this is a slightly-noobish question (I'm still a novice
myself, so if the problem is something more subtle, nevermind me).

Your template seems a little light on the use of the "|escape"
filter.  So if any of the values in your database have "special" chars
(like & or " or <), you could easily end up with bad HTML markup.

To verify, just "View Source" on the bad page and see exactly where
the HTML tag corruption starts.

To fix the problem, just change (for example)
  {{ contact.name }}
to
  {{ contact.name|escape }}

Don't go overboard, though -- you definitely _DON'T_ want
  {{ form|escape }}

=)


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Newbie: How to create different person models that share a profile model?

[rskm1]

On Aug 24, 7:28 pm, "Ariel Mauricio Nunez Gomez"
<[EMAIL PROTECTED]> wrote:
> Note: The user profile part was taken from this useful blog entry on James
> Bennet 
> site:http://www.b-list.org/weblog/2006/06/06/django-tips-extending-user-model

Yeah, that's the advice I keep seeing when this question comes up.
The trouble is, if you read all the comments below it, is that the
admin interface makes it LOOK LIKE you can edit the UserProfile
information inline with the "built-in" User fields, but in actual
fact, the changes or additions you make get *discarded*.

That's not just useless, it's misleading and dangerous.  I'm not sure
whether it's a bug in Django or just a mistake I made in my
UserProfile model definition, but since I only need a couple people
doing admin-level upkeep, I just shrugged and made sure they know they
have to go create/edit the UserProfile object separately.


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Multi field validation with clean method

[rskm1]

On Aug 9, 7:34 pm, [EMAIL PROTECTED] wrote:
> So, if I use clean_annotationvalue to do both how would I be able to put an 
> error
> message on the annotation type ...

I think you were on the right track the first time.  Philosophically,
the Form's clean() method is where you're supposed to be doing the
inter-field validations, and you don't have to worry about field
sequence there either.

So now your question boils down to a simple "How do I associate the
error message with a specific field, from the form's clean() method?"

Normally, if you raise a ValidationError exception from
YourForm.clean(), the message appears in a "special" section of the
form._errors collection named "__all__", accessed from the template as
{{ form.non_field_errors }}.
But if you can figure out how to manually inject the message into
yourform._errors yourself, you could make it appear on any field you
want.  Well, *theoretically* anyway; I haven't tried that myself,
since I always *want* the inter-field validation errors to appear in a
different spot.


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: about templates tags

[rskm1]

On Aug 9, 11:23 am, "Lic. José M. Rodriguez Bacallao"
<[EMAIL PROTECTED]> wrote:
> can I include more than one template tag definition in a single template tag
> file? Right  now I was trying  to do that and I can't.

I'm still a novice, but I know you can define multiple filters in
one .py file, and I'm pretty sure you can define multiple tags in
one .py file also.  I'll bet you could even *mix* filter and tag
definitions in the same .py file.

Since you claim you "can't", I would guess that you just forgot to
register one of the tags.
Or maybe you're not returning a Node-subclass object with a render()
method defined.
Or some other problem that is unrelated to it being in the same file
as another tag definition.

def mytagfunc(parser, token):
  # ...
  return myNode
register.tag('mytag', mytagfunc)

def myothertagfunc(parser, token):
  # ...
  return myotherNode
register.tag('myothertag', myothertagfunc)


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Templates: dynamic attribute referencing?

[rskm1]

(I know I can't simply _NEST_ {{}}'s in a template, but I'm using it
as pseudosyntax to help express what I'm _trying_ to do.)


Is there any way, in a template, to get an attribute of an object when
the NAME of that attribute is dynamic (i.e. in/from another object)?

What I really want is:
  {{ obj1.{{ obj2.attname }} }}  {# NOPE #}
or somewhat Pythonese:
  {{ obj1.__getattr__( {{ obj2.attname }} ) }}  {# NOPE #}

I thought I could be tricky and write a filter called "getattrbyname"
that would return only the specified attribute of the object...
...but that won't work either, because I'm not sure how to get the
name parameter to it from the template.
  {{ obj1|getattrbyname:"{{ obj2.attname }}" }}  {# NOPE #}


Is there another approach that would actually WORK?

(Note: This is kind of an "overzealous novice" question, so don't rule
out the possibility that I totally overlooked some obvious solution.
=)



If you're wondering how I came up with such a goofy request:
My application is displaying a table with information about a "key" in
each row.
I thought it would be cool to extend the table-header-sorting
capability (djangosnippet #308), to make headers() return the
order_criterion as 'columnname' in each entry.
Then I could reuse the same template for lots of different subsets of
the same table, simply by changing the set of headers I pass in.
(Because sometimes I want the table to contain more or less detail
about each "key")

Like so:

  

{% for header in headers %}
{% if header.sortable %}
  {{ header.text|escape }}
{% else %} {# !header.sortable #}
  {{ header.text|escape }}
{% endif %} {# header.sortable #}
{% endfor %} {# headers #}


{% for key in keylist %}
  
{% for header in headers %}

  {# NOPE, THIS DOESN'T WORK! #}
  {{ key.{{ header.columnname }}|escape }} {# NOPE #}

{% endfor %} {# headers #}
  
{% endfor %} {# keylist #}

  


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Newforms w/ *dynamic* ChoiceField choices?

[rskm1]

Newforms has a spiffy way to dynamically set the "initial" values of
fields, in the view code when the Form is constructed.
  choosecolorform = ChooseColorForm(initial={'color': 'black'})

I was hoping it would be just as easy to dynamically define the
choices available in a ChoiceField, too... but no such luck.

The choices in my ChoiceField will ultimately come from a database,
and will vary based on user permissions and/or the state of the page
that the form is being displayed on, etc.  For a contrived example,
consider paint-color choices that will depend on whether the form is
on a page displaying a metal object that takes enamel, or a wooden
object that takes latex paint.

I'd rather not make my Form be "aware" of my database, or the page
it's on, because that seems like poor encapsulation and probably a
violation of the DRY principle (I'm just going on intuition here,
though).

So here's what I'm doing, to allow my view to dynamically tweak the
choices:

myforms.py:
from django import newforms as forms

class ChooseColorForm(forms.Form):
  color = forms.ChoiceField(initial="unpainted", choices =
[("unpainted", "Don't paint it"),], label="Choose a color")

  def setchoices(self, choices):
field = None
for item in self.fields.items():
  if item[0]=="color":
field = item[1]
if field:
  field.choices = choices
  field.initial = choices[0][0]
else:
  print "INTERNAL ERROR! No color field found on ChooseColorForm
object"
# /class ChooseColorForm


views.py:
from myforms import ChooseColorForm
def remodelthingypage(httpreq):
  # ...
  choosecolorform = ChooseColorForm()
  if thingy.ismetal:
choosecolorform.setchoices(_getenamelpaintcolors(sa))
  else:
choosecolorform.setchoices(_getlatexpaintcolors(sa))
  return _respond(httpreq, 'remodeling.html', { 'thingy': thingy,
'choosecolorform': choosecolorform, })
# /remodelthingypage()


* NOTE: For my contrived example, I could obviously just make two Form
subclasses, one for latex paints and another for enamels, but the
actual scenario is more complicated and there are other factors
involved in determining the available choices, such as whether there's
enough of that color in stock to cover the whole thingy or not.


So anyway, this technique WORKS -- but I'm a bit tentative about it
because:
a) I'm still a Django *AND* a Python novice, and
b) I had to dig around in the newforms code to figure out how to ram
my own choices into the form object, which is dangerous because
there's no private/protected to warn me not to screw around with that,
AND my code is now tied to the internal implementation of newforms.

Afterwards, I found a blog entry that does something similar,
http://www.zoia.org/blog/2007/04/23/using-dynamic-choices-with-django-newforms-and-custom-widgets/
but it uses:
  Form.base_fields['tags'].choices
rather than my:
  Form.fields.items()[x][1].choices
That makes my goofy for-loop unnecessary, but I'm not sure what the
implications of each are (too lazy to analyze all the newforms code,
plus I wanted to ask anyway, because I don't know what the plans/
vision for newforms is)

So, are there better techniques for dynamically setting the choices in
a newforms ChoiceField?  (Or, is my whole approach dumb.?)


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: prepare() on oldforms.CheckboxSelectMultipleField not working properly?

[rskm1]

On Jul 22, 10:16 am, "Daniel Kvasnicka jr."
<[EMAIL PROTECTED]> wrote:
> errors = form.get_validation_errors(data)
>
> which in effect calls prepare() on every field, my data from those
> selects are trimmed and contain only the last checked item. So when I
> have the following choices from which I check the last two
>
> choices = (
> ('0', 'foo'),
> ('1', 'bar'),
> ('2', 'hello'),
> )
>
> only 'hello' gets saved to the DB (MySQL 5.0.38).

This might have nothing to do with the forms processing; I ran into
the same problem with a raw html form I'd hand-constructed that had a
set of checkboxes (same name, different values).

How are you getting the data from the HTTP request when the form is
submitted?

If you call
  httpreq.POST['choices']
that will return a string containing only the LAST of the chosen
items, with no indication that there's more to be had.

But if you call
  httpreq.POST.getlist('choices')
that will return a list containing ALL of the chosen items.

I think the Djangonati would recommend that you rewrite it in newforms
(better sooner than later, right?), but I don't think that would fix
your immediate problem anyway, if it's happening in the code where you
process the form input into db accesses.


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Django's User authentication

[rskm1]

Jason F. McBrayer wrote:
> james_027 <[EMAIL PROTECTED]> writes:
>
> > what if I need additional fields or methods for my apps? Do i inherit
> > it or edit the user class?
>
> The standard approach is here:
> http://www.b-list.org/weblog/2006/06/06/django-tips-extending-user-model

I'm glad this came up, I've been struggling with it myself.  I'd like
to be able to edit the additional fields that I associated with the
User (via my UserProfile class) from the admin interface, right inline
with the rest of the User fields.

So I took the advice in one of the comments in that thread.  I won't
pretend to comprehend it all, but it says:

| class UserProfile(models.Model):
|   user = models.ForeignKey(User, edit_inline=models.TABULAR,
num_in_admin=1,min_num_in_admin=1,
max_num_in_admin=1,num_extra_on_change=0)
|   # ... my additional fields


This produces an error when validating models,

| Validating models...
| keyapp.userprofile: At least one field in UserProfile should have
core=True, because it's being edited inline by user.User.
| 1 error found.


Okay, so who am I to argue with an error message?  I slap a
"core=True," in there with it (on ALL the fields in UserProfile;
anything less causes other problems), and it SEEMS to work!  That is,
there's another box in the admin interface for editing a User object,
with my additional fields available to edit.

Too good to be true, right?
Right. :-(
I can neither add a UserProfile nor edit the values of the UserProfile
from the User-edit admin page.

I know, I know, it was unreasonable to expect it to be THAT easy.  But
the fact that it DISPLAYS the fields from another table (and
*pretends* to let me edit them even though it discards my changes)
with so little work on my part makes me think it might work if I
wasn't doing something wrong or dumb.

/myproj/mainweb/settings.py:
|  INSTALLED_APPS = (
|'django.contrib.auth',
|'django.contrib.contenttypes',
|'django.contrib.sessions',
|'django.contrib.sites',
|'myproj.mainweb.myweb.myapp',  # my stuff
|'django.contrib.admin',# user-account administration interface
(provided by Django)
|  )
|  AUTH_PROFILE_MODULE = 'myapp.UserProfile'


/myproj/mainweb/myweb/myapp/models.py:
|  from django.db import models
|  from django.contrib.auth.models import User
|  class UserProfile(models.Model):
|user = models.ForeignKey(User, edit_inline=models.TABULAR,
num_in_admin=1,min_num_in_admin=1,
max_num_in_admin=1,num_extra_on_change=0, core=True)
|ftv = models.CharField('Favorite TV Station', maxlength=4,
core=True)
|phone = models.CharField('Telephone Number', maxlength=24,
core=True)
|  class Admin:
|pass

The UserProfile fields DO show up in the User-editing admin page, as
input fields... but any input or changes to them are ignored/discarded.


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: recursive relation

[rskm1]

On Jul 16, 3:36 pm, "Lic. José M. Rodriguez Bacallao"
<[EMAIL PROTECTED]> wrote:
> How can I make a recursive one-to-many relation?
>
> --
> Lic. José M. Rodriguez Bacallao

According to
http://www.djangoproject.com/documentation/model-api/#many-to-one-relationships

``To create a recursive relationship - an object that has a many-to-
one relationship with itself - use models.ForeignKey('self').''

So basically, just take the one-to-many relationship you wanted, and
*reverse* the roles.
For example, if you had a Person object and you wanted to keep track
of the multiple Person objects who were its "employees", simply
reverse the roles.  Make each Person object keep track of its "boss"
instead.


(Hopefully that's what you were looking for; if I misunderstood the
question and you were looking for more "advanced" info, I probably
won't be much help since I'm a novice myself)


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: {{ perms }} seems to be empty

[rskm1]

Jeremy Dunck wrote:
> On 5/23/07, Michael Lake <[EMAIL PROTECTED]> wrote:
> ...
> >  return render_to_response('lab/user.html', data)
>
> Yeah, that's your problem right there.
> :
> ... I imagine this bites a lot of people on the ass.  :(

Add me to the list of ass-bitten and extremely frustrated.  I followed
the tutorials through (including the part about the
render_to_response() shortcut), but when I started adding permission
levels to my own app, was left scratching my head when the
{{perms.foo}} feature didn't work at all.
(http://www.djangoproject.com/documentation/authentication/)

After trying every goofy combination of dot-syntax I could think of,
passing my own 'perms' to the shortcut as data (which I knew wasn't
right),
  { 'perms': httpreq.user.get_all_permissions(), }
and snooping in django/core/context_processors.py without any magical
insight,
I finally caved in and joined this list.

And, sure enough, it wasn't just me!

I'm WAY too much of a Python & Django noob to suggest design changes,
but...
Any chance of getting the _DOCS_ updated?

For example, it would be nice if the first place {{perms.foo}} was
mentioned would at least hint that it wouldn't work in conjunction
with the render_to_response() shortcut, or perhaps it could introduce
the RequestContext class (which I never would've _heard_ of, except
for this thread).

(Anyways, thanks to Jeremy for the explanation/solution, I'm at least
making some progress again now that I've got my own shortcut function
to replace render_to_response())


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: {{ perms }} seems to be empty

[rskm1]

rskm1 wrote:
> Any chance of getting the _DOCS_ updated?
>
> For example, it would be nice if the first place {{perms.foo}} was
> mentioned would at least hint that it wouldn't work in conjunction
> with the render_to_response() shortcut, or perhaps it could introduce
> the RequestContext class (which I never would've _heard_ of, except
> for this thread).

Whoops, I'm retarded, it actually DOES introduce the RequestContext
class (the significance of which didn't "sink in" until after reading
this thread).  It would've saved me a lot of pain, though, had it
mentioned that render_to_response() did NOT use RequestContext.


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---