Re: FormWizard: Setting up a ChoiceField.choices based on previous forms,

[David Durham, Jr.]

On Tue, Dec 30, 2008 at 3:16 PM, Ariel Mauricio Nunez Gomez
 wrote:
> Hello list,
> Today I started using FormWizard and could not find a clean way to populate
> a choices field based on previously submitted forms, I ended up overriding
> the render method like this(The only changed line is the one highlited):



If you're doing a lot of FormWizard work, maybe take a look at the
Session-based FormWizard I wrote and give me some feedback.

   http://code.djangoproject.com/ticket/9200

It sounds like you have a reasonable solution to your issue, but I
thought I'd go ahead and solicit some feedback anyway, and maybe this
class I wrote could benefit you some.

Thanks,
Dave

--~--~-~--~~~---~--~~
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: How to avoid out of sync sequence for primary key using Postgresql?

[David Durham, Jr.]

On Thu, Oct 16, 2008 at 2:38 PM, cfobel <[EMAIL PROTECTED]> wrote:
> I recently encountered a situation where the sequence for the primary
> key of one of my models became out of sync, which caused the following
> error when trying to save a new model instance:
>
> IntegrityError ...  'duplicate key violates unique constraint
> "myapp_mymodel_pkey"'

Like you said, if you inserted a record with a manual ID greater than
the current sequence value, assuming you're moving forward through a
sequence of numbers from lower numbers to greater ones, then you could
see this.  Or if you actually changed the sequence.  You might have
ran an 'alter sequence' statement.

Switching to MySQL is not going to help you out here.

-Dave

--~--~-~--~~~---~--~~
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-jython-postgres driver

[David Durham, Jr.]

On 10/13/08, dusans <[EMAIL PROTECTED]> wrote:
>  I have writen a Test.java with:
>  Class.forName("org.postgresql.Driver");
>
>  It works, so that means it should work.
>
>  But jython tells me: DatabaseError: driver [org.postgresql.Driver] not
>  found
>
>  What am i doing wrong
>  I have been reading documentation and googled to long, kinda giving up
>  on jython :X

Nothing in your message is really Django specific, so far as I know,
and you might have better luck in a purely Jython forum.  My initial
thinking is that perhaps the classpath for your test environment is
not the same as your Jython/Django one.  With that said, I don't
really know much about what it takes to use JDBC drivers with
Django/Jython.

HTH,
-Dave

--~--~-~--~~~---~--~~
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: using request.POST as keyword args

[David Durham, Jr.]

> I do not understand why you want to do this.  Why not just pass request.POST
> without the **, and declare your function to take a single argument which
> you expect to be a dictionary-like object (as request.POST, a QueryDict,
> is)?.  That is:
>
> result = ab.perform(request.POST)
> where:
> def perform(self, datadict):
>
> What could you do with 'kwargs' in your syntax that you cannot do with
> 'datadict' in this alternative?

What if he wanted to do something like:

   ab.perform(name='x', y=12) or whatever, but also have the option to use
   ab.perform(**a_dict) or
   ab.perform(a_dict)

Can you do something like:

def perform(self, datadict=None, **kwargs):
  if datadict is None:
  datadict = kwargs
  elif kwargs is not None:
  datadict.update(kwargs)

I'm not sure that this would work; just kind of thinking out loud.

-Dave

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

djangosnippets.org list navigation

[David Durham, Jr.]

The list navigation on djangosnippets is not so good.  Take this page
for instance:

 http://www.djangosnippets.org/users/

I happened to stumble across the following jquery plugin which might
be a quick fix for some of the issues (though searching should be
added to):

   http://www.ihwy.com/labs/jquery-listnav-plugin.aspx

-Dave

--~--~-~--~~~---~--~~
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: displaying list from dictionnary -django 1.0

[David Durham, Jr.]

