Tom Tobin wrote:
> On 3/13/06, Kieran Holland <[EMAIL PROTECTED]> wrote:
>> I don't like the idea of arbitrary content in template tags either but does
>> your "definite no" also apply to this old idea:
>>
>> {% endif %}{# endif start_process #}
>>
>> I think comments should be encouraged in templ
Gábor Farkas wrote:
>> Thoughts, criticisms? The only part I'm sketchy on is the side effect
>> of converting the values to their Python data types. The
>> cleanliness/consistency is quite nice, but it's slightly not something
>> a developer might expect. However, we can solve the latter through
>
Jacob Kaplan-Moss wrote:
> On Mar 13, 2006, at 9:41 PM, James Bennett wrote:
>> Sure they can. Imagine explaining Django to someone who's never seen
>> an MVC model before; if you told them "the model is where you provide
>> all the information about a class of objects, and describe how it
>> work
limodou wrote:
> On 3/14/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>> On Tue, 2006-03-14 at 09:34 +0800, limodou wrote:
>> [...]
>>> -1 I agree with gabor. Many orm models don't process validation, and
>>> these things should be implemented by manipulator. Why do so much
>>> things in mode
limodou wrote:
> Reasons sound very reasonable. But I think current implement in django
> is enough. Maybe model with validation is better but unnecessary. We
> have many ways to validate data before it saved in db.
Any Security Foil-Hat will tell: Validate early and validate often. It
makes no
Tom Tobin wrote:
> On 3/14/06, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
> >
> > Kieran Holland wrote:
> > >>>
> > >>> {% endif %}{# endif start_process #}
> > >> I think that original idea is cleaner: {% endif start_process %}.
> > >
> > > Perhaps in this case, but I would prefer we don't do spe
Eugene Lazutkin wrote:
>I think that original idea is cleaner: {% endif start_process %}.
>
>
It doesn't let you specify a general comment in the body of template:
{% tree %} {# Custom tag drawing a tree #}
--~--~-~--~~~---~--~~
You received this message becau
Hi,
My first attempt at #22 is in trac.
http://code.djangoproject.com/ticket/22
It's just a quick thing that I needed. But I will welcome suggestions
and ideas how to make this better.
Best Regards
On 3/12/06, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
> never go round to it - havent even st
limodou wrote:
>
> if endif has a comment string, what about endifequal and others end
> block tags? If doing this, all these end blog tags maybe need
> different treate as parsing.
The original proposal called for modification of all endXXX tags --- see
the *Subj* line. I used "endif" as an ex
On 3/14/06, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
>
> Kieran Holland wrote:
> >>>
> >>> {% endif %}{# endif start_process #}
> >> I think that original idea is cleaner: {% endif start_process %}.
> >
> > Perhaps in this case, but I would prefer we don't do special-case
> > solutions to what is
On 3/13/06, Kieran Holland <[EMAIL PROTECTED]> wrote:
>
> I don't like the idea of arbitrary content in template tags either but does
> your "definite no" also apply to this old idea:
>
> {% endif %}{# endif start_process #}
>
> I think comments should be encouraged in templates and the
> comment/e
Kieran Holland wrote:
>>>
>>> {% endif %}{# endif start_process #}
>> I think that original idea is cleaner: {% endif start_process %}.
>
> Perhaps in this case, but I would prefer we don't do special-case
> solutions to what is a more general problem. What about other tags:
> ifequal? for? bloc
On 3/14/06, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 3/13/06, limodou <[EMAIL PROTECTED]> wrote:
> > Maybe or maybe not. What django has implemented is exactly as what I
> > said, I think the ways is good. And I remember there was a discussion
> > about js invalidation, why we need this. Be
On 3/13/06, limodou <[EMAIL PROTECTED]> wrote:
> Maybe or maybe not. What django has implemented is exactly as what I
> said, I think the ways is good. And I remember there was a discussion
> about js invalidation, why we need this. Because we want to make
> mistakes can be found early, but not un
On 3/14/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On Mar 13, 2006, at 9:41 PM, James Bennett wrote:
> > Sure they can. Imagine explaining Django to someone who's never seen
> > an MVC model before; if you told them "the model is where you provide
> > all the information about a class of
On 3/14/06, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 3/13/06, limodou <[EMAIL PROTECTED]> wrote:
> > In most cases we do not do anything alone use model, but always there
> > is a ui layer, such as gui or web. They have to do any such thing.
>
> There should be the ability to generate an HT
On Mar 13, 2006, at 9:41 PM, James Bennett wrote:
> Sure they can. Imagine explaining Django to someone who's never seen
> an MVC model before; if you told them "the model is where you provide
> all the information about a class of objects, and describe how it
> works", they'd be awfully confused
On 3/13/06, limodou <[EMAIL PROTECTED]> wrote:
> In most cases we do not do anything alone use model, but always there
> is a ui layer, such as gui or web. They have to do any such thing.
There should be the ability to generate an HTML form for
creating/changing an instance of a model, yes, but t
On 3/14/06, limodou <[EMAIL PROTECTED]> wrote:
> On 3/14/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> >
> > On Tue, 2006-03-14 at 09:34 +0800, limodou wrote:
> > [...]
> > >
> > > -1 I agree with gabor. Many orm models don't process validation, and
> > > these things should be implemented b
On 3/14/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2006-03-14 at 09:34 +0800, limodou wrote:
> [...]
> >
> > -1 I agree with gabor. Many orm models don't process validation, and
> > these things should be implemented by manipulator. Why do so much
> > things in model?
>
> This i
On 3/14/06, James Bennett <[EMAIL PROTECTED]> wrote:
>
> On 3/13/06, limodou <[EMAIL PROTECTED]> wrote:
> > -1 I agree with gabor. Many orm models don't process validation, and
> > these things should be implemented by manipulator. Why do so much
> > things in model?
>
> Among other things, the mo
On Tue, 2006-03-14 at 09:34 +0800, limodou wrote:
[...]
>
> -1 I agree with gabor. Many orm models don't process validation, and
> these things should be implemented by manipulator. Why do so much
> things in model?
This isn't really an argument, though. Other systems working differently
is not
On 3/13/06, limodou <[EMAIL PROTECTED]> wrote:
> -1 I agree with gabor. Many orm models don't process validation, and
> these things should be implemented by manipulator. Why do so much
> things in model?
Among other things, the model is the place where the types of data are
specified for a parti
On 3/13/06, Gábor Farkas <[EMAIL PROTECTED]> wrote:
>
> Adrian Holovaty wrote:
> >
> > EXAMPLE CODE:
> >
> > class Person(models.Model):
> > name = models.CharField(maxlength=50)
> > birthday = models.DateField()
> > favorite_number = models.IntegerField()
> >
> p = Person(name='J
Eugene Lazutkin wrote:
> Kieran Holland wrote:
> >
> > I don't like the idea of arbitrary content in template tags either but
> > does your "definite no" also apply to this old idea:
> >
> > {% endif %}{# endif start_process #}
>
> I think that original idea is cleaner: {% endif start_process %}.
On 3/14/06, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
>
> Kieran Holland wrote:
> >
> > I don't like the idea of arbitrary content in template tags either but
> > does your "definite no" also apply to this old idea:
> >
> > {% endif %}{# endif start_process #}
+1 for me
>
> I think that original
Kieran Holland wrote:
>
> I don't like the idea of arbitrary content in template tags either but
> does your "definite no" also apply to this old idea:
>
> {% endif %}{# endif start_process #}
I think that original idea is cleaner: {% endif start_process %}.
Thanks,
Eugene
--~--~-~
On Monday 13 March 2006 22:06, Kieran Holland wrote:
> I don't like the idea of arbitrary content in template tags either
> but does your "definite no" also apply to this old idea:
>
> {% endif %}{# endif start_process #}
>
> I think comments should be encouraged in templates and the
> comment/en
On 3/14/06, Kieran Holland <[EMAIL PROTECTED]> wrote:
{% endif %}{# endif start_process #}I think comments should be encouraged in templates and the comment/endcomment tag set is almost prohibitively verbose at times. HTML has special tags for comments too, so I don't think it is too programmerish
On 3/14/06, Adrian Holovaty <[EMAIL PROTECTED]
> wrote:
On 3/13/06, Jonathan Daugherty <[EMAIL PROTECTED]> wrote:> Maybe implement generic support for /* .. */ in template tags?
A definite no on that one -- it's too programmerish.
I don't like the idea of arbitrary content in template tags either b
Adrian Holovaty wrote:
> > It regularly becomes difficult to track which {% endif %} belong to which {%
> > if %}, it would be good if we can say {% endif start_process %} where
> > start_process is purely comment.
>
> I'm -0 on this one, but it'd be good to get others' opinions.
I'm not entirel
On 3/13/06, Jonathan Daugherty <[EMAIL PROTECTED]> wrote:
> Maybe implement generic support for /* .. */ in template tags?
A definite no on that one -- it's too programmerish.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
--~--~-~--~~~---~--~~
You r
# It regularly becomes difficult to track which {% endif %} belong to
# which {% if %}, it would be good if we can say {% endif
# start_process %} where start_process is purely comment.
Maybe implement generic support for /* .. */ in template tags?
--
Jonathan Daugherty
http://www.parsed.or
On 3/13/06, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> It regularly becomes difficult to track which {% endif %} belong to which {%
> if %}, it would be good if we can say {% endif start_process %} where
> start_process is purely comment.
I'm -0 on this one, but it'd be good to get others' opinio
Hi,It regularly becomes difficult to track which {% endif %} belong to which {% if %}, it would be good if we can say {% endif start_process %} where start_process is purely comment. -- Amit Upadhyay
Blog: http://www.rootshell.be/~upadhyay+91-9867-359-701
--~--~-~--~~~--
On 3/13/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> If I create a model in my app with foreign key to the User model, the
> SQL for creating the table doesn't add a 'REFERENCES' clause:
> [...]
> It works fine for intra-app relations, just not cross-app ones.
> Is this a known issue? Is it by desi
If I create a model in my app with foreign key to the User model, the
SQL for creating the table doesn't add a 'REFERENCES' clause:
Model
-
class Test(models.Model):
user = models.ForeignKey(User, null=True)
Shell
-
django-admin.py sqlall myapp --settings='myproj.settings'
BEGIN
On Monday 13 March 2006 07:13, Adrian Holovaty wrote:
> I'm catching up on more than a week's worth of unread mailing-list
> messages. Is this still an open issue?
I committed my changes, so no.
Luke
--
"Where a person wishes to attract, they should always be ignorant."
(Jane Austen)
Luke P
Although I normally encourage plenty of formalization, I don't think
this is a good idea right now. Here's why:
1) The deadlines referred to in documentation are for a small team with
money coming in. Django is a larger "team" (meaning lots of input from
various interests) with no money as a direc
All,
The first thing that you read on the Django project website is this
statement:
"The web framework for perfectionists with deadlines."
I would like to build on the last word in that statement
"deadlines". Every significant project has a some sort of
deadline, it's about the o
Am 13.03.2006 um 08:00 schrieb Adrian Holovaty:
[snip]
> Thoughts, criticisms? The only part I'm sketchy on is the side effect
> of converting the values to their Python data types. The
> cleanliness/consistency is quite nice, but it's slightly not something
> a developer might expect. However, we
Nevermind - problems solved
It was:
lookup_variables = {
'timestamp__year' : d.year,
'timestamp__month' : d.month,
'timestamp__day' : d.day,
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
On 3/13/06, Christopher Lenz <[EMAIL PROTECTED]> wrote:
> Am 13.03.2006 um 08:27 schrieb Adrian Holovaty:
> > I think the best (and simplest) way to hook this into Django would be
> > a setting. Something like FIRST_DAY_OF_WEEK = 1.
>
> In that case, how would you make this dependent on the locale
Thanks, Russ.
Apologies for posting on the wrong list. I'll post a thread there
instead, as I'm having some problems with implementing this.
Thanks, Tom
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django deve
All,
Validation aware models have seen allot of attention so far with a
number of proposals out there. This proposal, like the others, has
it's strengths and weaknesses. This method of validating models is a
good start, and will surely evolve or be replaced over time. I believe
that we need t
Christopher Lenz wrote:
>In that case, how would you make this dependent on the locale of the
>remote user?
>
>
I also thought that this should be tied to i18n. I'm still not familiar
how this is exposed in js, could anyone give any guidance where to look?
--~--~-~--~~--
On 3/13/06, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> Does it mean AddManipulator/UpdateManipulator are going
> away?
Yes, the automatic manipulators are going away, but there will of
course still be away to generate forms/manipulators automatically from
a model.
Adrian
--
Adrian Holovaty
holo
Am 13.03.2006 um 08:27 schrieb Adrian Holovaty:
> On 3/9/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>> I was porting javascript calendar from Admin into my application and
>> enhanced it a bit with new boolean pref switching start of week to
>> Monday. To submit this to Django I want to hook thi
Adrian Holovaty wrote:
>I think the best (and simplest) way to hook this into Django would be
>a setting.
>
Yes. And how to access settings.py from js?
> Something like FIRST_DAY_OF_WEEK = 1.
>
>
"1" being what, Monday or Sunday? :-) I named it "weekStarstOnMonday" to
avoid this confusion. Is
HI Adrian,Does it mean AddManipulator/UpdateManipulator are going away?This way of doing things is inconsitant with handling custom forms. If it is, a good step for django ORM, a bad step for django web framework.
Let me elaborate, this is my typical view:def confirm_email(request): if not requ
Adrian Holovaty wrote:
>
> EXAMPLE CODE:
>
> class Person(models.Model):
> name = models.CharField(maxlength=50)
> birthday = models.DateField()
> favorite_number = models.IntegerField()
>
p = Person(name='Joe', birthday='never', favorite_number='foo')
p.validate()
> {'bir
51 matches
Mail list logo
