Re: FormWizard accessing previous fields data
On Feb 2, 2009, at 23:32, lbologn...@gmail.com wrote:
> On Feb 1, 2:38 am, "mattimust...@gmail.com" <mattimust...@gmail.com>
> wrote:
>
>> I never understood the logic of it either. I also expected to be able
>> to do something like {{previous_fields.firstname }}.
>
> Found it!
>
> class EnrollWizard(FormWizard):
>
>def get_template(self, step):
>return 'enroll_wizard_%s.html' % step
>
>def process_step(self, request, form, current_step):
>
>if current_step == 3:
>form0 = self.get_form(0, request.POST)
>form1 = self.get_form(1, request.POST)
>form2 = self.get_form(2, request.POST)
>
>context = (dict(form0=form0, form1=form1, form2=form2))
>
>return render_to_response(self.get_template(self.step),
> context)
>
> And then in the template to display a summary i play with ifequal
>
> {%ifequal form0.course 2%}
> Intensive course
> {%endif%}
>
> {%ifequal form0.course 1%}
> Standard course
> {%endif%}
>
> If anybody has a more elegant solution i'm all ears!
Not sure whether it is more elegant or not, but here goes:
As I understand it, the wizard-class contains an extra_context that
automatically gets handed to the templates. You can modify the
extra_context in the process_step-method, allowing you to add
additional information for each step you go through. Also, as I
understand it, the process_step-method is given a cleaned (correct)
form for the current step, so you can extract information from that
form and put it into the extra_context.
Thus, you could do something like (no changes to get_template):
class EnrollWizard(FormWizard):
def process_step(self, request, form, step):
if step == 0:
self.extra_context['foo'] = form.cleaned_data['foo']
elif step == 1:
self.extra_context['bar'] = form.cleaned_data['bar']
elif step == 3:
self.extra_context['baz'] = form.cleaned_data['baz']
Now, in each template you will have access to more and more additional
information, just like so:
{{ foo }}
{{ bar }}
{{ baz }}
I am not sure exactly how this maps to your example (as I do not fully
understand it), but maybe it could simplify things slightly for you?
Now, if someone could point me to a simple way of combining form
wizards with formsets, my day would be complete... :-)
Cheers,
johan
--
Johan Liseborn
--~--~-~--~~~---~--~~
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: Where is the source code for Practical Django Projects?
On Thu, Jul 17, 2008 at 09:56, Phillip Parrin <[EMAIL PROTECTED]> wrote: > > I don't think the templates for the weblog(coltrane) app are in the > book... atleast not where they should be, in the chapter covering > it > the templates i'm talking about are: > > entry_archive.html > entry_archive_year.html > entry_archve_month.html > entry_archive_day.html Pages 104-107 contains examples of the above, I believe. > and i think this is the same for the link_* templates. I didn't implement the link-part, but it seems some information is available on pages 110-111. I guess "the details is left to reader" regarding most of the link-templates... :-) Also, it seems you have to run the trunk version of django-tagging if you are running Django from trunk, and it seems the trunk version of django-tagging works slightly differently than described in the book, or at least I did not manage to get it working exactly as stated in the book. > - btw great book :D Agree. Cheers, johan -- Johan Liseborn --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Problem with custom manager from blog example in "Practical Django Projects"
I am working through some of the examples from James Bennetts "Practical Django Projects" and I have encountered a small problem. Note that I am not describing the whole context here, so if you have not read the book, you may find it somewhat difficult to answer. In the blog example, we define an additional manager for the Entry-class (called the LiveEntryManager); the purpose is to easily be able to retrieve "live" blog entries only (and skip the ones that are still draft or hidden, saying something like Entry.live.all()). The examples tells us to also add a "regular" manager to the Entry class, but to define them with the live one first, something like: live = LiveEntryManager() objects = models.Manager() Now, doing it like this gives me problems in the admin interface (I am running a fairly recent trunk), in that I cannot view (or edit) entries that are not in the "live" state; AFAIU, the admin interface will use the default manager, which is the first one defined, in this case the LiveEntryManager, and thus I will only have access to live entries in the admin. A simple solution to this is to just reverse the order, putting the "regular" manager first in Entry class. The problem with this is that in a later chapter, where we write custom tags, we write a tag that is able to handle different types of models, and you will want to use the LiveEntryManager for Entry classes, but as the tag should be able to handle different models, you don't know a priori that you are going to deal with an Entry, so in order to only get the live entries in that case, the tag relies on using the "self.model._default_manager.all()" way of getting to the objects. And obviously, this only works if the LiveEntryManager is defined first... So, is there an elegant solution to this, or does it have to get ugly...? Cheers, johan -- Johan Liseborn --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: How do I add the user ID to a template?
On Tue, Jun 24, 2008 at 15:47, Huuuze <[EMAIL PROTECTED]> wrote:
>
> A n00b question for everyone: My base template has a "Welcome
> " section in it. Currently, I'm adding the username (which
> is coming from Django's auth/auth framework) to the template with the
> following bit of code:
>
> {{ request.session.user.username }}
>
> This works, however, it requires me to add the "request" object to any
> return statement that deals with displaying a page:
>
> return render_to_response('somepage.html', {'request':request})
>
> I'm guessing there's a better way to do this, but I can't seem to find
> an answer. Help!
I believe you can use django.template.RequestContext to accomplish
what you want; in your view, do something like:
from django.template import RequestContext
return render_to_response('somepage.html',
context_instance=RequestContext(request))
That will, among other things (and depending on the
TEMPLATE_CONTEXT_PROCESSORS variable in your settings.py) populate the
request-object with a "user" field.
You can read more here:
http://www.djangoproject.com/documentation/templates_python/#subclassing-context-requestcontext
Cheers,
johan
--
Johan Liseborn
--~--~-~--~~~---~--~~
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: User Profile in Admin interface (using trunk)
On Sat, Jun 21, 2008 at 02:46, ristretto <[EMAIL PROTECTED]> wrote: > > Was there any solution to this? I'm looking through the tickets, > wiki, docs, web, and now the source trying to figure out how to get my > profile data saved along with a User in the admin. Anyone have that > working? My situation is the same as this poster's, except I don't > get any error; I just get no profile record created. I never got any suggestions, so I moved to a different solution (using my own form in "application space"); it was not optimal, but it worked well enough for my particular case. I am not yet that familiar with newforms-admin, but I assume it would allow for solving things like this, right? Anyway, it would be interesting to hear if there is some form of solution for this even before newforms-admin. I cannot imagine that we are the only two people that have stumbled upon the problem... :-) Cheers, johan -- Johan Liseborn --~--~-~--~~~---~--~~ 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-admin.py just doesn't go
On Feb 16, 2008 1:46 PM, doNascimento <[EMAIL PROTECTED]> wrote: > I'm on mac OS X (10.4) > Installed the official release (0.96.1) > I've put django-admin.py on my path folder but it's not working when I > use Python before it. (I get Python couldn't open ...) I believe you need to do one of two things: *either* you make sure that django-admin.py is on your path (so that when you do e.g. "echo $PATH" in a shell, one of the directories listed should be where you have django-admin.py). Then you also need to make sure that django-admin.py is executable (by setting the x-flag of django-admin.py; if you do "ls -l django-admin.py" in the directory where django-admin.py is located you should see something like "rwxr-xr-x" in front of django-admin.py; if there are no x:es, you need to set the x flag by doing someting like "chmod u+x django-admin.py"). When you have done this, you should be able to run django-admin.py from whichever directory you are in (given that you have a working installation of python that is, but it seems you already have that). *or* you run django-admin.py using the "python" command; in this case, you have to give the full (or relative) path to django-admin.py, as the python command will not use your PATH setting to locate files. Me personally, I usually create a "bin" directory in my home directory, put "/Users/" in my path, and put symlinks to whatever scripts or stuff I want to be able to run directly from the command line. Regards, johan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Using the sites-system with a twist - is it possible?
On Fri, Feb 15, 2008 at 2:31 PM, Dj Gilcrease <[EMAIL PROTECTED]> wrote: > > On Thu, Feb 14, 2008 at 12:41 PM, Johan Liseborn > <[EMAIL PROTECTED]> wrote: > > I tried your suggested approach, wrote a small middleware class, and > > I actually got it working quite quickly, thanks! > > > > The thing I am thinking about now is if there is a way to make the > > filtering part more "automagic" (like I think the sites-stuff does > > it); I was looking at custom managers, but it seems I cannot really do > > it like that, because the filter criteria needs to be known when you > > define the custom manager, whereas my filter criteria is only known at > > run-time, when a specific request hits the server. (What I am worried > > about is that I will forget to do the filtering for a view and > > accidentally return too much data.) > > Should be able to do this relatively simple within the middleware your > created by following the example @ > http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser to get > the current user outside a request, you just adapt it to get the > current site outside a request. Then your Manager looks something like > http://dpaste.com/35305/ Sweet, thanks! I managed to use the stuff you provided to accomplish what I want; now, in views, I can just use Foo.object.all() (or similar) and the returned set will have already been filtered according to the "domain" of the user. Now I only have to figure out exactly what it is I've done... :-) I guess the principle is that a single request/response always runs in one and only one thread, so therefore I can tuck stuff away in thread local storage and access it down the line during the same request/response "cycle", right? Thanks again! Regards, johan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Using the sites-system with a twist - is it possible?
Malcolm, Thanks for your reply! On Thu, Feb 14, 2008 at 2:55 AM, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Wed, 2008-02-13 at 14:52 +0100, Johan Liseborn wrote: > > > while my requirement seems to indicate > > that the "site" (or pseudo-domain) should be decided by the logged in > > user rather than the domain name, so I am a bit pessimistic that I can > > accomplish what I say above, even though the two use cases seems very > > similar data-handling-wise; please tell me I am wrong... :-) > > Well, they're similar in that different access paths see different data, > but that's pretty much everything in web land. The Sites framework is > one level at which these access paths can be controlled. You want to > control it at a different level: per-request. > > If I was going to be doing this, I'd almost certainly just write up a > quick middleware that ran after the authentication middleware on the > request path and set an attribute on the request object indicating the > "site" (in your model) to use for further lookups. Then it's just a > matter of filtering lookups with that restriction each time. Needs a > little thought, depending on what you're doing, but certainly possible. I tried your suggested approach, wrote a small middleware class, and I actually got it working quite quickly, thanks! The thing I am thinking about now is if there is a way to make the filtering part more "automagic" (like I think the sites-stuff does it); I was looking at custom managers, but it seems I cannot really do it like that, because the filter criteria needs to be known when you define the custom manager, whereas my filter criteria is only known at run-time, when a specific request hits the server. (What I am worried about is that I will forget to do the filtering for a view and accidentally return too much data.) Anyway, I'll keep at it and see what I can come up with; any additional input is always appreciated! Thanks! Regards, johan --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Using the sites-system with a twist - is it possible?
Hi all, I am trying to figure out if I can use Django's sites-system in a small experiment I am conducting. Please bear with me, as I am still struggling to fully understand the sites-system. I am using the svn version of Django (currently rev 7106, I believe). I would like to build a site published on *one* address (e.g. example.com) where users can register for something like a "master account" and several "normal accounts" and get their own little sandbox to handle their data (this would be similar to a site, but it would not have its own domain name; let's call this a "pseudo-domain"). The idea, of course, is to handle data for multiple pseudo-domains in the same database, while still disallowing people from one pseudo-domain access to the data of another pseudo-domain. This would be useful for a whole suite of software-as-a-service deployments; e.g. if I where to offer a service of "Family Accounting" (just a silly example), a family would setup a master account (the "administrator") and several normal accounts, and then they could happily start entering their earnings and spendings, resting assured that no one outside their pseudo-domain would see their accounting status. As far as I can tell, the Django site-system relies on the different sites having different domains, while my requirement seems to indicate that the "site" (or pseudo-domain) should be decided by the logged in user rather than the domain name, so I am a bit pessimistic that I can accomplish what I say above, even though the two use cases seems very similar data-handling-wise; please tell me I am wrong... :-) Also, is there a way to play with the sites-system using runserver? It seems you need to have multiple settings-files (which I guess would be simple using e.g. Apache and a bunch of virtual hosts), but it seems I cannot do that with runserver. Kind Regards, johan --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
