On Sep 16, 11:05 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> On Sep 16, 10:49 pm, "Rajeev J Sebastian" <[EMAIL PROTECTED]>
> wrote:
>
> > A problem would be referencing images, and media in css/js files.
> > Currently, in all our projects we use /site_media/ as the MEDIA_URL,
> > so this not a
A while back I proposed changing the way the ``django.VERSION`` tuple
is set up. That discussion petered out a bit, until I brought it up
with Jacob just before the 1.0 release. At the time, we felt it wasn't
possible to do it before we rolled 1.0 (this was, due to my
absent-mindedness, about ten
On Sep 16, 10:49 pm, "Rajeev J Sebastian" <[EMAIL PROTECTED]>
wrote:
> A problem would be referencing images, and media in css/js files.
> Currently, in all our projects we use /site_media/ as the MEDIA_URL,
> so this not a problem. But for a true solution, there should be a
> preprocessor for
On Wed, Sep 17, 2008 at 7:47 AM, sciyoshi <[EMAIL PROTECTED]> wrote:
>
> On Sep 16, 7:31 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
>> On Sep 16, 7:22 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
>>
>> > I really like the idea. However, I think there should also be a way to
>> > configure it to not
On Sep 16, 7:31 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> On Sep 16, 7:22 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> > I really like the idea. However, I think there should also be a way to
> > configure it to not copy to MEDIA_ROOT but to somewhere else.
>
> Sure - a --destination flag,
> > apt and rpm don't mix with project-specific packages and versioning
> > (virtualenv/buildout). It is just not feasible (or even possible if
> > something is built against django-0.96 and something else against
> > django-1.0)
>
> Don't tell that to my laptop and some systems I admin which
On Mon, 2008-09-15 at 14:10 -0700, Ken Arnold wrote:
> I previously brought up a URL resolution refactoring (http://
> groups.google.com/group/django-developers/browse_thread/thread/
> e16bcd24f9e27062/a84b8e58fe2e7786), and was wisely told to hold off on
> it. I thought this might be a good
Malcolm Tredinnick wrote:
> On Tue, 2008-09-16 at 05:06 -0700, mrts wrote:
>
> [...]
>> setuptools is a necessary evil for the agile developer who frequently
>> tracks updates for the bits he relies upon. Hopefully it will be
>> improved (the clamor around it is ever-ongoing), but unless we
On Tue, Sep 16, 2008 at 4:40 PM, Diego Andrés Sanabria Martin
(diegueus9) <[EMAIL PROTECTED]> wrote:
> sorry, you have reason, my english is bad and i am tired, but i have this
> error:
form.clean()
> Traceback (most recent call last):
> File "", line 1, in ?
> File
I started working on a patch 6 months ago to implement App objects,
but unfortunately never got to finish it because at the time I was
swamped at work.
Because of the all the work which has happened on trunk the code is
pretty much useless.
> The following can be addressed with app objects.
>
>
On Sep 16, 7:36 pm, Johannes Dollinger
<[EMAIL PROTECTED]> wrote:
> @register.tag
> @uses_token_stream
> def mytag(parser, bits):
> expr = bits.parse_expression(required=True)
> return MyNode(expr)
>
> `uses_token_stream` replaces the Token argument to the parser
> function with a
On Tue, 2008-09-16 at 13:37 -0700, David Cramer wrote:
> I think that will work Malcom. One thing we'll need to deal with,
> is .name, .attname, etc on these. It should act the same way on the pk
> as it does on the multi-column field (because after all, this will be
> just a wrapper). Right now
On Tue, Sep 16, 2008 at 7:35 PM, Collin Grady <[EMAIL PROTECTED]>wrote:
> On Tue, Sep 16, 2008 at 4:33 PM, Diego Andrés Sanabria Martin
> (diegueus9) <[EMAIL PROTECTED]> wrote:
> > i found this:
> > Changed in Django 1.0: The cleaned_data attribute was called
> > clean_data in earlier releases.
>
Hey All,
First off, I am a relatively new Django user, and certainly not a
developer at this point, and most of this post is pure speculation.
With that disclaimer, I'll share my situation and opinion:
>From DoctorMO:
> Well I've seen far more normalised models that don't match how simple
>
On Tue, 2008-09-16 at 20:36 +0200, Johannes Dollinger wrote:
> Why should django.template be refactored? Filter and Variable parsing
> is inconsistent. Many ad hoc parsers in defaulttags are fragile.
> Whitespace handling is ungraceful.
>
> The patch provided in #7806[1] splits __init__.py
On Tue, Sep 16, 2008 at 4:33 PM, Diego Andrés Sanabria Martin
(diegueus9) <[EMAIL PROTECTED]> wrote:
> i found this:
> Changed in Django 1.0: The cleaned_data attribute was called
> clean_data in earlier releases.
>
> in http://docs.djangoproject.com/en/dev/topics/forms/#topics-forms-index
>
> I
i found this:
Changed in Django 1.0: The cleaned_data attribute was called
clean_data in earlier releases.
in http://docs.djangoproject.com/en/dev/topics/forms/#topics-forms-index
I make a mistake?
On Tue, Sep 16, 2008 at 18:29, Collin Grady <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 16, 2008 at
Not sure if you guys are aware, but this seems a very likely candidate
for django-exensions which extends manage.py like functionality.
http://code.google.com/p/django-command-extensions/
-justin
On Tue, Sep 16, 2008 at 7:22 PM, Julien Phalip <[EMAIL PROTECTED]> wrote:
>
> On Sep 17, 8:49 am,
On Sep 16, 7:22 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
> I really like the idea. However, I think there should also be a way to
> configure it to not copy to MEDIA_ROOT but to somewhere else.
Sure - a --destination flag, defaulting to MEDIA_ROOT, would work.
> Also, instead of just
On Tue, Sep 16, 2008 at 4:27 PM, Diego Andrés Sanabria Martin
(diegueus9) <[EMAIL PROTECTED]> wrote:
> if name in self.cleaned_data and f.unique and not is_null_pk:
> and in the doc, the variable self.cleaned is now self.clean_data
You are incorrect. The variable was clean_data in 0.96 but
Hi,
I find a bug in forms of django, i know i have report a ticket but the
bug is very small,
in the file django/forms/models.py in line 236:
if name in self.cleaned_data and f.unique and not is_null_pk:
and in the doc, the variable self.cleaned is now self.clean_data
thanks
--
Diego Andrés
On Sep 17, 8:49 am, Brian Beck <[EMAIL PROTECTED]> wrote:
> On Sep 16, 6:45 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
>
> > Serving is totally orthogonal -- everyone is already serving up
> > MEDIA_ROOT in their projects somehow anyway, and this just copies
> > files to MEDIA_ROOT.
>
> Sorry, I
I've just had another thought. With `SplitDateTimeWidget` validation
coupled to `DateTimeField`, it's no longer easy to subclass
`DateTimeField` for use with your own `MultiValueWidget`. When you
call `super` for the DateTimeField validation, it will run
`DateTimeField.clean` which will return an
On Tue, 2008-09-16 at 05:06 -0700, mrts wrote:
> Both of these arguments are valid, but will not help to resolve the
> problem: smooth experience in distributing and using pluggable
> applications and some order in the current chaos.
>
> On Sep 16, 2:10 pm, Malcolm Tredinnick <[EMAIL
On Sep 16, 6:45 pm, Brian Beck <[EMAIL PROTECTED]> wrote:
> Serving is totally orthogonal -- everyone is already serving up
> MEDIA_ROOT in their projects somehow anyway, and this just copies
> files to MEDIA_ROOT.
Sorry, I guess that's not totally true -- everyone who uses more than
just the
On Sep 16, 6:29 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
> > Could it be a little smarter, and in the absence of specific apps, iterate
> > over all INSTALLED_APPS, and install their media automagically?
>
> +1 for some sort of media.autodiscover().
> It would have to be optional though, as
On Sep 17, 7:09 am, "Don Spaulding" <[EMAIL PROTECTED]> wrote:
> On Tue, Sep 16, 2008 at 11:26 AM, Brian Beck <[EMAIL PROTECTED]> wrote:
>
> > $ python manage.py installmedia appname [appname ...]
>
> > The command is "dumb."..
>
> Could it be a little smarter, and in the absence of specific
On Tue, Sep 16, 2008 at 5:23 PM, Steve Holden <[EMAIL PROTECTED]> wrote:
>
> Fredrik Lundh wrote:
> > Karen Tracey wrote:
> >
> >
> >> We've had at least three people run into a problem (#9090) after
> >> installing 1.0 over an old level. Now, we do document that before
> >> installing you
It's intentional, usually you see an object_pk as an integer field,
however that means it won't work with any field with a custom primary
key, specifically those with string type pks. And a textfield offers
the flexibility to work with all of those.
On Sep 16, 3:42 pm, smcoll <[EMAIL
Fredrik Lundh wrote:
> Karen Tracey wrote:
>
>
>> We've had at least three people run into a problem (#9090) after
>> installing 1.0 over an old level. Now, we do document that before
>> installing you should remove any old level. But I find the results when
>> you don't rather odd. It's
Karen Tracey wrote:
> We've had at least three people run into a problem (#9090) after
> installing 1.0 over an old level. Now, we do document that before
> installing you should remove any old level. But I find the results when
> you don't rather odd. It's not just old files
On Tue, Sep 16, 2008 at 11:26 AM, Brian Beck <[EMAIL PROTECTED]> wrote:
>
> $ python manage.py installmedia appname [appname ...]
>
> The command is "dumb."..
Could it be a little smarter, and in the absence of specific apps, iterate
over all INSTALLED_APPS, and install their media
Looking at contrib.comments admin, i noted that the Object ID input is
a textarea. i thought that was strange, since i expceted an input
(type="text"). Turns out, in the model, this is a TextField, rather
than a CharField.
Brian Beck wrote:
> Distributing media with apps could be a lot easier. Currently this
> requires copying or linking files manually (possibly each time the app
> is updated), and this encourages developers to put CSS and JavaScript
> inline in their templates. I propose a management command to
I think that will work Malcom. One thing we'll need to deal with,
is .name, .attname, etc on these. It should act the same way on the pk
as it does on the multi-column field (because after all, this will be
just a wrapper). Right now .pks is just an alias for .pk.as_tuple or
something. I had it
On Tue, Sep 16, 2008 at 2:20 PM, Don Spaulding <[EMAIL PROTECTED]>wrote:
>
> Hope it's useful!
>
and of course it isn't. I forgot my lambdas. Doh!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django
On Mon, Sep 15, 2008 at 10:29 PM, Russell Keith-Magee <
[EMAIL PROTECTED]> wrote:
>
> It would be
> fantastic if such a mapping existed, and I don't think you'd get any
> objections from the core developers if such a mapping were to
> magically materialize.
>
poof!
I took a shot at finding
On Sep 16, 2:36 pm, Johannes Dollinger
<[EMAIL PROTECTED]> wrote:
> Why should django.template be refactored? Filter and Variable parsing
> is inconsistent. Many ad hoc parsers in defaulttags are fragile.
> Whitespace handling is ungraceful.
>
> The patch provided in #7806[1] splits __init__.py
On Sep 10, 12:53 pm, Simon Willison <[EMAIL PROTECTED]> wrote:
> For those who weren't at DjangoCon, here's the state of play with
> regards to multi-db support: Django actually supports multiple
> database connections right now: the Query class (in django/db/models/
> sql/query.py) accepts a
> I have already implemented this in our in-house django-based
> framework. If interested, I can provide it. As you said, it really
> does make things very simple.
>
Please do, I'd be interested even if it doesn't make it to the trunk.
Erik
--~--~-~--~~~---~--~~
On Tue, Sep 16, 2008 at 9:56 PM, Brian Beck <[EMAIL PROTECTED]> wrote:
>
> Distributing media with apps could be a lot easier. Currently this
> requires copying or linking files manually (possibly each time the app
> is updated), and this encourages developers to put CSS and JavaScript
> inline
Why should django.template be refactored? Filter and Variable parsing
is inconsistent. Many ad hoc parsers in defaulttags are fragile.
Whitespace handling is ungraceful.
The patch provided in #7806[1] splits __init__.py into separate
modules[2] and introduces a TokenStream class that
Martin Diers wrote:
> This is not a bug. It is how the permissions system works. So far as
> the Admin goes, it is model granular, not row granular or field
> granular, meaning that if you grant a user full access to the User
> object, as you did, they can do anything to that table,
Steve Holden wrote:
[...]
> I've just done an install of 1.0 on my Python 2.6 alpha2 distribution
> and I see, for example, that .../django/views/static.py is dated
> 12/17/2007. In this case there wasn't a previous installation, so I
> can't verify that the compilation won't take place if
Karen Tracey wrote:
> We've had at least three people run into a problem (#9090) after
> installing 1.0 over an old level. Now, we do document that before
> installing you should remove any old level. But I find the results
> when you don't rather odd. It's not just old files renamed/deleted in
We've had at least three people run into a problem (#9090) after installing
1.0 over an old level. Now, we do document that before installing you
should remove any old level. But I find the results when you don't rather
odd. It's not just old files renamed/deleted in the new level that wind up
On Sep 16, 8:37 am, "Justin Lilly" <[EMAIL PROTECTED]> wrote:
> I don't think anyone will complain that they have to type less, as its
> still understandable. +1 for allow_override.
Changed to allow_override. See patch #4 at:
http://code.djangoproject.com/ticket/9093
Distributing media with apps could be a lot easier. Currently this
requires copying or linking files manually (possibly each time the app
is updated), and this encourages developers to put CSS and JavaScript
inline in their templates. I propose a management command to make
this easier:
$
On Sep 16, 1:03 pm, Julien Phalip <[EMAIL PROTECTED]> wrote:
> This is a call to review ticket #1105. The proposed patch is fully
> functional, backwards-compatible and contains tests and
> documentation.http://code.djangoproject.com/ticket/1105
>
> Currently it is not possible to access the
On Sep 16, 2:10 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Tue, 2008-09-16 at 00:16 -0700, mrts wrote:
> > Let me try to wrap this up:
>
> > * there seems to be a general consensus that amending setuptools to
> > create Django-specific extensions is not required
> > * a separate
I'll take a look at this, the reason the second part didn't go in
originally(yeah, we thought of it), was that it was considered to be
in a different scope then the rest of the work on unique validation.
On Sep 16, 7:14 am, mrts <[EMAIL PROTECTED]> wrote:
> A bug in 1.0 makes unique_together
Great mail !
This has to be published somewhere like Jacob is suggesting.
I'd like to react on the PyPI part:
On 15 sep, 04:52, Kevin Teague <[EMAIL PROTECTED]> wrote:
>
> PyPI
> -
>
> Everyone knows what this is (hopefully!). A small point to note is
> that it was originally called The
Malcolm,
I strongly concur with the proposed API. It looks like it can be used
to implement future RangeHash partitioning support. Consider:
I have a model to be partitioned that has an IntegerField that will
become the range partitioning value:
week = models.IntegerField() # 1 to 53 depending
53 matches
Mail list logo
