On 1/12/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
Crap. Lets try this again without tabbing onto the send button.
On 1/12/06, Adrian Holovaty <
[EMAIL PROTECTED]> wrote:
On 1/11/06, scum <[EMAIL PROTECTED]> wrote:> Could the comment tag be simplified to something like {! !} or {# #}.
We've
In the IRC channel tonight there was some discussion (mostly motivated
by ticket #1204) about template tags and filters failing silently,
particularly those in the markup app. Since it was kind of late and
people were popping in and out it sputtered, but I think it's an
interesting topic to bring
> Also, I don't believe post_url would allow you to use something like
the new object id in your url.
I needed this capability (I have wizard-like interfaces derived from
the admin pages), and ended up modifying change_stage so it read
something like this:
redir = redir_dict.get(None, '../../')
Adrian Holovaty wrote:
You can get started, if you're willing to use the magic-removal branch. :)
The event system is in that branch, in django.dispatch.
Ok. I'll get to it as soon as I could kill some more lines from ToDo on
my desktop :-)
On 1/11/06, Maniac <[EMAIL PROTECTED]> wrote:
> I kinda want to write such a thing if there are no serious objections
> and when event system is ready.
You can get started, if you're willing to use the magic-removal branch. :)
The event system is in that branch, in django.dispatch.
Adrian
--
A
Crap. Lets try this again without tabbing onto the send button.
On 1/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
On 1/11/06, scum <[EMAIL PROTECTED]> wrote:> Could the comment tag be simplified to something like {! !} or {# #}.We've already got two different types of tags -- {% %} and {{ }} -
On 1/12/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
>
> On 1/11/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
> >
> > I've been looking at the same thing in the last day and I found the
> > 'post_url' keyword arg to the add_stage() view that allows you to
> > redirect somewhere after adding
On 1/12/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
On 1/11/06, scum <[EMAIL PROTECTED]> wrote:> Could the comment tag be simplified to something like {! !} or {# #}.We've already got two different types of tags -- {% %} and {{ }} --
and introducing a third would be too complex for my tastes.Adr
On 1/11/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote:
>
> I've been looking at the same thing in the last day and I found the
> 'post_url' keyword arg to the add_stage() view that allows you to
> redirect somewhere after adding a new object but this arg doesn't
> exist for the change_stage() vie
On 1/12/06, oggie rob <[EMAIL PROTECTED]> wrote:
>
> > Another option would be to have the callable return a (url, message)
> tuple, and let the view handle HttpResponseRedirect and
> request.user.add_message.
>
> I think you should use a dictionary. For example, you could pass in the
> following
Maniac wrote:
- auth app using event system hooks to the save event for models
- auth middleware populates request.user and also keeps the user for
itself in some warm private place
- on model's save it looks in its Meta for fields that should be
populated and does it
Wait, there's more! :-
Adrian Holovaty wrote:
I don't see a need to add this functionality for use beyond the scope
of the admin site.
Well... I can recall more than one request in django-users :-). And this
feature is pretty commonplace...
The auto_now options aren't coupled to a request,
so they're a special c
On 1/11/06, scum <[EMAIL PROTECTED]> wrote:
> Could the comment tag be simplified to something like {! !} or {# #}.
We've already got two different types of tags -- {% %} and {{ }} --
and introducing a third would be too complex for my tastes.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproj
This all sounds good to me ( although I care less about this than some
). Good to compress the name churn into a short time period if possible,
ie all in magic removal
One thing, with all of changes, the django.db.models thing ends up being
quite deep for such a core part. Thoughts?
Adrian Holovaty wrote:
> On 1/11/06, Maniac <[EMAIL PROTECTED]> wrote:
>
>>This will work only in Admin but authentication generally isn't tied to
>>it. I recall that people in django-users were interested in automatic
>>user assignment to work in any view and they didn't want to insert
>>"SomeMo
Could the comment tag be simplified to something like {! !} or {# #}.
The current convention is a bit bulky for my taste.
{% comment %}
{% if 1 %}{% endif %}
{% endcomment %}
could be simplified to...
{! {% if 1 %}{% endif %} !}
or
{% comment %} Short comment about following code {% endcomme
On 1/11/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/11/06, Maniac <[EMAIL PROTECTED]> wrote:
> > This will work only in Admin but authentication generally isn't tied to
> > it. I recall that people in django-users were interested in automatic
> > user assignment to work in any view and
On 1/11/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > I've got a patch ready to commit that moves django.utils.httpwrappers
> > to django.http and updates all the dependencies and docs. I'd move
> > Http404 in another commit. Also,
Adrian Holovaty wrote:
> Let's go with the http package, with an __init__.py in it, simply
> because it makes it more flexible to put stuff in there in the future.
This raises an issue of coding style: my feeling, though PEP 8 (the
python style guide) doesn't rule on it, is that __init__.py is
i
On 1/11/06, Maniac <[EMAIL PROTECTED]> wrote:
> This will work only in Admin but authentication generally isn't tied to
> it. I recall that people in django-users were interested in automatic
> user assignment to work in any view and they didn't want to insert
> "SomeModel.created_by=request.user"
On 1/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> I've got a patch ready to commit that moves django.utils.httpwrappers
> to django.http and updates all the dependencies and docs. I'd move
> Http404 in another commit. Also, if we are going to rename the classes
> in here, (as suggested by
On 1/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/7/06, kmh <[EMAIL PROTECTED]> wrote:
> > django.utils.httpwrappers -> django.http
>
> +1. I'm a big fan of this. django.http would get that'd get the
> current contents of django.utils.httpwrappers, plus the Http404 and
> Http500 exce
> Another option would be to have the callable return a (url, message)
tuple, and let the view handle HttpResponseRedirect and
request.user.add_message.
I think you should use a dictionary. For example, you could pass in the
following dictionary:
{None:'../report1/%s'}
and then in the default met
Joseph Kocherhans wrote:
> On 1/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > On 1/11/06, Radek Svarz <[EMAIL PROTECTED]> wrote:
> > > Could you follow some uniform way of the pluralization of module names?
> > >
> > > I mean why there is django.shortcuts.views (plural) and django.form
>
On 1/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> Hmm... what about django.template (singular) becoming django.templates
> (plural)? Any strong preferences? I think templates makes more sense.
django.templates suggests a collection of templates. django.template
suggests a library, imo.
On 1/11/06, Maniac <[EMAIL PROTECTED]> wrote:
>
> Joseph Kocherhans wrote:
>
> >Create a ForeignKey field that references
> >django.contrib.auth.models.User or whatever. This field cannot be
> >editable=False, or the manipulator will skip over it when you save the
> >object. Exclude the field from
Joseph Kocherhans wrote:
Create a ForeignKey field that references
django.contrib.auth.models.User or whatever. This field cannot be
editable=False, or the manipulator will skip over it when you save the
object. Exclude the field from your admin screens using the fields
attribute of the new inn
On 1/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> On 1/11/06, Radek Svarz <[EMAIL PROTECTED]> wrote:
> > Could you follow some uniform way of the pluralization of module names?
> >
> > I mean why there is django.shortcuts.views (plural) and django.form
> > (singular)?
> >
> > I hate thos
On 1/11/06, Radek Svarz <[EMAIL PROTECTED]> wrote:
> Could you follow some uniform way of the pluralization of module names?
>
> I mean why there is django.shortcuts.views (plural) and django.form
> (singular)?
>
> I hate those code mistakes when just one s is forgotten.
You're right. 'forms' fi
Could you follow some uniform way of the pluralization of module names?I mean why there is django.shortcuts.views (plural) and django.form (singular)?
I hate those code mistakes when just one s is forgotten.
RadekOn 1/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
On 1/8/06, Adrian Holovaty <[
On 1/11/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > Create a ForeignKey field that references
> > django.contrib.auth.models.User or whatever. This field cannot be
> > editable=False, or the manipulator will skip over it when you
2006/1/11, Adrian Holovaty <[EMAIL PROTECTED]>:
> Oooh, I like this. Putting methods in the inner Admin class is very clean.
>
\o/
--
Brice Carpentier aka Br|ce
On 1/11/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> Create a ForeignKey field that references
> django.contrib.auth.models.User or whatever. This field cannot be
> editable=False, or the manipulator will skip over it when you save the
> object. Exclude the field from your admin screens usin
2006/1/11, Joseph Kocherhans <[EMAIL PROTECTED]>:
> Create a ForeignKey field that references
> django.contrib.auth.models.User or whatever. This field cannot be
> editable=False, or the manipulator will skip over it when you save the
> object. Exclude the field from your admin screens using the f
On 1/8/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> Let's get some more feedback quickly and move forward with this. Also,
> is anybody interested in implementing this code in magic-removal?
I've added a new page to the wiki [1] (and a link to that page [2])
describing what decisions were m
On 1/11/06, Brice Carpentier <[EMAIL PROTECTED]> wrote:
>
> 2006/1/11, Joseph Kocherhans <[EMAIL PROTECTED]>:
> > I wrote both patches. Please just ignore #1132. It sucks. I was pretty
> > much just trying to start a conversation there with the simplest (in
> > this case least amount of code) thin
I think this is a very good idea, and I like the precedent of adding
methods to the inner Admin class to influence the admin behavior. I
do agree, however, that this should wait until after we finish the
magic-removal branch. There's nothing in this proposed change that
would break any
I hate to request more changes to magic-removal... but that's where
this should happen. Maybe it should wait until after it's been merged
though.
Currently the redirects after add_stage and change_stage in the admin
system are hardcoded. One of the most frequent requests I get in my
projects is t
>i understand the general unicode-related problems with python, i just
>wanted to understand what's django specific.
Since Django is written in Python, those _are_ django specific. For
example several of the template filters make use of uppercase/lowercase
conversions (only interesting if you can
hugo wrote:
i understand that django's architecture should use unicode because it's
the better way, but from the "outside"... what functionality is not
working fine with non-english characters?
currently you are up to your own to turn the
unicode strings returned from those into utf-8 bytest
>i understand that django's architecture should use unicode because it's
>the better way, but from the "outside"... what functionality is not
>working fine with non-english characters?
There are loads of things that don't work - actually anything that has
a notion of a character but get's fed wit
2006/1/11, Joseph Kocherhans <[EMAIL PROTECTED]>:
> I wrote both patches. Please just ignore #1132. It sucks. I was pretty
> much just trying to start a conversation there with the simplest (in
> this case least amount of code) thing I could get to work. (I probably
> should have done so on the li
2006/1/11, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Hi folks,
> Yes, I'm bringing this issue again, please don't throw things at me !
>
> Basically, I would want to open a discussion on these subjects so as to
> define a clean solution to this problem, if at least possible.
>
> I think I'm gonna g
hugo wrote:
I think that Django should support(use only) python unicode strings.
Since the work needed would be a bit involved (not the actual work, I
think, but finding and fixing all relevant places), I set up a wiki
page to collect places and procedures regarding unicodefication.
I think
44 matches
Mail list logo