On Fri, Oct 3, 2008 at 12:13 PM, tsmets <[EMAIL PROTECTED]> wrote:
> I have an application that records the status of an applications.
> Basically something like :
>  _ started-request
>  _ started
>  _ stop-requested
>  _ stopped
> + some technical informations (version, host, URL, ...)
>
> I thought having a page that display per environment : dev, test,
> acceptance, prod the status for one application.
> I can easilly build a dictionnary where the keys is for that specific
> environment the last 5 status change (named in my code :
> app_deployed_status_lst).

If I have you correctly, your data looks something like:

env_history = { dev : [
{'started' : 'x', 'stopped' : 'y', 'version' : 'z'},
 ... ],
   test : [
   ],
   ..
}

so you can do something like:

{% for env, statuses in env_history.items() %}
  {{ env }}
  {% for status in statuses %}
 {{ status.version }} {{ status.started }} to {{ status.stopped  }}
  {% endfor %}
{% endfor %}


-Dave

--~--~-~--~~~---~--~~
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: Form controls for choosing from long lists

[David Durham, Jr.]

On Fri, Sep 26, 2008 at 12:12 PM, Donn <[EMAIL PROTECTED]> wrote:
>
> Hi,
> I thought I'd ask before rolling my own (at tedious pace) widget/whatever:
>
> If you have a foreign key field to a table of thousands of, say, author names,
> the drop-down control becomes a real problem:
> 1. It's not paged so all the items have to be stuffed into the html.
> 2. It's damn hard to use.
>
> What are the alternatives? Any working solutions out there? How does one offer
> a choice out of thousands?

You could use something like an auto completing combo box.  I don't
have any examples of how this is done with Django.

-Dave

--~--~-~--~~~---~--~~
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: amd64 vs x86 hosting

[David Durham, Jr.]

>> I think the primary difference is the amount of RAM that is supported
>> and whether or not you have compatible software.  With that said, all
>> modern processors are x64 so you probably want to default with an x64
>> OS unless you need x86 for software compatibility reasons.
>
> That's not what our tests tells. Just swaping operating system build
> for amd64 gives some 10% ~ 15% gain. It's a gain that enables
> inserting a small site into the same box.

I hope you end up running amd64 on Intel(R) Core(TM) 2 Duo because you
can get another 10 to 15 percent improvement that way.  :)

-Dave

--~--~-~--~~~---~--~~
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: Multiple instances using mod_python

[David Durham, Jr.]

> I see on this thread
> 
> from last year that there is suspicion that Apache can at times misdirect
> mod_python requests to the wrong mod_python instance.

You could try mod_wsgi.

-Dave

--~--~-~--~~~---~--~~
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: amd64 vs x86 hosting

[David Durham, Jr.]

On Wed, Sep 24, 2008 at 11:07 AM, David Durham, Jr.
<[EMAIL PROTECTED]> wrote:
> On Wed, Sep 24, 2008 at 6:14 AM, mcosta <[EMAIL PROTECTED]> wrote:
>> One question: ¿amd64 or x86? we've got some bechmark claiming superior
>> performance for amd64, both with python and mysql, but then we can not
>> tune with psyco. We've taken a look at pyrex but we do not know even
>> if we are shooting in our foot with any of these. ¿are these
>> technologies useful for actual web app tuning?
>
> I think the primary difference is the amount of RAM that is supported
> and whether or not you have compatible software.  With that said, all
> modern processors are x64 so you probably want to default with an x64
> OS unless you need x86 for software compatibility reasons.

Actually I don't know that all modern processors are x64, but it seems
to me that the server ones are.

-Dave

--~--~-~--~~~---~--~~
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: amd64 vs x86 hosting

[David Durham, Jr.]

On Wed, Sep 24, 2008 at 6:14 AM, mcosta <[EMAIL PROTECTED]> wrote:
> One question: ¿amd64 or x86? we've got some bechmark claiming superior
> performance for amd64, both with python and mysql, but then we can not
> tune with psyco. We've taken a look at pyrex but we do not know even
> if we are shooting in our foot with any of these. ¿are these
> technologies useful for actual web app tuning?

I think the primary difference is the amount of RAM that is supported
and whether or not you have compatible software.  With that said, all
modern processors are x64 so you probably want to default with an x64
OS unless you need x86 for software compatibility reasons.

