Re: Desktop Application for Django

[Mike Ramirez]

On Saturday, February 05, 2011 01:10:56 am Izz ad-Din Ruhulessin wrote:
> Hi all,
> 
> I've been theorizing about a Django Desktop Application built a GUI
> framework (eg. PyGTK, Tkinter).
> 
> It basically comes down with this:
> 
> 1. Login using an SSL POST request and create a user object.
> 
> 2. Download certain tables from the DB to the local machine, perhaps
> specified by a "download_local" attribute (True/False) on models. If
> it already is downloaded, synchronize it with the server.
> 
> 3. Use the Django ORM locally to do your work.
> 
> 4. Provide wrapper classes for the models save, delete methods etc.
> Foo.objects.get(pk=4) for example sends a POST request: {'obj': 'Foo',
> 'kwargs_keys': 'pk', 'kwargs_values': 4, 'op': 'get'}; the server then
> can do the job via get_model, getattr, etc.
> - OR - log all changes on the local machine, and provide a 'Send my
> work to the server'-button.
> 
> 
> This is my basic idea. What do you think about this? Is this the right
> approachs? And what would be possible pitfalls?
> 
> Kind regards,
> 
> Izz ad-Din Ruhulessin


If you only want to use the orm for the desktop appliction, I would suggest 
using sqlalchemy over django, much easier configuration and setup for a 
desktop application. I like to use sqlalchemy with PyQt, which does include a 
QtSql module. But it's more like PHP, you have to write all queries in SQL. 
The db table can be tossed back and forth with json still or use the orm's db 
settings to communicate with the server. While not advised for public apps, 
you can have the client talk directly with the db by passing a restful 
interface. Then you create a db user who has special permissions to the tables 
you want them to have access to.

I'm also not sure you're gaining anything this way. I think it would depend on 
the use. If you're aiming to make a data entry application, it would be easier 
to just do the communication and let the server handle all the work.  The 
application should validate before you send the data off, but gui libs provide 
nice tools for validation already, just implement those. And validate at the 
server end, always, especially if you're going with a restful style interface.

I also think you're approaching this idea the wrong way. The desktop 
application should be in pure django, with a script/batch file loading the 
page in the users browser. Then you get all of django's benefits. But even 
here, I still have my own doubts on the validity of it. This part is about 
wide-spread usage and what's the real benefit of this use? 

You could also build a simple browser with a notification area/systray icon 
for hiding the app off the desktop. 

I have previously played with this idea and these are some of the things I've 
come across, in the theory stage. The last question of benefit being the 
stopper from implementing it for desktop apps that work with a website/db. I 
just found it better and easier to implement it in a gui lib and use 
sqlalchemy to communicate with the server, or just skip the db part in the 
client and send off json, dumping the readied json to a pickle (or shelf) file  
when the network/user is not ready to send. When the network con is available 
read and send the data from the pickle file.

Mike





 
-- 
Look into my eyes and try to forget that you have a Macy's charge card!

-- 
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: Best DRY practices for a view function that will be used by all other views.

[Ken Chida]

Yes, I think I have it figured out now.  Sorry for asking such a newb 
question.  If I understand correctly, all I need to do is change the form 
action to the login URL.  Then, url.py will direct the request to my 
existing login view function.

I bet you guys were all bashing your heads against the wall!  Sorry for the 
confusion.  Thanks for all the input, guys! I really appreciate it.

-- 
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: Use development server database with production server

[Mike Ramirez]

On Saturday, February 05, 2011 01:52:43 am Amit wrote:
> Hello,
> First of all one should go through with below link;
> 
> http://stackoverflow.com/questions/4887851/django-database-settings-for-pro
> duction-server
> 
> 
> Now, let come up with my hurdle. I am using a database lay out in
> filesystem(windows) say;
> C:/miami/data.db
> 
> I have to use same database with production server, since I don’t have
> avail corresponding database in PostGreSQL.
> 
> 
> 
> 
> 
> Amit.

Witht his situation you might want to have a local_settings.py file.  This 
file should be local to the django instance and not part of any revision or 
deployment strategy unless you're providing a templated form for others to 
modify (name the templated local_settings.py something else like 
local_settings.tmpl).

In settings.py add this to the top:

from local_settings import *

Remove the database settings from settings.py (and anything else you've added 
to local_settings.py)

in your local_settings.py you have your database settings and any other  (path 
based and/or installed apps) settings that are specific to the server.

I've found this approach optimal when dealing with databases, templates, 
middleware, context processors, and installed apps. I can keep my debugging 
stuff out of the production version.  

Google "local_settings.py" for more examples. Personally I don't use the 
try/except form shown on some of the blogs, that's because I want it to fail 
loudly and clearly when I attempt to use it with a missing/broken 
local_settings.py.

As a friend once told me, if you're going to fail, fail spetacularly. I find 
this very true with programming. 

Mike

-- 
Detroit is Cleveland without the glitter.

-- 
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: Pythonish approach to widgets

[Mike Ramirez]

On Saturday, February 05, 2011 07:02:17 am Alex Polovjan wrote:
> Hi list,
> 
> 
> Django.forms have a great system of widgets. But customizing them can
> be a pain. Writing complex html in the python code is write-only and
> error-prone approach.
> 
> I know that js files can be included in admin:
> 
> class ModelAdmin(admin.ModelAdmin):
> class Media:
> css = {
> 'all':('/static/admin/mywidget.css', )
> }
> js = [
> "/static/admin/mywidget.js"
> ]
> 
> What are best practices to separate html from python code?

you can use the Media class in your widgets also [1] or you can include the 
css/js in the html.

In the case of adding them to your html template:

# base.html



{% block css %}{% endblock %}


{% block javascript %}{% endblock %}


{% block main_content %}

{% endblock %}




