Re: virtualenv, PIP, fabric and patches to external projects

2009-11-30 Thread Wes Winham
We solve this problem by keeping forks of the external projects on
github, bitbucket, etc. Since PIP works so nicely with those tools,
it's pretty easy to do. You'll also find that beyond the initial work
of creating your own fork (which is actually really really easy on
both github and bitbucket), maintaining your patches is easier in the
fork than keeping your patch files laying around. It's also nice in
that if your patch is useful to the project, it's easy for them to
merge it in, which is good for both you and the project. Of the 19
external django apps we use, we maintain our own branches on github/
bitbucket for 7 of them because of minor patching we had to do.

One tip though, it took me a while to get this through my head, but
explicit versions in your requirements file are almost always the way
to go. You might think it's a hassle to update your requirements file
every time you make a new commit to your fork of a project, but it
ensures that no change every sneaks up on you and it also lets you add
a useful commit message to your actual project like "Updated
requirements for django-foo to add support for feature X and fix bug
Y" which means you only have one commit log to grep through to find
what you need later. It also means that you can always reproduce old
builds if needed.

-Wes

On Nov 24, 3:53 pm, Alex Rades  wrote:
> Hi,
> I know this is probably not 100% django related (well, actually is 0%)
> but I think most of you have worked with virtualenv and PIP and this
> looks like a good place to talk about deployment scenarios.
>
> Basically, I'd like to handle dependencies of my virtual environment
> with PIP, but I have some patches to external projects that I have to
> apply to apply before I can use them.
> Looks like PIP does not offer a facility to apply patches to
> downloaded dependencies. Maybe pip is not the right tool to do this.
>
> How do you handle your patching needs in your environments? I've
> started thinking about using fabric to do this, but I'm not really
> sure.
>
> Thank you very much.

--

You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this 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: Value proposition of Rails

2009-03-19 Thread Wes Winham

It's also important to note the architectural differences between Java
and your favorite LAMP flavor. LAMP is generally a "shared nothing"
situation where scaling out is a matter of just adding more machines
with some transparent load balancing (on the non-database side). Java
scaling tends towards beefing up the one box that's running your
application server. Often, when you're talking about "will my site
work with x million page views" you're talking about scalability more
than performance.

The bottom line though is that every one of the options mentioned
scale "well enough" for any real world need. You can name sites
written in all of those languages/frameworks (plus .NET) that work
well with load above what a VAST majority of other apps will see. If
Django only showed half the performance of J2EE (not true), then for a
lot of sites you're talking about doubling a cost which is tiny
compared to your development costs. My company gets a bill around $400
per month for our hosting on ec2. If we doubled that, it still
wouldn't be worth spending a day per month doubling the performance of
our application. Whichever tool you (and your clients) can use most
effectively from a development and maintenance standpoint is almost
definitely the right tool for the job.

-Wes

On Mar 19, 7:33 am, Brian Morton  wrote:
> Given how expensive developer time is relative to current hardware
> costs (especially on the x86 server platforms), it is almost always
> more cost effective to throw hardware at the problem than it is to
> spend countless hours porting apps from one language or framework to
> another for performance reasons.  If you want examples, see the Django
> book's deployment section.  On that same note, it is more effective to
> spend money on hardware (usually) than to code in a language that
> takes 5 times as long to develop, configure, and deploy.
> Configuration alone for most Java applications is enough to make your
> head spin.
>
> In my opinion, Django does this way better than PHP's many frameworks
> thanks to the "batteries included" approach.  I have been developing
> PHP for many years, and I do so professionally.  My hope is that one
> day more companies will go the way of Django so I can combine my play
> time and my work time.
>
> On Mar 19, 3:17 am, Torsten Bronger 
> wrote:
>
> > Hallöchen!
>
> > Malcolm Tredinnick writes:
> > > [...]
>
> > > Even PHP: I mean, Flickr, Wikipedia, Yahoo -- these are some
> > > pretty large sites running on PHP.
>
> > I've always wondered why anybody uses something non-Java for Web
> > applications.  Given that Java is faster than PHP, Python etc., this
> > also means that you need less computing power in your server farm.
> > On the long run, this should *always* be worth it financially,
> > unless Java is a nightmare to maintain, which I don't assume.
>
> > Granted, I use Python for our institute's internal Web application,
> > but I expect our traffic to be smaller than what one single
> > processor can handle.
>
> > Is it because the network and the database are the limiting factors?
> > But even then, the part of your server farm running the interpreters
> > could be reduced.
>
> > On the other hand, PHP is *highly* popular.  So why is this?
>
> > Tschö,
> > Torsten.
>
> > --
> > Torsten Bronger, aquisgrana, europa vetus
> >                    Jabber ID: torsten.bron...@jabber.rwth-aachen.de
--~--~-~--~~~---~--~~
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: Your IDE of choice

2009-01-12 Thread Wes Winham

I still really like WingIDE (in VIM mode). If you think it's worth
throwing some cash down, I don't think it can be beat.

-Wes

On Jan 6, 3:32 pm, Ovnicraft  wrote:
> 2009/1/6 Berco Beute 
>
>
>
> > On Jan 6, 2:35 pm, Pigletto  wrote:
>
> > > So, Netbeans is currently my IDE of choice. Good svn integration,
> > > faster than eclipse and komodo, stable, nice markup highlighting.
>
> > +1
> > I'm using SciTe and emacs for simple, single file editing.
> > I've used pydev for a while but eclipse's startup time is too long.
> > I've tried Eric (which is really nice), but the editor is less feature
> > rich than pydev and the auto-completion is hard to configure
> > Then I switched to Netbeans (after having used it 10 years ago for
> > Java development) and I'm really suprised by its speed and feature
> > richnes. The auto-completion is the best I've encountered. Highly
> > recommended.
>
> +1
> and this comeshttp://wiki.netbeans.org/Python70Roadmap
>
>
>
> > 2B
>
> --
> [b]question = (to) ? be : !be; .[/b]
--~--~-~--~~~---~--~~
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: Media and putting javascript last

