Re: modularity of apps
> Malcolm Tredinnick wrote: > One point of view (mine!) is that if an application can't play nicely > with other applications and wants to do its own authentication, etc, > then it's not an application, it's a whole other project. The project > developer should have complete control over what the policies are for > things like this. Otherwise it's too hard to understand what each app is > doing when incorporating it. Just musing a bit here - I'm wondering about this too - I'm working on a few applications, and was not sure if it was best to distribute them as django _projects_ or django _apps_. In fact, what is the distinction between an app and a project? Most of the examples I've seen have been a one-app-one-project style. If this is the way people are going to do things, is there any benefit in having an app/project distinction? I *do* like the idea of settings per application - I've got a lot of use out of the main settings file by adding an APPNAME dictionary and adding user configuration vars into that, but this does mean that I have to distribute a _project_, instead of an _app_. Would it be a good idea for startapp to create an empty settings.py in each application dir? Django.conf.settings could then load get this as settings.APPNAME Per-app settings would also give you some method of directly over-riding any other settings. Finally - I'm not entirely sure that Django needs to try to solve dependencies, it's up to the app/project developers to describe what's needed to run their software. This is what readme files are for. --Simon --~--~-~--~~~---~--~~ 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: big picture of middelware
You might be interested in this rather excellent write up by James Bennet, which explains things well: http://www.b-list.org/weblog/2006/06/13/how-django-processes-request --Simon --~--~-~--~~~---~--~~ 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: Can custom tag use namespace
On 8/13/06, limodou <[EMAIL PROTECTED]> wrote:
> On 8/13/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> >
> > On 8/7/06, limodou <[EMAIL PROTECTED]> wrote:
> > > How to use namespace? For example,
> > >
> > > {% load example %}
> > > {% example.testtag %}
> > >
> > > And I think if the namespace can be optional is better. I don't know
> > > if it's useful, but sometimes I read others projects, and as I reading
> > > the template, I don't know which tag is in which file. So find the
> > > correct tag definition file is somewhat diffcult. If I can add
> > > namespace in the front of a custom tag name, it'll be easy to locate
> > > the source file.
> >
> > Hi limodou,
> >
> > This would be a nice improvement, and it seems like it could be
> > accomplished in a backwards-compatible fashion, by allowing
> > non-qualified template tag names. Would you (or anybody else) be
> > interested in coming up with a solution?
> >
> > Adrian
> >
> Ok, I'll try to implement it.
>
Adrian:
I'v finished my work, you can check it.
http://code.djangoproject.com/ticket/2539
I hope this would be useful.
--
I like python!
My Blog: http://www.donews.net/limodou
My Django Site: http://www.djangocn.org
NewEdit Maillist: http://groups.google.com/group/NewEdit
--~--~-~--~~~---~--~~
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: modularity of apps
On Sat, 2006-08-12 at 22:29 -0700, Gary Wilson wrote: > Malcolm Tredinnick wrote: > > One point of view (mine!) is that if an application can't play nicely > > with other applications and wants to do its own authentication, etc, > > then it's not an application, it's a whole other project. The project > > developer should have complete control over what the policies are for > > things like this. Otherwise it's too hard to understand what each app is > > doing when incorporating it. > > So if am using the admin application with its (contrib.auth) > authentication and then the rest of my site using a custom user model > with its own authentication, you are saying that I should make them > separate projects? That just doesn't seem right. Project administrators (or whatever we want to call them) having their decision usurped by individual apps feels like bad system administrations practice. If a project sets up a particular authentication scheme (particularly authentication, which is security-related), an application should not be able to avoid that. I'm not really sure that there is a true "right" answer here, Gary. Again, this is a thread where a lot of untested ideas are being bounced around. I do know how I would be thinking as a Systems Administrator or Operations Manager in cases like this (even if it just on my own personal production machine(s)). Most of what we come up with is going to be suggestions or best practice ideas and we need to think about that side of things as well when coming up with ideas. > I don't think anyone has answered the OP's question of how plugable are > apps supposed to be? Except that wasn't Todd's original question. :-) He was floating a few ideas about how to manage multiple applications. We've had quite a few productive emails on those lines with various ideas in this thread. And some of the consensus that came out was that it was going to require some thinking on the part of the project creator and that isn't necessarily a bad thing. There is also the quite valid position, that you're obviously an advocate for, of having a lot of automated configuration stuff as well. But it feels like we are going around in circles with semantics at some points in this thread. Words like "pluggable" or "modular" or "application" or "project" are somewhat irrelevant: what we are really talking about is "how can I use some of that guy's code and use it in my code". > Currently, the only way you can achieve full > modularity is to make every installed app its own project. Only then > can I set the app's TEMPLATE_CONTEXT_PROCESSORS, MIDDLEWARE_CLASSES, > AUTHENTICATION_BACKENDS, etc. and be sure that applications won't stomp > over each other. Stop viewing your applications as warring parties and start thinking of them as cooperative contributors to your project as whole. You're not trying to prevent them from stomping over each other, you are trying to get them to work together. :-) I can think of lots of potential problems with per-app configurations like this and I can see that in some cases it might make life easier as well. It feels a lot like you are moving request-level things down into applications, for example. (So at which point in the request handling do they get processed?). But try it out for a while. See if it does make your application sharing easier. I have zero experience with your approach, so maybe it is easier and I'm just old and inflexible. Like I said in my first or second post to this thread, we can only benefit from people reporting back real-world experiences: things they have tried that worked or didn't work and why the new thing wasn't handled nicely by our existing infrastructure. Best wishes, Malcolm --~--~-~--~~~---~--~~ 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: modularity of apps
On Sun, 2006-08-13 at 01:15 -0700, [EMAIL PROTECTED] wrote: > > Malcolm Tredinnick wrote: > > One point of view (mine!) is that if an application can't play nicely > > with other applications and wants to do its own authentication, etc, > > then it's not an application, it's a whole other project. The project > > developer should have complete control over what the policies are for > > things like this. Otherwise it's too hard to understand what each app is > > doing when incorporating it. > > Just musing a bit here - > > I'm wondering about this too - I'm working on a few applications, and > was not sure if it was best to distribute them as django _projects_ or > django _apps_. In fact, what is the distinction between an app and a > project? Most of the examples I've seen have been a one-app-one-project > style. If this is the way people are going to do things, is there any > benefit in having an app/project distinction? Be careful not to generalise from a few examples to the whole universe of Django users. :-) The Lawrence guys have mentioned on this list previously that they have many different applications they pull together in various projects. If you look at the source code repository that Ian Holsman periodically posts for Zyons and his other projects, you can see he's using multiple apps to do different things. I'm doing the same in a few places (including sharing applications between projects). There are plenty of "silent" users of Django, so you should assume maximum variation. :-) Regards, Malcolm --~--~-~--~~~---~--~~ 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: Dependency problem in flatpages...
- Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: [snip] > Have a poke around in django/core/management.py in the > _get_sql_model_create() function and see if you can work out why we're > getting this wrong. > > The fact that the generated SQL has a "...REFERENCES ..." clause on the > problem line, rather than trying an "ALTER TABLE..." statement later > (out of _get_sql_for_pending_references()) means that the code thinks > that table has already been created. We try hard not to do that. So I > suspect this is a silly bug somewhere and it might be easy to fix if you > drop in a few print statements and have an already failing example. > > I didn't know we allowed wildcards there (although it makes sense that > it would work, whether intended or not), but the output is close to > correct, so it might easy enough to work out what is going wrong. I little more research has found a couple more things. First, many to many fields aren't stored in opts.fields. They're moved at construction time into opts.many_to_many, and _get_sql_model_create() doesn't do anything with those fields. The REFERENCES string is actually coming out of _get_many_to_many_sql_for_model(), which assumes that the necessary tables already exist. The fundamental issue is that the table being referenced doesn't reside in the same application. It's actually part of the contrib.sites application, and I don't see anything in the code trying to analyze the dependencies across applications. This actually sounds like something that's been discussed in the past, and was probably present pre-magic-removal, although I'm certain that initially populating the database used to work before. I'm not sure where to go next, short of analyzing dependencies across applications. And unfortunately, that's a much bigger issue than I have time to deal with. :-( -John --~--~-~--~~~---~--~~ 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: translation of content
On 13 Aug 2006, at 05:26, Kenneth Gonsalves wrote: I have sites that are in english, but need to be translated into the 22 official indian languages. The interface and django is in the process of getting translated using i18n, but content is the problem ... so just thinking aloud. I need something very like gettext for content, so the translators can have a similar interface - or even use kbabel for it, though it wouldnt be short strings, but long pieces of content. Take a look at http://trac.studioquattro.biz/djangoutils/wiki/ TranslationService. It's still in alpha stage, but usable. --- Nebojša Đorđević - nesh Studio Quattro - Niš - Serbia http://studioquattro.biz/ | http://trac.studioquattro.biz/djangoutils/ Registered Linux User 282159 [http://counter.li.org] What is the sound of one backpack EMP weapon discharging? -- Joe Thompson "Clickety-click" -- Charles Cazabon PGP.sig Description: This is a digitally signed message part
admin/doc for templates ?
Hi all, is there a reason why in the admin/doc templatetags, filters and views are accessible but templates are not ? Was it only not done until yet ? How could it be done ? Regards, Dirk -- Echte DSL-Flatrate dauerhaft für 0,- Euro*. Nur noch kurze Zeit! "Feel free" mit GMX DSL: http://www.gmx.net/de/go/dsl --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Security questions
Hi, At the company I work for most of the sites run django and I have been pushing hard for it's adoption, while facing a lot of adversity from all kinds of camps most notably the .NET and java. I have already proven that django/python is enterprise ready, faster to develop in, and performs extremely well for small/midsized website. The only concern I really have is security. I'm happy to see a security process put in place. But I do have some questions: 1. From "Reporting security issues" document "Pre-notify everyone we know to be running the affected version(s) of Django. We will send these notifications through private e-mail which will include documentation of the..." Hm how will this work and where do I sign up? 2. Due to time/money reasons I am running a relatively old version of django. I realise that by doing that I'm left on my own. However It would be nice to be able to go to Trac or somewhere and see all security related bugs/fixes so that I can back port them to my version. Right now all I found is "Active tickets by keywords" report. Are there any plans to enhance that? e.g. I'm interested in all security related changes. Closed/active tickets, bug reports, patches (even the refused ones) etc. Thoughts? Best Regards --~--~-~--~~~---~--~~ 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: Security questions
On 8/13/06, Jakub Labath <[EMAIL PROTECTED]> wrote: > 2. Due to time/money reasons I am running a relatively old version of > django. I realise that by doing that I'm left on my own. However It > would be nice to be able to go to Trac or somewhere and see all > security related bugs/fixes so that I can back port them to my > version. How old? It looks there will be some work backporting bugfixes to 0.91. http://groups.google.com/group/django-developers/browse_thread/thread/587004d127dd9444/a748f75990565a6e#a748f75990565a6e (I have a site running on an even older codebase, ouch.) > Right now all I found is "Active tickets by keywords" report. Are What version of trac is the site running? I've previously thought about writing some additional reports, but it appears Trac is changing to have an actual reporting engine. ;) " Note: The report module is being phased out in its current form because it seriously limits the ability of the Trac team to make adjustments to the underlying database schema. We believe that the query module is a good replacement " http://trac.edgewall.org/wiki/TracReports --~--~-~--~~~---~--~~ 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: Security questions
We recently discussed the security policy in light of the recent Rails shenanigans here: http://groups.google.com/group/django-developers/browse_thread/thread/7a647b883d637920 The new django-announce mailing list should keep you abreast of security issues. --Simon --~--~-~--~~~---~--~~ 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: A model_object.is_saved() method
On 8/13/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > This is an interesting feature request/idea. If we were to add a > default method along the lines of is_saved(), I think it would make > the most sense if that method actually *checked* the database rather > than just checking that the primary-key value is set. Ah yes. I was forgetting about records that may have their primary key hand-allocated rather than auto-allocated, and about data changes over an object's lifetime. Checking the database would also more closely match the logic of the save() method. > But, if I > understand correctly, that would be overkill for your situation, > right? Certainly it's more thorough than is required, but the small overhead of a query against a table's primary key would be acceptable at that point in the application. Alan. --~--~-~--~~~---~--~~ 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: Security questions
On 8/13/06, Jakub Labath <[EMAIL PROTECTED]> wrote: > 2. Due to time/money reasons I am running a relatively old version of > django. I realise that by doing that I'm left on my own. However It > would be nice to be able to go to Trac or somewhere and see all > security related bugs/fixes so that I can back port them to my > version. Yesterday we created a "0.91-bugfixes" branch, which will provide patches and fixes for known bugs in pre-magic-removal Django, though the focus is any bugs in general, not just security. Security-related announcements will still be made as described in the security documentation, of course, but I'll be applying any needed security patches for the older version of Django in that branch just as I'll be applying any known bugfixes. As for security issues in Trac, we very strongly discourage the reporting of security-related bugs in Trac, so I doubt we'd be able to set up such a search; security issues, as the documentation points out, should be submitted to '[EMAIL PROTECTED]' . -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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: Security questions
Hi, Thanks everybody for the info. James, thanks for the effort to still support the 0.91 branch, It's much appreciated. Best jakub --~--~-~--~~~---~--~~ 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: Security questions
On 8/13/06, James Bennett <[EMAIL PROTECTED]> wrote: > > On 8/13/06, Jakub Labath <[EMAIL PROTECTED]> wrote: > > 2. Due to time/money reasons I am running a relatively old version of > > django. I realise that by doing that I'm left on my own. However It > > would be nice to be able to go to Trac or somewhere and see all > > security related bugs/fixes so that I can back port them to my > > version. > > Yesterday we created a "0.91-bugfixes" branch, which will provide > patches and fixes for known bugs in pre-magic-removal Django, though > the focus is any bugs in general, not just security. Security-related > announcements will still be made as described in the security > documentation, of course, but I'll be applying any needed security > patches for the older version of Django in that branch just as I'll be > applying any known bugfixes. > > As for security issues in Trac, we very strongly discourage the > reporting of security-related bugs in Trac, so I doubt we'd be able to > set up such a search; security issues, as the documentation points > out, should be submitted to '[EMAIL PROTECTED]' . > Something we've done in Samba that seems useful is a security page to track past vulnerabilities and what versions are affected, which also includes the patch for the affected version. See http://samba.org/samba/history/security.html. Can't really do something like this until after the fact, but something to consider, should the time come. Cheers, deryck -- Deryck Hodge http://www.devurandom.org/ Web Developer, Naples News http://www.naplesnews.com/ Samba Team http://www.samba.org/ --~--~-~--~~~---~--~~ 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: Pagination
Hi Mike, In case you are interested, I wrote a ticket that (in addition to adding some other paginator functionality) provides a PaginatorPage object which is a wrapper for a specific page. http://code.djangoproject.com/ticket/2093 I just updated it to provide some useful properties: next_page_number and previous_page_number - thanks for the idea. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