# template with form
{% extends "base.html" %}
{% block css %}

{% endblock %}

{% block javascript %}

{% endblock %}

{% block main_content %}

{{ form.as_p }}


{% endblock %}

### end of page.

I prefer this style as it completely decouples the form html and styles from 
the business logic of the forms.  You can get even deeper with the form fields 
in the html[2]. This is just a simplistic idea to get you started.





[1] http://docs.djangoproject.com/en/1.2/topics/forms/media/

[2] http://docs.djangoproject.com/en/1.2/topics/forms/#displaying-a-form-
using-a-template


-- 
"The jig's up, Elman."
"Which jig?"
-- Jeff Elman

-- 
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: Best DRY practices for a view function that will be used by all other views.

[Pete Corsaro]

Your last paragraph here indicates to me you don't under HTML forms. I
think you need to go read about them and you'll understand why people
keep telling you don't need to do anything funny with decorating your
views or whatever just because your form is now on every page.

In short, your form needs to POST to some URL (I.e. /login or
something like that). You can post to that URL from any page. Just
make sure your URL patterns maps the URL the form is posting to your
login view code and it'll work like you want.

Good luck,
Pete

On Feb 5, 7:58 pm, Ken Chida  wrote:
> Hi James - I want to point out that I will not have a dedicated login URL,
> as the functionality will be available on each page (not just a link to the
> login page, but the actual form).  Previously, I had a dedicated login URL
> and link to the login page, but my frontend guy made a slick jQuery
> drop-down login/register box that shows up on each page.  As to whether this
> was a good way to implement login is a whole different story that goes
> beyond the scope of what I'm dealing with at the moment.  
>
> I'm kinda leaning towards a decorator for each view function.  At least the
> login view code will be in one place.  The only thing I will be repeating
> over and over is "@login", which isn't a big deal.
>
> Base.html already has the necessary html/JS to show the login form.  I just
> need to figure out how to organize or call the view code.
>
> Let's suppose that we're on my blog page.  The login/register form from
> base.html shows at the top of the page and the blog is directly below it.  
> If the user enters login info and clicks the login submit button, what
> mechanism should I use to ensure that the request object goes to the login
> view code -- wherever it might live (not implying that it has to be in a
> view.py).
>
> Thanks!

-- 
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: Django-filebrowser path problems

[gerram]

I decided my problem!
If you use dynamic method for getting you path, example:

import os
SITE_ROOT = os.path.realpath(os.path.dirname(__file__))
MEDIA_ROOT = os.path.join(SITE_ROOT, 'media')

you can dismiss path of you real folder especially when project lies
outside of the site root.

I check it out in folder with project:
python manage.py shell
>>> from django.conf import settings
>>> import filebrowser.settings
>>> filebrowser.settings.MEDIA_ROOT
/var/www/mysite.com/media
>>> filebrowser.settings.DIRECTORY
uploads/

you can check is or not is such folder: (/var/www/mysite.com/media/
uploads/)

Good luck!


On Feb 4, 2:34 pm, gerram  wrote:
> Can anybody to help me with demo project of correct settings.py for
> django-filebrowser and structure of folders. I tried very much places
> of locate FILEBROWSER folders for media and uploads but always get
> such error: 'Error finding Upload-Folder (MEDIA_ROOT +
> FILEBROWSER_DIRECTORY). Maybe it does not exist?'
> Best regards, George

-- 
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: Best DRY practices for a view function that will be used by all other views.

[Andre Terra]

You don't need a "dedicated" login page with a form like the default login
for django admin. All you need is a urlpattern (i.e. domain.com/login) that
would allow for forms in other pages to POST to it. You would obviously need
a view to handle that POST, but you don't need to link to it anywhere in
your website. You just need to be able to work with the POST information.


Best regards,
André Terra

On Sat, Feb 5, 2011 at 22:58, Ken Chida  wrote:

> Hi James - I want to point out that I will not have a dedicated login URL,
> as the functionality will be available on each page (not just a link to the
> login page, but the actual form).  Previously, I had a dedicated login URL
> and link to the login page, but my frontend guy made a slick jQuery
> drop-down login/register box that shows up on each page.  As to whether this
> was a good way to implement login is a whole different story that goes
> beyond the scope of what I'm dealing with at the moment.
>
> I'm kinda leaning towards a decorator for each view function.  At least the
> login view code will be in one place.  The only thing I will be repeating
> over and over is "@login", which isn't a big deal.
>
> Base.html already has the necessary html/JS to show the login form.  I just
> need to figure out how to organize or call the view code.
>
> Let's suppose that we're on my blog page.  The login/register form from
> base.html shows at the top of the page and the blog is directly below it.
> If the user enters login info and clicks the login submit button, what
> mechanism should I use to ensure that the request object goes to the login
> view code -- wherever it might live (not implying that it has to be in a
> view.py).
>
> Thanks!
>
>  --
> 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.
>

-- 
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: Best DRY practices for a view function that will be used by all other views.

[Ken Chida]

Hi James - I want to point out that I will not have a dedicated login URL, 
as the functionality will be available on each page (not just a link to the 
login page, but the actual form).  Previously, I had a dedicated login URL 
and link to the login page, but my frontend guy made a slick jQuery 
drop-down login/register box that shows up on each page.  As to whether this 
was a good way to implement login is a whole different story that goes 
beyond the scope of what I'm dealing with at the moment.  

I'm kinda leaning towards a decorator for each view function.  At least the 
login view code will be in one place.  The only thing I will be repeating 
over and over is "@login", which isn't a big deal.

Base.html already has the necessary html/JS to show the login form.  I just 
need to figure out how to organize or call the view code.