2008-11-20 Thread Wes Winham

> Any reason this wouldn't work for you as well?

The problem with that is that when I do {{ form.media.js }} (or
whatever media output stuff I need to do) at the bottom, I'm going to
have included jquery twice since jquery is a requirement in the Media
class of any widgets/forms that need it. The trick is trying to not
have jquery in there twice.

-wes

On Nov 18, 5:59 pm, Justin Lilly <[EMAIL PROTECTED]> wrote:
> The way I structure this is I put my jquery include at at the top with  
> the css. At the bottom of my script, I add an {% block extra_script %}
> {% endblock %} block just before the  tag which is where excess  
> javascript goes. Any reason this wouldn't work for you as well?
>
>   -justin
>
> On Nov 18, 2008, at 5:19 PM,WesWinhamwrote:
>
>
>
> > == Quick summary ==
>
> > I want to find a consistent way of putting media.css at the top and
> > media.js at the bottom while still allowing jquery stuff in the
> > document body.
>
> > == Reason I want the JS at the the bottom ==
>
> > I'm a big fan of the yslow (http://developer.yahoo.com/yslow/) addon
> > and Yahoo's recommendations for improving user experience in regard to
> > page load time and responsiveness. One of the recommendations I've
> > personally found most useful is that CSS should go at the top and JS
> > should go at the bottom to improve rendering speed and allow your page
> > to be "loaded" as quickly as possible (even if there's still some JS
> > stuff going on, your users likely won't notice it).
>
> > == Reason I need the jquery include at the top ==
>
> > For several jquery widgets I use (a wymeditor widget, autocomplete
> > widget, jquery calendar widget), I've written the django widget such
> > that it does any initialization and setting up using $
> > (document).onLoad
> > () so that I don't have to worry about adding any javascript for
> > specific widgets in the template. It's all handled through python so
> > that the designer side doesn't have to worry about it. Because of the
> > onLoad() usage, I need jquery at the top (so that all of the stuff in
> > the body can use it).
>
> > == Problems with re-usable widgets and class Media ==
>
> > All of my widgets obviously have the Media.js element set with jquery
> > and their required libraries (my favorite Django 1.0ish feature, btw)
> > which works wonderfully except for the fact that if I was to do
> > {{ media.js }} after I've already included jquery at the top of the
> > page, I get lots of problems for having jquery included twice. I'd
> > like to go the Pinax route and include jquery in my base.html so that
> > it's on every page (since I use it on almost every page), but then I
> > need a method of extracting out any jquery includes for any of my
> > media elements. I could do that in every view, but it seems like there
> > must be easier way to do it from one location.
>
> > == Ideas for removing jquery includes from all media objects ==
> > 1. I first looked in to a context processor, but then I realized that
> > you could only add/overwrite context and not alter it.
> > 2. Now I'm considering some kind of form subclass that will strip out
> > the jquery stuff
>
> > Does anyone have any suggestions on a better way to keep my jquery
> > include and my css at the top and all the rest of my javascript at the
> > bottom while avoiding including jquery twice?
>
> > thanks
> > -Wes
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



Media and putting javascript last

2008-11-18 Thread Wes Winham

== Quick summary ==

I want to find a consistent way of putting media.css at the top and
media.js at the bottom while still allowing jquery stuff in the
document body.

== Reason I want the JS at the the bottom ==

I'm a big fan of the yslow (http://developer.yahoo.com/yslow/) addon
and Yahoo's recommendations for improving user experience in regard to
page load time and responsiveness. One of the recommendations I've
personally found most useful is that CSS should go at the top and JS
should go at the bottom to improve rendering speed and allow your page
to be "loaded" as quickly as possible (even if there's still some JS
stuff going on, your users likely won't notice it).

== Reason I need the jquery include at the top ==

For several jquery widgets I use (a wymeditor widget, autocomplete
widget, jquery calendar widget), I've written the django widget such
that it does any initialization and setting up using $(document).onLoad
() so that I don't have to worry about adding any javascript for
specific widgets in the template. It's all handled through python so
that the designer side doesn't have to worry about it. Because of the
onLoad() usage, I need jquery at the top (so that all of the stuff in
the body can use it).

== Problems with re-usable widgets and class Media ==

All of my widgets obviously have the Media.js element set with jquery
and their required libraries (my favorite Django 1.0ish feature, btw)
which works wonderfully except for the fact that if I was to do
{{ media.js }} after I've already included jquery at the top of the
page, I get lots of problems for having jquery included twice. I'd
like to go the Pinax route and include jquery in my base.html so that
it's on every page (since I use it on almost every page), but then I
need a method of extracting out any jquery includes for any of my
media elements. I could do that in every view, but it seems like there
must be easier way to do it from one location.

== Ideas for removing jquery includes from all media objects ==
 1. I first looked in to a context processor, but then I realized that
you could only add/overwrite context and not alter it.
 2. Now I'm considering some kind of form subclass that will strip out
the jquery stuff

Does anyone have any suggestions on a better way to keep my jquery
include and my css at the top and all the rest of my javascript at the
bottom while avoiding including jquery twice?

thanks
-Wes

--~--~-~--~~~---~--~~
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 along with PHP - avoiding Apache crashes

2008-10-28 Thread Wes Winham

I'm currently in production with Apache2, mod_php, mod_python, Django
1.0, MySQL 5.x, and PHP5 using everything (except django) out of the
Ubuntu 8.04 repository with no troubles, if that helps at all.

On Oct 28, 8:58 am, Giles Thomas <[EMAIL PROTECTED]>
wrote:
> Graham,
>
> Thank you again for the help - as you might have guessed, my separate
> question that you answered on the mod_wsgi list was because I'd decided
> to try out the WSGI solution to the problem first.
>
> What's very strange is that although I did get the same crash when I
> first tried running up Apache + PHP  + mod_wsgi as I had with mod_python
> - as you would expect - it now works fine!  I *think* that the change
> that fixed it was when I ran apt-get remove libapache2-mod-python - but
> I'm not quite sure why that worked.
>
> So I'm now in the uncomfortable position of having a server that works
> perfectly well, when I'm pretty sure that it should not.  One
> possibility: I'm using PHP5, and although the Django page [1] just says
> that there can be problems with PHP, the mod_python description of the
> bug [2] in one place refers to PHP4 - so perhaps the problem wasn't with
> PHP in the first place, but was instead some kind of mod_python version
> incompatibility.
>
> Anyway, for now I'll leave this alone and just keep an eye on it in case
> things start going wrong again.  In case it's of any interest, here's
> what I got when I checked the MySQL library versions in the current
> working setup:
>
> ---
> # ldd /usr/lib/python2.4/site-packages/_mysql.so | grep mysql
>         libmysqlclient_r.so.15 => /usr/lib/libmysqlclient_r.so.15
> (0x2b8df786)
> # ldd /usr/lib/apache2/modules/mod_*.so | grep mysql
> # ldd /usr/lib/php5/20060613/* | grep mysql
> /usr/lib/php5/20060613/mysqli.so:
>         libmysqlclient.so.15 => /usr/lib/libmysqlclient.so.15
> (0x2b8f8bd3f000)
> /usr/lib/php5/20060613/mysql.so:
>         libmysqlclient.so.15 => /usr/lib/libmysqlclient.so.15
> (0x2b28d2295000)
> /usr/lib/php5/20060613/pdo_mysql.so:
>         libmysqlclient.so.15 => /usr/lib/libmysqlclient.so.15
> (0x2ba328e47000)
> #
> ---
>
> Cheers,
>
> Giles
>
> [1]http://docs.djangoproject.com/en/dev/howto/deployment/modpython/#if-y...
>
> [2]http://modpython.org/FAQ/faqw.py?req=show&file=faq02.013.htp
>
> --
> Giles Thomas
> MD & CTO, Resolver Systems Ltd.
> [EMAIL PROTECTED]
> +44 (0) 20 7253 6372
>
> Try out Resolver One! 
>
> 17a Clerkenwell Road, London EC1M 5RD, UK
> VAT No.: GB 893 5643 79
> Registered in England and Wales as company number 5467329.
> Registered address: 843 Finchley Road, London NW11 8NA, UK
--~--~-~--~~~---~--~~
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 Hosting Survey

2008-10-09 Thread Wes Winham

If you're looking for something with some power off the bat (which it
doesn't sound like you are), Amazon's EC2 (http://aws.amazon.com/ec2/)
is amazing. If you start there, you can stay there right up to the
point that you're bigger than amazon.com :) It has the same
disadvantages of slicehost or linode as far as needing to set
everything up yourself, but if you're going to be spending anything
close to $70 on slicehost or linode, you'd be doing yourself a huge
favor by starting with EC2.

Hope that helps
-Wes

On Oct 6, 1:30 pm, Jeff <[EMAIL PROTECTED]> wrote:
> I am about to begin a new Django project and I am currently evaluating
> hosting options. I know there has been a number of discussions on this
> topic, and I have read most of them. However, seeing how quickly
> things change in the web development / hosting world, I wanted to get
> some opinions if the following summary still holds true.
>
> The most useful information I have found on Django hosting was 
> here:http://www.djangoproject.com/weblog/2008/jan/12/mt/
>
> From this, and other sources, I believe the best hosting options to
> be:
>
> 1. Web Faction - for those that want to get Django up and running as
> quickly and easily as possible, using their automated setup.
>
> OR
>
> 2. Slicehost - for those that want COMPLETE control of their hosting
> environment. Only drawback (for some) is that everything needs to be
> installed from scratch.
>
> In the case of Slicehost, I am also curious if the 256 slice is
> sufficient for most Django apps.
>
> I appreciate any thoughts or comments.
>
> Thanks!
>
> Jeff
--~--~-~--~~~---~--~~
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: ANNOUNCE: Django 1.0 released

2008-09-04 Thread Wes Winham

Thanks again for the huge amount of awesome that you guys have brought
to web development.

On Sep 3, 8:07 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> The Django team is pleased to announce the release of Django 1.0 this evening:
>
> Download:http://www.djangoproject.com/download/
> Release notes:http://docs.djangoproject.com/en/dev/releases/1.0/
>
> Have fun with it, and we'll see you in a few days for DjangoCon.
>
> --
> "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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---



Re: Boosting your productivity when debugging Django apps

2008-08-25 Thread Wes Winham

I use Wing IDE (not free, wingide.com). It contains a full debugger
that worked for me with Django with minimal fuss. I can step through
the whole thing by debugging the manage.py runserver --noreload

The thing I find most valuable about their debugger is that it gives
you a full python shell (with autocomplete) that evaluates to wherever
your debugger is at the time. So you can set a breakpoint in a
function that's giving you trouble and then run whatever python
commands you'd like to in order to figure out what's going on. Pretty
solid. I used Eclipse with pydev for 4 months and it was causing some
stability issues with my machine. I was also having some trouble with
the autocomplete terms and it doesn't have a debugger that I could get
working. Eclipse + pydev is the best free option I found, but throwing
down the cash for Wing IDE has been a good investment in my particular
situation.

Hope that helps
-wes

On Aug 22, 2:20 pm, Delta20 <[EMAIL PROTECTED]> wrote:
> This question is aimed at those of you who, like me, come from a Java
> and C++ background and are used to being able to debug things with a
> debugger - setting breakpoints, stepping through code, evaluating
> expressions, etc. What do you find to be the most productive approach
> to debugging Django apps?
>
> Personally, I've been trying to get PyDev to work but attempting to
> run a Django app crashes Eclipse every time for me so I haven't been
> able to evaluate its debugger. I don't much like Eclipse anyway and am
> hoping the NetBeans Python debugger will provide a viable
> alternative.
>
> I'm new to both Python and Django, and right now I feel horribly
> unproductive without an efficient way to debug things.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



Django learning management application

2008-05-14 Thread Wes Winham

Does anyone know of any learning management application written in
Django? My googlefu is too weak and I wasn't able to find anything on
django pluggables. I have a few weeks before I have to make the build
versus integrate decision, but a simple quizzing application seems
like something that would have potential uses across a variety of
projects and I was surprised when I couldn't find one.

The application I envision lets a user create quizzes out of multiple
choice questions that can be automatically graded. Questions and
quizzes could be linked through generic relations to any object. Quiz
requirements could be assigned to users and reports could be run
against those requirements.

If there's really nothing around, then hopefully I'll be able to
persuade my boss of the merits of open-sourcing such a generic,
reusable application.

-wes
--~--~-~--~~~---~--~~
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: Many to Many Inline Editing

2008-05-13 Thread Wes Winham

So, to make sure I understand the question, you're looking for a
solution for editing m2m inline for a ModelForm? Or are you talking
about django.views.generic.create_update?

I know how to do a "custom" inline edit by overriding a field in the
ModelForm, adding a ModelForm from the view for the inline model,
using javascript (jquery) to duplicate the inline form with field
names that are indexed, and using some custom processing in the view
to create the inline models and then link them, but that's a pain. I'd
also love to see some sort of widget, maybe a MultiWidget, that works
as an inline ModelForm for m2m inline (if that's what you're asking),
maybe combined with a bit of jquery to handle adding more than one.
It's on my "to do" list.

-Wes

On May 12, 11:05 am, JReynolds <[EMAIL PROTECTED]> wrote:
> I have seen this posted a few times on the list here, but it always
> seems to become a discussion about the many to many implementation and
> move away from making it work as the one to many inline editing works
> in the newforms-admin branch.
>
> So... does anyone have a fix for being able to add/edit/delete objects
> on the other side of a many to many relationship from the edit view of
> a model?  I have tried to hack up a fix by copying and changing the
> current inline implementation, but can't even get the forms to
> generate.  I can elaborate on my failure if no one else has any
> working ideas...
>
> I'm sure I'm not the only one that needs this and can't seem to get it
> done myself, so maybe this is a useful feature that could be added by
> someone with a better understanding of the admin internals?
--~--~-~--~~~---~--~~
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 Performance using PyISAPIe on IIS Rocks

2008-05-13 Thread Wes Winham

It's also worth noting that you sometimes lose stability using
eAccelerator. I've experienced a notable number of apache segfaults
trying to squeeze out some performance, where as .pyc comes out of the
box with no instability.

-Wes

On May 12, 10:30 am, rcs_comp <[EMAIL PROTECTED]> wrote:
> Mat,
>
> You are right, I should have done that.  I setup eAccelerator for IIS
> in both FastCGI and ISAPI modes.  Unfortunately, I could not get
> eAccelerator working in non-thread-safe mode with FastCGI (which is
> what Microsoft recommends).  Here are my results:
>
> PHP ISAPI eAccelerator Symfony: 25.06
> PHP FastCGI eAccelerator Symfony (thread-safe mode): 23.41
> PHP ISAPI Symphony (no accelerator): 11.36
>
> Even if I got FastCGI and eAccelerator working in non-thread-safe
> mode, I don't think it would come close to touching PyISAPIe and
> Django in these tests.
>
> Thoughts?
>
> On May 12, 6:19 am, "Mat" <[EMAIL PROTECTED]> wrote:
>
> > Dunno if you can do it on IIS (cant say ive ever tried), but try installing
> > a PHP accelerator such as eaccelarator or APC, both are open source. This
> > will cache your php files similar to *.pyc in python, and should give you a
> > x8-x10 boost. It is not really a fair test without it :) It is how we run
> > all out symfony servers and they wouldn't cope otherwise!
>
> > Mat
--~--~-~--~~~---~--~~
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: newforms and views.generic.create_update.create_object

2008-05-12 Thread Wes Winham

I've been using Brian Rosner's patch from that ticket, and it's been
working great for me. I haven't ran in to any bugs so far and it's cut
my view code down by several lines each view in some places and
completely eliminated view code in many others. Gotta love newforms
and modelforms :)

I might be a little dense, but the documentation was a little
confusing as far as what parameters I needed to pass, so I had to look
at the great test cases that were added with that patch. So if seeing
examples helps, I recommend checking out the url_conf for the
generic.create_update tests.

-wes

On May 11, 10:10 am, "M.Ganesh" <[EMAIL PROTECTED]> wrote:
> Karen Tracey wrote:
> > On Sun, May 11, 2008 at 5:55 AM, M.Ganesh <[EMAIL PROTECTED]
> > > wrote:
>
> > Hi all
>
> > I am a django rookie.
>
> > Is it true that "views.generic.create_update.create_object" generate a
> > oldform?  (the documentation says so!)
>
> > The docs are generally accurate.  Searching the in the ticket tracker
> > for generic create_update reveals:
>
> >http://code.djangoproject.com/ticket/3639
>
> > It's got a patch you could try, and is apparently just waiting for a
> > good time to check it in since it is a backwards-incompatible change.
>
> > Karen
>
> Thanks Karen for confirming. I've added myself to the cc list of the ticket
>
> Regards Ganesh
--~--~-~--~~~---~--~~
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: Announce: Djikiki - Django wiki application

2008-05-07 Thread Wes Winham

I haven't looked in to the project much myself, but Sphene Community
Tools seems to have a django-based wiki (http://sct.sphene.net/wiki/
show/Wiki/).

On May 7, 3:20 am, shabda <[EMAIL PROTECTED]> wrote:
> Wanted to announce Djikiki - A Django based wiki to the community.
> Looks like there is no Django wiki, well apart from [1]. I had this
> done a few months ago, but I wanted to polish thing up a bit before I
> announced it here, but I guess right now I am going to be sorta busy
> for a long time withwww.42topics.com, so here is Djikiki.
>
> Source is available from,http://code.google.com/p/djikiki/
>
> An install for Djikiki can be seen atwww.djikiki.com
>
> Its features include
>
>1. All pages are versioned. (It is a wiki, what do you expect. )
>2. All pages have an associated discussion page. (Which is also
> versioned.)
>3. See edit history, for all users, all pages etc.
>4. Featured pages.
>5. Only registered users can edit. (But registering takes a few
> second).
>6. Wikicreole based markup.
>
> Please take it for a spin. Feedback, patches welcome. :)
>
> [1]http://showmedo.com/videos/video?name=110&fromSeriesID=110
--~--~-~--~~~---~--~~
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: Distributed databases

