On Apr 9, 11:56 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> they share the same longitudes. But it is reasonable to do it based on
> locale (including using the default locale setting).
Using the locale setting sounds great. Need any help?
Simon Litchfield said the following:
> Tad ugly though, don't you think? Most platforms/languages/frameworks
> handle the MDY/DMY situation relatively elegantly using some kind of
> setting.
Well I wasn't pitching it as the best solution, just *a* solution :p
--
Collin Grady
Of all forms of
On Tue, 2008-04-08 at 18:28 -0700, Simon Litchfield wrote:
[...]
> Am I not the only non-US guy who sees this as a major shortcoming in
> newforms?
It's not a forgotten corner, but we haven't fixed it yet. The idea is to
solve the entire problem, not just the one little piece that is date
time
> I haven't tried to use it, but couldn't a DateTimeInput widget with those
> fields
> solve the problem? It accepts a format arg which is how it will render its
> data
> - combined with the right input_formats in the field, it stands to reason that
> would work :)
Yes you're right, so we can
Simon Litchfield said the following:
> No control is given over how initial date/datetime values are
> rendered, using DateField/DateTimeField.
>
> Clients don't like -MM-DD; who can argue?
>
> At the very least, I propose we at least allow an optional
> display_format string, kinda like
On Apr 7, 8:19 pm, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> On Mon, Apr 7, 2008 at 9:09 AM, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > I'm also mostly in agreement here.
>
> As am I. Syntax is tough, of course; here's my two cents::
>
> form = ModelForm(model=Person,
On Apr 8, 5:19 am, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]>
wrote:
> form = ModelForm(model=Person, exclude=["pay_grade"])
Looks fine to me. Any reasoning against?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
No control is given over how initial date/datetime values are
rendered, using DateField/DateTimeField.
Clients don't like -MM-DD; who can argue?
At the very least, I propose we at least allow an optional
display_format string, kinda like input_formats.
More importantly though, I think we
I thought I'd mention Kodos as a help for people with regex troubles:
http://kodos.sourceforge.net/
When I've wondered why things just weren't working in my URLs, and I've
wasted time banging on stuff, copying the pattern into Kodos and typing in
the URL I wanted to match it has usually pointed
On Apr 8, 12:55 pm, Derek Anderson <[EMAIL PROTECTED]> wrote:
> to reuse a well-known axiom: "those who don't know regular expressions
> are doomed to reinvent them... poorly"
>
That saying can be countered by this old saw which I find amusing:
"A programmer has a problem to solve and decides
Sorry, but I also think that this is the place to discuss about a new
db backend.
IMHO everybody thought about a backend for the datastore/bigtable, but
what about supporting Google App Engine models in django? Will it be
very complicated? I don't know if anybody at Google contacted anybody
at
i *would* like to champion this, as django's regex -> function mapping
is its best single feature, IMO.
to reuse a well-known axiom: "those who don't know regular expressions
are doomed to reinvent them... poorly"
derek
Rob Hudson wrote:
> Just a note: I'm not going to champion this one
On Apr 8, 12:14 pm, AmanKow <[EMAIL PROTECTED]> wrote:
> I don't know about sticking that in core, but that sure is a neat idea
> that I think I might use in some personal stuff. Particularly useful
> when urls have a complex 'bases' that I wish to use to parse the same
> info out of groups of
I don't know about sticking that in core, but that sure is a neat idea
that I think I might use in some personal stuff. Particularly useful
when urls have a complex 'bases' that I wish to use to parse the same
info out of groups of urls each time that are distinguished with
additional fiddly
On Tue, Apr 8, 2008 at 11:30 AM, konryd <[EMAIL PROTECTED]> wrote:
> A question I'd like to ask experienced developers:
That's not what django-developers is for. It's for the development of
Django itself. There are plenty of experienced developers reading
django-users too.
> Is it possible to
A question I'd like to ask experienced developers:
Is it possible to write a django db backend that uses google's db api?
(this one: http://code.google.com/appengine/docs/datastore/)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
Just a note: I'm not going to champion this one since I do know
regular expressions. I simply read elsewhere that it is a common
stumbling block for newbies and thought I'd bring it up.
Actually, the regex newbies I know usually just need a few examples to
get them off the ground. E.g. use
On Tue, Apr 8, 2008 at 4:25 AM, mrts <[EMAIL PROTECTED]> wrote:
>
> On Apr 8, 12:53 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
> wrote:
>
> > > Agreed, but as previously described, there should be a way to override
> > > the default behaviour and retain session data if needed.
> >
> > No, I
> El mar, 08-04-2008 a las 04:27 -0500, James Bennett escribió:
> Or people could go learn from one of the many thousands of regex
> tutorials that's already been written? There's a point at which we
> have to assume that people are willing to help themselves out a bit by
> learning Python and
On Tue, Apr 8, 2008 at 4:10 AM, Marc Fargas <[EMAIL PROTECTED]> wrote:
> Maybe the documentation refactoring could include an Appendix:
> "Introduction to REGEX" and "The regular expressions you'll find
> everyday" or something like that.
>
> With this, newcomers would have an
El mar, 08-04-2008 a las 10:09 +0200, David Larlet escribió:
> >>url(r'^(?P[-\w]+)/$', myview),
> >
> > Note that this example is more complicated than it needs to be. I'd
> > write it like this:
> >
> >(r'^([-\w]+)/$', myview)
> In this case, what about a default dictionary of popular
On Apr 8, 12:53 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> > Agreed, but as previously described, there should be a way to override
> > the default behaviour and retain session data if needed.
>
> No, I don't see any need for this at all. Once you've logged out, the
> session is over.
Le 8 avr. 08 à 08:25, Adrian Holovaty a écrit :
>
> On Mon, Apr 7, 2008 at 3:49 PM, Rob Hudson <[EMAIL PROTECTED]>
> wrote:
>> would be much less daunting to those that haven't read the Friedl
>> book
>> than this:
>>
>>url(r'^(?P[-\w]+)/$', myview),
>
> Note that this example is more
Simon,
Ran in the same issue as you.
I filed documentation ticket #6690 to document a clean way to
dynamically create ModelForm instances. The ticket got closed because
the runtime creation of forms "isn't common enough"...
See also the thread "ModelForm: Dynamically change model and fields"
On Mon, Apr 7, 2008 at 3:49 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> would be much less daunting to those that haven't read the Friedl book
> than this:
>
> url(r'^(?P[-\w]+)/$', myview),
Note that this example is more complicated than it needs to be. I'd
write it like this:
On Mon, Apr 7, 2008 at 3:49 PM, Rob Hudson <[EMAIL PROTECTED]> wrote:
> It was discussed previously that making URL matching easier by not
> having to understand regular expressions would be a nice goal, and
> perhaps a nice 1.0 goal...
Two things:
1. If Django were going to support an
Rob Hudson wrote:
> * Defaulting to "[-\w+]" makes sense to me as a default regular
> expression to catch most URL patterns. It can catch strings, slugs,
> and numbers. Things like this would still work: "/{{ year }}/{{ month
> }}/{{ day }}/{{ slug }}/" but may not be as optimized as
27 matches
Mail list logo