Let's suppose that we're on my blog page.  The login/register form from 
base.html shows at the top of the page and the blog is directly below it.  
If the user enters login info and clicks the login submit button, what 
mechanism should I use to ensure that the request object goes to the login 
view code -- wherever it might live (not implying that it has to be in a 
view.py).

Thanks!

-- 
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: Best DRY practices for a view function that will be used by all other views.

[Ken Chida]

A global context processor would probably work, but is it kosher to put 
business logic in a context processor?  To me it seems that the whole point 
of a context processor is to simply take a piece of data and extract/format 
information from it to form a context dictionary.

-- 
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: Best DRY practices for a view function that will be used by all other views.

[Ken Chida]

Because I will have the login form on each page, I will not have a separate 
login URL. That's why I'm having difficulties with organizing the business 
logic code (i.e. view).  It's almost as if I need to have two view functions 
-- one for login and another for the current page -- for the URL for the 
current page.  I hope that makes sense.  Of course, we all know that we 
can't have two separate view functions for one URL, so I would have to take 
the login code and somehow tie it to the view for each page.  There are 
several ways to make this work, but my main question is:  What is the 
cleanest and most maintainable way for me to do this?

Thanks all for your input!

-- 
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: Get request object in class based generic view and form

[roman]

Hello Simon,

> But I can't figure out how I can retrieve the request object in the class
> based generic view.

As far as I understand just get it from self.request.

> I want to re-verify the user once again to
> make sure his authenticated.
>

I always do it the way it's recommended in the docs, by decorating the
the dispatch() method:
http://docs.djangoproject.com/en/dev/topics/class-based-views/#decorating-class-based-views

Isn't that sufficient?

Regards Roman

-- 
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: Amazing work

[Cal Leeming [Simplicity Media Ltd]]

To be honest, I've *never* been a fan of frameworks that try to merge every
language into one, like Ext JS, or HTML builders in PHP. Hell I don't
particularly like the 'widgets' in Django either :S I even once saw a PHP
project that builds HTML and JavaScript from PHP objects, it was absolutely
awful.

On Sat, Feb 5, 2011 at 6:12 PM, Jon J  wrote:

> Yeah, I guess I'll have to redact my comment about Zope.
>
> I must say though, I've never been much of a fan of bloated frameworks
> like this. I spent enough time being forced to maintain Cold Fusion,
> thank you.
>
> On Sat, Feb 5, 2011 at 11:56 AM, kojiro  wrote:
> > It would be a mistake to compare Zope to Django. Django is a
> > lightweight, easy-to-learn, something-like-MVC framework with a built-
> > in ORM. Zope is a complex, rich, unabashedly pythonistic metaframework
> > with a built-in ACID compliant key-value store. Zope is neither a POS
> > nor unusually slow. Its history is inextricably intertwined with the
> > history of Python itself. Some superb libraries and tools have come
> > out of the Zope project, including both Plone and Repoze.BFG, now
> > Pyramid.
> >
> > Let's not get any further OT, but please, keep the FUD off the list.
> >
> > References:
> >
> http://books.google.com/books?id=5zYVUIl7F0QC=PA1130=HUb87eoQwI=PA1130#v=onepage=false
> > http://plope.com/bfg-becomes-pyramid
> >
> > On Feb 5, 10:50 am, Jon J  wrote:
> >> Well I was unfortunate enough to  look up the official zope website,
> >> and as I'm typing this it's STILL loading. Haha, I can see what a POS
> >> it is and definitely won't be using it for any projects anytime soon.
> >>
> >> On Fri, Feb 4, 2011 at 10:24 PM, Kenneth Gonsalves
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>  wrote:
> >> > On Fri, 2011-02-04 at 01:02 +, Cal Leeming [Simplicity Media Ltd]
> >> > wrote:
> >> >> May I ask, how well did you get along with Zope? From what I can
> tell,
> >> >> Django is suited for SME, where as Zope is the kinda thing that banks
> >> >> would
> >> >> be using etc.
> >>
> >> > as long as one sticks to out of the box stuff and zope's own object
> >> > database, things are dead easy - but the moment you want to fine tune
> or
> >> > use an external database - then things become hairy. Documentation
> sucks
> >> > big time - I see a lot of refugees from zope here. And bloat - dont
> even
> >> > talk of it.
> >> > --
> >> > regards
> >> > KG
> >> >http://lawgon.livejournal.com
> >> > Coimbatore LUG rox
> >> >http://ilugcbe.techstud.org/
> >>
> >> > --
> >> > 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 athttp://
> groups.google.com/group/django-users?hl=en.
> >
> > --
> > 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.
> >
> >
>
> --
> 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.
>
>

-- 
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: Amazing work

[Chris Hannam]

Hi,
Plone (which runs on Zope) is not that unusual a CMS system for business. It
suffers from a lack of documentation like Zope but there is a pretty
thriving community behind Plone currently.

Certainly worth a look if nothing else.

CH

-- 
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: model form validation

[Shawn Milochik]

On 02/05/2011 01:38 PM, Axel Bock wrote:

Shawn,

thanks for hint, I'll give that a try. Also I have some questions, for 
my own clarification of things:


1) using your method - would is_valid() retur true then?


Yes, is_valid should end up true.


2) in my form display I should hide the "takeoff" field then, correct?


Yes. No reason to display it. You could even add it to the 'exclude' 
list in the form's meta info. If you do that, then instead of manually 
setting the cleaned_data in your clean_takeoff_str function, you could 
just set self.instance.takeoff to that value, which will be saved on 
form.save().


3) I alredy tried to override clean_takeoff() - it didn't get called. 
Any ideas, why?




I'd have to look into Django's source, but I'm assuming that Django 
validates the field first, and since it's not a valid value for the 
field type (datetime) it raises a validation error before it gets that far.




Axel.



Shawn

--
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: model form validation

[Axel Bock]

Shawn,