2008-04-17 Thread Wes Winham

Found it. http://softwaremaniacs.org/soft/mysql_cluster/en/ (found
through Simon Willison's blog). It looks like my memory was wrong
though, because it doesn't switch databases automatically depending on
query type. It leaves it up to the view to decide which database to
use. If you absolutely must use different tables on different
databases instead of just using master/slave replication, then that
won't fit for you. I imagine looking at the code could be useful
though.

-Wes

On Apr 17, 9:49 am, Wes Winham <[EMAIL PROTECTED]> wrote:
> One of the blogs I follow posted up an example of an ORM tweak built
> for master/slave mysql setups. I'm having trouble finding it, but it's
> definitely possible to modify the ORM to make decisions about which
> database to use automatically so that you don't have to worry about it
> in your views or your models.
>
> -Wes
>
> On Apr 16, 2:44 pm, mg <[EMAIL PROTECTED]> wrote:
>
> > It sounds like you would either have to go with the custom driver idea
> > or use another ORM package like Sqlalchemy(which means you don't get
> > certain features like the contrib apps)
>
> > On Apr 16, 1:04 pm, "Chris Czub" <[EMAIL PROTECTED]> wrote:
>
> > > Would it be possible to replace the Django database driver(i.e. 
> > > postgresql,
> > > sqlite, mysql) with a custom one that managed the various database
> > > connections? Similar to the SQL proxy idea(or maybe identical).
>
> > > On Wed, Apr 16, 2008 at 1:41 PM, RaviKondamuru <[EMAIL PROTECTED]>
> > > wrote:
>
> > > > Here is the thread that talks about multiple database support:
>
> > > >http://groups.google.com/group/django-users/browse_frm/thread/02fb947...
> > > > Ravi.
>
> > > > On Apr 16, 6:19 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> > > > > Hello everyone,
>
> > > > > This is my first post on this list, so please by gentle and patient ;)
>
> > > > > I would like to ask, if it is possible to have DJango running on one
> > > > > machine, and have several databases (each with different content) on
> > > > > other machines. Basically I would specify a few tables, and each would
> > > > > be in different database, while main server would aggregate and
> > > > > display this data. Would be also possible, to have different database
> > > > > types (i would like to have several sqlite databases and one postgres
> > > > > running)?
>
> > > > > I need all this for scalability reasons. I am choosing framework for
> > > > > the project and what DJango provides seems really cool. If only it
> > > > > provides some mechanisms for scalability I guess I will fall in
> > > > > love ;-)
--~--~-~--~~~---~--~~
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: Distributed databases

