Luke,
I completely agree on the need for change and personally +1 this as
it is a completely confusing historical annoyance.
However, as in all deprecation, I would suggest that we start with a
global setting that allows these links to be hidden on an installation
by installation basis and the de
Hi Luke,
On 05/23/2011 05:14 PM, Luke Plant wrote:
> On 23/05/11 18:33, Carl Meyer wrote:
>>> It is not nearly as invasive as the other changes you suggested.
>>> However, it does fix the failing tests in my project (i.e. fixes
>>> csrf_protect), and leaves TemplateResponse objects unrendered as l
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 set
On 23/05/11 18:33, Carl Meyer wrote:
> On 05/23/2011 11:31 AM, Luke Plant wrote:
>> Putting all these things together, I've uploaded a new patch to #16004:
>>
>> http://code.djangoproject.com/attachment/ticket/16004/16004.fix.alternative.diff
>>
>> It is not nearly as invasive as the other changes
On 23/05/11 19:45, Idan Gazit wrote:
> I agree that it's redundant and unnecessary, but absent a particular
> *need* to remove it, I'd say leave it until the admin gets an overall
> refresh.
>
> While having two links may be marginally confusing for new users,
> _removing_ an existing bit of funct
This looks interesting so far.
How does setting the form layout affect rendering individual fields in
a form?
Is the output of {% renderform my_form "first_name" %} equivalent to
{{ form.first_name }}, or is it more like the output of "as_p" or
"as_table"? Which templates are involved in a form l
I agree that it's redundant and unnecessary, but absent a particular *need*
to remove it, I'd say leave it until the admin gets an overall refresh.
While having two links may be marginally confusing for new users, _removing_
an existing bit of functionality is akin to a breaking change, IMO. It'
On 05/23/2011 11:31 AM, Luke Plant wrote:
> I think your core idea is quite interesting. I haven't had time to think
> through all the implications.
>
> It does make the result of what is returned from view functions rather
> obscure, and this could affect things like testing.
I don't think it'
On Mon, May 23, 2011 at 6:52 PM, Luke Plant wrote:
> On 23/05/11 16:18, Mateusz Marzantowicz wrote:
>
> > Is there any reason to keep this column? Can I remove it?
> >
> >
> > Yes, you can. It''s how Open Source works. You get the source code and
> > do with it what you want. Django is very m
On 23/05/11 16:18, Mateusz Marzantowicz wrote:
> Is there any reason to keep this column? Can I remove it?
>
>
> Yes, you can. It''s how Open Source works. You get the source code and
> do with it what you want. Django is very modular and easy to change. You
> can override admin template bas
Hi,
I like the API and I'm looking forward to this. Just a small comment
on the {% widget %} tag:
On Sun, May 22, 2011 at 10:21 PM, Gregor Müllegger wrote:
> (You can read this RFC online if you prefer:
> https://github.com/gregmuellegger/gsoc2011-stuff/blob/master/rfc_syntax.rst )
> {% widg
Hi Carl,
I think your core idea is quite interesting. I haven't had time to think
through all the implications.
It does make the result of what is returned from view functions rather
obscure, and this could affect things like testing.
For example, the new tests I wrote for decorator_from_middlew
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
ca
On Mon, May 23, 2011 at 12:54 PM, Luke Plant wrote:
>
> Is there any reason to keep this column? Can I remove it?
>
>
Yes, you can. It''s how Open Source works. You get the source code and do
with it what you want. Django is very modular and easy to change. You can
override admin template based o
Hi Luke,
On May 11, 7:00 pm, Luke Plant wrote:
> Yeah, I guess I was seeing TemplateResponse as the culprit, on the basis
> of Last In First Out, but maybe it's decorators we need to be worrying
> about.
>
> I've actually documented a specific instance of #15855 in the CRSF docs
A possible fix f
Hi Jonathan,
On 05/23/2011 04:30 AM, Jonathan Slenders wrote:
> 1. Like Carl said, I always prefer template tags which alter the
> context to create a scope. (I hate {% url ... as varname %})
>
> {% form "table" %}
> {% renderform my_form %}
> {% endform %}
Well, in any case, not all context
On Mon, May 23, 2011 at 6:54 AM, Luke Plant wrote:
> Is there any reason to keep this column? Can I remove it?
I don't really see the point of removing it. Generally index pages are not
pressed for space. People may be more used to using the Change links than
the links on the left, removing th
On Mon, May 23, 2011 at 1:54 PM, Luke Plant wrote:
> On the admin index page, you've got things like this:
>
> == Auth ==
> Groups | Add | Change
> Users| Add | Change
>
> The 'Change' links are completely redundant - they take you to the same
> places as the links in the first column
On the admin index page, you've got things like this:
== Auth ==
Groups | Add | Change
Users| Add | Change
The 'Change' links are completely redundant - they take you to the same
places as the links in the first column (e.g. Groups/Users). This is bad
because:
1) They're confusing -
1. Like Carl said, I always prefer template tags which alter the
context to create a scope. (I hate {% url ... as varname %})
{% form "table" %}
{% renderform my_form %}
{% endform %}
2. Also totally agreed with Russell that we need consistency about
when template tag parameters need to be q
20 matches
Mail list logo