thanks for hint, I'll give that a try. Also I have some questions, for my
own clarification of things:

1) using your method - would is_valid() retur true then?
2) in my form display I should hide the "takeoff" field then, correct?
3) I alredy tried to override clean_takeoff() - it didn't get called. Any
ideas, why?


Axel.



2011/2/5 Shawn Milochik 

> On 02/05/2011 01:08 PM, Axel Bock wrote:
>
>> practically:
>> - the user enters "0300" in the datetime field.
>> - I make "0300" into date=0, time=03:00, valid field.
>>
>
> Axel,
>
> In your example, you're wanting to populate a DateTime field in a model,
> but you want to allow the user to enter a string which would be invalid for
> the field.
>
> One way to do this is to add an additional field to your form.
>
> Example, given your 'takeoff' field:
>
>1. Add a charfield named takeoff_str in your form definition.
>
>2. Add a method named clean_takeoff_str to your form definition.
>
>In this function, check to ensure that the string entered is a valid
>HHMM value, if not raise a forms.ValidationError.
>
>Then, create a valid datetime from the input, and set
>self.cleaned_data['takeoff'] equal to this value.
>
>
> Shawn
>
> --
> 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.
>
>

-- 
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: jquery grid and django

[Javier Guerra Giraldez]

On Thu, Feb 3, 2011 at 7:50 PM, Tony  wrote:
> Is there any viable,
> simple way to use the jquery grid plugin with django fairly quickly?

I made my own, which i find very usable and intend to eventually
share; but there's still no documentation, and very few examples.

if you can wait a week or two, i'll try to flesh some examples and put
it somewhere

-- 
Javier

-- 
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: model form validation

[Shawn Milochik]

On 02/05/2011 01:08 PM, Axel Bock wrote:

practically:
- the user enters "0300" in the datetime field.
- I make "0300" into date=0, time=03:00, valid field.


Axel,

In your example, you're wanting to populate a DateTime field in a model, 
but you want to allow the user to enter a string which would be invalid 
for the field.


One way to do this is to add an additional field to your form.

Example, given your 'takeoff' field:

1. Add a charfield named takeoff_str in your form definition.

2. Add a method named clean_takeoff_str to your form definition.

In this function, check to ensure that the string entered is a 
valid

HHMM value, if not raise a forms.ValidationError.

Then, create a valid datetime from the input, and set
self.cleaned_data['takeoff'] equal to this value.

Shawn

--
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: Amazing work

[Jon J]

Yeah, I guess I'll have to redact my comment about Zope.

I must say though, I've never been much of a fan of bloated frameworks
like this. I spent enough time being forced to maintain Cold Fusion,
thank you.

On Sat, Feb 5, 2011 at 11:56 AM, kojiro  wrote:
> It would be a mistake to compare Zope to Django. Django is a
> lightweight, easy-to-learn, something-like-MVC framework with a built-
> in ORM. Zope is a complex, rich, unabashedly pythonistic metaframework
> with a built-in ACID compliant key-value store. Zope is neither a POS
> nor unusually slow. Its history is inextricably intertwined with the
> history of Python itself. Some superb libraries and tools have come
> out of the Zope project, including both Plone and Repoze.BFG, now
> Pyramid.
>
> Let's not get any further OT, but please, keep the FUD off the list.
>
> References:
> http://books.google.com/books?id=5zYVUIl7F0QC=PA1130=HUb87eoQwI=PA1130#v=onepage=false
> http://plope.com/bfg-becomes-pyramid
>
> On Feb 5, 10:50 am, Jon J  wrote:
>> Well I was unfortunate enough to  look up the official zope website,
>> and as I'm typing this it's STILL loading. Haha, I can see what a POS
>> it is and definitely won't be using it for any projects anytime soon.
>>
>> On Fri, Feb 4, 2011 at 10:24 PM, Kenneth Gonsalves
>>
>>
>>
>>
>>
>>
>>
>>  wrote:
>> > On Fri, 2011-02-04 at 01:02 +, Cal Leeming [Simplicity Media Ltd]
>> > wrote:
>> >> May I ask, how well did you get along with Zope? From what I can tell,
>> >> Django is suited for SME, where as Zope is the kinda thing that banks
>> >> would
>> >> be using etc.
>>
>> > as long as one sticks to out of the box stuff and zope's own object
>> > database, things are dead easy - but the moment you want to fine tune or
>> > use an external database - then things become hairy. Documentation sucks
>> > big time - I see a lot of refugees from zope here. And bloat - dont even
>> > talk of it.
>> > --
>> > regards
>> > KG
>> >http://lawgon.livejournal.com
>> > Coimbatore LUG rox
>> >http://ilugcbe.techstud.org/
>>
>> > --
>> > 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 
>> > athttp://groups.google.com/group/django-users?hl=en.
>
> --
> 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.
>
>

-- 
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: model form validation

[Axel Bock]

let's make an example: in the datetime fields of the forms there will only
be a time, which is ok for the user. the date will be added later by some
background logic, for convenience.

practically:
- the user enters "0300" in the datetime field.
- I make "0300" into date=0, time=03:00, valid field.

if you have any other idea how to do this - don't hesitate :) . and maybe
(hopefully) this will also solve the mysteriously vanished datetime values.


Thanks!
Axel.



2011/2/5 Shawn Milochik 

> What exactly are you trying to accomplish? I'm not sure overriding is_valid
> is a good idea; it's not a part of the validation -- it's how a model knows
> that the validation was successful.
>
> In your sample view, you're calling is_valid on the formset, not the forms
> in the formset. That would explain why your 'is_valid' is never called.
>
> You can iterate through the formset to get at the actual form instances
> inside.
>
> Shawn
>
> --
> 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.
>
>

-- 
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: model form validation

[Shawn Milochik]