2008-04-17 Thread Wes Winham

One of the blogs I follow posted up an example of an ORM tweak built
for master/slave mysql setups. I'm having trouble finding it, but it's
definitely possible to modify the ORM to make decisions about which
database to use automatically so that you don't have to worry about it
in your views or your models.

-Wes

On Apr 16, 2:44 pm, mg <[EMAIL PROTECTED]> wrote:
> It sounds like you would either have to go with the custom driver idea
> or use another ORM package like Sqlalchemy(which means you don't get
> certain features like the contrib apps)
>
> On Apr 16, 1:04 pm, "Chris Czub" <[EMAIL PROTECTED]> wrote:
>
> > Would it be possible to replace the Django database driver(i.e. postgresql,
> > sqlite, mysql) with a custom one that managed the various database
> > connections? Similar to the SQL proxy idea(or maybe identical).
>
> > On Wed, Apr 16, 2008 at 1:41 PM, RaviKondamuru <[EMAIL PROTECTED]>
> > wrote:
>
> > > Here is the thread that talks about multiple database support:
>
> > >http://groups.google.com/group/django-users/browse_frm/thread/02fb947...
> > > Ravi.
>
> > > On Apr 16, 6:19 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> > > > Hello everyone,
>
> > > > This is my first post on this list, so please by gentle and patient ;)
>
> > > > I would like to ask, if it is possible to have DJango running on one
> > > > machine, and have several databases (each with different content) on
> > > > other machines. Basically I would specify a few tables, and each would
> > > > be in different database, while main server would aggregate and
> > > > display this data. Would be also possible, to have different database
> > > > types (i would like to have several sqlite databases and one postgres
> > > > running)?
>
> > > > I need all this for scalability reasons. I am choosing framework for
> > > > the project and what DJango provides seems really cool. If only it
> > > > provides some mechanisms for scalability I guess I will fall in
> > > > love ;-)
--~--~-~--~~~---~--~~
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: Sharing session data between PHP and Django

