Re: Django Forms in HTML 4.01 Strict
Malcolm Tredinnick wrote: >On Wed, 2009-01-28 at 14:33 +0100, Gertjan Klein wrote: >> Malcolm Tredinnick wrote: >> >> I disagree. When I develop web pages (using Django or otherwise) I use >> the Firefox HTML validator extension. This helps me write >> standards-compliant HTML -- a big red cross indicates a problem in my >> page. It is annoying if that big red cross no longer indicates anything >> (there might be problems *I* caused, or it might just be Django stuff). > >You realise that you're effectively confirming what I said, right?. The >big red cross is a cosmetic issue. The fact that it makes precisely zero >difference to the practical matter of how a real-world web browser >processes the page means it's not fatal/tragic. No, I think you may have misunderstood me. The XHTML slash is cosmetic; to my knowledge, all current browsers are capable of dealing with that (thus deviating from what the standard dictates them to do, but practicality beats purity, I guess ;)). However, *my* HTML (as opposed to Django's generated HTML) may contain errors as well, and regularly does. The big red cross in an invaluable indicator that I messed something up, and losing that functionality is annoying. Now, when using HTML as opposed to XHTML, I can no longer see if I did something wrong, as the page is *always* in error (from a standards compliance POV). >Then you'll have no trouble creating a parallel set of form widgets or a >form framework that can handle this and everybody will be happy. :-) No, I have no desire to do such a thing. As I stated before, the practical solution for me was to switch to XHTML. >Or look at the django-html project on Google Code, where various ideas >are being tried out. I did, briefly, and didn't like what I saw. They overcomplicate things, IMHO. I don't want DOCTYPE management, for example. >(you're certainly paid just as much to work on Django as me, for >example). This payment thing comes up regularly here, and pollutes the discussion. I have been using Django for a while, and found it to have good things and downsides (both IMHO). I have not even critisized Django here (yet ;)), just expressed mild curiousity. I don't think I've given you reason to bring up that you're not payed for your work on Django. >Maintaining two copies of everything certainly adds to the workload. I have not suggested such thing though. From a brief look at the source code, it appeared to me that it would be easy to create a setting that specifies whether to include the slash or not, and based on that setting write either " />" or ">" at the end of input tags (and ). However, like I said, I have not researched this thouroughly, and I most certainly have not requested the Django developers to implement this. I may have overlooked more complicated things, and besides, if I wanted this badly I'd try and write it myself and if successfull, attempt to get it included in Django. Regards, Gertjan. --~--~-~--~~~---~--~~ 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 Forms in HTML 4.01 Strict
Malcolm Tredinnick wrote: >In HTML, the requirement for errors of this form ( instead of >), is that the parser *must* recover in a way that forces it to >treat it as "" -- it has to ignore the invalid characters and >recover in a particular, well-defined fashion. Do you have a reference for that? It is my understanding that there is, indeed, a well-defined meaning the SGML specification for HTML: the slash inside a tag introduces a so-called "shorttag". This treats everything up until the next slash as the element's contents. Browsers don't treat it as such, but that is a deviation of what the standard asks them to do, not error recovery per se. >That's why non-validity for HTML, when it's this kind of non-validity >isn't a really big deal. It's cosmetic, rather than tragic. I disagree. When I develop web pages (using Django or otherwise) I use the Firefox HTML validator extension. This helps me write standards-compliant HTML -- a big red cross indicates a problem in my page. It is annoying if that big red cross no longer indicates anything (there might be problems *I* caused, or it might just be Django stuff). As a result, I decided to switch to XHTML when developing with Django -- also not fully standards compliant (the doctype is wrong), but at least when I see a big red cross I know *I* did something wrong... Before I decided to switch and stop worrying about it, I also wondered why Django didn't make this configurable. It didn't seem like a lot of work, but I haven't really researched it. Gertjan. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Admin: design question
Marc Boivin wrote: [queryset method on ModelAdmin] >It is valid, tested and working on Django 1.0. I have it working. It is not >documented, you need to search in the source code to get around it. Ah, yes, it does work -- but not in the way I expected it to! I spent the better part of two hours trying to figure out why the queryset method wasn't called, and wondering if my admin.py was somehow wrong. (The documentation on this at http://docs.djangoproject.com/en/dev/ref/contrib/admin/ could use some more information on how to put it all together, especially if you *don't* want a custom AdminSite, but even if you do.) Anyway, I have found that the *only* time the queryset method is called is on the list page for ProjectCodes. I don't need a filter there! I need a filter on the edit page for Hours instances, but queryset isn't called there. It appears that the queryset method is intended mainly to restrict what a given user can see in the list. Useful for implementing complicated permission systems, but not appropriate in my case I believe. Regards, Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> --~--~-~--~~~---~--~~ 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: Admin: design question
Keith Eberle wrote: >Maybe you can do something similar to what's in this post (using queryset): >http://groups.google.com/group/django-users/browse_thread/thread/c59b3807631d2914/a07cabfb4725447d?lnk=gst=restrict+users+to+their+own+data#a07cabfb4725447d Is that still valid? I can find no documentation for a queryset method on the ModelAdmin class here: http://docs.djangoproject.com/en/dev/ref/contrib/admin/ I added one regardless to my ProjectCodeAdmin class: class ProjectCodeAdmin(admin.ModelAdmin): def queryset(self, request): return super(ProjectCodeAdmin, self).filter( Customer= request.Customer) but it seems to be ignored. (I also wonder -- is this supposed to get called *everywhere* I need a ProjectCode dropdown? Even if there is no Customer on that page, and hence the request? ...) That said, placing it there feels wrong. IIUC, a site-specific admin.py and ModelAdmin instances are ment to tweak the admin interface. Limiting the list of ProjectCodes in the dropdown can be done there, but resticting the allowed ProjectCodes should be done in the model. Doesn't that mean the code now has to be written twice? My biggest worry, though, is updating the user interface if a new or different Customer is selected. I have seen no suggestions yet that admin is able to cope with that without too much intervention on my part... Hopefully that's because people knowing it can, and how, are currently busy with more important stuff like going out and having fun. ;) Regards, Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> --~--~-~--~~~---~--~~ 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: Admin: design question
Steve Holden wrote: >Gertjan Klein wrote: >> However, there is one obvious problem >> here: when editing an Hours instance, the ProjectCode dropdown lists >> *all* project codes, not just those related to the selected customer. >As long as you only want this in th admin, check out the >"ForeignKey.limit_choices_to" attribute. However, I don't know whether >this would give you the correct results where no project code was >specified, and I'm not sure how to do this in general applications yet. Thanks. I have just tried that, but failed. In the model, I don't know how to specify that the result should be limited to an attribute of the instance (e.g., something like self.Customer.id), as there is no self at that point. This may very well be my lack of understanding, I'm just starting with Django. However, that would still only help with saved instances; when creating a new Hours entry, the Customer value will be empty, so the dropdown with appropriate ProjectCodes would be too. So the question remains whether the django admin code helps make this possible... Regards, Gertjan. -- Gertjan Klein <[EMAIL PROTECTED]> --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Admin: design question
Hi,
I am writing a timekeeping app with Django, and have some design
questions. Stripped down, I have a model somewhat like this:
class Customer(models.Model):
Name = models.CharField(max_length=200)
class ProjectCode(models.Model):
Customer = models.ForeignKey('Customer')
Code = models.CharField(max_length=30)
class Hours(models.Model):
Customer = models.ForeignKey('Customer')
ProjectCode = models.ForeignKey('ProjectCode', blank=True)
Date = models.DateField()
Hours = models.FloatField()
That is, the time registration class (Hours) has both a customer, and
(optionally) a project code.
I am currently using the standard admin interface to enter/edit objects,
and it works to my expectations. However, there is one obvious problem
here: when editing an Hours instance, the ProjectCode dropdown lists
*all* project codes, not just those related to the selected customer.
Obviously, I am going to need either a wizard-like interface or an Ajax
solution to fix this. My preference here would be Ajax (to populate the
ProjectCode dropdown based on the selected Customer).
My question is twofold:
- Does the standard admin application have provisions for something like
this?
- Alternatively, is there a change in my design I can make so the admin
interface *can* cope with this?
I'd really prefer to keep using the standard admin for now, focussing on
adding functionality rather than getting the user interface the way I
want it.
Regards,
Gertjan.
--
Gertjan Klein <[EMAIL PROTECTED]>
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