What exactly are you trying to accomplish? I'm not sure overriding 
is_valid is a good idea; it's not a part of the validation -- it's how a 
model knows that the validation was successful.


In your sample view, you're calling is_valid on the formset, not the 
forms in the formset. That would explain why your 'is_valid' is never 
called.


You can iterate through the formset to get at the actual form instances 
inside.


Shawn

--
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: Amazing work

[kojiro]

It would be a mistake to compare Zope to Django. Django is a
lightweight, easy-to-learn, something-like-MVC framework with a built-
in ORM. Zope is a complex, rich, unabashedly pythonistic metaframework
with a built-in ACID compliant key-value store. Zope is neither a POS
nor unusually slow. Its history is inextricably intertwined with the
history of Python itself. Some superb libraries and tools have come
out of the Zope project, including both Plone and Repoze.BFG, now
Pyramid.

Let's not get any further OT, but please, keep the FUD off the list.

References:
http://books.google.com/books?id=5zYVUIl7F0QC=PA1130=HUb87eoQwI=PA1130#v=onepage=false
http://plope.com/bfg-becomes-pyramid

On Feb 5, 10:50 am, Jon J  wrote:
> Well I was unfortunate enough to  look up the official zope website,
> and as I'm typing this it's STILL loading. Haha, I can see what a POS
> it is and definitely won't be using it for any projects anytime soon.
>
> On Fri, Feb 4, 2011 at 10:24 PM, Kenneth Gonsalves
>
>
>
>
>
>
>
>  wrote:
> > On Fri, 2011-02-04 at 01:02 +, Cal Leeming [Simplicity Media Ltd]
> > wrote:
> >> May I ask, how well did you get along with Zope? From what I can tell,
> >> Django is suited for SME, where as Zope is the kinda thing that banks
> >> would
> >> be using etc.
>
> > as long as one sticks to out of the box stuff and zope's own object
> > database, things are dead easy - but the moment you want to fine tune or
> > use an external database - then things become hairy. Documentation sucks
> > big time - I see a lot of refugees from zope here. And bloat - dont even
> > talk of it.
> > --
> > regards
> > KG
> >http://lawgon.livejournal.com
> > Coimbatore LUG rox
> >http://ilugcbe.techstud.org/
>
> > --
> > 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 
> > athttp://groups.google.com/group/django-users?hl=en.

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

model form validation

[Axel Bock]

hi all,

really, I don't get this model form validation stuff. And currently, right
now, I am immensely p*** off, because either the documentation is horribly
bad (at least for me) or I am simply way too stupid.

okay, enough rant, let's get practical - on to my little problem. I want to
do model formset validation.

I have a modelform like the one below. And I wanted to intercept the
is_valid() method of the modelform, to prepare some stuff before the
standard validation kicks in. But, the fun fact is, is_valid NEVER gets
called - at least my breakpoints in that method are not hit. The clean()
method does get called, but this one is totally useless to me ... here the
validation seems to be done already. I also have the funny little thing that
the TimeInput fields are not in the cleaned_data dict, but that's another
thing maybe.

Can anyone help me out here, please? That can't be that hard ...

Thanks in advance & greetings,
Axel.


class LegForm(forms.ModelForm):
class Meta:
model = Leg
widgets = { 'flownmission'  : widgets.HiddenInput(),
'blockoff'  : widgets.TimeInput( attrs={ 'size':10 }
),
'takeoff'   : widgets.TimeInput( attrs={ 'size':10 }
),
'landing'   : widgets.TimeInput( attrs={ 'size':10 }
),
'blockon'   : widgets.TimeInput( attrs={ 'size':10 }
),
'num_landings'  : widgets.TextInput( attrs={ 'size': 5 }
),
  }

def is_valid(self):
return True # never EVER gets called

def clean(self):
super(forms.ModelForm, self).clean()
return self.cleaned_data


@login_required
def addlegs(request, mission_id=None):
LegFormSet = modelformset_factory(Leg, form=LegForm, extra=3)
if not request.method == "POST":
# if mission_id is set we're being called from another method in
here ... :)
formset = LegFormSet(queryset=Leg.objects.none())
return rtr(request, 'flightlog/templates/addlegs.html',
{"formset":formset})
else:
formset = LegFormSet(request.POST)
formset.is_valid()
return redirect("/")

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

Comments app confuses class_prepared signal

[+shaun]

I'm trying to create models dynamically for the django.contrib.auth User 
model using the class_prepared signal.
My code works properly except when django.contrib.comments is installed.
Seems like class_prepared signals for auth models no longer fire when the 
comments app is installed.

Here's a buildout illustrating the 
problem.
A class_prepared handler simply prints sender on each trigger.

Runserver without comments installed:

$ ./bin/django-without-comments runserver
Validating models...









0 errors found

Django version 1.2.4, using settings 'project.without_comments'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

Runserver with comments installed:

$ ./bin/django-with-comments runserver
Validating models...


0 errors found

Django version 1.2.4, using settings 'project.with_comments'
Development server is running at http://127.0.0.1:8000/
Quit the server with CONTROL-C.

Is this a known issues in the comments app? Am I doing something wrong?

Thanks

-- 
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: Amazing work

[Jon J]

Well I was unfortunate enough to  look up the official zope website,
and as I'm typing this it's STILL loading. Haha, I can see what a POS
it is and definitely won't be using it for any projects anytime soon.

On Fri, Feb 4, 2011 at 10:24 PM, Kenneth Gonsalves
 wrote:
> On Fri, 2011-02-04 at 01:02 +, Cal Leeming [Simplicity Media Ltd]
> wrote:
>> May I ask, how well did you get along with Zope? From what I can tell,
>> Django is suited for SME, where as Zope is the kinda thing that banks
>> would
>> be using etc.
>
> as long as one sticks to out of the box stuff and zope's own object
> database, things are dead easy - but the moment you want to fine tune or
> use an external database - then things become hairy. Documentation sucks
> big time - I see a lot of refugees from zope here. And bloat - dont even
> talk of it.
> --
> regards
> KG
> http://lawgon.livejournal.com
> Coimbatore LUG rox
> http://ilugcbe.techstud.org/
>
> --
> 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.
>
>

-- 
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: Having trouble creating instances of another model in the __init__ of one model

[Daniel Klein]

So I need to create the two teams for a new game instance when I
create the game instance? That just feels so clumsy.

Thanks!

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

Pythonish approach to widgets

[Alex Polovjan]

Hi list,


Django.forms have a great system of widgets. But customizing them can
be a pain. Writing complex html in the python code is write-only and
error-prone approach.

I know that js files can be included in admin:

class ModelAdmin(admin.ModelAdmin):
class Media:
css = {
'all':('/static/admin/mywidget.css', )
}
js = [
"/static/admin/mywidget.js"
]

What are best practices to separate html from python code?

-- 
Best,
Alex

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

Database synchronization with sometimes-connected mobile client

[Greg Humphreys]

Hi everyone. I've developed a django website of medium complexity
(about 50,000 lines of python), and the company I work for is now
asking for a subset of the functionality to be available on an iPad.

I'm familiar with iPad development, so I'm not worried about that, but
all the research I've done on keeping the databases synchronized has
basically boiled down to "it's hard, good luck" :)

I want people to be able to make updates, deletes, and additions to
the database on an iPad, and then later synchronize these changes with
the web server (sort of like omnifocus), while also getting any new
changes that have been made on the server side.   This is important
because the users won't always be connected to the internet.

Every solution I've sketched out has my head spinning trying to figure
out how to handle foreign keys properly, what to do if the sync dies
partway through, and so forth. The server database will always be
considered sacrosanct, so if two people edit the same object, the
server version should always win (I'd just present the iPad user with
a list of things that he "lost" on). This includes situations like the
iPad user deleting an object that had been updated on the server since
the last sync, etc.

Has anyone on this list ever tackled annoying like this?  All my
django objects keep track of creation and modification time. I have
lots of foreign keys and many to many relationships. One very simple
thing that needs to happen just to get started would be that the
pre_delete signal would need to copy / flag entries so that deletions
could later be handled in synchronization. The iPad must keep deleted
objects (or at least their pks) around until the next sync, and the
server needs to keep the pks somewhere so it can tell remote clients
about the deletions later. And it just gets more complex from there!

Another situation is if the iPad users creates a new object, and then
uses foreign keys to refer to it, the synchronization might change the
pk of the new object (since a new object with the same pk might have
been created on the server), so if that happens all those foreign keys
need to be fixed up on the iPad, and those implicit changes uploaded
to the server as well. Then if the app dies in the middle of that
process, it seems very very easy for one (or both!) of my quite large
databases to get in some inconsistent state that would be nearly
impossible to repair.

One of the things I'd like to avoid is having to make every single
many to many relationship have to use a custom "through" class just
for synchronization, since that makes the admin interface less nice
without adding any real functionality to the web users.

Am I screwed?  Should I dust off my old silberschatz database book, or
is this easier than I think?

Sent from my iPad

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

how to make a datatime filed model without timestamp?

[Nima Gaemi]

hello,
i am using Djano 1.3 rev.15387 and i made a field
'last_updated=models.DateTimeField(auto_now=True)'
when i wanted to get the data out of the database i wanted to get a
delta with datetime module of python but i was warned that my
datetime.datetime.now() object was not timezone aware.so i though
about turning off timezone in postgres too.with pgadmin i was able to
turn it off and my results was ok.but i don't know if i can do similar
at the time of model creation in django model.is that possible? [sth
like  last_updated=models.DateTimeField(timestamp_timezoneaware=False)]

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

Use development server database with production server

[Amit]

Hello,
First of all one should go through with below link;

http://stackoverflow.com/questions/4887851/django-database-settings-for-production-server


Now, let come up with my hurdle. I am using a database lay out in
filesystem(windows) say;
C:/miami/data.db

I have to use same database with production server, since I don’t have
avail corresponding database in PostGreSQL.





Amit.


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

Desktop Application for Django

[Izz ad-Din Ruhulessin]

Hi all,

I've been theorizing about a Django Desktop Application built a GUI
framework (eg. PyGTK, Tkinter).

It basically comes down with this:

1. Login using an SSL POST request and create a user object.

2. Download certain tables from the DB to the local machine, perhaps
specified by a "download_local" attribute (True/False) on models. If
it already is downloaded, synchronize it with the server.

3. Use the Django ORM locally to do your work.

4. Provide wrapper classes for the models save, delete methods etc.
Foo.objects.get(pk=4) for example sends a POST request: {'obj': 'Foo',
'kwargs_keys': 'pk', 'kwargs_values': 4, 'op': 'get'}; the server then
can do the job via get_model, getattr, etc.
- OR - log all changes on the local machine, and provide a 'Send my
work to the server'-button.


This is my basic idea. What do you think about this? Is this the right
approachs? And what would be possible pitfalls?

Kind regards,

Izz ad-Din Ruhulessin

-- 
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: Having trouble creating instances of another model in the __init__ of one model

[Tom Evans]

On Sat, Feb 5, 2011 at 6:29 AM, Daniel Klein  wrote:
> I'm teaching myself django by idling poking at a project in the hope that it
> may become a playable browser game some day. It's early days.
> So I have a model "Game", which is one game session. Each game is supposed
> to have two teams. I doubt the content of the Team model matters very much,
> so I'll just paste the relevant bits from Game:
>
> class Game(models.Model):
>
> team1 = models.OneToOneField(Team, related_name="team1", null=True)
>
> team2 = models.OneToOneField(Team, related_name="team2", null=True)
>
>
>
> def __init__(self, *args, **kwargs):
>
> super(Game, self).__init__(self, *args, **kwargs)
> self.team1 = Team()
> self.team2 = Team()
>