2008-02-12 Thread Wes Winham

Alex,

Wow. I guess today is definitely my lucky day. That Python
serialization class you linked is perfect and the code samples are
really helping me understand where I need to be tinkering.

Like you, I'm still not sure how I'll go about integrating the
authentication systems specifically. This is especially true if the
user is stored as an object by the authentication middleware, because
it doesn't seem like you would be able to pickle/serialize objects
back and forth.

Thanks a ton for the insight.
-Wes

On Feb 12, 6:18 pm, "Alex Ezell" <[EMAIL PROTECTED]> wrote:
> I realize that I didn't talk too much about getting your Django
> authentication stuff specifically. I'm still working on that bit, but
> have moved ahead for right now.
>
> Our initial thoughts are to just call a Django login method from PHP
> after the PHP login. Since they are sharing a session (essentially),
> it may be that easy.
>
> I'll let you know once we have something working.
>
> /alex
>
> On Feb 12, 2008 5:09 PM, Alex Ezell <[EMAIL PROTECTED]> wrote:
>
> > Hi Wes,
> > It's fortuitous that you ask this question today. I spent last Friday
> > working all this out for our application.
>
> > The overview is to setup Django to use a file-based session system and
> > point it to the same files that PHP is using. Then override some
> > methods to help Python read and write the PHP arrays stored in the
> > session file. Now, if you can't use file-based sessions, this won't
> > specifically work for you, but may help in seeing what's possible.
>
> > First things first, this will make everything much easier:
> >http://hurring.com/scott/code/python/serialize/
>
> > In my case, I use files for maintaining the session data for my PHP
> > app. So, you'll need to setup your Django settings to use files for
> > session data and point it to the same folder (ie. /tmp/).
>
> > More 
> > info:http://www.djangoproject.com/documentation/sessions/#using-file-based...
>
> > Then, create a file, I called mine handshake.py, to which you will
> > point your SESSION_ENGINE setting (note, this is different than what
> > the docs say above, because you are modifying the engine a bit to suit
> > your needs). In that file, you want to subclass SessionStore and
> > override the encode and decode methods. In each, you will use the
> > PHPSerialize or PHPUnserialize to work with the data and return it in
> > a form which Django can use.
>
> > Something like this:
> > from django.contrib.sessions.backends.file import SessionStore as
> > SessionFileStore
> > from PHPSerialize import *
> > from PHPUnserialize import *
>
> > class SessionStore(SessionFileStore):
> > '''
> > Howdy pardner! Speaking of pardners, I subclass the SessionStore
> > class in the file session backend.
>
> > This allows me intercept the decode and encode methods to grab the
> > PHP sessions and use them.
>
> > So, in a way, this makes me PHP's pardner, also.
> > '''
> > def __init__(self, session_key=None):
> > # call the super class's init
> > super(SessionStore, self).__init__(session_key)
> > #override the file_prefix
> > self.file_prefix = 'prefix_'
>
> > def decode(self, session_data):
> > # uses special session decode method in PHPUnserialize
> > u = PHPUnserialize()
> > return u.session_decode(session_data)
>
> > def encode(self, session_dict):
> > # users special encode method in PHPSerialize
> > s = PHPSerialize()
> > return s.session_encode(session_dict)
>
> > Remember to set your SESSION_COOKIE_NAME to the same name that your
> > PHP setup uses. This allows Django to find the session cookie on the
> > client machine.
>
> > You may not need to override the file_prefix as I have, but this will
> > depend on your setup.
>
> > Once this is all in place, you can just call request.session in your
> > views as you normally would. You can modify or add values and your PHP
> > app will see them just fine.
>
> > /alex
>
> > On Feb 12, 2008 4:38 PM, Wes Winham <[EMAIL PROTECTED]> wrote:
>
> > > Hello,
>
> > > I'm in the process of switching my new development over to Django
> > > (goodbye PHP + my horribly mediocre custom framework). The only real
> > > tough problem to solve in getting the two sides of the application to
> > > play nice with eachother (for me) is