-Dave

--~--~-~--~~~---~--~~
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: Two Django visions running at once.

[David Durham, Jr.]

On Wed, Sep 17, 2008 at 3:21 PM, KillaBee
<[EMAIL PROTECTED]> wrote:
>
> Is it possible to have two versions of django running at the same time
> on an Ubuntu server(9.0 and 1.0)?
> It is taking to long to recode, and until I do I wanted It up and
> running with the old version.
> I got the tar.gz from the web site, but do I have to get rid of the
> new version?

This is the kind of thing that 'virtualenv' deals with.  On ubuntu you
can set that up with:

$ sudo apt-get install python-setuptools
$ sudo easy_install virtualenv
$ virtualenv --no-site-packages /path/to/sandbox1
$ virtualenv --no-site-packages /path/to/sandbox2

then, checkout or download the different django version and place/link them in:

/path/to/sandbox1/lib/pythonX.X/site-packages/
/path/to/sandbox2/lib/pythonX.X/site-packages/

you can test with

/path/to/sandbox1/bin/python manage.py runserver
/path/to/sandbox2/bin/python manage.py runserver

As far as apache configuration goes, this kind of thing is pretty
easily configured with mod_wsgi.

-Dave

--~--~-~--~~~---~--~~
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 simulate recursive inlines in admin?

[David Durham, Jr.]

2008/9/22 Steve Holden <[EMAIL PROTECTED]>:
> This all seems rather ambitious for the admin. Isn't it supposed to be a
> simple application, and aren't those kind of functions supposed to be
> implemented by other views? There's no point trying to make the admin
> all things to all people - that would just complicate it so much as to
> make it unusable by anyone other than a guru.

I'm not writing this SessionWizard thing specifically for the admin,
though I wouldn't necessarily rule it out.  The point of it is to walk
ordinary, non-DB savvy, users through the creation of multiple
entities without these users having to know specifically the
relationships between entities (a programmer worries about that).  For
instance, creating a complete questionaire with the current admin
would involve, creating a questionaire, then creating questions and
answers and associating the questions with the questionaire and the
answers with the questions (basically select the same things
repeatedly from drop-downs).  This is resolved if you allow arbitrary
nesting of inlines and know how to map the relationships without the
user having to repeated select the same things from drop-downs, but it
could lead to one really long form.  Taking a multiple forms/requests
approach allows people to 1- pick up where they left off (say a
machine crashes or they just want save and pick up where they left off
and 2- quickly navigate to specific parts of the workflow in order to
add, change or remove or whatever.

I'm still a django newb, though, so please correct me if I stated
anything incorrectly.

Thanks,
Dave

--~--~-~--~~~---~--~~
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 simulate recursive inlines in admin?

[David Durham, Jr.]

On Mon, Sep 22, 2008 at 4:05 PM, Petar Marić <[EMAIL PROTECTED]> wrote:
> I'm using the admin app for creating Questionnaires and I'd like to let users
> edit questions and answers in the same form. AFAIK recursive inlines aren't
> supported in Django (a hard problem by itself) so the only other way I could
> think of is to inject a TextArea form field inside of the QuestionInline and
> then do the processing of it manually. Answers would then be separated by
> newlines and the positions would be determined by the order of lines in the
> TextArea.
>
> The problem is I don't know how to inject the TextArea in the inline. I tried
> many things from simple to complex - and the otherwise excellent documentation
> doesn't give much help.

Another approach is to go with some kind of wizard-like very simple
workflow where you start off creating a questionaire, then you add
questions and answers.  I have a working "session wizard"  that
handles some of the boiler plate with this kind of thing.  It's not
"done" yet, but it is working.  Here's a link to the django snippets
entry:

   http://www.djangosnippets.org/snippets/1078/

I have code that dynamically manipulates the "form_list" associated
with the wizard so that I can, for instance, display buttons like
'save and add question' and then add a question form to the list of
forms.   I also display navigation links to each form or step in the
wizard (which in your case would be a tree-like structure -- actually
maybe wizard in the right word for this thing ...).  Let me know if
this interests you at all, and I'd be glad to say more about it.


- Dave

--~--~-~--~~~---~--~~
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: ModelForm initial= vs. instance=

[David Durham, Jr.]

> Basically, I  store the cleaned_data in the session for POSTs and use
> the cleaned_data in order to initialize a ModelForm for display after
> GETs.  Eventually, I have to save some things.  When that happens, I
> again get the data from a session:
>
>for i in range(len(self.get_form_list(request.session))):
>page_data = self._get_page_data(request.session, i)
>form_class = form_list[i]
>form = form_list[i](page_data)
>form.save()
>
> At this point, though, I will have trouble with foreign keys again.
> Specifically, I have actual ForeignKey model objects in my data
> argument, and save throws a TypeError like so:
>
>int() argument must be a string or a number, not 'MyModel'


Just for the record, I ended up with this:

 SomeModel(**page_data).save()

instead of the corresponding:

 SomeModelForm(page_data).save()

and that resolves the issue with foreign keys.  I guess ModelForm is
expecting ids instead of an actual model instance.

-Dave

--~--~-~--~~~---~--~~
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: ModelForm initial= vs. instance=

[David Durham, Jr.]

> No, there's quite a difference. "Initial" is used to set the initial
> values and is quite appropriate when a *new* model instance is going to
> be created. The "instance" is used when you want the ModelForm to be
> used to update an existing instance of a model.
> Since Django does not
> currently incorporate mind-reading technology, if the two parameters
> were merged into one, the framework wouldn't know whether it's meant to
> be updating an existing instance or creating a new one.

I don't think this is necessarily the case, and maybe you'll correct
me if I'm wrong. :)  Looking at db.models.base.save_base, there is
some checking to see if 1) the pk is set and 2) if the pk exists in
the db when determining whether or not to save or update.  And it does
not look as though ModelForm will force_update or force_insert when
calling instance.save().

