On Sat, 2007-04-07 at 00:20 -0500, Adrian Holovaty wrote:
> On 4/7/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > Can one of you guys create a unicode branch in the repository, please. I
> > don't have the right permissions to make a branch with "svn copy".
>
> OK, I've created the
Adrian or Jacob,
Can one of you guys create a unicode branch in the repository, please. I
don't have the right permissions to make a branch with "svn copy".
Not blindingly urgent, since I have my own copies over here, but useful
for sharing in the near-future.
Thanks,
Malcolm
On 4/6/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> As of [4944], the newforms-admin admin site should be working properly
> -- you're right that I hadn't finished the AdminSite stuff. (Sorry for
> the miscommunication!) It's working pretty well now. To activate the
> admin site, do this:
>
On 4/6/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> We currently have a bug in HttpResponseRedirect: the HTTP spec requires
> using absolutely URLs in the Location header for redirects.
This is a tricky one... Ideally, HttpResponseRedirect would accept
relative URLs, handling the
On 3/26/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> Gah. Nevermind. Only the index page is working of AdminSite, and it's
> root method acts like a view that takes url as a param. Doesn't
> explain my problems with django.contrib.admin.views.main.index, but
> that's a different issue.
>
>
Apropos of nothing in particular...
On Fri, 2007-04-06 at 21:26 -0500, [EMAIL PROTECTED] wrote:
> Author: adrian
> Date: 2007-04-06 21:26:45 -0500 (Fri, 06 Apr 2007)
> New Revision: 4941
>
> Modified:
>django/branches/newforms-admin/django/contrib/admin/options.py
> Log:
> newforms-admin:
On Fri, 2007-04-06 at 12:39 -0700, Jonas Maurus wrote:
[...]
> So I'd say: make the next release painful and then stop until 1.1.
> Make all the changes now, including full unicodization and newforms-
> admin and if it's still on the map the "Admin"-class-removal that was
> being discussed a
On Fri, 2007-04-06 at 16:21 +, Rob Hudson wrote:
> On Apr 6, 3:51 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
>
> > [An unproven gut feeling: keeping a small reminder, however subliminal,
> > that things are relational-database backed is actually a good idea. It
> > will stop widely
I made this suggestion on the django board.
@auto_now('updatted_on')
@auto_add_now('submitted_date')
def save(self):
super(MyModel).save()
I even have started coding it as I need SOME solution that is simple.
One problem I have had is with edit_inline and auto_now where the
entries are
+1. Follows DRY. An AutoDateTimeField is very common.
j
On 4/6/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
>
> > seems like it should be as easy as a function in contrib somewhere:
> [snip]
>
> Another option is a trivial field subclass::
>
> class
> seems like it should be as easy as a function in contrib somewhere:
[snip]
Another option is a trivial field subclass::
class AutoDateTimeField(models.DateTimeField):
def pre_save(self, model_instance, add):
return datetime.datetime.now()
Jacob
On Apr 6, 2007, at 11:39 AM, David Larlet wrote:
>
> 2007/4/6, Brian Beck <[EMAIL PROTECTED]>:
>>
>> On Apr 2, 12:52 pm, "trbs" <[EMAIL PROTECTED]> wrote:
>>> It could be just me, but although i don't mind losing auto_*, it
>>> don't
>>> look very DRY in save.
>>>
>>> I know it's only a few
Almodovar-Penelope Cruz - Late Show with David Letterman II
http://penelope.teenwag.com/playvideo/1333
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email
I have defined the following aliases in my models. It looks good
except that ForeignKey has no support for specifying whether you want
to cascade DELETEs to the foreign class. I'd like to point out that
IsMy would provide a very simplistic implementation of class
inheritance (with a named
On Fri, Apr 06, 2007 at 11:26:07PM +1000, Malcolm Tredinnick wrote:
> On Fri, 2007-04-06 at 09:08 -0400, Forest Bond wrote:
> > My point rests on the assumption that, no matter how good django gets at
> > parsing regular expressions, it will always be possible to write one that
> > works perfectly
Howdy folks,
I was hacking around on a project, trying to use signals during model
instantiation. I've used signals before, but came across an
interesting 'wart' in the signals/dispatcher framework.
The end result is that a listener can become registered with the
dispatcher more than once...
Did people feel that save() was a better solution because it's already
a place where you have to put equivalent functionality for other
fields? I don't know why, but defining my own save() always seems like
a "big deal" that should be reserved for more complex stuff.
What about a new attribute
On Apr 6, 2:16 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> Hi all,
>
> A few backwards incompatible changes have been raised on the list in
> the last week or so:
>
> - Removing auto_add_now and auto_add
> - Removing LazyDate
> - Renaming localflavour.usa to localflavor.us
>
> This
On Apr 6, 9:11 pm, "tonnzor" <[EMAIL PROTECTED]> wrote:
> Short templates comments {# #} are odd if used incorrectly - it eats
> text.
>
> This template (invalid comments):
>
> Hello
> {# this
> comment
> has
> newlines #} World! {{ "some more text" }}
>
> Now produce this output (text "World!"
Short templates comments {# #} are odd if used incorrectly - it eats
text.
This template (invalid comments):
Hello
{# this
comment
has
newlines #} World! {{ "some more text" }}
Now produce this output (text "World!" is eaten):
Hello
some more text
Yes, the comments are invalid, but in this
I think that short template comments should allow multi-line comments
- it is much easier to use {# #} instead of {% comment %} {%
endcomment %}
Now short comments do not allow newlines in them, so following
template is invalid:
{# very long
many-lines
comment #}
It seems odd that this code do
2007/4/6, Brian Beck <[EMAIL PROTECTED]>:
>
> On Apr 2, 12:52 pm, "trbs" <[EMAIL PROTECTED]> wrote:
> > It could be just me, but although i don't mind losing auto_*, it don't
> > look very DRY in save.
> >
> > I know it's only a few lines (like 4 ? for both options, not using
> > default= for
On Apr 2, 12:52 pm, "trbs" <[EMAIL PROTECTED]> wrote:
> It could be just me, but although i don't mind losing auto_*, it don't
> look very DRY in save.
>
> I know it's only a few lines (like 4 ? for both options, not using
> default= for sake of keeping the logic together) but when lots of
>
On Thursday 05 April 2007 07:35, meyyitfani wrote:
> In the Name of
> God, the Merciful, the Compassionate.
Isa said, "I am the way, the truth, and the life. No one comes to the
father
except by me". Isa also said, "I am the resurrection and the life...
whosoever believes in me, though
On Apr 6, 3:51 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> [An unproven gut feeling: keeping a small reminder, however subliminal,
> that things are relational-database backed is actually a good idea. It
> will stop widely read people from thinking there is a true object
> backing store.
2007/4/6, Gabor Farkas <[EMAIL PROTECTED]>:
>
> Ivan Sagalaev wrote:
> but, even if it not, i think full django-unification is worth ANY cost.
I agree completly with you. just look at
http://code.djangoproject.com/ticket/3924 and similar tickets.
The actual mix is a nightmare for non english
Ivan Sagalaev wrote:
> Malcolm Tredinnick wrote:
>> I applaud Adrian's attempts to be unicode-aware from the get go, but
>> it's also cost a bit of sleep lately trying to debug things. Having
>> spent most of my free time over the last three days looking at this
>> exact set of problems, I'm
Hello all of my friends,
Glad to join this groups, I'm a new user of django and I find it's a great
software.
My name is nick, a chinese software engineer in c/c++ language & IC Test field.
I have used python for about 2 years, if there is any thing I can do for
django, welcome to let me know.
Jeff Forcier wrote:
> On Apr 6, 9:14 am, Nebojša Đorđević <[EMAIL PROTECTED]> wrote:
>
>> I already have some code for the `DELETE RESTRICT` case. It checking all
>> of the FK relations and forbids deletion (throws exception) if they
>> exist. If there are interest I can make patch, I just have
Nebojša Đorđević wrote:
> OTOH, maybe validator is the better place for this?
(trying not to hijack the thread :) )
(also see http://code.djangoproject.com/ticket/1553)
Now when .96 is out I'm very interested on the status of the model level
validation.
This issue was delayed for a long
Malcolm Tredinnick wrote:
> Do you use git or cogito? I can put my repository up if you want to play
> along at home over the weekend. I guess I could also make it subversion
> accessible, although that will take more than the three minutes a git
> repository would (still, git -> subversion isn't
Adrian Holovaty wrote:
> I'm 100% for that. Let's do it. If you think a branch would be better
> for this, we can make that happen, too.
Yes, that would be handy. Malcolm asked about 'git' and 'cogito' which,
I assume, has something to do with automated patch control but I never
seen that :-).
On Apr 6, 9:14 am, Nebojša Đorđević <[EMAIL PROTECTED]> wrote:
> I already have some code for the `DELETE RESTRICT` case. It checking all
> of the FK relations and forbids deletion (throws exception) if they
> exist. If there are interest I can make patch, I just have to find out
> how to stop
On 4/6/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> I like Jeremy's idea of posting to django-users and django-announce,
> saying the development version will be a bit tumultuous for the
> immediate future. I'll send out that announcement.
>
Would it also be worth updating the FAQ?
On 4/6/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> I applaud Adrian's attempts to be unicode-aware from the get go, but
> it's also cost a bit of sleep lately trying to debug things. Having
> spent most of my free time over the last three days looking at this
> exact set of problems, I'm
Hey Ivan,
On Fri, 2007-04-06 at 18:07 +0400, Ivan Sagalaev wrote:
> Malcolm Tredinnick wrote:
> > I applaud Adrian's attempts to be unicode-aware from the get go, but
> > it's also cost a bit of sleep lately trying to debug things. Having
> > spent most of my free time over the last three days
On Fri, 2007-04-06 at 15:04 +0200, Michael Radziej wrote:
> Hi,
>
> in the course of triaging a few tickets ... how is newforms expected to
> deal with model attributes, like in {{{ aModel.field=value }}}? Should
> it use unicode strings or UTF-8 encoded bytestrings?
>
> I see that it
On Fri, 2007-04-06 at 09:08 -0400, Forest Bond wrote:
> On Fri, Apr 06, 2007 at 03:17:41AM -, Django Code wrote:
> > Parsing regexps is hardly dangerous. Let's keep some perspective.
>
> Pardon my tone, I suppose "dangerous" might be a bit strong of a word.
>
> > It is difficult and if
Russell Keith-Magee wrote:
> However, underneath the name churn, there is an interesting idea - in
> your proposal, there is an important difference between "isA" and
> "IsMy". It looks like what you are trying to describe is an interface
> to the SQL "ON DELETE CASCADE". This could be done with
On Fri, Apr 06, 2007 at 03:17:41AM -, Django Code wrote:
> Parsing regexps is hardly dangerous. Let's keep some perspective.
Pardon my tone, I suppose "dangerous" might be a bit strong of a word.
> It is difficult and if you have a better way to do reverse matching, please
> post a patch.
Hi all,
A few backwards incompatible changes have been raised on the list in
the last week or so:
- Removing auto_add_now and auto_add
- Removing LazyDate
- Renaming localflavour.usa to localflavor.us
This raises the question - do we have any particular timeline or
strategy for making these
On Fri, 2007-04-06 at 10:07 +, [EMAIL PROTECTED] wrote:
> Hello,
>
> I'm new to Django so please forgive me if my question doesn't make
> sense or is addressed in the trunk/active branches. Also I'd like to
> start by saying that Django is a great piece of software, and that I
> appreciate
On 4/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Remarks/trolls/thoughts welcome :)
Straight out name churning isn't open for debate. Is ForeignKey the
best name for a n-1 relation between models? This is a value
judgement, Ultimately, it doesn't matter if ForeignKey is renamed
Hello,
I'm new to Django so please forgive me if my question doesn't make
sense or is addressed in the trunk/active branches. Also I'd like to
start by saying that Django is a great piece of software, and that I
appreciate that a lot of hard work went into it.
As an outsider I'm a bit puzzled
44 matches
Mail list logo
