Re: need add RELATIVE_URL_ROOT as a default settings for project?

[Russell Keith-Magee]

On Tue, May 24, 2011 at 11:19 AM, vicalloy  wrote:
> if project is hosted at : mydomain.com/hidjango/
> you need do some settings.
> 1. the session path need set to /hidjango/, but it will use default set '/'.
> 2. also you need create a hidjango_urls like:
> urlpatterns = patterns('',
>     (r'^hidjango/', include(urls)),
> )
> 3. modify LOGIN_URL
> need add a settings  as ROR's  RAILS_RELATIVE_URL_ROOT?
> link:
> http://guides.rubyonrails.org/v2.3.8/configuring.html#rails-environment-settings

This has been proposed and rejected in the past:

https://code.djangoproject.com/ticket/8906

The reasoning for this decision stems from the fact that settings.py
is intended to be a project-specific file, not something that is a
redeployable asset. Therefore, you *should* need to modify settings.py
if you want to deploy to a different sub-URL.

There is a separate discussion about whether LOGIN_URL should be
easier to use -- in particular, whether it should allow the use of
named URLs.

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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Caching model choice fields in admin inlines.

[andybak]

I seem to recall a similar problem rears it's ugly head on editable
changelists too.

And obviously it's potentially worse there as n can often be larger.

On May 23, 4:29 pm, Sean Brant  wrote:
> If you have ever used a inline in the admin for a model that contained
> a model choice field you have probably noticed it has to query the
> database for each row to fill the select drop-down. This results in n+
> identical queries.
>
> I though it might be useful to have a way to tell a admin inline to
> cache the choices of fields. Here is some rough code that gets the job
> done::
>
>     from django.forms.models import BaseInlineFormSet
>
>     class CachedInlineFormSet(BaseInlineFormSet):
>         cached_fields = []
>
>         def _construct_form(self, i, **kwargs):
>             form = super(CachedInlineFormSet, self)._construct_form(i,
> **kwargs)
>             for cache_field in self.cached_fields:
>                 field = form.fields[cache_field]
>                 field.cache_choices = True
>                 choices = getattr(self, '_cached_%s_choices' %
> cache_field, None)
>                 if choices is None:
>                     choices = list(field.choices)
>                     setattr(self, '_cached_%s_choices' % cache_field,
> choices)
>                 field.choice_cache = choices
>             return form
>
>     class CachedTabularInline(admin.TabularInline):
>         cached_fields = []
>
>         def get_formset(self, request, obj=None, **kwargs):
>             formset = super(CachedTabularInline,
> self).get_formset(request, obj=None, **kwargs)
>             formset.cached_fields = self.cached_fields
>             return formset
>
>     class MyInline(CachedTabularInline):
>         model = MyModel
>         cache_fields = ['myfk']
>
> Im not super big on how this patches the classes in various places so
> i'm open to better suggestions. Is this something that the admin could
> benefit from or is this better kept as a 3rd party tool?

-- 
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: list_display does not allow foreign keys __ syntax

[Anshuman Aggarwal]

Hate to bump a thread, but any thoughts on the last proposal, Luke?

On May 20, 4:13 pm, Anshuman Aggarwal  wrote:
> Usage would be: list_display = (ff('model__field__fkfield',
> short_description='FK Field') but ideally, the short_description
> should be optional with the default logic being used to fetch it out
> of the FK.
>
> We can change the __ to a . easily enough without any impact to
> anything else.
>
> On May 20, 4:08 pm, Anshuman Aggarwal  wrote:
>
>
>
>
>
>
>
> > Hi Luke,
> >  Thanks for a detailed reply. I have gone over your points carefully
> > and agree on most except a few key ones.
>
> > Based on your response:
> >  - The question here is really how often is the guesswork right and
> > for how many different projects/use cases.
> > I have overseen Django used at more than a few projects and my
> > observation is that the guesswork logic that you described that is
> > presently followed for the headers will work very well (~75%) for FK
> > fields (i.e. take short description/verbose_name/name of field itself)
> > from the final model.
> > I realize that this may not be perfect and for advanced cases a
> > fallback to callables would be required. its anybody guess without
> > analyzing every single django project out there to say how many people
> > would benefit.
>
> > All in all, without this estimation maybe not worth the effort you
> > described building the . syntax
>
> > I have an alternate suggestion:
> > Can we develop the accessor callable that you described to be able to
> > access the short descrition/verbose_name etc and make it available as
> > a shortcut/decorator in the admin? With that, it won't complicate code
> > for the main admin, while keeping a quickie around for others??
> > I have taken your example and developed it a bit (though it still
> > violates DRY IMHO), but was wondering how the admin can pass in a
> > parameter with the model description so that it can be traversed to
> > obtain the field  verbose_name/short_description parameters
>
> > def ForeignFieldFunc(field_name, short_description=None,
> > admin_order_field=None):
> >     def accessor(obj):
> >         val = obj
> >         for part in field_name.split('__'):
> >             val = getattr(val, part)
> >         return val
> >     if short_description:
> >         accessor.short_description = short_description
> >     else:
> >         accessor.__name__ = field_name
> >     if admin_order_field:
> >         accessor.admin_order_field = admin_order_field
> >     else:
> >         accessor.admin_order_field  = (field_name,)
> >     return accessor
>
> > Regards,
> > Anshuman
>
> > On May 17, 11:35 pm, Luke Plant  wrote:
>
> > > Hi Anshuman,
>
> > > On 17/05/11 14:42, Anshuman Aggarwal wrote:
>
> > > > list_display
> > > > allows for callables and hence arbitrary names can be used which are
> > > > similar to the syntax for foreign key fields.
> > > > However, this problem exists for list_filter also: someone may define
> > > > a
> > > > field with the name class__field and try to use that in list_filter as
> > > > a
> > > > foreign key field. (i've just checked that you can indeed name a field
> > > > like that)
>
> > > > So we can't really be compensating for dev stupidity at the cost of
> > > > functionality as we haven't done in list_filter also.
> > > > Since all FKs always start with an alphabet are in the regex format
> > > > (.+__.+.*), the __unicode etc cases can be easily and correctly
> > > > filtered
> > > > as is required to be done in list_filter.
>
> > > OK, back to basics:
>
> > > ModelAdmin.list_display answers this question:
>
> > > 1) Given a Python object that is a Model instance, what pieces of
> > > information should we display about it in the admin change list?
>
> > > It answers the question in this way:
>
> > > We display string representations of A) attributes of the instance,
> > > which can be defined by strings and B) where that does not suffice,
> > > arbitrary callables, which can be defined by strings (referring to
> > > ModelAdmin attributes), or can be actual callables.
>
> > > However, once you've answered that question, you've got another:
>
> > > 2) Given only a ModelAdmin and/or Model class, how can we define
> > > *titles* (i.e. column headers) for the pieces of information defined by
> > > list_display?
>
> > > The answer to this is harder, because in general we can't. However, we
> > > can make some pretty good guesses that will cover 95%. These include:
>
> > >   A) if the piece of information is an attribute that is a field on the
> > >      class, use metadata from the Model field to create the title i.e.
> > >      Field.verbose_name.
>
> > >      This is a very good guess, because we can be pretty sure that the
> > >      attribute will correspond to the field.
>
> > >   B) if the attribute is '__str__', use the verbose_name of the Model
>
> > > Failing this:
>
> > >   C) Just turn