Still though, couldn't your logic be applied on just an initial
variable.  I.e., if initial is a dict, it's an insert.  If it's a
model, then we have an update (not that I agree this is the way it
should be).  It does however look as though initial values will
override instance values, and I don't see a way to retain this feature
without having both of these arguments.  I guess I question how useful
the "initial values override instance values" feature is, because why
not simply change the model before constructing the form?

Anyway, none of this really has to do with my issue, which is that
initial= doesn't appear to set FK drop-downs (or I'm doing it wrong).
Using instance= does set FK drop-downs (even though this is not an
update; I create the model from a dict stored in a session), however I
am have trouble saving the values POSTed from a form created based on
the following sequence:

In a GET:

page_data = self._get_page_data(request.session, page0)
form_class = self.get_form_list(request.session)[page0]
if issubclass(form_class, forms.ModelForm):
form = form_class(instance=form_class.Meta.model(**page_data))
# ... render the form

When this form is POSTed, something like this happens:

if form.is_valid:
request.session[self._get_page_key(page0)] = form.cleaned_data


Basically, I  store the cleaned_data in the session for POSTs and use
the cleaned_data in order to initialize a ModelForm for display after
GETs.  Eventually, I have to save some things.  When that happens, I
again get the data from a session:

for i in range(len(self.get_form_list(request.session))):
page_data = self._get_page_data(request.session, i)
form_class = form_list[i]
form = form_list[i](page_data)
form.save()

At this point, though, I will have trouble with foreign keys again.
Specifically, I have actual ForeignKey model objects in my data
argument, and save throws a TypeError like so:

int() argument must be a string or a number, not 'MyModel'



Thanks for any suggestions,
Dave

--~--~-~--~~~---~--~~
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: Template Inheritance Question

[David Durham, Jr.]

On Fri, Sep 19, 2008 at 4:07 PM, djandrow <[EMAIL PROTECTED]> wrote:
>
> I have a template, text that extend a template base.
>
> In my text template I have;
>
> {% extends 'base.html' %}
>
> {% block content %}
>
> SOME CODE
>
> {% endblock content %}

