Re: django.contrib.markup and ReST
On 9/16/2009 2:34, Exe wrote:
>
>> What isn't working with section headers? They seem to be working fine
>> in the cases that I use them...
>>
>> Can you give an ReST example that is failing to render correctly?
>
> Shure. Test program to reproduce problem:
>
>
> from docutils.core import publish_parts
>
> content="""
> TEST HEADER
> ===
>
> test
> """
>
> doc = publish_parts(source=content, writer_name="html4css1")
> print("FRAGMENT:")
> print(doc['fragment'])
> print
> print("FULL BODY:")
> print(doc['html_body'])
>
This is intended behavior from docutils: if the reST document starts
with a header it is considered the "document header" and is
intentionally not a part of the fragment by default. Rather than using
the body the correct approach would be to pass in the proper flag to
disable "document headers" so that the opening.
Rather than switch to the 'html_body', it probably makes more sense for
Django's default template tag to open up a setting to provide additional
flags to publish_parts/docutils writer/docutils transformer, such as the
aforementioned one to disable document headers, or other generally
useful flags such as the ones to enable certain security features.
--
--Max Battcher--
http://worldmaker.net
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Proposal: Better HTML4 support
Simon Willison wrote: > HTML 5 is the > final nail in the coffin - the refocusing of the W3C on that over > XHTML 2 is an acknowledgement that XML is no longer the future of the > Web. I actually think Django's XHTML output makes us look a bit out of > date. I don't think either of those conclusions can be drawn from the facts. XHTML 2 was a bold attempt to redefine what it is exactly that web pages produce: less crud, more content. I'm, personally, a bit disappointed that it has been "canceled", but I assume that smart people will continue to explore concepts in that direction. XHTML 2's cancellation does not say that XHTML 1 was a bad idea or is in anyway invalidated and it absolutely says nothing about XML. (Also, whether or not XML is the "future" of the web, it is a strong part of what defines the "present".) Furthermore, support for XHTML "5" (which is indeed a part of the HTML 5 standard) shows that XHTML 1's principles are still around and still respected. Django's XHTML output can't be "out of date" if XHTML 5 is considered a successor to XHTML 1. -- --Max Battcher-- http://worldmaker.net --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: Better HTML4 support
Simon Willison wrote: > On Sep 26, 10:17 am, Max Battcher wrote: >> Furthermore, support for XHTML "5" (which is indeed a part of the HTML 5 >> standard) shows that XHTML 1's principles are still around and still >> respected. Django's XHTML output can't be "out of date" if XHTML 5 is >> considered a successor to XHTML 1. > > Opinions differ, but in the interest of keeping this thread about HTML > support in Django I'm going to leave that discussion here - let's > assume that it would be a Good Thing for Django should provide support > for outputting both HTML and XHTML, and focus on how we can achieve > that. But I'm not sure that is a correct assertion. I don't think there is a strong enough difference between HTML and the XHTML that Django generates for there to be a need for more complicated mechanisms of rendering. If the only point of contention is self-closing tags (), then HTML 4 might not support it explicitly (although in fact most modern browsers support it implicitly), but HTML 5 (the HTML form factor, not just XHTML 5) explicitly supports self-closing tags: http://dev.w3.org/html5/spec/Overview.html#start-tags Under Section 9.1.2.1 -- Start Tags, I quote: 6. Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS (/) character. This character has no effect on void elements, but on foreign elements it marks the start tag as self-closing. I really don't see what the fuss here is about. If we are worried about forwards-compatibility, HTML 5 takes care of it. If we are worried about better backwards-compatibility with HTML 4, everyone else is saying that the future is now and the focus should be HTML 5... What is this argument really about? -- --Max Battcher-- http://worldmaker.net --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Solving the POST-data-lost-after-redirect problem
Luke Plant wrote: > I'm not sure how useful it is for Mac and Windows users. The middleware > doesn't actually do any validation -- it's done by 'validate' from > Debian's 'wdg-html-validator'. I personally wrap that in a shell > script which beeps and pops up a KDE notification when a page fails. For the notifications you could switch to Jabber notifications. Plus, you get the benefit of free remote notifications and logging... The validator I'm not so sure about. WDG's appears to be Perl, so you could just make Windows/Mac users install perl. -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Generic Relationships/convert_post_data in forms
Ian Holsman wrote: > Hi. > > I working on integrating the new GenericRelation field that was > recently committed and making into into a 'tag field' where a user > would just enter > a list of strings into a single text field. Have you seen Ivan Sagalaev's tag model? It needs updating to support the new GenericRelation (it currently uses a similar but proprietary clas), but it has a very neat Tag widget for the Admin. http://softwaremaniacs.org/soft/tags/ -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: specifying newforms-admin options
On 1/25/07, Lachlan Cannon <[EMAIL PROTECTED]> wrote: > The reason I don't like this is it still leaves models tied to admin, rather > than the other way around. If someone wants to not have the admin displayed > for > a particular app, it should be as easy as deleting or renaming a file, imo, > you > shouldn't need to change it in other places. The problem with that is that there is a good amount of description per model (list_display, et al in the current inner class) that I would hate to have to move to other files because I think it mentally makes sense to keep with the model because: a) It's "meta-information" on the model itself and b) it's "meta-information" that yes is currently 95% used by the Admin but can be just as useful to other applications. I've certainly felt that smarter versions of the list_detail generic views might take into account list_display and list_filter. Perhaps I'm just an old fogey on this issue, but I'm certainly not yet convinced that entirely moving what's currently in the Admin inner class is a good idea. Better theoretically perhaps, but from a practical standpoint I'd certainly rather not have this information in two separate files when it 95%+ of it is descriptive model-level information. I can understand, at a project level, if I think I'm becoming too dependent on the Admin refactoring that data into separate files, but forcing it from the start gets us closer to the slippery slope of scaffolding magic... > My suggestion? > > ADMIN_MODEL_FILE = 'admin.py'; set to this by default so most people won't > even > need to think about setting it themselves -- but is is settable if someone > really wants to change it. [snip] > How does this sound? Yuck. -1. Too much magic. Create an admin.py for some other purpose and watch as errors crop up or things start working differently in other applications. Worse, this should solely be Python relative dot notation so the above would become just ADMIN_MODEL_MODULE = 'admin', which then adds the possibility, until everyone standardizes on the new relative dot notation, of huge blow ups if you choose to name a project, application or already happen to have an existing Python library named admin. For new users trying to use the Admin app you are effectively either going to have to hand-hold them hugely through the process of "create the magic named file, add these incantations, pray no errors are returned" or you scaffold these files for them and then hand-wave around it like those other guys do when it comes time to do a screen cast. Magic-named inner class is more than enough as it is. -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: specifying newforms-admin options
On 1/25/07, Lachlan Cannon <[EMAIL PROTECTED]> wrote: > There's no reason values useful for more than admin can't be stored in meta. > There's nothing to stop admin reusing model wide metadata, but it shouldn't be > polluting the main model file with its own specific settings. No problem. I agree that decoupling is a worthy *goal*. But I'm certainly going to need convincing to drop the current, practical, declarative approach for another purely on theoretical beauty. What effort does moving admin stuff into a different file gain me? How much effort am I going to need to upgrade just to fit with your "better academic approach"? Those are my arguments here. I certainly see no reason that many current uses of the inner-Admin class need deprecate at all. It's certainly OK in Python for a duck-test... if there is something resembling (looks, smells, quacks like it) an old "static inner Admin declaration", the Admin could do its best to follow it. Basically, someone needs to play advocate for all the poor people that might look at the migration path for this change and think "this is Magic-Removal all over again". Particularly with the Meta -> Admin switcharoo that's still fresh in some people's minds. > Obviously I haven't explained this well enough. Admin would look for the > admin.py file in the app, and then it would use any classes in the file that > inherit from AdminBase.. as Adrian is doing things already, if I understand > correctly. You could do whatever else with the file you wanted; you could have > an admin.py file without any adminbase inheriting classes, and it'd all be > left > alone by admin. Unfortunately Python doesn't work that way. Imports and import attempts have side effects in current versions of Python. You cannot just iterate through every "admin.py" file in a project and hope that there aren't any errors or conflicts you just opened up. Not to mention that in mod_python and similar setups every import you make has a long term impact on memory usage. Model loading is the only thing I can think of that "vacuums" in a large number Python modules in that way and adding a second solely for the Admin application quite possibly could anger a lot of potential Admin users. > I don't see how this is 'magic'. Magic, as discussed here, is all about doing > things implicitly.. assuming what the user wants. Allowing the admin file name > to be set and overridden is the exact opposite of that -- it's setting things > explicitly, with sensible defaults. No, it's not. Sure you have 1 explicit setting that you might remember in a year has an effect on the process when you are trying to debug that subtle but unfortunate bug, but you are sucking in a lot of excess data from a single setting, and there is very little precedent for that. In most cases Django settings are precisely focused: DJANGO_SETTINGS_MODULE points to a single module and so does ROOT_URLCONF. Keep in mind, I pointed out that the least vile approach I've seen so far is using an setting that defines Admin models on a per-model basis. It's not the cleanest, but it's certainly precisely explicit and I can think of several utility functions I might write to remove a majority of the tedium from editing that list. Any ADMIN_MODELS setting should follow the example of ROOT_URLCONF or the aforementioned plan and point to a either a list of specific classes or a single specific module. I still don't think either is the best possible approach, and I certainly think that there is still good enough reason to leave the majority of my projects' admin information where it currently resides, but I'm willing to be convinced. > Again, no errors because admin only cares about its own classes. And creating > an > admin.py file is surely no harder than creating a urls.py, etc., for your app. As I said, in the case of Python as it currently exists it is unbelievably easy to trigger odd bugs and weird errors solely due to importing one more module than you expected. It's unfortunate, but it is simply the case that Python runs code in a module on import whether you "only care about certain subclasses within the module" or not. Module import and module introspection have prices, even if as a dynamic language there is certain ease of doing such things. -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Looking for a Django Developer (web based feed aggregator)
Have you seen Feedjack (http://www.feedjack.org/)? On 2/26/07, Tixx <[EMAIL PROTECTED]> wrote: > > Hi, > I'm looking for a Django developer who help us with the development of > a feed aggregator based on Django and Universal Feed Parser. > > Thanks. > > Best Regards, > Tiziano. > > > > > -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Possible enhancement: CGI-style population of os.environ
On 3/11/07, James Bennett <[EMAIL PROTECTED]> wrote: > > On 3/11/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > [Insert standard rant about components intended to be reusable that do > > not provide an alternative way to specify the environment. Makes testing > > kind if hard. Their developers are probably cruel to small animals as > > well.] > > :) > > In this case it's not so bad -- I'm working on unobtrusive ways to > hook Akismet into the comments system, and the Python Akismet module > looks in os.environ for request info (which is good, because there's > no way my code can pass it request information without having to hack > the comments app, and I'm trying to avoid that). > I'm happy with my solution hooking Akismet in. I just copied the post_free_comment view into a new views file in my application and then use a custom comments URL pattern, just as you might switch from a generic view to a wrapper on a generic view as needs change. I like my solution and don't consider it a "hack". Right now I have to diff my version of the few with updates to the comments app, but only because I haven't taken the time to refactor the view to try to remove most of the redundant code. (In looking over it for the first time in a while it looks like I could get away with just modifying request.POST["options"] and request.POST["gonzo"] and then calling the normal view.) Anyway, I think my suggestion is that in this particular case maybe the better approach is to push for better genericity in the Comments app (particularly as it gets rewritten and better documented)... If you are curious, I'd be happy to post my post_free_comment view. -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: contrib proposal: django-values
On 4/8/07, Gulopine <[EMAIL PROTECTED]> wrote: > > > * The name "values" is a bit too abstract -- it took me a while to > > figure out exactly what this framework *does*. Maybe something like > > "editable constants" or "model-specific options" would be more clear. > > I will admit that I never really had a clear idea on what to call it. > I knew going in that it would be hard to describe, and I couldn't > think of a clear phrase that adequately captured it. The best I had > come up with was "run-time value configuration" which still isn't > really a good one. I had personally avoided the term "constants" since > they are in fact editable without a restart, but from a programming > standpoint, they function just like constants, so I wouldn't be > completely opposed. It's a magic numbers (avoidance) framework. I know this is going to sound like a joke, but what about calling it django.contrib.magic_numbers? -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: newforms: custom error messages
On 4/8/07, Ceph <[EMAIL PROTECTED]> wrote:
>
> There's an open ticket currently regarding custom error messages in
> newforms: http://code.djangoproject.com/ticket/3457
>
> I currently have an ugly hack in place that gives me an error_message=
> parameter for the field types I use, but, it's ugly, and doesn't work
> entirely. I'm working on getting a real patch done for this, but have
> some questions/roadblocks.
>
> How do we want to handle field types that have multiple error
> messages? For instance, IntegerField has a "max" message, "min"
> message, and "required" error message. I don't really like the idea of
> three named parameters max_error_message, min_error_message,
> error_message, but I can't seem to come up with any easier solutions.
You could use a dictionary for that. Something like:
error_messages={
'max': '...',
'min': '...',
'required': '...',
}
--
--Max Battcher--
http://www.worldmaker.net/
All progress is based upon a universal innate desire on the part of
every organism to live beyond its income. --Samuel Butler
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---
Re: database connection user - newbie question
On 5/9/07, foobarmus <[EMAIL PROTECTED]> wrote: > > I'm managing a programming team that's developing a web app in python. > I'd like to be using Django but can't at the moment because one of the > things we are doing is driving the application user into the database > connection, so that we can implement access control at database level. > > I would like some opinions on this practice. I think it's important. I > don't understand why frameworks like Django don't allow for it. It is > not difficult to do. > > Is there some popular wisdom on this issue that I haven't been exposed > to? Yes. The conventional wisdom that everyone "should know" is never to use such web to database pass-through authentication for anything bigger than an intranet application behind corporate firewalls/VPNs. There are huge security concerns with any sort of pass-through authentication, and putting a pass-through authentication into a public-facing website is just asking for crackers to sit there and pound your site for any and every SQL injection they can think of. Pass-through authentication *can* be just as devastating as allowing direct remote connections to your database. If you are willing to _meticulously_ audit every security implication then good luck. For a general purpose framework like Django adding support for this without big flashing warning signs and a general "HERE BE DRAGONS" on the big map of Django features is not a good idea and a good way to singe people's fingers. Furthermore, for the majority of cases this sort of database authentication is overkill and bad for performance (instead of maintaining one long session with the database per thread the framework has to back out and deal with database sessions per request which just reeks of early (pre-auto-session-magic) bad PHP applications). Unfortunately it's a bit late and I can't scrounge up some good links on the subject (hopefully someone else can follow up with those), but I hope that I at least have illustrated at least the conventional wisdom with a few smudges of reasoning... Regards, -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Changeset [5231] -- do_clean_*() is awkward naming
On 5/14/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I think we should try to stay with the "cleaning" line of thinking, > rather than validate- or normalise-related terms, just for consistency, > though. Sounds like time to visit Ye Olde Thesaurus... Off the top of my head: scrub or wash are very useful clean-connected words. -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: apps with the same name
Joseph Kocherhans wrote: Any ideas that don't involve 50+ character table names and 10 level deep template directories? ;-) What about application relabeling? Just like you might do a python ``import something as somebettername`` when there are conflicts across namespaces or you just want something nicer in your actual code, you could just add an "as" option to INSTALLED_APPS to specify an app name. -- --Max Battcher-- http://www.worldmaker.net/
Re: Documentation as a single download
Simon Greener wrote: OK, thanks for confirming this for me. I had seen the docs but simply didn't know their relationship to those on the site. Anyway, the ones on the site are easier to read which is why I asked if they could be downloaded all in one hit rather than having to File>Save As (as I have done for previous ones). If you want the nice inter-hyperlinked HTML you can download the tools from http://docutils.sourceforge.net/ and use the command line tool ``buildhtml.py`` included in the package's tools directory. -- --Max Battcher-- http://www.worldmaker.net/ "History bleeds for tomorrow / for us to realize and never more follow blind" --Machinae Supremacy, Deus Ex Machinae, Title Track
Re: appache and pthonpath
[EMAIL PROTECTED] wrote: my Django proeject is not in the sitepackages it is in /var/www/mysite First of all, it isn't a good practice to store a python web application under /var/www. This can pose a potential security risk. PYTHONPATH "['/var/www/mysite']" Could be you are looking for: PythonPath "['/var/www/mysite'] + sys.path" > DocumentRoot /var/www/mysite/ This also isn't a good practice, as again it can pose a security risk that is better off avoided. -- --Max Battcher-- http://www.worldmaker.net/ "History bleeds for tomorrow / for us to realize and never more follow blind" --Machinae Supremacy, Deus Ex Machinae, Title Track
Re: magic-removal: "Change subclassing syntax"
Jeremy Dunck wrote: This makes me think the world needs a wiki whose wikitext syntax is restructured text. Anybody know of one? I've seen a home-brew Zope-based one. It would be real quick to build one as a django app... In fact its own my personal project todo list. How soon do you want it? :-) -- --Max Battcher-- http://www.worldmaker.net/
Re: magic-removal: "Change subclassing syntax"
Joseph Kocherhans wrote: The wiki doesn't say a whole lot about it, although it's probably in someone's brain ;) I'm wondering about the ETA of this as well. I could use a good subclassing system for my project *today*, particularly because as far as I can tell the One-To-One relationship is currently broken (broken default ordering; no way to order a class in the admin based upon a join; broken generic object_detail view). (Like many, I need a subclass of ``django.contrib.auth.models.User`` for site-specific data.) -- --Max Battcher-- http://www.worldmaker.net/
Re: magic-removal: "Change subclassing syntax"
Maniac wrote: Jacob Kaplan-Moss wrote: If I ask for places, give me a list of places and don't bother looking up restaurants. So:: ``place_instance.description`` should raise an ``AttributeError`` regardless if weather or not it is actually a restaurant. Why? This is not how duck typing works all over the Python: if the object does have an attribute you shouldn't do nothing special (like casting) to get it. Agreed. Instead, I think the explicitness Jacob wants should actually be a factor of the Manager class in question, particularly because the biggest impact is on the amount of database work involved (to join or not to join). Maybe the default manager doesn't join, it just returns everything in terms of the class that it is attached to. But you could explicitly create a "PolymorphicManager" that can (and does) join subclassed models. Something like: `` app_objects = managers.PolymorphicManager(Place, Restaurant, ItalianRestaurant) `` This also makes it explicit which classes are participating in a join, rather than potentially joining a large number of installed model classes. -- --Max Battcher-- http://www.worldmaker.net/
Re: Django auth magic
Joseph Kocherhans wrote: On 2/3/06, Jonathan Daugherty <[EMAIL PROTECTED]> wrote: # I think this would be cleaner if there were an authentication # utility (just a class probably) that you could switch by changing a # setting. Something like AUTH_UTIL = 'myauthmodule.LdapAuthenticator' I think it's also worth noting that this won't work if you ever want to try a sequence of authenticators. I'm concerned particularly with OpenID authentication, and OpenID auth is usually tried in addition to whatever is desired for the site's normal accounts, in which case authentication mechanisms must be able to coexist. I didn't mention it, but I thought it ;) This would still allow you to check multiple sources, but you'd have to write a wrapper to do it for you. The other possibility would be to use a tuple or list of authenticators. I'm fine with just writing a wrapper myself. It makes sense to do it as a tuple as the AUTH_MANAGERS or AUTHENTICATORS is going to be similar to MIDDLEWARE or TEMPLATE_LOADERS. This actually makes quite a bit of sense to me: the need for an API like Middleware to allow cascaded authentications. In this case you'd probably want "auto-groups" based on the authentication scheme (I'm thinking there needs to be a way to "suggest" population for a User class and/or subclasses and permissions/groups... I'm just not yet sure how to do it nicely decoupled). For instance, LDAP authenticated users are going to be "more trusted" initially then OpenID-authenticated users, at least on the first that user is "verified" in some manner. (OpenID you get the further situation that you'll have varying trust levels for different DNS paths too.) LDAP authenticated users are also going to have a directory's worth of User information where OpenID aren't going to have anything beyond a verified URL. I think I might look things over as I'm thinking about maybe chipping in that OpenID Authenticator. -- --Max Battcher-- http://www.worldmaker.net/
Re: How about converting python config files to text config files
limodou wrote: >> The addition of an extra line in the installed application list of >> settings.py is only a one line change - so again, I would argue effort > >> need. > > Maybe it's simple, but what about install an app? You should modify: > > settings.py > urls.py > copy media files to special directory > > I want these things can be done easily. For example, I download a > third app, and want to run with it. If I could only supply some > parameters about my environment let things easily be done, that will > be so happy. But if there is a tool for this thing, it may need to > modify the settings.py and urls.py automatically according to the > parameters supplied from you. If I were to build such a thing, and I'm like most everyone else in that I don't see a use for it, I would probably just simply start modifying them in memory and then Pickling_ the Settings module and URL patterns. .. _Pickling: http://docs.python.org/lib/module-pickle.html -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: How about converting python config files to text config files
limodou wrote:
> Using pickle is more harder to modify by hand.
You can always Python shell, load pickle, change, save pickle. Not that
much more different than load text editor, change, save and quit text
editor.
Or you could load the pickle and then check for changes in the text file.
Or you could do whatever else came to mind that didn't require framework
changes and could make use of the fact that the settings file is just a
Python script that can have arbitrary code or be introspected by some
other outside code. Not to sound rude, I don't really care enough to
come up with a good solution to make you happy. ("Not my problem", "I'm
not going to need it")
> Ok, you don't know how
> an automatic tool is useful, so I'll ask you: is django-admin.py
> useful? is manage.py useful?
My honest opinion (and I apologize for a brief rant) is that these are
both useful and hindrances. My biggest turn off when I saw Ruby on
Rails was the *huge* reliance on automatic scripts. No thanks. I think
that anything that requires such an automatic tool isn't well automated
in the places that count (the abstractions and framework level).
That isn't to say that I don't use manage.py, but that I want to make
sure that I can do everything manage.py can do myself and I know exactly
what it is doing at every point in its operation. When its my source
code at stake, when I need to know every corner of the code in case of
bugs and defects, I'm very wary about any automated tool.
I really like the fact that a similar philosophy has been taken in the
development of Django's manage.py (versus what it might have been) and
that magic-removal has furthered removed some of the reliance on the
tool. (I don't use startapp, for instance.)
> These are also automatical tools, but
> they can do only separate task, but not many serials tasks.
Uh, I can certainly do "serial tasks" with manage.py... I have access
to several available tools such as my Operating System's command scripts
and I know that I can even write a Python script to run through a small
list of manage.py actions.
> I also
> want you assume once you need to install many apps to an existed
> django site, how to do that? Maybe these apps have different
> directories or different deploy requirements.
>
> So how to do that? If we has a deployment specification which
> describes what things need to do for an automatical deployment tool,
> and also supply a standard automatic tool and starndard APIs, install
> apps may be simple. Then writing a corrrect installation script
> belongs to the author of the app. For an end user, what he need to do
> is just supply a environment parameters, and run the installation
> script, so everything is automatically installed correctly. If that is
> true, I may laugh in sleeping.
Maybe we should look at assumptions: I don't see individual
applications as "end-user deployable", I expect individual components to
be pluggable components in an overall Software Design to be installed
and tested by someone knowledgeable. I don't expect my applications to
be seen from the same URL scheme, I expect the install-person to decide
that.
What I see as the "end-user deployable" solution is a connected Project
of applications with a designed URL configuration and settings
configuration, and from what I've seen and done these are deployable
easily enough.
This also more closely mirrors any other website deployment style you
might find.
So again, the existing work is perfect for my needs, and what you are
asking for is a huge change with little/no gain for me.
--
--Max Battcher--
http://www.worldmaker.net/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers
-~--~~~~--~~--~--~---
Re: Some suggestion about date_base generic view function
Ken Kennedy wrote:
> Yep...I'm actually dealing with that today. It's instead only returning
> a list of datetimes that represent the months within that year that
> contain objects. (ie, if it's a blog, and you have posts in Oct-Dec of
> 2005, then the date_list would contain datetime objects for Oct 1st,
> Nov 1st, and Dec 1st, representing the months that have objects). I
> guess the assumption within the framework here is that the year is a
> stepping stone to the month...too many objects at the year level, so
> they just give you the months to build URLs from to get to the
> archive_month view easily. I'm not thrilled with it either. *grin*
Of course, that's when you break out and write your own view. (I needed
to write my own views anyway because I needed a full calendar and the
archive_* views filter out "future" dates anyway, though.) For
instance, I thought it would be cool to have "major" object float to
this year page, so I wrote that as view, and that is based wholly on a
model-specific judgment that can't easily be expressed in a generic view.
On the other hand, the code I just wrote to yield a month calendar grid,
instead of just a list of objects, is a bit more useful/generic.
> I have a related issue...now that I have the datetime date_list of
> months, I try to iterate over it, and it's being treated as a string:
>
> print date_list gives me : [datetime.datetime(2005, 1, 1, 0, 0),
> datetime.datetime(2005, 3, 1, 0, 0)]
>
> for month in date_list, though, gives me
> 'str' object has no attribute 'month'
>
> So it's treating date_list as a string, rather than a iterable list. I
> know that "free" access to the datetime module is being removed in
> magic-removal, but I'm at rev 1811...have I somehow gotten caught in
> betwixt something? How/where do I import datetime; I'm using a generic
> view.! Or is there something I can add in the template that I'm missing
> (or something else silly that I'm missing *grin*)
You shouldn't have to import anything inside a template or generic view
that either don't already have access to. Also, the "free" access
didn't affect templates to begin with, it was something that model
classes got.
As for your error, it sounds like Django may be misleading you, here.
The error templates don't generally highlight the correct line for
variable lookups( {{ }} ), and instead highlight the containing template
tag ( {% %} ). It sounds like somewhere below you are trying to do {{
month.month }} Keep in mind to iterate the months you need something like:
{% for month in date_list %}
{{ month|date:"F" }}
{% endfor %}
The date filter being the only way to get information from a date time.
--
--Max Battcher--
http://www.worldmaker.net/
"History bleeds for tomorrow / for us to realize and never more follow
blind" --Machinae Supremacy, Deus Ex Machinae, Title Track
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers
-~--~~~~--~~--~--~---
Re: Database migration practices?
xamdam wrote: > No, I am talking about altering the DB schema of your app. (I started > off withthe noMagic branch, so there is nothing to migrate) Right now there is no automatic way to do schema migration, as it's a very serious thing to do (ie, do you want an automatic tool potentially destroying your data?). The assumption is that you should be able to come up with the SQL ALTER statements yourself. Basically, you probably want your db's SQL manual close at hand and use a development database to test changes on. The manage.py sql* commands are also your friends to show you what the final schema should be. -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Proposal: Validation-aware models
Nebojša Đorđević wrote: > On 2006-02-22, at 11:18 CET, hugo wrote: > >> I would propose to instead do validation in those situations where the >> data is moved to the external storage - on .save() (or in the >> unit-of-works .save() if we have them). That way you can happily >> create >> invalid objects, but you will be forced to make them valid to save >> them. An additional .validate() method could be introduced that will >> trigger validation without saving to allow programmers to do early >> validation if they need to. > > I'm definitely +1 on this, when I'm looked trough my current code- > base I found lot's of examples of creating invalid objects and later > (before .save()) adding required data to make it valid and (as > someone else also pointed out) I have more than few cases of mutually > dependent fields which can't be changed in one property access. I have one script that intentionally causes validation failures (it auto-populates a slug field, based on data it is marshalling from an outside source), that I want to make sure I have the ability to turn off validation to leave the script an automatic process (slug ambiguities are easy to correct in the admin). -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: tracking people
Mary Adel wrote: > is their a way to track the people that visit my website using Django > cause i know that Turbogears has this functionality If you are running on top of Apache, why reinvent the wheel? Grab an Apache log viewer like AWStats. -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: urlconf, applications..coupling
gabor wrote: > i actually got around this problem by adding the project-dir to the > PYTHONPATH, but it seems a little as a hack... I'd have to disagree. I don't think it's a hack at all, as far as I'm concerned it makes sense if you think of the project directory as a "library namespace" (you don't expect the django framework itself, or any other Python library, to drop their namespace when you start using them in your own project, do you?). -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Change logs on the recommendations
limodou wrote: > Django is developing very quickly, so many things to catch up. > Has anyone written a change logs let us know the latest changes you. There are always the auto-generated sort, such as: http://code.djangoproject.com/timeline/ http://code.djangoproject.com/log/ -- --Max Battcher-- http://www.worldmaker.net/ "History bleeds for tomorrow / for us to realize and never more follow blind" --Machinae Supremacy, Deus Ex Machinae, Title Track --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: What if instead of calling them "projects" we called them "sites"?
On 3/2/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > My initial thought is that I'm -0 on the proposal, since I'm not sure it > makes that much of a difference. It is kind of logical, since a project > is a collection of applications and the configuration that ties them all > together. But, inuitively, I think of a "site" as something more > specific still, but I'm not really sure why it is that different. I am > also not convinced that somebody capable of developing in Django is > going to be able to understand "site" and not "project". Let's give our > users some credit. Particularly if they are programmers. Most coders are going to understand the term project, keep in mind that several major IDEs (Visual Studio, among others) make use of the term Project. (In VS, for instance, in developing an ASP.NET website using a Solution of Projects.) Keep in mind, too, that not all Projects are Sites (and vice versa as mentioned in the Ellington example). I've got at least one Project that I feel qualifies more as a Library, whose applications are often much more useful in conjunction with more site-specific functionality built on top. -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: templates and html escaping
On 3/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Jacob Kaplan-Moss wrote:
>
> > Why not do it for all variables? At times you want to pass chunks of
> > HTML into a template that get displayed raw. I don't think the
> > behavior you suggest should be default, but do you have any ideas on
> > how to make it optional?
>
> the standard solution is to use a wrapper for strings that you
> *don't* want escaped. see e.g. the section on "HTML templates"
> on this page:
The other problem is that not everyone wants the same escape. For
instance, there are those of us that {% load markup %} and then
|restructuredtext (or |markdown or |textile) just about everything,
and auto-HTML escape could certainly cause havoc here.
--
--Max Battcher--
http://www.worldmaker.net/
All progress is based upon a universal innate desire on the part of
every organism to live beyond its income. --Samuel Butler
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers
-~--~~~~--~~--~--~---
Re: Finalizing descriptor implementation
On 3/6/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > I think that if the foreign key is None (for whatever reason), then > __get__ should return None; otherwise it should expect a valid > reference to exist and raise DoesNotExist. (For template authors, > note that DoesNotExist exceptions are swallowed silently by the > template engine so you don't have to worry about being bitten by this). Speaking of which: right now the Template engine isn't swallowing the Descriptor's DoesNotExist. I mentioned this and posted a patch: http://code.djangoproject.com/ticket/1396 Basically, resolve_variable() isn't checking for silent_variable_failure for attribute/property/descriptor lookups (it was only checking for that on callable). -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Validation-aware models: First stab
limodou wrote: > Reasons sound very reasonable. But I think current implement in django > is enough. Maybe model with validation is better but unnecessary. We > have many ways to validate data before it saved in db. Any Security Foil-Hat will tell: Validate early and validate often. It makes no sense for a good ORM to allow someone to save data that breaks database constraints, without jumping through a few hoops (validate=False) if you expect a secure ORM. It makes perfect sense that at least basic data validation should be implemented in models, and it *is* a necessity to anyone security-minded. -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Validation-aware models: First stab
limodou wrote:
> On 3/14/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>> On Tue, 2006-03-14 at 09:34 +0800, limodou wrote:
>> [...]
>>> -1 I agree with gabor. Many orm models don't process validation, and
>>> these things should be implemented by manipulator. Why do so much
>>> things in model?
>> This isn't really an argument, though. Other systems working differently
>> is not a reason why Django should not work in the way Adrian described
>> ("other systems are not blue like this, they are red. So blue is no
>> good.") Why do you see it as bad that it should work this way? What are
>> the arguments against doing this in the model (which is a representation
>> of the data structure and so not a completely illogical place to work
>> with the data)?
>>
>> Malcolm
>>
>
> because I think manipulator can be standalone separated from the model
> and maybe someday the orm can be designed as an interface, so that we
> can use other orm module to replace django orm.
>
> If you don't want, and the model becames more and more rich, so these
> things maybe not be separated any more.
The current proposal leaves Manipulators (custom forms rely on them,
they are not going away), and validation at model level is simply yet
another defense in a long line of defenses.
--
--Max Battcher--
http://www.worldmaker.net/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers
-~--~~~~--~~--~--~---
Re: Validation-aware models: First stab
Gábor Farkas wrote:
>> Thoughts, criticisms? The only part I'm sketchy on is the side effect
>> of converting the values to their Python data types. The
>> cleanliness/consistency is quite nice, but it's slightly not something
>> a developer might expect. However, we can solve the latter through
>> clear documentation.
>
> >>> p1 = Person(name='Joe', birthday='2005-1-3', favorite_number='foo')
> >>> p2 = Person(name='Jack', birthday = datetime.date(2005,1,3),
> favorite_number='foo')
> >>> p1.birthday == p2.birthday
> False
>
> i don't know. i understand that this would make life easier, but on the
> other hand, it does not feel good for me :) some points:
>
> - explicit is better than implicit
> - we're removing the magic there or adding it back? :-)
> - does this not tie too much the web-layer to the db-layer?
>
> basically.. what does the developer win with the auto-conversion?
> perharps some use-case scenarios would help to explain it to us...
>
> summary:
> it's a very cool change. i'm just not sure about the auto-conversion part.
I'm going to agree with this. At the very least I think a developer
should *always* expect a field on field __get__ to return the Pythonic
type. Under the proposal this would probably mean an implicit
``to_python`` call and half-verification on field __get__, which sounds
un-Pythonic.
Here's a suggestion: abstract the string->python into a field function.
Consistently require Python types, but allow the string unmarshalling
through something like:
>>> p1.birthday.from_string('2005-1-3')
This is clear and explicit, albeit potentially wordy. It would not
allow complete stringified Constructors, but you could easily enough
create a "shortcut" tool. I think this may actually be more suitable
for the Manager class:
>>> p1 = Person(name='Jack', birthday=datetime.date(2005,1,3),
favorite_number='foo')
>>> p2 = Person.objects.html_unmarshal(name='Joe', birthday='2005-1-3',
favorite_number='foo') # convert strings to Python types
>>> p1.birthday == p2.birthday
True
This then makes it possible to change things like locale-based
unmarshalling (or other unmarshal situations, such as importing from
object-db systems or what have you) by overriding the system-wide
default Manager.
--
--Max Battcher--
http://www.worldmaker.net/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers
-~--~~~~--~~--~--~---
Re: proposal: endif, endfor etc assume whatever follows in tag is comment
Tom Tobin wrote:
> On 3/13/06, Kieran Holland <[EMAIL PROTECTED]> wrote:
>> I don't like the idea of arbitrary content in template tags either but does
>> your "definite no" also apply to this old idea:
>>
>> {% endif %}{# endif start_process #}
>>
>> I think comments should be encouraged in templates and the
>> comment/endcomment tag set is almost prohibitively verbose at times. HTML
>> has special tags for comments too, so I don't think it is too programmerish.
>
> +1 -- I liked this idea when it first came up, and I still like it.
> :-p Comment syntax shouldn't be judged by the same rules as other
> programmatic constructs; comments should be easy to throw down (and
> remove) rapidly in any text editor, and I can't help but think that
> the current comment syntax lends itself more towards use in an IDE
> than vim, emacs, or [insert your favorite editor].
Agreed, current syntax is too wordy (thus, I'm not using it). Another
option would be to use something closer to HTML comments, as all
designers should recognize HTML comments, so something like:
{}
or:
Themes on the pattern of the first example.
{< This is a comment >}
or:
{! Comment !}
I think I'm +1 on this last one. It evokes the aesthetic of both the
Django template tags and an HTML comment. It is also very readable and
less programming-language looking and blocky than {# #}.
--
--Max Battcher--
http://www.worldmaker.net/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers
-~--~~~~--~~--~--~---
Re: Multiple Authentication Backends
Joseph Kocherhans wrote: > I've rethought how to implement multiple authentication backends, > updated the wiki and posted a new patch. This should be a lot simpler > than the previous attempt. Please check it out, and post your comments > to the list rather than the wiki. Also, question for Jacob/Adrian, is > an ldap backend something you'd like to see included out of the box? > > Here's the skeleton for the new docs: > http://code.djangoproject.com/wiki/MultipleAuthBackends > > And a patch that does most of it: > http://code.djangoproject.com/attachment/ticket/1428/multiauth.diff -1. I don't want to add layer after layer of code to my views to support whatever authentication backends I feel necessary. Similarly, once a user is "active" (noted in the session), I want RequestContext to know it so that my generic views are seeing the same thing that the other views are seeing. Authentication/Authorization really doesn't belong in every view. That way leads to bad coupling and lots of repetition. The previous version is a lot of work, but I think it is probably closer to preferred use-cases: http://code.djangoproject.com/wiki/MultipleAuthBackends?version=9 -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Multiple Authentication Backends
Joseph Kocherhans wrote: > On 3/14/06, Max Battcher <[EMAIL PROTECTED]> wrote: >> -1. I don't want to add layer after layer of code to my views to >> support whatever authentication backends I feel necessary. > > You don't have to. There is "one true way" to access authentication > regardless of the backend. The specific backend(s) are controlled via > settings. This isn't very obvious in your "simple" wiki post. So you are saying that every authentication backend, if successful, should set request.user? How is backend ordering handled? All of this was somewhat obvious in the last version of the page. If you are going to refactor an entire page, at least include information on where the true differences are. I'm really having a hard time seeing where your example is any simpler/more useful because you wrote the document entirely different. AFAICT, the only real simplification here is the removal of the Credential abstraction, which couples the backends directly to the HttpRequest! I'm not sure if this is an improvement. The other thing is the replacement of a list of backends with only a single backend setting. This assumes that most people only want one backend, and makes anyone who wants multiple backends bend over backwards. I don't see that as much of an improvement, either. It also assumes that every backend will be able to persist the current logged in user as a simple user_id number. I know that won't work too well for OpenID, alone. >> Similarly, >> once a user is "active" (noted in the session), I want RequestContext to >> know it so that my generic views are seeing the same thing that the >> other views are seeing. > > I'm not sure where you get the idea that different views would "see" > anything different. Could you point be more specific? request.user is > still lazily populated using settings.AUTHENTICATION_BACKEND which > defaults to using the standard Django tables. This is not mentioned in your design document. >> Authentication/Authorization really doesn't belong in every view. That >> way leads to bad coupling and lots of repetition. > > You're right, it doesn't belong in every view, and I didn't intend it > to be that way. The example code is meant to show how authentication > works at the lowest level. The way I envision it, most people would > just use a generic decorator to abstract all the details away. I was confused that your view example was for every view dealing with users, not just the login form views. -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Multiple Authentication Backends
Gary Wilson wrote: > I think it would be nice to have the authentication backend > configurable per app instead of project-wide. This way, I could use an > LDAP backend for the app that my users use, and use the builtin backend > for the admin app. I continue to use the example of OpenID authentication, both because it is very different from Model/LDAP and also because it is something that I would use in just about every project on top of any other auth schemes. OpenID is great for comments, forum posts, semi-anonymous polls, et al, but is absolutely not something you want to allow logging into the admin site by default, for instance. OpenID is also something that's great as a choice among several login types (for an example, take a look at LiveJournal's login options). Which brings me to a point that needs to be kept in mind: we need to make sure that permissions and groups work regardless of the backend. -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Descriptor syntax and performance
Correct me if I'm wrong (I don't currently have a system to test this
with), but you can already do this caching yourself (if you need it)
by:
>>> c = Camp.objects.all()[1]
>>> myleaders = c.leaders.all()
Further iterations of myleaders should use the cached queryset.
Obviously, this doesn't help with performance of templates using {%
for leader in object.leaders.all %}, but I'm curious if there is as
much of need for multiple iterations of the same related field in a
template.
I know that the few places where I do multiple iterations of a related
field (or any sort of queryset, really) are in view code and those I
can (and do) optimize by creating a local cache variable per above.
So, I'm not sure if such an improvement is really necessary, again as
the biggest case I see _for_ it being template performance, and I'm
wondering if there might be a better way to optimize that single edge
instead (ie, is it worth it to have some caching added to
django.template's resolve_variable() for QuerySets?).
--
--Max Battcher--
http://www.worldmaker.net/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers
-~--~~~~--~~--~--~---
Re: Magic-removal query syntax
Eugene Lazutkin wrote: > What was the motivation behind using complex kwargs like (taken from > http://code.djangoproject.com/wiki/RemovingTheMagic): The complex kwargs predate magic-removal. Most of the magic kwargs are slowly disappearing, too, like the sudden recent introduction of .exclude(). (Yay for exclude! Boo for making me spend too much time in confusion! Yay for moving targets!) > name='John' (it is possible now) This has been possible in magic-removal for a while: Article.objects.filter(name='John') -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Magic-removal query syntax
Russell Keith-Magee wrote:
> You still need to parse kwargs to handle queries across joins (e.g.,
> Article.objects.filter(author__name__exact='fred'))
Just playing around with ideas, but what if you could do something like:
Article.objects.filter(author=Author.objects.filter(name='fred'))
It's a bit verbose, mainly because of the repeated .objects. and
.filter, but it does point to an interesting question: how hard would it
be for filter to create a join in cases where it is getting a related
object QuerySet, like above?
It also points to several possibilities that the current join kwargs
can't handle, such as:
authors = Author.objects.order_by('last_name', 'first_name')
articles = Article.objects.filter(author=authors).order_by('title')
At the very least, it gives a lazier alternative to __in for QuerySets.
In fact, why keep __in, anyway? Why not just have it check to see if
the object is scalar, QuerySet, or List/Tuple and "do the right thing"?
--
--Max Battcher--
http://www.worldmaker.net/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers
-~--~~~~--~~--~--~---
Re: How to use not equal in QuerySet
limodou wrote: > I seen that in the db-api.txt document, > > neNot equal to. > > But when I want to get the users who are not the superuser, I got the > error below: > > Got invalid lookup_type: 'ne' > > The statement is: > > blogers = User.objects.all().filter(is_superuser__ne=True) Welcome to Moving Target land. __ne and various other negation things were moved into the new filter() companion exclude(). Example: blogers = User.objects.exclude(is_superuser=True) -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: magic-removal: plans/estimates for the trunk-merge?
Andy Dustman wrote: > It might be worth considering puting in some backwards-compatibility > with 0.91, though, keeping a meta module but giving a deprecation > warning if it's used, warning if your model has a META class, etc. I'm > thinking meta can be a light wrapper around model in a lot of cases. > It would probably help the early adapters a lot. The list of things > that need to be changed when going from 0.91 to 0.92 is pretty large. > And then remove the deprecated stuff prior to 0.93 or 1.0. The whole point of M-R is that it is backwards-incompatible. There are a lot of exceptions thrown that should reasonably guide people through the upgrade, and the final version of the RemovingTheMagic wiki page should also be extremely handy. If 0.91 was 1.0, yes there should be a softer upgrade. However, 0.91 is still 0.91. My only suggestion is that to point to the hard upgrade the magic-removal merger, even though it should still be the next release, should be 0.95 rather than 0.92 to make a larger contrast. -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Think about urlconf again
limodou wrote: > No, urlconf just one place, we also have view and template need to > deal with. Last I checked, none of my views have URLs, other than redirects to relative paths like '../' or 'thanks/' or redirects to major pages like '/' and '/member/login/'. As for my templates, certainly my site-specific templates have URLs for navigation, but all of my app-specific templates get along just fine with relative paths and model_object.get_absolute_url. Maybe if you just focused on clean code you wouldn't have to worry about baroque complexes of settings? -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Reverse URL lookup implementation
On 4/6/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: > That way if you set up your URLconfs in a logical manner -- I'd bet > 90% of my urlconfs already work this way -- the shortcut version > would Just Work™. Unfortunately the Generic Views don't fit this too well... 'object_id' is not 'id'. -- --Max Battcher-- http://www.worldmaker.net/ All progress is based upon a universal innate desire on the part of every organism to live beyond its income. --Samuel Butler --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: More specific CSS rules for the admin
Christopher Lenz wrote: > Am 07.04.2006 um 18:30 schrieb Rudolph: >> It could be solved by putting the django-admin stuff inside a tag with >> a django-admin class. Then ".django-admin p" or ".django-admin >> #content" will format only the admin stuff and not your site. > > No, because the admin style sheets use "p" as a selector, and not > ".django-admin p". Thus, the admin styles also affect stuff outside > the admin itself, which was exactly my point. I believe what Rudolph was trying to say was, wrap the entire template in a or change the id or class. -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: #1602: urlify.js blocks out non-English chars
Petar Marić wrote: > I suggest we change urlify.js in a way that will not block out > non-English chars. Instead it should translate them into their English > feel-a-like, as suggested in #1602. Browsers now support Unicode URLs (albeit turned off by default in English editions lately due to security issues), might it make more sense just to allow non-English characters as is, if the said nationality might reasonably be willing/able to type them into the address bar? I don't have any needs along these lines (I'm just a stupid American dealing solely with English applications), so the debate is merely academic to me at this point. -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: exception error running syncdb
bradford wrote: > Exception exceptions.AttributeError: "'NoneType' object has no > attribute 'print_exc'" in ignored I've been seeing this at the end of every manage.py command. It does appear to be non-fatal, but it is something that needs to be debugged. Sorry I haven't taken the time yet to file a formal report. This was on my Windows development machine. My uninformed guess is it may be related to the new color output (ie, I see no color output and instead this exception). -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: SlugField utf-8 support
Viktor wrote: > James Bennett wrote: >> Even when I copy/paste that URL (which I had to do, because my >> web-based email client didn't recognize that the Cyrillic portion of >> it was part of the URL) into Firefox, the URL encoding turns >> "��_��" into >> "%D0%93%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0_%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B0". > > That is only in firefox (they said that urlencoding=false would be > default in FF 1.5, but it still isn't :-/). Every other browser supports > it well. > IIRC, It _was_ the default in Firefox 1.5, but the default was quickly switched back in a security patch for English-language builds as they were given too much flack about the Phishing sites that made evil use of it and the English speakers were too easily confused into thinking things like www.pāýpàļ.com (random name, I don't know if it actually was one of the ones involved) were www.paypal.com, when clicking links in their email. -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: CsrfMiddleware
Luke Plant wrote: > Hi all, > > I've had a number of people suggest that the Cross Site Request Forgery > protection middleware I wrote a while back should go in Django's > contrib section, and if I recall correctly Adrian was enthusiastic > about this happening at some point, but it hasn't actually happened. > > I'm prompted to bring this up because I haven't released a version that > works with m-r (although I've updated my own copy to do so), but it > seems some people are using it with m-r and having to patch it > themselves. So, what do people think about it going in? I'm guessing > it should go in django/contrib/middleware/csrf.py (the middleware > directory doesn't exist yet). I'll add documentation for it as well, > of course. I believe that with the current layout of django/contrib in magic-removal it should probably be django/contrib/csrf/middleware.py, with the focus on "apps" rather than functionality. -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Ideas for /examples/ directory
Ian Holsman wrote: > Hi Adrian. > > I'd love to see an example which uses the 'dispatcher' class. > > also .. MySQL (or someone related to them) have released a > demonstration database called 'Sakila' > http://www.openwin.org/mike/index.php/archives/2006/04/sakila-08/ > we might want to build a example which does have a backend to show a > lot more of the complex issues. You could do similar things with SQLite. Particularly since an SQLite library will be a standard library in Python 2.5. -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: using 'in_bulk' vs 'all' on a model
Ian Holsman wrote: > personally i'd prefer to have all() just return a dict mapping so I > don't need to have 2 different ways of getting to the same > information, but your in feature freeze mode, so I'm not going whine > about it. Python makes it very easy to dict-ify your all() result if you want. dict((object.id, object) for object in ContentType.objects.all()) -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: ATTENTION: magic-removal being merged to trunk TODAY
Adrian Holovaty wrote: > Attention all users of the Django development version (a.k.a. trunk)! > > We are merging the magic-removal branch to trunk this evening, Monday, May 1. > > Do not "svn update" your Django code unless you're ready to convert > your code to magic-removal syntax. > > If you "svn update" by mistake and aren't yet ready for the > magic-removal APIs, you'll be able to "svn switch" back to the last > version of pre-magic-removal Django, which will be tagged in > Subversion. svn update can take an optional revision number as an argument (IIRC, --rev=) and it will "de-update" (update your working copy to a previous revision). -- --Max Battcher-- http://www.worldmaker.net/ "I'm gonna win, trust in me / I have come to save this world / and in the end I'll get the grrrl!" --Machinae Supremacy, Hero (Promo Track) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: django-values -> django-policy?
On 5/28/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > Maybe a combination of the two would be a bit better. "policyvalues"? > Indicating its usefulness in the scope of policies while still being > clear that its features only extend to the values. When I think of Policies I think more of Constraints than Values, so django-policy-constraints doesn't sound that bad, just verbose. Or what about just django-constraints? I think the term constraint may even work better because it sounds (linguistically) about right for a Variable -> Constraint -> Constant axis when describing which to use and when. -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Design Decision: Dynamic settings.SITE_ID (ref. #4438)
I recently created and started testing a simple middleware, that I thought may even be worthy of django.contrib.sites. In brief, here's the question being asked: Is modifying settings, and in particular settings.SITE_ID, allowable? Is it workable? (ie, what breaks if that assumption does not hold?) Here's the impetus: myblogname.example.com can look friendlier and be easier to remember than example.com/myblogname. Many modern sites place user-controlled content under relatively dynamic subdomains (ie, new users might sign up any moment). It is also certainly advocated by many Rails philosophers. For most sites of this type it doesn't make sense to be required to build a VirtualHost file and a Settings file for each and every User/Blog/Project/Family Dog/Whatever. In those cases it makes sense to use wildcard (*) subdomain VirtualHost and a single settings file with a bunch of shared applications. I think the django.contrib.sites.models.Site seems perfect for the task of determining which Sites might be available at a given moment, and is an already existing way to configure applications to handle such. To make this as easy and nearly transparent to existing Site-based code I proposed a simple process_request middleware to set settings.SITE_ID to the id of the Site whose domain matches request.META['HTTP_HOST'] and I attached the code to a simple one that I started testing to Ticket #4438. [1] Here's where the debate begins... I would like to see something as simple as adding a middleware to support dynamic Sites rather than a single static Site for a settings file. But, can you modify the settings from a middleware? Should you? I don't think this sort of thing belongs in the view because it keeps someone from using unmodified/unwrapped generic views (which can often be a sign of a loss of DRY, right?) and because it makes a huge distinction between a website with a static, unchanging SITE_ID and a settings file that might host multiple SITE_IDs. It also doesn't belong in a Manager class because a Manager shouldn't need to deal with HttpRequest and if it did, it can't be used for filtering in a urls.py file if it requires a request object... I don't see a better alternative. [1] http://code.djangoproject.com/ticket/4438 What do you y'all think? -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Design Decision: Dynamic settings.SITE_ID (ref. #4438)
On 5/31/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Every single piece of code that caches anything based on having read > something from settings would then have to query settings every time > (and recompute whatever it cached). There is code that relies on the > current behaviour and the assumption that settings will never change > once you access them makes this a useful pattern. Having to change this > to "some settings will change" means there is always some flipping back > and forth checking which set of assumptions you are operating under when > developing. Feels error prone. I'm pretty stupid, so I'm a big fan of > things behaving as expected with consistency. I'm starting to see this. In my testing there is an inconsistency from time to time in the results and/or the caching. > An alternative approach to a solution for a problem that requires this > question (can I change a setting?) is to work out whether it makes sense > to move the "feature" away from being a setting (since it's no longer a > user-configured setting, but the user setting can still act as a hint). Agreed. Hence the reason I try to make sure to provide the full story as I see it so that a little Root Cause Analysis can be performed. > > I would like to see something as > > simple as adding a middleware to support dynamic Sites > > That's the problem that might be interesting to solve! All the stuff > about settings changes flows from your particular solution. Don't > misunderstand me here: I'm not trying to dismiss on your solution -- I > just want to distinguish between real barriers on the way to the goal > and barriers imposed by other decisions. I'm not married to my solution and opening this discussion was precisely what I saw as finding a much better solution. I realize that I'm not an everyday Django coder and I've very rarely used Django's source as anything other than a reference when I have a question as a consumer of the framework, so I certainly realize that my first instincts might not be the best. > Two alternatives spring to mind. Neither of these are fully thought-out > yet, but let's see how they sound: > > (1) We introduce a formal thread-local settings feature as well. > (2) We come up a with a more dynamic site object. (1) sounds more generally useful. If you've been thinking about it for some time and it looks like it might solve/alleviate some other things along the line it might be the better approach.(2) does seem like a lot of work for a single (contrib) application, but having fewer checks against SITE_ID could be a nice benefit (reducing some over-reliance on django.conf.settings). > I realise your original question was motivated by not wishing to make > any changes to the code at all and instead *just completely violate one > of our most sacred, honorable and historic assumptions* (alright, you > may not have viewed that way). I just thought I might have found a simple minimal solution in a few lines of code. I don't mind realizing that my solution created more side problems than it was worth. It was a learning experience... I had assumed that the functionality didn't exist because few had thought about it and fewer used the sites application rather than roll their own thing. Now I know that I was wrong and the problem is a bit bigger than I first thought it was. I personally think that Dynamic Sites support of one form or another should be provided sometime by 1.0, just because I don't think django.contrib.sites is complete without. It's the sort of functionality a new person might assume it contains... It took me a while to get used to the idea that sites didn't bother to check the address at all and simply took SITE_ID for face value. > I'd like to solve the problem in a slightly more intrusive way, though, > just because I like viewing the settings module as a static thing. Which > conflicts massively with my "I don't like random backwards incompat > changes" inner child, but that's something I have to work out. I have no problem for seeing it solved the intrusive way if that's what makes the most sense for the problem set. Hopefully something like this can even be done without breaking too many backward compatibility eggs... -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Allowing multiple {% block %}s in one template
I had yet another suggestion: use template vars for block repetitions, such as:
{% block title %}Page Title{% endblock %} | Some Site
{{ block.title }}
Make the "block object" suitably lazy and in most cases I would think
it "should just work"... (I used {{ block.title }} rather than {{
blocks.title }} to mirror the existing {{ block.super }} var...)
Assuming the order of template rendering is what I remember thinking
it was...
--
--Max Battcher--
http://www.worldmaker.net/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---
Re: make db form settings
I'm not sure if there is a large enough need for your script, Carl K. Creating the databases themselves should be a rare activity. Perhaps you'd be better off looking for a deployment engine that supports what you need, such as Capistrano. -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Session based Messages
On 7/9/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> There was some discussion on this a while back, and my main concern
> with that, is whether or not those are sufficient for everybody. For
> instance, many projects would probably benefit more from "success" and
> "failure" info than the ones you mention.
>
> I'm not sure there's a way to make everybody (or even a majority)
> happy on this. It's worth trying, but I'm not holding my breath.
You could just leave it as a unqualified tag/slug-style string (ie,
only characters useful in identifiers and space-separated when
multiple values), and leave it to template writers to decide how they
want to handle it, with the most useful two options being something
like:
[{{ message.level }}] {{ message }}
versus
{{ message }}
In the first, the template writer is just passing the data straight
through to the user and doesn't care what values get passed back. Add
an {% if message.level %} around the square brackets and the output
would be the same for classic/simple level-less messages.
In the second the template writer wants to style messages based on
level and here the writer can easily add CSS rules for the levels that
are interesting, such as:
.message .error, .message .failure {
background: red;
}
.message .i-cant-believe-not-butter {
background: chartreuse;
}
...and CSS allows them to provide a simple generic fall-back for the
cases when a template writer doesn't explicitly style a level.
Apps don't need to agree on levels as long as template writers don't
mind checking what levels an app might "throw".
So, basically I'm suggesting adding a tags or labels field rather than
a debug-style levels field. Then let template writers decide how the
tags/labels might be used.
--
--Max Battcher--
http://www.worldmaker.net/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---
Re: mod_python: Why use req.uri, not req.path_info?
On 7/10/07, Forest Bond <[EMAIL PROTECTED]> wrote:
> So, the problem is that I have to update my urls.py to include the /mysite/
> prefix in all URLs.
>
> ...
>
> If this can be solved using some crazy middleware-type solution, I'd be open
> to
> that. It doesn't seem ideal to me for the current behavior to be the default,
> though.
Fixing the URLs redundancy is easy, create a new mysite_urls.py and
mysite_settings.py for the site at /mysite/. In mysite_settings put
the ROOT_URLCONF to mysite_urls.py and mysite_urls just needs the
simple url pattern ('^mysite/', include('urls.py')) to match the new
"global" prefix. You can do the same for other sites or it would be
easy enough to use a more generic prefix regex and share the same
prefix matching urls and trade off a little regex efficiency... Each
site should have its own settings anyway, at the very least for
separate SITE_IDs. (Settings is just python, so you can easily
inherit some base settings with a line like ``from base_settings
import *``.)
--
--Max Battcher--
http://www.worldmaker.net/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---
Re: Django 1.0 features -- the definitive list
On Nov 30, 2007 2:18 AM, jj <[EMAIL PROTECTED]> wrote: > move 0.96 to 1.0 status. This might sound somewhat artificial, but > would clearly indicate that 0.96 is a version one can already trust. > Isn't the Web site already advocating 0.96 that way? That might be a good idea... backport any remaining useful fixes to 0.96, maybe go ahead and do the newforms -> forms rename, and not much more really needs to be done and call that 1.0 and everything else becomes 2.0... On the other hand I also see the humor in skipping directly from 0.96 to 2.0. The way changes steadily get pushed to Trunk I'm wondering if Django might not be better off using Ubuntu-style date-based versions, anyway. (ie, the current Ubuntu release was official in October 2007 and thus is version 7.10) I think it would be even funnier to skip from 0.96 to 8.01... and then follow that up with new versions each quarter, if not each month... -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: Reorganising management/validation.py
Malcolm Tredinnick wrote: > Anybody feel strongly that we should go for option (1)? I think I'm -0 on option 1, but thought that it should be mentioned that Warnings complicate option 1. The obvious example being that darned DeprecationWarning currently seen on trunk for every remaining instance of maxlength rather than max_length... It's still convenient to rope together all warnings rather than have them printing at odd times during debugging. It would be nice to easily validate non-installed models, but I don't think that's a compelling use case in either direction. -- --Max Battcher-- http://www.worldmaker.net/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~--~~~~--~~--~--~---
Re: specifying newforms-admin options
On Jan 21, 4:25 pm, "Matthew Flanagan" <[EMAIL PROTECTED]> wrote:
> ADMIN_FIND_ADMIN_CLASSES = True
> ADMIN_MODELS = (
> 'myproj.myapp.admin.PollAdmin',
> 'someotherproj.someapp.admin.FooAdmin',
> )
My 2 (belated) cents on the issue: the settings.py idea is the best
I've seen in the thread so far. Let me throw in another option: maybe
it's time to return to Meta? In the dawn before time
(pre-magic-removal) Meta housed all of the Admin options until it was
determined which merely served the Admin itself and which were more
generally useful, breaking things into two inner-classes, Meta and
Admin. If we want to deprecate the inner-Admin class it makes sense to
me that we can use the Meta class we still have lying around for odd
jobs (like ordering and verbose_name_plural). For instance::
class Meta:
show_in_admin = True
admin_model = ModelAdmin({
'list_display': ... })
Certainly that should look eerily familiar to pre-0.95 developers. You
could easily then do something like::
admin_model = ModelAdmin(ModelName.Admin.__dict__)
This becomes the easy to add explicit "magic" sub-typing of the inner
Admin class, and you just have the Admin assume until deprecated (ie,
one version later when oldforms is deprecated) that the above line
already exists in Meta if it doesn't exist. For simple classes
up-conversion is simply add two lines to Meta (show_in_admin and
admin_model).
This keeps Admin information inside the model (which I'm still
uncertain if that is a Bad Thing just yet) and yet still adds a good
amount of explicitness. Those worried about "admin contamination" of
apps for non-admin users could handle that difficulty using something
akin to::
if use_admin_flag:
from django.contrib.admin import ModelAdmin
else:
def ModelAdmin(dict):
pass
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---
Re: apps with the same name
I was thinking that another option would be to decouple the
INSTALLED_APPS setting from the data store to allow for future changes
(such as a better place to store app-specific settings than the global
namespace as CAPS_NAMES in the settings file), similar to the
patterns() and include() functions of URLconf. Something like:
INSTALLED_APPS = (
app('django.contrib.admin'),
app('myapp.admin', as_='myadmin'),
)
Like I said, this could allow for future compatibility with things like
static_url= or other application-specific settings.
Re: Similar software to django/New Django features/Working on Django
> There are some things that we do though, that I don't see in Django. The > biggest is our logging system, which I really like. In Django I've > just seen logging in the admin page with the 'History'. Our setup is that > we have a class LogEntry (actually action_log but i would change it now) > correspding to a table in the db with all of the changes. It makes sense for Django not to add this overhead by default. However it is really easy to add on your own on the classes where it makes sense. For instance, I built a simple Issue/Bug tracker (similar to Trac's) and for that you want full change tracking. By overloading the save() command (in magic-removal, in trunk you would utilize pre_save and post_save), I have it generate a complete changelog on every save. Right now you have to do this manually, so it might be useful for someone to build a more generic package that might be useful to plug into any sort Model class. If you want to look at my current code for ideas, I'll be happy to let you see it. Your triggers needs could also probably be taken care of in the save() overload (another example from my issue tracker is that it generates emails with change notifications). > We have authentication in our website that is tied to the user's main > password, which we want to keep. This brings up two things - Is there a > way to have the admin interface pwcheck based on a different method? In > our case, NIS. And having an easy way to slip an authentication page into > Django 'apps' is good. There might be something like that already. This is still being debated as to the best way to approach a lot of the authentication issues. Feel free to try to come up with some good general approach and offer it as a solution. > We also have the equivalent of the Django admin interface in command line > form. > We have a program called 'userbase' which sysadmins can do to query > anything about a user or users. For example: > userbase -look activeusers -with resources cluster1,cluster2 \ > -with 0 sponsors -query name_first='Alan' -get name_last Django's query syntax is very clear and easy to read, and on most systems you can easily use Python scripts like shell scripts and you can easily type in ``python`` for a command line or for a better shortcut with some nice auto-imports you can do ``python manage.py shell``. An example script might look like (in the recent descriptor syntax): `` #!/usr/bin/python import userbase.models.User users = User.objects.filter(resource__name='cluster1') | \ User.objects.filter(resource__name='cluster2') users = user.filter(active=True, sponsor__count=0, name_first='Alan') for user in users: print user.name_last `` Not as compressed as your one-line command, but very readable, and even easy enough to do on the fly from a Python console. Not to mention you are free to make as useful a Python API as you need (for instance adding an active_users filter to User, if that is commonly used). Again, no reason not to just use Python for such command-scripting needs. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
