Hello,
Now 1.2 is released I have a couple of long-standing issues I'd like
some feedback on.
First one for now, would be adding 1-line input support to admin
actions.
I opened a ticket a while back here: http://code.djangoproject.com/ticket/10871
- A proof of concept patch (although it may not
Hi Zain
This looks very good. One minor complaint; the checkbox-ish design of
the handle is a bit counter-intuitive. Is it possible to have it on
the right like the other handle, and only be able to grab it from the
left side (gmail-ish interface)?
Hoping this makes into trunk soon!
J
On Jul 6
Nice work! I'll certainly have a look at it very soon.
Jerome
On Jun 18, 3:16 pm, Stephen wrote:
> Hi,
>
> I have ported the Django template system to the Qt C++ framework.
>
> http://www.grantlee.org
>
> I've already delivered two talks about the system and I'll be
> delivering another at the
I have never messed with this part of Django but I'm up for a try; by
the end of this month I'll have some time off to work on it if no one
else is able to. Feel free to file a ticket.
On Jun 16, 3:55 pm, Justin Myers wrote:
> On Jun 16, 3:49 am, Ivan Sagalaev wrote:
>
> > Indeed I don't really
On Jun 16, 11:27 am, Ivan Sagalaev wrote:
> Sorry for interrupting your lively conversation gentlemen... If you
> allow me to give an advice then your proposal will look better without
> constantly referring to one trailing slash with disparaging adjectives
> (such as "unclean"). Most of Django
Are you sure you understood the original proposal?
No one here wants to remove all slashes! Just "cleanup" the url:
Clean:
http://example.com/foo/bar
Unclean
http://example.com/foo/bar/
http://example.com/foo///bar
http://example.com///foo//bar///
The last two would be a more aggressive sett
I've been looking for this, as an user. I can only agree with the
proposal.
I think a single setting would be less confusing though:
TRAILING_SLASH = ("append", "remove", "remove_last", "full_clean") for
the different methods you described. Or maybe that's just overdoing
it... For backwards-compat
Hi all
I've been working on DurationFields this evening (ticket #2443)[1]. My
implementation is working pretty well with a single TextInput. I'm
storing the durations as Decimal in the database (since from what I've
heard storing them as a 64-bit int is a no-go), in microseconds.
When creating or
http://groups.google.com/group/django-developers/browse_thread/thread/87aae5cbd60bb904/505f3bd962711db7?hl=en
You wanted an use case, someone else just provided you with it.
"Why do you care so much about the index being there, anyway? It
should only
affect you badly under quite extreme circumst
I made a small patch for my local Django install to be able to precise
add_constraint=False (default True, normal behaviour) to FKeys/
M2Ms/...
As the tin says, it prevents index/constraint creation for that field.
I won't bother going through the use cases for this; I know I need it
and maybe oth
long, just use an IntegerField, possibly with model
> > functions to do the querying (which could be made properties to act
> > like fields) to get the info from the other table and return the
> > default you want if the other row is missing.
>
> > On Sun, Feb 22, 2009 at 2
ems you could just use an IntegerField and do it yourself, instead
> of expecting django to adapt itself to your bad db design :)
>
>
>
> On Sat, Feb 21, 2009 at 5:16 PM, Adys wrote:
>
> > I see what you mean. I agree to an extent - data needs to stay as
> > cle
maintenance, which is not something django should
> cover in my opinion, it seems logically you do a cleaning of your database
> to set all non-existing foreignkeys to NULL.
>
> 2009/2/22 Killian
>
> > Hi
>
> > 2009/2/21 Adys
>
> >> Hi there
>
>
Hi there
I've been thinking for the past couple of days of a simple "lazy"
ForeignKey design (or whichever name would fit better). It's something
I've tried really hard to find in Django, unsuccessfully. Some
explanation first...
I tried to get some background on django-users, cf
http://groups.g
14 matches
Mail list logo