I'm not a django expert, but I think that you don't need {% endblock
content %}, just {% endblock %}.

> Anyway, my question is when I enter this save it then stick it on my
> server, it adds closing tags at the bottom;  and the
> Doctype stored in base,html on the top, is this the way i'm uploading
> the files or is it sommething to do with Django, and if so is there
> anyway to stop it?

I guess try my suggestion and report back unless someone else has any ideas.

-Dave

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

ModelForm initial= vs. instance=

[David Durham, Jr.]

I'm writing a little wizard application to walk a user through
creating a bunch of Model objects.  I stumbled across something kind
of interesting; if I create a ModelForm like so:

   SomeModelForm(initial={...})

All of the fields I have are prepopulated, except the ForeignKey ones.
 I don't have many-to-many, so can't say if the problem is there too.
Now, if I create one with:

   SomeModelForm(instance=some_instance)

All fields are prepopulated correctly, including the ForeignKey
variety.  To me, this is not desirable because I have a component that
now has to check if it has a ModelForm or not.  Ideally I could pass a
{} with foreign key values and have drop-downs preselected with the
corresponding options.

Thinking about it a little more, couldn't this interface simply be:

   ModelForm(initial=X)

where X is either a dict or a Model instance?  Seems like this would
be consistent with the Form init (but Form would only work with {})
while adding what's needed for ModelForm.

Any thoughts?

Thanks,
Dave

--~--~-~--~~~---~--~~
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: Reusable views from a template - How?

[David Durham, Jr.]

>> Have you read up on template inheritance?
>> http://docs.djangoproject.com/en/dev/topics/templates/#id1
>
> I've read that part, I can see how that would work if I statically define
> the form. But right now I have
> a view defined that pushes out the LoginForm to my template. So say I have
> another view which populates the links dynamically... How do I incorporate
> both of these with inheritance, I could have one block for login and one
> block for links, but then how do the Login and Links views (where I'm
> passing the forms) fit into this picture?
>
> Perhaps I'm missing something.

How about Inclusion Tags?

http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#inclusion-tags

--~--~-~--~~~---~--~~
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: Reusable views from a template - How?

[David Durham, Jr.]

On Wed, Sep 17, 2008 at 1:35 PM, WillF <[EMAIL PROTECTED]> wrote:
> I have written a login view as I have followed the tutorial but how do I
> reuse this view in multiple pages of the site?
>
> Is there a way to render this particular view as part of a template, so I
> could have the login form (or anything for that matter) be displayed on
> every single page?

Have you read up on template inheritance?
http://docs.djangoproject.com/en/dev/topics/templates/#id1

--~--~-~--~~~---~--~~
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: date time input in a modelform

[David Durham, Jr.]

