Re: contrib.comments: working example must make a boost.
Hi Russ, I did at least the follwoing: http://code.djangoproject.com/ticket/9604 regards Valery On Nov 8, 5:56 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Sat, Nov 8, 2008 at 6:45 AM,Valery<[EMAIL PROTECTED]> wrote: > > > Hi all, @mtredinnick, @jacob, @wilson, @ubernostrum > > > not sure if any "community boosts" are at all wanted here, but finally > > django is not for a closed circle of django-gurus and things are for > > the larger audience, isn't it? :) so, why there is no easy-to-launch > > example of last contrib.comments code? > ... > > Just single me and those hundreds. I don't want really enter the long > > discussions. I'd like to know how could I help getting such an example > > running. (Of course, I have some work copy) > > How can you help? By doing it. Build it, and they will come. :-) > > Seriously - you don't have to ask for permission to help out. If you > think there is an area where Django needs more/better/different > documentation or examples, then dig in and get your hands dirty. There > are many ways that you could make this happen: > > 1) The obvious solution would be to write a new tutorial or example > page that could be distributed as part of the core documentation. > Write up the docs in ReST format, and submit them as a ticket. It > might take a while to get through the editorial process, but then your > tutorial would be part of the Django core for ever more. > > 2) Blog about it. Write an N part series on setting up comments on a > site. There are certain blogs (such as James Bennett's B-list) that > are well known and oft-referenced sources of unofficial documentation > of common tasks. > > 3) Screencast about it. Screencasts can be a more engaging way to > demonstrate something by doing it, live on camera. > > 4) Set up a demo site, and provide the code for that site. I notice > that how-to-use-django-comments.com is available... :-) > > Good ideas are easy to have - I usually have three or four each time I > have a shower. Executing is much harder. Any contribution is welcome, > but if you want to see improvement, you have to contribute. > > I look forward to seeing your contribution :-) > > Yours > Russ Magee %-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Django 1.1, app() and ticket #3591
Re. the recent post by Jacob Kaplan-Moss on Django 1.1 features and votes: ORM-23 gets a +1 from me. Jacob has given it a -0 and a comment "A huge can of worms. Some really awesome benefits come out of this, but so far everyone who's tried to make this work has failed. Until there's an actual implementation that works (even mostly), I'll probably just ignore." I've maintained a patch on #3591 which has been working as regards the terms of reference of the original ticket: the ability to specify app_label and a verbose name, using the app() object approach originally suggested by Joseph Kocherhans. I've kept the patch updated since early May 2007 and through the 1.0 milestone, and AFAIK it still passes all tests (runtests.py). Anecdotally (and for whatever it's worth - I do realise the limitations of anecdotes), people who have installed the patch have reported that "it just works". In what respect does the patch not work, mostly or otherwise? I'd welcome some specific criticism which helps to improve the patch. >From my experience, I don't find it such a big can of worms, at least as far as the original requirements go. The majority of the changes I made to the Django source in implementing this patch was to change references to "settings.INSTALLED_APPS" to "get_installed_app_paths ()". This is because settings.INSTALLED_APPS in the pre-patch world is a list of paths, whereas in the post-patch world it's a list of app() instances. The get_installed_app_paths() function just returns the list of paths. I am very willing to do further work on the patch/this feature as long as I understand what's expected of it by the committers. What, in your view, are the requirements that the current #3591 patch does not meet? Let's remember "Explicit is better than implicit", by which I mean: I believe that the patch addresses the requirements mentioned in the ticket. Other requirements may be there in the committers' and other people's heads (implicit), and I am just asking for those requirements to be spelled out explicitly. Thanks, Vinay Sajip --~--~-~--~~~---~--~~ 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.1, app() and ticket #3591
On Nov 15, 12:27 pm, Vinay Sajip <[EMAIL PROTECTED]> wrote: > Re. the recent post by Jacob Kaplan-Moss on Django 1.1 features and > votes: > > ORM-23 gets a +1 from me. Jacob has given it a -0 and a comment "A > huge can of worms. Some really awesome benefits come out of this, but > so far everyone who's tried to make this work has failed. Until > there's an actual implementation that works (even mostly), I'll > probably just ignore." > > I've maintained a patch on #3591 which has been working as regards the > terms of reference of the original ticket: the ability to specify > app_label and a verbose name, using the app() object approach > originally suggested by Joseph Kocherhans. I've kept the patch updated > since early May 2007 and through the 1.0 milestone, and AFAIK it still > passes all tests (runtests.py). > > Anecdotally (and for whatever it's worth - I do realise the > limitations of anecdotes), people who have installed the patch have > reported that "it just works". In what respect does the patch not > work, mostly or otherwise? I'd welcome some specific criticism which > helps to improve the patch. > > From my experience, I don't find it such a big can of worms, at least > as far as the original requirements go. The majority of the changes I > made to the Django source in implementing this patch was to change > references to "settings.INSTALLED_APPS" to "get_installed_app_paths > ()". This is because settings.INSTALLED_APPS in the pre-patch world is > a list of paths, whereas in the post-patch world it's a list of app() > instances. The get_installed_app_paths() function just returns the > list of paths. > > I am very willing to do further work on the patch/this feature as long > as I understand what's expected of it by the committers. What, in your > view, are the requirements that the current #3591 patch does not meet? > Let's remember "Explicit is better than implicit", by which I mean: I > believe that the patch addresses the requirements mentioned in the > ticket. Other requirements may be there in the committers' and other > people's heads (implicit), and I am just asking for those requirements > to be spelled out explicitly. > > Thanks, > > Vinay Sajip Following the above post, I had another look at Jacob's spreadsheet for comments others have made regarding ORM-23. Malcolm says: "Multiple competing proposals at the moment and I still don't see the great benefits it gets us in any of the cases for all the trade-offs implied. Would prefer to push this back until it's better developed (and since smart people have already tried and failed a bit, I'm not hopeful, so rushing something is the wrong plan)" I agree that rushing would be wrong - I'm firmly of the view that getting it right is more important. However, it would be helpful if Malcolm could spell out what the multiple competing proposals are, and what the implied trade-offs are, and what the failures are as he sees them. With specific points rather than generalities in hand, wouldn't it be easier to move things forward? Brian Rosner says: "I am +1 to the idea, but no one has stepped up with a good implementation. I may consider looking at it, but I put no guarantee on it." Please provide some specific criticism of the implementation in #3591. Have you tried it, and found it wanting - in which case, where is it wanting? Or is it missing some features which you think it should have, which stops you from even trying it - in which case, what are those features? Gulopine says: "The only tangible benefit I've seen brought up so far is the ability to have multiple instances of the same app, and I can't imagine that can be done with the app being written to do so. And at that point, the app could be written to be customized in multiple ways without an app() object controlling it." What about the tangible benefits of a customisable app_label (to avoid clashes between different apps from different third parties, important if reusable apps are important - which they undoubtedly are) and verbose names for the app in the admin? These are not earth-shattering in their impact, but they *are* tangible benefits. David Cramer says: "This can wait". Sure it can, but if other people are willing to put in the effort to get it in, what's the objection to that? Why give it a -1, even if it's not high on your list of priorities? Is it a bad idea altogether - and if so, what are the reasons for that? jezdez says: "As Jacob said, that's such a pain. I tried and wasn't able to implement even part of the wanted features. The app cache needs a thourough look. But I don't see installing apps multiple times as a favored feature. I will happily participate in any work on this." Well, what are those features you wanted, explicitly? The "apps multiple times" would be a corner case, the minimum benefits are third- party app disambiguation and verbose names for apps in the admin. Did you try the #3591 patch? Re. the above comments - the common thread is
Bug in admin or in my model ?
I forget to write some details: OS: Debian Etch with python 2.4 Django version: 1.0, also tested on new 1.0.1 with same results -- Ivan --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Bug in admin or in my model ?
It looks like the bug #3924 which should be allready closed. -- Ivan --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Bug in admin or in my model ?
Hi,
I have a problem when adding record by Django Admin and I am not sure where I
have to look for it. Is this some problem in Django Admin or it can be solved
by some
configuration in model ?
I use Foreign Key in table where I want to add record. Foreign Key is the
field containing some non ASCII characters. See:
http://gista.sk/dl/bugs/django/add_record_in_admin.png
*** When I submit, I get this error:
Mod_python error: "PythonHandler django.core.handlers.modpython"
Traceback (most recent call last):
File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 299, in
HandlerDispatch
result = object(req)
File "/var/lib/python-support/python2.4/django/core/handlers/modpython.py",
line 222, in handler
return ModPythonHandler()(req)
File "/var/lib/python-support/python2.4/django/core/handlers/modpython.py",
line 195, in __call__
response = self.get_response(request)
File "/var/lib/python-support/python2.4/django/core/handlers/base.py", line
128, in get_response
return self.handle_uncaught_exception(request, resolver, exc_info)
File "/var/lib/python-support/python2.4/django/core/handlers/base.py", line
148, in handle_uncaught_exception
return debug.technical_500_response(request, *exc_info)
File "/var/lib/python-support/python2.4/django/views/debug.py", line 39, in
technical_500_response
html = reporter.get_traceback_html()
File "/var/lib/python-support/python2.4/django/views/debug.py", line 95, in
get_traceback_html
c = Context({
File "/var/lib/python-support/python2.4/django/utils/encoding.py", line 35,
in smart_unicode
return force_unicode(s, encoding, strings_only, errors)
File "/var/lib/python-support/python2.4/django/utils/encoding.py", line 70,
in force_unicode
raise DjangoUnicodeDecodeError(s, *e.args)
DjangoUnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1:
ordinal not in range(128). You passed in
*** Snippets from my model:
class Metadata(models.Model):
vrstva = models.ForeignKey(Vrstva)
nazov = models.CharField(u"Názov stĺpca", max_length=100)
dlhy_nazov = models.CharField(u"Dlhý názov stĺpca", max_length=200)
hodnota = models.CharField(u"Formátovanie hodnoty", max_length=512,
default="%s")
externa_databaza = models.ForeignKey(Externa_databaza, blank=True,
null=True)
sql = models.TextField(u"SQL dopyt", blank=True)
def __unicode__(self):
return "%s %s" % (self.vrstva,self.nazov)
class Meta:
ordering = ["vrstva", "nazov"]
verbose_name_plural = u"metadata"
class Vrstva(Vrstvy_zaklad):
kategoria = models.ForeignKey(Kategoria, verbose_name=u"Kategória")
sql_atrib = models.TextField(u"Atributový SQL", blank=True)
tabulka = models.CharField(u"Tabuľka", max_length=200, blank=True,
help_text=u"Tabuľka v ktorej sú gid a geom pre danú vrstvu")
transparent = models.BooleanField(u"Transparent")
zoom_level = models.IntegerField(u"Zoom level", default=1,
help_text=u"Zoom level ktory sa použije pri zoomovaní na objekt pri
vyhľadávaní")
sql_hladanie = models.TextField(u"Vyhľadávací SQL", blank=True)
class Meta:
ordering = ['kategoria','poradie']
verbose_name_plural = u"vrstvy"
Can anybody give me some hint where to look for the solution ?
Thanks a lot
--
Ivan
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Css and Images are missing
Hello guys I need your help in here.
Sorry I am new in Django and I am having a problem, my css and jpgs
are missing.
I will write everything what i have and then maybe someone could give
me a hint :)
My settings.py:
MEDIA_ROOT = '/home/lgoncalves/Arquivos/MyVitaminesShop/media/'
MEDIA_URL = 'http://127.0.0.1:8000/media/'
ADMIN_MEDIA_PREFIX = '/media/'
My urls.py:
(r'^media/(?P.*)', 'django.views.static.serve',{'document_root':
'settings.MEDIA_ROOT'}),
And an example of base.html:
http://127.0.0.1:8000/media/
mm_health_nutr.css" type="text/css" />
http://127.0.0.1:8000/media/picture.jpg"; alt="Header image"
width="382" height="101" border="0" />
Thanks so much for your help.
Best Regards,
Luis
--~--~-~--~~~---~--~~
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: Bug in admin or in my model ?
On Sat, Nov 15, 2008 at 5:57 AM, Ivan Mincik <[EMAIL PROTECTED]> wrote:
>
> Hi,
> I have a problem when adding record by Django Admin and I am not sure where
> I have to look for it. Is this some problem in Django Admin or it can be
> solved by some
> configuration in model ?
If you are unsure whether it is a bug in Django or in your code, the right
place to post is django-users, not here. This list is for discussion of
developing Django, not using it. Even bugs discovered using Django are more
properly raised on django-users, since this list focuses more on development
discussions, not bug fixing, unless there's some discussion required as to
how a particular bug should be fixed.
> I use Foreign Key in table where I want to add record. Foreign Key is the
> field containing some non ASCII characters. See:
> http://gista.sk/dl/bugs/django/add_record_in_admin.png
> *** When I submit, I get this error:
>
> Mod_python error: "PythonHandler django.core.handlers.modpython"
>
> Traceback (most recent call last):
>
> File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 299, in
> HandlerDispatch
>result = object(req)
>
> File
> "/var/lib/python-support/python2.4/django/core/handlers/modpython.py", line
> 222, in handler
>return ModPythonHandler()(req)
>
> File
> "/var/lib/python-support/python2.4/django/core/handlers/modpython.py", line
> 195, in __call__
>response = self.get_response(request)
>
> File "/var/lib/python-support/python2.4/django/core/handlers/base.py",
> line 128, in get_response
>return self.handle_uncaught_exception(request, resolver, exc_info)
>
> File "/var/lib/python-support/python2.4/django/core/handlers/base.py",
> line 148, in handle_uncaught_exception
>return debug.technical_500_response(request, *exc_info)
>
> File "/var/lib/python-support/python2.4/django/views/debug.py", line 39,
> in technical_500_response
>html = reporter.get_traceback_html()
>
> File "/var/lib/python-support/python2.4/django/views/debug.py", line 95,
> in get_traceback_html
>c = Context({
>
> File "/var/lib/python-support/python2.4/django/utils/encoding.py", line
> 35, in smart_unicode
>return force_unicode(s, encoding, strings_only, errors)
>
> File "/var/lib/python-support/python2.4/django/utils/encoding.py", line
> 70, in force_unicode
>raise DjangoUnicodeDecodeError(s, *e.args)
>
> DjangoUnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
> 1: ordinal not in range(128). You passed in
>
>
Was there really nothing printed after "You passed in"?
>From the traceback it looks like there was an error encountered during the
save, but that error has been masked by this UnicodeDecode error in
attempting to build the debug page. So there may be two problems here. The
2nd one may very well be a Django bug but it's hard to know without more
information.
Please post to django-users with information including:
- the answer to my question above about what was printed after "You passed
in", if anything.
- a pointer to your complete models uploaded to someplace like dpaste.com --
the problem is not recreatable from the snippets you posted here since they
are missing key things (model def for a model used in inheritance,
__unicode__ for one of the models involved, etc.)
- some information on the database you are using.
Karen
--~--~-~--~~~---~--~~
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: Css and Images are missing
As this is a usage question, please post it on django-users. This list is for discussion of developing Django, not using it. Karen --~--~-~--~~~---~--~~ 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: Bug in admin or in my model ?
Thanks, I will move to django-users for more details.
On Saturday 15 November 2008 16:23, Karen Tracey wrote:
> On Sat, Nov 15, 2008 at 5:57 AM, Ivan Mincik <[EMAIL PROTECTED]> wrote:
>
> >
> > Hi,
> > I have a problem when adding record by Django Admin and I am not sure where
> > I have to look for it. Is this some problem in Django Admin or it can be
> > solved by some
> > configuration in model ?
>
>
> If you are unsure whether it is a bug in Django or in your code, the right
> place to post is django-users, not here. This list is for discussion of
> developing Django, not using it. Even bugs discovered using Django are more
> properly raised on django-users, since this list focuses more on development
> discussions, not bug fixing, unless there's some discussion required as to
> how a particular bug should be fixed.
>
>
> > I use Foreign Key in table where I want to add record. Foreign Key is the
> > field containing some non ASCII characters. See:
> > http://gista.sk/dl/bugs/django/add_record_in_admin.png
> > *** When I submit, I get this error:
> >
> > Mod_python error: "PythonHandler django.core.handlers.modpython"
> >
> > Traceback (most recent call last):
> >
> > File "/usr/lib/python2.4/site-packages/mod_python/apache.py", line 299, in
> > HandlerDispatch
> >result = object(req)
> >
> > File
> > "/var/lib/python-support/python2.4/django/core/handlers/modpython.py", line
> > 222, in handler
> >return ModPythonHandler()(req)
> >
> > File
> > "/var/lib/python-support/python2.4/django/core/handlers/modpython.py", line
> > 195, in __call__
> >response = self.get_response(request)
> >
> > File "/var/lib/python-support/python2.4/django/core/handlers/base.py",
> > line 128, in get_response
> >return self.handle_uncaught_exception(request, resolver, exc_info)
> >
> > File "/var/lib/python-support/python2.4/django/core/handlers/base.py",
> > line 148, in handle_uncaught_exception
> >return debug.technical_500_response(request, *exc_info)
> >
> > File "/var/lib/python-support/python2.4/django/views/debug.py", line 39,
> > in technical_500_response
> >html = reporter.get_traceback_html()
> >
> > File "/var/lib/python-support/python2.4/django/views/debug.py", line 95,
> > in get_traceback_html
> >c = Context({
> >
> > File "/var/lib/python-support/python2.4/django/utils/encoding.py", line
> > 35, in smart_unicode
> >return force_unicode(s, encoding, strings_only, errors)
> >
> > File "/var/lib/python-support/python2.4/django/utils/encoding.py", line
> > 70, in force_unicode
> >raise DjangoUnicodeDecodeError(s, *e.args)
> >
> > DjangoUnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
> > 1: ordinal not in range(128). You passed in
> >
> >
> Was there really nothing printed after "You passed in"?
>
> From the traceback it looks like there was an error encountered during the
> save, but that error has been masked by this UnicodeDecode error in
> attempting to build the debug page. So there may be two problems here. The
> 2nd one may very well be a Django bug but it's hard to know without more
> information.
>
> Please post to django-users with information including:
>
> - the answer to my question above about what was printed after "You passed
> in", if anything.
> - a pointer to your complete models uploaded to someplace like dpaste.com --
> the problem is not recreatable from the snippets you posted here since they
> are missing key things (model def for a model used in inheritance,
> __unicode__ for one of the models involved, etc.)
> - some information on the database you are using.
>
> Karen
>
> >
>
--
Mgr. Ivan Minčík
Gista s.r.o
tel:. 0907 639 570
email: [EMAIL PROTECTED]
http://www.gista.sk, http://demo.gisplan.sk
--~--~-~--~~~---~--~~
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.1, app() and ticket #3591
I haven't looked at the patch yet, but I'd really like to be able to change an app's name (and with it the names of the database tables), which I thought was something that this proposal would include. So fwiw, I personally would like to see it in 1.1. Michael --~--~-~--~~~---~--~~ 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.1, app() and ticket #3591
I personally was a 0 on this one. Let me explain why. I want Django to be a strong platform for developers, like myself, who really want the opportunity to have power in the framework, as well as features. As of lately I have been using Rails for a project, and to be quite honest, the maturity and feature set of Rails makes Django a lot less fun. I think the app() (last I read) could be a nice addition, but I'd much rather see the more powerful features, which fix critical issues in Django, be put in first. Issues such as multiple database support, better URL resolving, and similar tickets. While this I think provides more flexibility for pluggables, and similar, I'd much rather see it wait til 1.2 (as the list of items in the 1.1 proposals is fairly massive). On Nov 15, 11:16 am, Michael Elsdörfer <[EMAIL PROTECTED]> wrote: > I haven't looked at the patch yet, but I'd really like to be able to > change an app's name (and with it the names of the database tables), > which I thought was something that this proposal would include. So > fwiw, I personally would like to see it in 1.1. > > Michael --~--~-~--~~~---~--~~ 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.1, app() and ticket #3591
Thanks for bringing this topic up for discussion. > jezdez says: "As Jacob said, that's such a pain. I tried and wasn't > able to implement even part of the wanted features. The app cache > needs a thourough look. But I don't see installing apps multiple times > as a favored feature. I will happily participate in any work on this." > > Well, what are those features you wanted, explicitly? Mostly what has been written down at http://code.djangoproject.com/wiki/InstalledAppsRevision . Using an app multiple times is pretty difficult since it requires changes in the way the models are registered. To be honest, I'm not sure what the use case is for that. Could someone give an example please? > The "apps multiple times" would be a corner case, the minimum benefits > are third-party app disambiguation and verbose names for apps in the > admin. Did you try the #3591 patch? Yes, I tried it but wasn't convinced of how it's bound to the settings. In my (indeed unfinished) try I refactored the AppCache to live in django.core.apps that would contain instances of the new django.core.apps.base.App base class, each representing an app entity. The model loading mechanism would then use the app instances to get a list of available models, instead of the global model registry Django has now. Moving the app definition out of the settings.py would also allow i18n and all the other wonderful benefits class inheritance brings. Users would be able to subclass the django.core.apps.base.App to use hooks for app-level testing, signal registration, database prefixes and verbose names. INSTALLED_APPS could then be a list of: a) a Python path to that app class or b) a path to a Python module, e.g.: INSTALLED_APPS = ( 'django.contrib.admin', 'tagging.app.TaggingApp', 'registration', ) Those items in INSTALLED_APPS that aren't paths to App subclasses would prompt the AppCache to create App instances on runtime by using the base class -- much like the admin does it now with ModelAdmin classes. Additional (and future) use cases could be inter-app dependencies and compatibility with the WSGI app standard -- although I understand that's very much debatable. Cheers, Jannis --~--~-~--~~~---~--~~ 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.1, app() and ticket #3591
On Nov 15, 6:57 pm, David Cramer <[EMAIL PROTECTED]> wrote: > I personally was a 0 on this one. Let me explain why. I want Django to > be a strong platform for developers, like myself, who really want the > opportunity to have power in the framework, as well as features. As of > lately I have been using Rails for a project, and to be quite honest, > the maturity and feature set of Rails makes Django a lot less fun. I > think the app() (last I read) could be a nice addition, but I'd much > rather see the more powerful features, which fix critical issues in > Django, be put in first. Issues such as multiple database support, > better URL resolving, and similar tickets. While this I think provides > more flexibility for pluggables, and similar, I'd much rather see it > wait til 1.2 (as the list of items in the 1.1 proposals is fairly > massive). > It's understood that other things might have higher priorities, but it's not a zero-sum game. Developers scratch their own itches, and I'm willing to put in the work on this particular feature - so unless you feel that putting this feature in now would get in the way of other things, then there's no reason for it not to go in since there's a patch which passes all existing regression tests and the implementation has a limited impact on other code, primarily settings.INSTALLED_APPS -> get_installed_app_paths(). Best regards, Vinay Sajip --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Suggestion for doc search
Would it be possible to have the doc search add a "-inurl:olddocs" to all search queries? Anytime you search for something without it right now, you always hit the redirect warning, even though there was no redirect, and it was confusing a few users today in IRC, since they thought they hit an out of date doc page. -- Collin Grady --~--~-~--~~~---~--~~ 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.1, app() and ticket #3591
On Nov 15, 7:19 pm, Jannis Leidel <[EMAIL PROTECTED]> wrote:
> Thanks for bringing this topic up for discussion.
>
> > jezdez says: "As Jacob said, that's such a pain. I tried and wasn't
> > able to implement even part of the wanted features. The app cache
> > needs a thourough look. But I don't see installing apps multiple times
> > as a favored feature. I will happily participate in any work on this."
>
> > Well, what are those features you wanted, explicitly?
>
> Mostly what has been written down
> athttp://code.djangoproject.com/wiki/InstalledAppsRevision
Thank you for your response. If you mean
* Allow change of name of third-party app
* Allow change of db_prefix of third-party app
* Allow multiple instances of an app with different names,
db_prefix, etc.
> .
>
> Using an app multiple times is pretty difficult since it requires
> changes in the way the models are registered. To be honest, I'm not
> sure what the use case is for that. Could someone give an example
> please?
>
I'm not sure there is a particularly good case for worrying
excessively about multiple instances of the same app, as it's hardly
the common case. Are not the first two of the three goals sufficient
justification? Given that there is an ever-increasing body of
applications out there, the chances of a name clash in the label is
also ever-increasing. AFAIK, the #3591 patch meets the first two
goals, assuming that by "name of third-party app" you mean a verbose
name which can be e.g. internationalised. I would rather not bang on
about the multiple-instances-of-the-same-app case because it would be
a side benefit rather than a benefit which would be widely enjoyed.
>
> Yes, I tried it but wasn't convinced of how it's bound to the
> settings. In my (indeed unfinished) try I refactored the AppCache to
> live in django.core.apps that would contain instances of the new
> django.core.apps.base.App base class, each representing an app entity.
> The model loading mechanism would then use the app instances to get a
> list of available models, instead of the global model registry Django
> has now. Moving the app definition out of the settings.py would also
> allow i18n and all the other wonderful benefits class inheritance
> brings.
I'm not quite sure what you mean by "wasn't convinced of how it's
bound to the settings." Did it work, in the sense that you could
disambiguate apps and apply verbose names to them? In my
implementation, I went for minimal changes to the Django source,
because I thought it would make it easier for people to scan,
understand, review and hopefully accept the changes. If the basic
premise of an app class - instances of which can live in
settings.INSTALLED_APPS - is acceptable (and, of course, this means
instances of subclasses of app can live in settings.INSTALLED_APPS
too) then the precise location of an implementation (e.g.
django.core.apps) can be refined. Also, the functionality of that app
class (the base class) can be enhanced over time. What's important as
the first step is to have a place to hang your hat when talking about
an app instance in a Django site.
> Users would be able to subclass the django.core.apps.base.App to use
> hooks for app-level testing, signal registration, database prefixes
> and verbose names. INSTALLED_APPS could then be a list of: a) a Python
> path to that app class or b) a path to a Python module, e.g.:
>
> INSTALLED_APPS = (
> 'django.contrib.admin',
> 'tagging.app.TaggingApp',
> 'registration',
> )
>
> Those items in INSTALLED_APPS that aren't paths to App subclasses
> would prompt the AppCache to create App instances on runtime by using
> the base class -- much like the admin does it now with ModelAdmin
> classes.
>
> Additional (and future) use cases could be inter-app dependencies and
> compatibility with the WSGI app standard -- although I understand
> that's very much debatable.
>
Previous objections by the committers have been about the apparent
complexity of proposed changes, and I have tried to keep the design/
implementation as minimal as possible in deference to these worries.
However, the approach allows app-centric functionality to be refined
over time, and I can't see any specific problems with the current
approach which would hamper this refinement. I believe your idea of
using app class names in INSTALLED_APPS is weaker than using app class
instances because it does not allow you to parametrise entries in the
simplest possible way. For example, if I have a couple of third-
party applications whose package paths end in 'auth' and 'comments',
and I want to also use 'django.contrib.auth' and
'django.contrib.comments' on my site, then I have a problem with
app_labels 'auth' and 'comments'. With app instances in the mix, I can
do for example
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.comments',
...
app('third.party.app1.package.path.ends.in.auth', 'tp_auth'),
app('third.party.app2.packa
Re: Proposal: Minor admin CSS refactoring
Just wanted to update to say the bulk of this is now done (Steps 1, 2 and 3). One note: the file structure is largely the same, but I did remove the hidden import rules in each file that made it confusing as to which styles were being included where. Each stylesheet is now explicitly linked to from the template in addition to base.css (rather than overriding base.css and then re-importing base.css as it was before). The end result is that it's now possible to reuse the individual stylesheets (like forms.css or widgets.css) on custom admin pages without including extraneous rules. More details in the commit log: http://code.djangoproject.com/changeset/9463 --~--~-~--~~~---~--~~ 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: ANN: Django 1.0.1 released
On Sat, Nov 15, 2008 at 7:48 AM, leonel <[EMAIL PROTECTED]> wrote: > Ive downloaded the tar.gz from > http://www.djangoproject.com/download/1.0.1/tarball/ > > and the md5sum does not match the md5sum from: > http://media.djangoproject.com/pgp/Django-1.0.1-final.checksum.txt OK, so here's what happened: 1. When I rolled the release last night, I did 'python manage.py sdist' to generate the package, then uploaded it to the djangoproject.com server. 2. I then made my fatal error, which was that I uploaded it to the Cheese Shop via 'python setup.py sdist upload'. 3. And then I did the checksums and placed the signed file on djangoproject.com. Astute readers will notice what I did not, namely that step 2 re-generated the package, resulting in a tarball whose constituent files and directories have slightly different creation times than the package from step 1. And as a result, the checksums of the package generated in step 2 are different from the checksums of the package generated in step 1 -- even though their unpacked contents are identical -- because 'tar' stores information about creation time in the resulting compressed file. So I've replaced the package on djangoproject.com with the copy generated in step 2 above, and we've verified that its contents and its checksums match exactly. Your friendly local release manager apologizes for the inconvenience, and will now go find someplace to hang his head in shame. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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: ANN: Django 1.0.1 released
On Sat, Nov 15, 2008 at 8:42 PM, James Bennett <[EMAIL PROTECTED]> wrote: > 1. When I rolled the release last night, I did 'python manage.py > sdist' to generate the package, then uploaded it to the > djangoproject.com server. (and obviously I meant 'setup.py sdist') -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Multi-Threaded Dev Server
I think http://code.djangoproject.com/ticket/3357 should be given another look at enabling optional multi-threading on the dev server. Jacob previously closed this ticket, noting the patch could introduce threading bugs, and would provide functionality too similar to that of a production environment. This is my rationale to accept this ticket: 1. Ajax is very common place, and often requires a multi-threaded server. The dev server is very convenient, but by not providing multi- threading support, we're preventing it from being even more useful. 2. Since multi-threading would be an optional setting, the default scenario would still be single-threaded and would not break anything. Only those specifically desiring multi-threading would subject themselves to any unforeseen bugs. 3. Fear of multi-threading bugs shouldn't be a reason to avoid multi- threading, especially when it could be very useful. We don't even know if there are multi-threading bugs. And even if there are, they can be fixed. Regards, Chris --~--~-~--~~~---~--~~ 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: Multi-Threaded Dev Server
Does it need to be multi-threaded? Can you get a multi-process dev server instead/also? On Sun, Nov 16, 2008 at 1:26 AM, Chris <[EMAIL PROTECTED]> wrote: > > I think http://code.djangoproject.com/ticket/3357 should be given > another look at enabling optional multi-threading on the dev server. > > Jacob previously closed this ticket, noting the patch could introduce > threading bugs, and would provide functionality too similar to that of > a production environment. > > This is my rationale to accept this ticket: > 1. Ajax is very common place, and often requires a multi-threaded > server. The dev server is very convenient, but by not providing multi- > threading support, we're preventing it from being even more useful. > 2. Since multi-threading would be an optional setting, the default > scenario would still be single-threaded and would not break anything. > Only those specifically desiring multi-threading would subject > themselves to any unforeseen bugs. > 3. Fear of multi-threading bugs shouldn't be a reason to avoid multi- > threading, especially when it could be very useful. We don't even know > if there are multi-threading bugs. And even if there are, they can be > fixed. > > Regards, > Chris > > > > -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy --~--~-~--~~~---~--~~ 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: Multi-Threaded Dev Server
If the patch that's currently on there works with no changes at all, I'd be hesitantly in favor of it, however if there any bugs, or other complications associated with it, my answer is to use a real server, setting up something like CherryPy locally is almost no effort, as seen here: http://www.oebfare.com/blog/2008/nov/03/writing-custom-management-command/ On Nov 16, 1:39 am, "Calvin Spealman" <[EMAIL PROTECTED]> wrote: > Does it need to be multi-threaded? Can you get a multi-process dev > server instead/also? > > > > On Sun, Nov 16, 2008 at 1:26 AM, Chris <[EMAIL PROTECTED]> wrote: > > > I thinkhttp://code.djangoproject.com/ticket/3357should be given > > another look at enabling optional multi-threading on the dev server. > > > Jacob previously closed this ticket, noting the patch could introduce > > threading bugs, and would provide functionality too similar to that of > > a production environment. > > > This is my rationale to accept this ticket: > > 1. Ajax is very common place, and often requires a multi-threaded > > server. The dev server is very convenient, but by not providing multi- > > threading support, we're preventing it from being even more useful. > > 2. Since multi-threading would be an optional setting, the default > > scenario would still be single-threaded and would not break anything. > > Only those specifically desiring multi-threading would subject > > themselves to any unforeseen bugs. > > 3. Fear of multi-threading bugs shouldn't be a reason to avoid multi- > > threading, especially when it could be very useful. We don't even know > > if there are multi-threading bugs. And even if there are, they can be > > fixed. > > > Regards, > > Chris > > -- > Read my blog! I depend on your acceptance of my opinion! I am > interesting!http://techblog.ironfroggy.com/ > Follow me if you're into that sort of thing:http://www.twitter.com/ironfroggy --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