Don't do this! __init__ is called every time an object is created,
whether it is an existing instance loaded from the database, or a new
one created and not yet saved. This would clobber any saved team{1,2}
links with empty, new objects for every single instance of this class,
which is not what you want.

Your actual error comes because you cannot assign unsaved instances to
be related to another object. Just leave them as is, and do away with
the __init__ entirely.

Cheers

Tom

-- 
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: Best DRY practices for a view function that will be used by all other views.

[James Bennett]

On Sat, Feb 5, 2011 at 6:01 AM, Ken Chida  wrote:
> Hey - Thanks for replying.  So I'm thinking that the method that I
> originally described would amount to only a few lines of code.  A decorator
> would look nicer, but i'd have to remember to add it for future views, which
> is kinda annoying.  Also, I wouldn't have a login URL because all pages will
> have it available.

The form has to POST to some URL. Preferably one that's, you know,
wired up to the login view in django.contrib.auth.

So you don't need to write code to handle logging someone in. You just
need to spit out some HTML. This is a templating issue, and the
template system gives you options to do it quite easily.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

-- 
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: Best DRY practices for a view function that will be used by all other views.

[Kenneth Gonsalves]

On Sat, 2011-02-05 at 00:21 -0800, Ken Chida wrote:
> Is there a better way to do this?  Maybe I can use a custom template
> tag?

put it in your base.html - since all your templates extend that (at
least I hope they do), you get it on all pages
-- 
regards
KG
http://lawgon.livejournal.com
Coimbatore LUG rox
http://ilugcbe.techstud.org/

-- 
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: Best DRY practices for a view function that will be used by all other views.

[Ken Chida]

Hey - Thanks for replying.  So I'm thinking that the method that I 
originally described would amount to only a few lines of code.  A decorator 
would look nicer, but i'd have to remember to add it for future views, which 
is kinda annoying.  Also, I wouldn't have a login URL because all pages will 
have it available.

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

Date internationalizaation

[Simon W]

Hey,
I have a datetime field in my models. When I format the date into letters it
appears in english and I'd like it in another langue. How to?

Thank you!
// Simon

-- 
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: Having trouble creating instances of another model in the __init__ of one model

[Ronghui Yu]

The error in save, not in constructor, seems you need to set dome default
value to Team instances, not quite sure

On Sat, Feb 5, 2011 at 2:29 PM, Daniel Klein  wrote:

> I'm teaching myself django by idling poking at a project in the hope that
> it may become a playable browser game some day. It's early days.
>
> So I have a model "Game", which is one game session. Each game is supposed
> to have two teams. I doubt the content of the Team model matters very much,
> so I'll just paste the relevant bits from Game:
>
> class Game(models.Model):
>
> team1 = models.OneToOneField(Team, related_name="team1", null=True)
>
> team2 = models.OneToOneField(Team, related_name="team2", null=True)
>
>
>
> def __init__(self, *args, **kwargs):
>
> super(Game, self).__init__(self, *args, **kwargs)
>
> self.team1 = Team()
>
> self.team2 = Team()
>
>
> The code I used to have, which worked, manually created a game and its two
> teams. This was in the view for the "create new game" page, which I found
> all kinds of ugly. Since every game should start out with exactly two teams
> in it, it makes most sense to have that code inside the Game model, right?
>
> So here's the error I'm currently getting when I try to save a game:
>
> >>> from game.models import Team, Game
>
> >>> tg = Game(name="testgame")
>
> >>> tg.save()
>
> Traceback (most recent call last):
>
>   File "", line 1, in 
>
>   File "c:\coding\django-1.1.1\django\db\models\base.py", line 410, in save
>
> self.save_base(force_insert=force_insert, force_update=force_update)
>
>   File "c:\coding\django-1.1.1\django\db\models\base.py", line 470, in
> save_base
>
> manager.filter(pk=pk_val).extra(select={'a':
> 1}).values('a').order_by())):
>
>   File "c:\coding\django-1.1.1\django\db\models\manager.py", line 129, in
> filter
>
> return self.get_query_set().filter(*args, **kwargs)
>
>   File "c:\coding\django-1.1.1\django\db\models\query.py", line 498, in
> filter
>
> return self._filter_or_exclude(False, *args, **kwargs)
>
>   File "c:\coding\django-1.1.1\django\db\models\query.py", line 516, in
> _filter_or_exclude
>
> clone.query.add_q(Q(*args, **kwargs))
>
>   File "c:\coding\django-1.1.1\django\db\models\sql\query.py", line 1675,
> in add_q
>
> can_reuse=used_aliases)
>
>   File "c:\coding\django-1.1.1\django\db\models\sql\query.py", line 1614,
> in add_filter
>
> connector)
>
>   File "c:\coding\django-1.1.1\django\db\models\sql\where.py", line 56, in
> add
>
> obj, params = obj.process(lookup_type, value)
>
>   File "c:\coding\django-1.1.1\django\db\models\sql\where.py", line 269, in
> process
>
> params = self.field.get_db_prep_lookup(lookup_type, value)
>
>   File "c:\coding\django-1.1.1\django\db\models\fields\__init__.py", line
> 210, in get_db_prep_lookup
>
> return [self.get_db_prep_value(value)]
>
>   File "c:\coding\django-1.1.1\django\db\models\fields\__init__.py", line
> 361, in get_db_prep_value
>
> return int(value)
>
> TypeError: int() argument must be a string or a number, not 'Game'
>
>
> I have no idea what this error means, and I strongly suspect I'm Doing It
> Wrong [tm] in the first place. There's probably a very easy way to do this
> that I'm not seeing.
>
>
> Thanks!
>
> --
> 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.
>