On Tue, Sep 16, 2008 at 3:13 PM, David Durham, Jr.
<[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I'm working through a simple wizard using the formtools wizard stuff.
> My issue is that my forms don't display with niceties such as date
> time popup and foreign key 'add' options.  Is there something extra
> that has to be done for these features?

So tackling the first issue I've got something working, but I'm not
particularly proud of it.  To get a "DatePicker" on a
models.DateField, I had to kind of hack things up a bit with custom
Model Field:


from django import forms
from django.db.models import DateField

class CSSDateField(DateField):

def formfield(self, **kwargs):
defaults = {'widget' : forms.TextInput(attrs={'class':'date'})}
defaults.update(kwargs)
return super(DateField, self).formfield(**defaults)


Then in my Model I do something like

class MyModel(models.Model):
starts_on = CSSDateField()

Then in my form template, I use jquery and do something like:

$("input.date").datetimepicker()


Like I said, I don't really like this solution, and I'm hoping there's
a better one.  My thinking is that the best way would be to hook this
kind of thing into a ModelForm Meta class.  Specifically, the
ModelForm would know to add this css class to DateFields based on some
configuration in the Meta class.  Maybe this already exists, and I
just don't know it.

The other thing I thought is that if I'm going to create a custom
model Field just to add a css class, then it would be better to just
add an argument like widget_attrs={'css' : 'some_class'}.  Maybe a
purist would say, oh, you've coupled your model with your view, and I
kind of agree, so I think the ModelForm magic would be better, but end
the end, there was already a coupling so I really don't care, but want
to define this in one spot.

Thanks in advance.

-Dave








> Just as a simple test, I reduced things to this:
>
> in forms.py:
>
> class EstimateForm1(forms.Form):
>start_on = forms.DateField(widget=forms.DateTimeInput)
>
> class EstimateWizard(FormWizard):
>def done(self, request, form_list):
>return render_to_response('done.html', {
>'form_data': [form.cleaned_data for form in form_list],
>})
>
>
> in urls.py
>
>   (r'^estimate/$', EstimateWizard([EstimateForm1])),
>
>
> and wizard.html:
>
> {% extends "admin/base_site.html" %}
>
> {% block content %}
> Step {{ step }} of {{ step_count }}
> 
> 
> {{ form.as_table }}
> 
> 
> {{ previous_fields|safe }}
> 
> 
> {% endblock %}
>
> Thanks for any help,
> DAve
>

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

date time input in a modelform

[David Durham, Jr.]

Hi all,

I'm working through a simple wizard using the formtools wizard stuff.
My issue is that my forms don't display with niceties such as date
time popup and foreign key 'add' options.  Is there something extra
that has to be done for these features?

Just as a simple test, I reduced things to this:

in forms.py:

class EstimateForm1(forms.Form):
start_on = forms.DateField(widget=forms.DateTimeInput)

class EstimateWizard(FormWizard):
def done(self, request, form_list):
return render_to_response('done.html', {
'form_data': [form.cleaned_data for form in form_list],
})


in urls.py

   (r'^estimate/$', EstimateWizard([EstimateForm1])),


and wizard.html:

{% extends "admin/base_site.html" %}

{% block content %}
Step {{ step }} of {{ step_count }}


{{ form.as_table }}


{{ previous_fields|safe }}


{% endblock %}

Thanks for any help,
DAve

--~--~-~--~~~---~--~~
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: Nesting inlines with django-admin

[David Durham, Jr.]

> I'm having the same need for nested inlines.

Bump.  I'm probably going to take the plunge and try to implement this
if no one has beaten me to it.


-Dave

--~--~-~--~~~---~--~~
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: filters should throw exceptions

[David Durham, Jr.]

On Mon, Apr 21, 2008 at 1:06 PM, Peter Rowell <[EMAIL PROTECTED]> wrote:
>  From http://www.djangoproject.com/documentation/templates/#variables
>
>  If you use a variable that doesn't exist, the template system will
>  insert the value of the TEMPLATE_STRING_IF_INVALID setting, which is
>  set to '' (the empty string) by default.
>
>  So you could at least define this to be something more eye catching.
>
>  Part of the problem is that the variable reference syntax a) is not
>  python, and b) is ambiguous because of all the different ways
>  foo.bar.mumble can be resolved. If you look at
>  django.template.__init__, class Variable, the routines __init__(),
>  resolve(), and _resolve_lookup do a lot of try:ing to guess what value
>  you meant. The result is that any "obvious" error you might expect
>  gets eaten in the process.
>
>  A possible alternative is to use a custom tag (E.g.
>  http://www.djangosnippets.org/snippets/9/) where you can do a full-on
>  python expression and let the exception hit the fan. This is what I do
>  for those real head scratchers.

Good information.  That's exactly it, I would want a stack trace
during development, but probably blank or something else in
production.

-Dave

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

filters should throw exceptions

[David Durham, Jr.]

Hi all,

I'm new to working with Django so forgive my newness.  I'm reading
through chapter 10 of the free online django book, and I've come
across the statement that filter should silently ignore errors.  I
disagree with this.  I think they ought to raise exceptions, and the
site should be configured to ignore filter exceptions if that's the
desired behaviour.  I can go into my reasons for wanting this, but I
don't want to waste anyone's time.  Is my thinking on this current?
Is this not how things are currently done with Django?

Thanks,
Dave

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