Re: modularity of apps
Not wanting to get overly involved, but I just want to put my 2p in on
this.
Todd O'Bryan wrote:
> 1. Allow people to set a prefix for each app in the settings.py file.
> This would basically tell the app what URLs that are mapped to it
> start with, and views and templates inside the app could use this
> when they want to create internally mapped URLs. By default, it would
> also pass control of any URL starting with the prefix to the given
> app's urls.py module, much as already happens, I imagine, in most
> people's implementations, but the prefix would be an attribute of the
> app, rather than some unconnected string as it is now.
I not a fan of the idea that apps must map to a particular tree of URLs
(i.e.
the blog app is always under /blog/). It's a common implementation, and
a good
one, but I don't necessarily think it fits all projects. I'd rather we
could
say "write your apps using relative references, and here's a toolkit to
help
you"
Basically I like the how powerful and how specific the current urls.py
scheme
is (sidenote: you're never going to get RoR's 'trigger a nasty script
from a
URL because I was trying to be clever' hole in django :-) ). I'd be
sorry to
see it usurped by side-effects of other processes.
In fact, I'd rather this sort of conversation focused more on 'best
practices', and utilising what is already available, rather than
introducing
extra mechanisms (especially 'magic' ones) unless really required.
btw: It's always bugged me that the tutorial on de-coupling app urls
[1]
moves the app specific urls into the app directory, but still has to
reference
the 'mysite' project name in it's urlconf.
[1]
http://www.djangoproject.com/documentation/tutorial3/#decoupling-the-urlconfs
Malcolm Wrote:
> Bill Wrote:
> > Plone (products) and Eclipse (osgi) do a good job structurally. But any
> > kind of plugin framework models suggest Django shift from being a web
> > framework to an app server. It's quite a difference, imo.
>
> Agreed. This was something I was having to explain in my chat with the
> Drupal guy as well. That Django was a little more generic than Drupal.
+1. Django is not just an app server!
For the dependancy/registration stuff, I like the idea of putting some
boiler
plate code in __init__.py. If INSTALLED_APPS is iterated over at some
point
during startup, it could inspect some predefined attributes to see if
dependancies are met.
e.g. __init__.py:
APPNAME= "Lebowski"
APPVERSION = "0.3"
REQUIRES = (("White Russian", ">=3.0"),
("Rug", "=1.0"))
def register(**kwargs):
settings.TEMPLATE_DIRS.append(kwargs['app_path']+"/templates/bowling")
in settings.py:
INSTALLED_APPS = (blah,
blah,
mysite.lebowski,
blah)
APP_ARGUMENTS = {mysite.lebowski : {'app_path' :
"/home/django_apps/lebowski",
'something_else' : 42}}
If any of these things aren't there, no harm, no foul. If they are they
get
checked/called.
It's pretty simple to understand, and pretty flexible. I'm in two minds
about
the register function though. I think if you have somewhere where
people
can do things like modify settings then they're likley to abuse it,
especially
if they start trying to add things which are ordered. Maybe they just
need a
separate 'requires list' like the one above for apps.
e.g. __init__.py:
REQUIRES_MIDDLEWARE =
('django.contrib.auth.middleware.AuthenticationMiddleware',)
And then it's just down to the person installing that they're on the
list and in
a good order.
Paul
--~--~-~--~~~---~--~~
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: Re: modularity of apps
On 8/13/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> The Lawrence guys have mentioned on this list previously that they have
> many different applications they pull together in various projects.
:)
If we couldn't modularize, we wouldn't be able to sell different
"editions" of Ellington.
The more I think about it, the more I like the idea of using imports
in __init__.py to specify an application's dependencies; the thing
that'd make it especially nice would be some method -- either
conventional or built straight in to Django -- of checking for
"importable" versus "installed" and for throwing nicer error messages.
Something like this, maybe:
from django.conf import settings
dependencies = (
{'name': 'tags', 'module': 'foo.tags'},
{'name': 'todo', 'module': 'bar.todo'},
{'name': 'comments', 'module': 'django.contrib.comments'},
)
dependency_errors = []
for app in dependencies:
try:
__import__(app['module'])
except ImportError:
dependency_errors.append("The '%s' application is required,
but is not present on this system" % app['name'])
finally:
if not app['module'] in settings.INSTALLED_APPS:
dependency_errors.append("The '%s' application is
required, but is not listed in Django's installed applications" %
app['name'])
if dependency_errors:
### echo them to console, or pass along to a management function
For extra bonus points, we'd make it use the stuff in
django/core/management to verify that the needed app, if importable
and in INSTALLED_APPS, is either already installed into the DB or
scheduled to be during the current 'syncdb' run.
Anything more complex would be tending a bit too much toward the "app
server", I think.
--
"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: admin/doc for templates ?
On 8/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 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 ? Hi Dirk, I'm not sure what sort of template documentation we could add. Would it just be a list of all the available templates, or what? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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: admin/doc for templates ?
Hi Adrian, > I'm not sure what sort of template documentation we could add. Would > it just be a list of all the available templates, or what? what about where exactly the template is located ? I had a problem that the same template was located in different places and I didn't know that. what about the template-extends structure ? It is hard to see which templates are inherited, if you don't know the complete template set. what about the loaded templatetag-sets and where they are located ? Regards, Dirk -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer --~--~-~--~~~---~--~~ 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 and LDAP support
On Sat, Aug 12, 2006 at 10:11:53PM -0700, Gary Wilson wrote:
> You can remove the l.unbind_s() on line 77.
:) Thanks again.
>
> It would also be great if the authenticate() method wasn't tied to the
> contrib.auth.models.User model. I, for one, use my own custom user
> model. Maybe extracting the parts that try to get and update the user
> in authenticate() could be extracted to another method so that people
> using a custom user model could easily override these methods.
>
> Maybe the LDAP_BIND_STRING_FUNC should be moved to a class method
> instead, which would be empty by default? Then you could just inherit
> LDAPBackend and override this pre_bind() method if you wanted to do
> something special (like bind with a service account first). This
> pre_bind() could be called after intialize() and be passed the ldap
> object and username, just as LDAP_BIND_STRING_FUNC.
>
I've been thinking about how to decouple from contrib.auth.models.User,
and I think having people inherit and override is the best method. With
that change the LDAP_BIND_STRING_FUNC would be changed as suggested.
I'll probably have a patch up tonight changing this.
One question: should I leave in the provided mk_pre_auth_bind() function?
If I did you could override the pre_bind function simply by:
pre_bind = mk_pre_auth_bind('username', 'pass')
It sounds like there are enough people looking for the feature so I
think leaving it in is a benefit.
Anyhow, let me know if you have any thoughts, and I'll have the patch in
tonight.
Scott
--
Scott Paul Robertson
http://spr.mahonri5.net
GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601
signature.asc
Description: Digital signature
Admin Interface: extend change_list.html vs change_list_results.html
I have been fiddling around to add something to the Admin interface for a system I'm building. Basically, I am adding a total for the duration of the set of time tracker elements which are displayed. I did it by making a copy of change_list.html and adding a call to a custom template tag. It works "okay", but in looking at ways to make it better I ran into a difference I'd like to toss around and see if it is my understanding of it at fault or if I should create an enhancement ticket for it. I used the new Admin changes (covered at http://code.djangoproject.com/wiki/NewAdminChanges in the section "Admin converted to separate templates") for change_list.html. I am making use of the "magic" usage of a "templates" directory inside an app to serve up templates without explcitly adding them to TEMPLATE_DIRS in settings.py. Therefore, I have a directory like myproject/myapp/templates/admin/myapp/mymodel with change_list.html in it. I added my template tag class to the "load" and called it in the "result_list" block, and it shows the total duration for the events in the list. That is the "okay" part, because it isn't part of the table created within the "result_list template tag, so it doesn't look quite right. I looked into the result_list tag and saw that it uses change_list_results.html, and that it renders the actual table, so I thought I'd put a copy of it in place with the change_list.html. No joy. I tried every directory up the tree without success. I had to add a reference to a separate template directory in TEMPLATE_DIRS in settings.py, then put change_results_list.html into an admin directory inside that for it to work. Therefore, my two templates which act together to show a set of results, no live in two completely separate tree structures. I wonder whether or not that is desirable. It seems that the "magic" of having a templates directory within myproject/myapp would be even more magical if everything could make use of it, and that having those two related files closer together would make it easier to find them. I know that I could create a TEMPLATE_DIRS entry and put EVERYTHING in there, but I like the separation of templates into app-specific branches. If this should be a ticket, I'd be more than happy to enter it. If I'm not looking at it right, thanks for any hints in the right direction. H.B. --~--~-~--~~~---~--~~ 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: Re: admin/doc for templates ?
On 8/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > what about the loaded templatetag-sets and where they are located ? Template tag libraries already get picked up, and if they've got docstrings those should be displayed. -- "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: Re: admin/doc for templates ?
Hi James, James Bennett schrieb: > On 8/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> what about the loaded templatetag-sets and where they are located ? > > Template tag libraries already get picked up, and if they've got > docstrings those should be displayed. I mean which templatetags libraries are loaded from a template. Probably with a cross reference link to the doc of the templatetags. Regards, Dirk -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer --~--~-~--~~~---~--~~ 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: admin/doc for templates ?
On 8/14/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > what about where exactly the template is located ? > I had a problem that the same template was located in different places and I > didn't know > that. > > what about the template-extends structure ? > It is hard to see which templates are inherited, if you don't know the > complete template > set. > > what about the loaded templatetag-sets and where they are located ? Hi Dirk, This sounds like a great addition to the automatic admin documentation. Would you be willing to code up the patch? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Checking Permission Template Tag
Hi,
Joseph and I were talking earlier this evening about how to replace the
permission wrapper context to allow for his generic auth and my row
level permission. We could not determine a way to expand the current
context processor to allow an object to be passed (if you have any
ideas, please let us know).
So what I have done is create a template tag to check for permissions.
It is basically an if statement focused on permissions.
The syntax is
{% load auth %}
{% if_has_perm [not] (permission_codename) [object] %}
{% end_if_has_perm %}
The params in square brackets are optional, you do need to pass on the
permission codename. Right now, the permission codename has to be in
the format that is accepted by user.has_perm (which is
app_label.codename). It can also have an {% else %} tag imbetween the
start and end. I did not implement any AND or OR into it, I think it
would be too busy if they were put in. The user is assumed to be the
current user
Any thoughts on this? Do you think this is an ideal way of checking for
permissions? Or do you know a method we can use to pass the object to
the perm wrapper?
Thanks,
Chris
PS: To see the actual code, check revision 3589 in
per-object-permission branch.
--~--~-~--~~~---~--~~
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 and LDAP support
On Mon, Aug 14, 2006 at 12:51:47PM -0600, Scott Paul Robertson wrote:
> Anyhow, let me know if you have any thoughts, and I'll have the patch in
> tonight.
>
Patch is in place. I'm aware of a trailing sentence in the doc string
and a typo with get_user() in the doc string as well, but won't worry
about that till it's be checked and tested.
So now if you want to change the model for the user you simply:
class MyBackend(LDAPBackend):
def _get_user_by_name(self, username):
return Model.objects.get(username=username)
def _create_user_object(self, username, password):
return Model(username, password)
def get_user(self, userid):
try:
return Model.objects.get(pk=userid)
except:
return None
And you can change the generation of the bind string like so:
class MyBackend(LDAPBackend):
_pre_bind = LDAPBackend.mk_pre_auth_bind('user', 'pass')
It seems pretty clean to me, and allows for more flexibility. Let me
know what all of you think, and if there is anything else that should
change.
Scott
(http://code.djangoproject.com/ticket/2507)
--
Scott Paul Robertson
http://spr.mahonri5.net
GnuPG FingerPrint: 09ab 64b5 edc0 903e 93ce edb9 3bcc f8fb dc5d 7601
pgpAinNrT2ksA.pgp
Description: PGP signature