-- 
===
Regards
Ronghui Yu

-- 
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: Best DRY practices for a view function that will be used by all other views.

[James Bennett]

On Sat, Feb 5, 2011 at 2:21 AM, Ken Chida  wrote:
> Is there a better way to do this?  Maybe I can use a custom template tag?

The only thing you need is some HTML that spits out the form elements
and does a POST to whatever your login URL is. So, you know, do that.

Whether you do it with an include, a template tag, or various other
mechanisms doesn't matter, but this isn't something you should be
trying to account for in the view.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

-- 
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 on adding CSS to django project

[Ronghui Yu]

It seems that you need to setup your web server to support static contents,
django has a middleware to do the job, but it is not recommended to use it
in product environment. I had this similar problem when I started to learn
django.

On Sat, Feb 5, 2011 at 6:15 AM, Chris Hannam  wrote:

> Apologies for that premature send:
>
>
>> Hi,
>> The way I have approached this is to have a static dir set in my urls.py:
>>
>
>>
> (r'^static/(?P.*)$', 'django.views.static.serve', {
> 'document_root': settings.MEDIA_ROOT }
>  )
>
> settings.py has the following
> MEDIA_ROOT = os.path.join(PATH_SITE_ROOT, 'static')
> PATH_SITE_ROOT = os.path.normpath(os.path.dirname(__file__))
>
> I reference the css files in the html as /static/css/style.css etc
>
> The urls.py maps the url to the location on disk of the css files.
>
> Can you supply the error messages and some of your config if you are still
> having issues?
>
> CH
>
> --
> 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.
>



-- 
===
Regards
Ronghui Yu

-- 
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: Best DRY practices for a view function that will be used by all other views.

[a.esmail]

On Feb 5, 3:21 am, Ken Chida  wrote:
> I tried my best to search for an answer but my efforts yielded nothing.  
> Allow me to give you a simple example to illustrate my problem.  Let's
> pretend that I want to have a login form on every single page on my
> website.  Obviously, the login form will have a corresponding view
> function.  What is the most elegant way to implement the login functionality
> on every single page?  One brute force method would be to include the login
> view inside all view functions for every page; these view functions would
> call the login view if the HttpRequest object contains a flag that becomes
> active when the user clicks the login submit button.  This method would
> work, but it goes against DRY best practices.
>
> Is there a better way to do this?  Maybe I can use a custom template tag?
>
> Thanks in advance!!
> Ken

You can include everything you need in a template context processor
(e.g., login form).
This will make it available in every template, so you can do like
{{ login_form.as_p }} in the base template.
And the form just points to /login/ to process the login information.
Look for template context processors in the docs. They might be
exactly when you need.

-- 
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: Best DRY practices for a view function that will be used by all other views.

[Ronghui Yu]

To create a separate decorator, then all other view functions are decorated
by this decorator. For implement this decorator, you don't need to include
the login function, just redirect to login URL. Is that what you are asking
for?

On Sat, Feb 5, 2011 at 6:48 PM, Marc Aymerich  wrote:

> On Sat, Feb 5, 2011 at 9:21 AM, Ken Chida  wrote:
> > I tried my best to search for an answer but my efforts yielded nothing.
> > Allow me to give you a simple example to illustrate my problem.  Let's
> > pretend that I want to have a login form on every single page on my
> > website.  Obviously, the login form will have a corresponding view
> > function.  What is the most elegant way to implement the login
> functionality
> > on every single page?  One brute force method would be to include the
> login
> > view inside all view functions for every page; these view functions would
> > call the login view if the HttpRequest object contains a flag that
> becomes
> > active when the user clicks the login submit button.  This method would
> > work, but it goes against DRY best practices.
> >
> > Is there a better way to do this?  Maybe I can use a custom template tag?
>
> it sounds to me like you need a custom decorator for your views, I
> can't give you more details since I've never written one.
>
> --
> Marc
>
> --
> 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.
>
>


-- 
===
Regards
Ronghui Yu

-- 
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: Best DRY practices for a view function that will be used by all other views.

[Marc Aymerich]

On Sat, Feb 5, 2011 at 9:21 AM, Ken Chida  wrote:
> I tried my best to search for an answer but my efforts yielded nothing.
> Allow me to give you a simple example to illustrate my problem.  Let's
> pretend that I want to have a login form on every single page on my
> website.  Obviously, the login form will have a corresponding view
> function.  What is the most elegant way to implement the login functionality
> on every single page?  One brute force method would be to include the login
> view inside all view functions for every page; these view functions would
> call the login view if the HttpRequest object contains a flag that becomes
> active when the user clicks the login submit button.  This method would
> work, but it goes against DRY best practices.
>
> Is there a better way to do this?  Maybe I can use a custom template tag?

it sounds to me like you need a custom decorator for your views, I
can't give you more details since I've never written one.

-- 
Marc

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

Best DRY practices for a view function that will be used by all other views.

[Ken Chida]

I tried my best to search for an answer but my efforts yielded nothing.  
Allow me to give you a simple example to illustrate my problem.  Let's 
pretend that I want to have a login form on every single page on my 
website.  Obviously, the login form will have a corresponding view 
function.  What is the most elegant way to implement the login functionality 
on every single page?  One brute force method would be to include the login 
view inside all view functions for every page; these view functions would 
call the login view if the HttpRequest object contains a flag that becomes 
active when the user clicks the login submit button.  This method would 
work, but it goes against DRY best practices.

Is there a better way to do this?  Maybe I can use a custom template tag?

Thanks in advance!!
Ken

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