Sharing session data between PHP and Django

2008-02-12 Thread Wes Winham

Hello,

I'm in the process of switching my new development over to Django
(goodbye PHP + my horribly mediocre custom framework). The only real
tough problem to solve in getting the two sides of the application to
play nice with eachother (for me) is session management. When I log in
a user through the PHP side, I need them to stay logged in when they
go to the Django side, obviously, and they need to take all their
other session data with them. I've searched google, blogs, this group,
and IRC and nothing has jumped out at me as a solution. I'd love to
hear what some more experienced Django users think about my proposed
solution:

1) Create a custom bit of middleware (or modify the authentication
middleware) and a custom PHP session handler to tie the two together.
I would have two columns for session data. One for PHP-serialized auth
data and one for python-serialized auth data.

Every time I save user data to the session in PHP (basically just the
userid and some authorization rights), the session handler uses exec
to call some sort of python code that creates the django-equivalent
information, which I believe is just an object from the user model and
returns the serialized version of that object (http://
www.djangoproject.com/documentation/authentication/#authentication-in-web-requests).
I then save that object in to the column for python data along with
the php data in the php column.

On the Django side, I hook in to the authentication framework somehow
so that any time the user session information is updated, I call some
PHP code that generates the right bit of serialized data and then I
insert that in the php column.


So, some problems I see with my strategy already:
-I don't know how hard it will be to trick the auth middleware to use
my "special" phython-serialized auth data column instead of pulling
stuff from the general session-data column like it will want to (or
how hard it would be to just deserialize the current python data, add
on my user data, reserialize and stick it back in).
-I don't know how hard it will be to do the reverse operation from PHP
to python
-I see some concurrency issues cropping up with all of this trying to
keep two versions of the same data going from two different languages/
sites.

Does anyone see an easier way or maybe have some insight into how I
might accomplish the serialization/pickling stuff?

The good news is that if I can get it to work, I'll definitely be
releasing my middleware changes and my PHP session handler for use by
any other poor sap trying to stick their PHP and Django
Authentications together.
--~--~-~--~~~---~--~~
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: Basic Form Design Question: Pulling as much as possible from models

2008-01-08 Thread Wes Winham

Oops. So it is.

Thanks for the clarification.

On Jan 7, 1:10 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> On Jan 7, 5:07 pm, Wes Winham <[EMAIL PROTECTED]> wrote:
>
> >http://www.pointy-stick.com/blog/2008/01/06/django-tip-complex-forms/
>
> > A shiny solution to the problem with code and the reasoning behind it.
> > Simon Willison is awesome.
>
> It's Malcolm that's awesome, I just link to his stuff!
>
> Cheers,
>
> 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---



Re: Basic Form Design Question: Pulling as much as possible from models

2008-01-07 Thread Wes Winham

http://www.pointy-stick.com/blog/2008/01/06/django-tip-complex-forms/

A shiny solution to the problem with code and the reasoning behind it.
Simon Willison is awesome.

On Jan 4, 1:03 pm, Wes Winham <[EMAIL PROTECTED]> wrote:
> Thanks Malcom. That reassured me greatly. I didn't think of the clever
> id meta-fields to keep the form from modification, but I ended up
> getting a shell implementation with each question being it's own
> question form, and the overallquizform just adds in as many question
> forms as there are questions in aquiz. I'll need to abstract out that
> functionality, just like you've suggested, but overall I think it will
> end up making sense in a month when I have to look at it again and I
> wonder who wrote this junk :)
>
> Thanks
> -Wes
>
> On Jan 3, 9:28 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
>
> > On Thu, 2008-01-03 at 09:51 -0800, Wes Winham wrote:
> > > Hello,
>
> > > I've got a bit of a design issue I'm trying to wrap my head around in
> > > order to do things the Django Way.
>
> > > I'm attempting to creating a simple form that allows a user to take a
> > > multiple choice "quiz."Quizis a model and it has a many to many with
> > > Questions which has a m2m with AnswerOptions.
>
> > > I'm also not sure on which is the best way to get the questions and
> > > answers to the form and I'm not sure if I should be using one form, or
> > > a collection of forms.
>
> > Hmm  deja vu. I've been working on an almost analogous problem this
> > morning. I haven't coded it all up yet, but here's my current design
> > thinking...
>
> > Each question is a form class. You can use the same form class each time
> > and part of its __init__ method will be to store the "question" string
> > (say in self.question). I will display 'N' of these on the page using
> > the "prefix" attribute to the form's __init__ method. So it will look
> > something like this:
>
> > class QuestionForm(forms.Form):
> >answers = forms.ChoiceField(widget=forms.RadioSelect)
>
> >def __init__(self, question, *args, **kwargs):
> >   super(Question, self).__init__(*args, **kwargs)
> >   self.question = question
> >   self.fields['answers'].choices = ...
>
> > I also have some meta-information in the form, such as a security hash
> > to make sure the form isn't modified, so that uses another form class
> > (which currently just contains the security hash, but I might need other
> > stuff when I flesh things out).
>
> > Then my view will look like this:
>
> > def quiz_view(request, quiz_id):
> >quiz=Quiz.objects.get(pk=quiz_id)
> >if request.method == 'POST':
> >   # TODO ...
> >else:
> >   meta = MetaForm(quiz)
> >   q_forms = []
> >   for num, question in enumerate(quiz.questions.all()):
> >  q_forms.append(QuestionForm(question, prefix=str(num)))
> >return render_to_response('quiz.html', {'meta': meta_form,
> >   'question_forms': q_forms})
>
> > and then, in the template:
>
> >
> >   {{ meta }}
> >   {% for form in question_forms %}
> >  {{ form.question }}
> >  {{ form.as_p }}
> >   {% endfor %}
> >   
> >
>
> > Obviously, a lot has been glossed over here (and there are no doubt some
> > bugs, as I haven't finalised the code in my case yet and I'm simplifying
> > a bunch of stuff). The point I want to make, though, is that I'm using
> > multiple form classes to render a *single* HTML form. I'm also shoving
> > things like the question text into the appropriate form so that I can
> > use that normally in the template (it's not a form field, so it wouldn't
> > normally be displayed).
>
> > In the final analysis, I'll end up pulling out the form creation stuff
> > into a separate function, since I need to do it in multiple places (at
> > least, in both the POST and GET paths), but that's just normal stuff.
>
> > Hopefully this gives you another idea to play with. I don't think any of
> > your options allowed for the possibility of multiple form classes, but
> > sometimes that can make things a lot easier.
>
> > Regards,
> > Malcolm
>
> > --
> > Save the whales. Collect the whole set.http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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: Basic Form Design Question: Pulling as much as possible from models

2008-01-04 Thread Wes Winham

Thanks Malcom. That reassured me greatly. I didn't think of the clever
id meta-fields to keep the form from modification, but I ended up
getting a shell implementation with each question being it's own
question form, and the overall quiz form just adds in as many question
forms as there are questions in a quiz. I'll need to abstract out that
functionality, just like you've suggested, but overall I think it will
end up making sense in a month when I have to look at it again and I
wonder who wrote this junk :)

Thanks
-Wes

On Jan 3, 9:28 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Thu, 2008-01-03 at 09:51 -0800, Wes Winham wrote:
> > Hello,
>
> > I've got a bit of a design issue I'm trying to wrap my head around in
> > order to do things the Django Way.
>
> > I'm attempting to creating a simple form that allows a user to take a
> > multiple choice "quiz." Quiz is a model and it has a many to many with
> > Questions which has a m2m with AnswerOptions.
>
> > I'm also not sure on which is the best way to get the questions and
> > answers to the form and I'm not sure if I should be using one form, or
> > a collection of forms.
>
> Hmm  deja vu. I've been working on an almost analogous problem this
> morning. I haven't coded it all up yet, but here's my current design
> thinking...
>
> Each question is a form class. You can use the same form class each time
> and part of its __init__ method will be to store the "question" string
> (say in self.question). I will display 'N' of these on the page using
> the "prefix" attribute to the form's __init__ method. So it will look
> something like this:
>
> class QuestionForm(forms.Form):
>answers = forms.ChoiceField(widget=forms.RadioSelect)
>
>def __init__(self, question, *args, **kwargs):
>   super(Question, self).__init__(*args, **kwargs)
>   self.question = question
>   self.fields['answers'].choices = ...
>
> I also have some meta-information in the form, such as a security hash
> to make sure the form isn't modified, so that uses another form class
> (which currently just contains the security hash, but I might need other
> stuff when I flesh things out).
>
> Then my view will look like this:
>
> def quiz_view(request, quiz_id):
>quiz = Quiz.objects.get(pk=quiz_id)
>if request.method == 'POST':
>   # TODO ...
>else:
>   meta = MetaForm(quiz)
>   q_forms = []
>   for num, question in enumerate(quiz.questions.all()):
>  q_forms.append(QuestionForm(question, prefix=str(num)))
>return render_to_response('quiz.html', {'meta': meta_form,
>   'question_forms': q_forms})
>
> and then, in the template:
>
>
>   {{ meta }}
>   {% for form in question_forms %}
>  {{ form.question }}
>  {{ form.as_p }}
>   {% endfor %}
>   
>
>
> Obviously, a lot has been glossed over here (and there are no doubt some
> bugs, as I haven't finalised the code in my case yet and I'm simplifying
> a bunch of stuff). The point I want to make, though, is that I'm using
> multiple form classes to render a *single* HTML form. I'm also shoving
> things like the question text into the appropriate form so that I can
> use that normally in the template (it's not a form field, so it wouldn't
> normally be displayed).
>
> In the final analysis, I'll end up pulling out the form creation stuff
> into a separate function, since I need to do it in multiple places (at
> least, in both the POST and GET paths), but that's just normal stuff.
>
> Hopefully this gives you another idea to play with. I don't think any of
> your options allowed for the possibility of multiple form classes, but
> sometimes that can make things a lot easier.
>
> Regards,
> Malcolm
>
> --
> Save the whales. Collect the whole set.http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



Basic Form Design Question: Pulling as much as possible from models

2008-01-03 Thread Wes Winham

Hello,

I've got a bit of a design issue I'm trying to wrap my head around in
order to do things the Django Way.

I'm attempting to creating a simple form that allows a user to take a
multiple choice "quiz." Quiz is a model and it has a many to many with
Questions which has a m2m with AnswerOptions.

I'm also not sure on which is the best way to get the questions and
answers to the form and I'm not sure if I should be using one form, or
a collection of forms.

I guess I'll try and outline the options I have in my mind right now
and hope someone can clarify what they would choose.

Getting data to the form:
A. Pass a Quiz to the form and then drag out the questions and answer
options in __init__, and set a ChoiceField for each question with the
AnswerOptions as the choices and with the label set to the text of the
question
B. Pass a dictionary of questions with the question text as the key
and the options as the value and then do the parsing in __init__ to
set the ChoiceFields
C. Something else that makes creating an arbitrary number of
ChoiceFields easier

Setting up the form:
E. Create one form called TakeQuiz that uses one of the options from
above to set a bunch of ChoiceField's
F. Create a form called AnswerQuestion that only has one ChoiceField
and takes a question and a list of choices. Then string those together
in the view.

G. Something totally different.

Any input on what is most inline with the Django way of doing things
would be appreciated.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---