On Thu, Jun 3, 2010 at 7:41 PM, M Rotch wrote:
> The closest thing I've come across as a solution so far is
> http://code.google.com/p/django-nav/
As the developer of django-nav it is nice to hear it is closest to a
solution you have found, but often closest isnt enough, and I am not
sure I under
On Thu, Jun 3, 2010 at 11:19 PM, burc...@gmail.com wrote:
> Hi all,
>
> I've written a prototype, and put it on
> http://github.com/buriy/django-configurator.
> It has few good design decisions, and few maybe not that good.
> Anyway, I consider it as a good addition to app loading GSoC Proposal,
>
Building a site with more than 50 views tends to require some sort of
sub-sub-page type of system in order to make for easy navigation. For
instance:
/eggs-view/
/eggs-view/sub-view/
/eggs-view/sub-view/sub-sub-view/
/spam-view/
/spam-view/spam-sub-view/
/spam-view/spam-sub-view/spam-sub-sub-view
Thanks for your hard work Keven. There are those of us that appreciate
input.
On Jun 2, 4:25 pm, Kevin Howerton wrote:
> This was not a "hey you guys are lazy", actually came across it ...
> after I had fixed the same issue.
>
> I just posted a patch for you generated off trunk... and left a
> ho
On Jun 3, 5:48 pm, "petr.marhoun" wrote:
> - It seems that it is not possible to say if form has fieldsets
> (fieldsets method even construct fieldsets if meta attribute is not
> set) - I think it is useful to know it in templates.
I spoke too quickly here: this is a relevant API question. In for
Hi Petr,
On Jun 3, 5:48 pm, "petr.marhoun" wrote:
> I have some notes to forms-utils:
> - The code says: "if legend is None: legend = name". I dislike it - I
> want to have possibility not to set legend. I think that if legend is
> not set it should be "None" in fieldset.
Yes, this is one of the
Hello,
> One thing form-utils does differently from your proposal is that it
> defines each fieldset as a two-tuple (like admin fieldsets), with a
> name as the first element and the dictionary of additional info as the
> second element. One advantage of having a fieldset "name" is that it
> also
I agree the jquery ui widget is the rift way to go IMO!
On Jun 2, 1:57 pm, Thomas Schreiber wrote:
> +1 for JqueryUI, it has come a long way in the last year, and it now has a
> nice system for subclassing widgets with the widget
> factory.http://bililite.com/blog/extending-jquery-ui-widgets/
>
On Jun 3, 8:57 am, Russell Keith-Magee
wrote:
> 5. Parameters "template" and "attrs" for forms, formsets, fieldsets,
> forms, (bound) fields and widgets
> 6. Support for (X)HTML5 and legacy HTML
>
> I strongly suspect that these two may be covered by something I
> discussed with Jacob at DjangoCon
Hey Petr,
On Jun 3, 11:32 am, "petr.marhoun" wrote:
> OK, more details: If fieldsets would be defined, fields would be
> concatenation of fields from individual fieldsets. So methods
> as_table, as_ul and as_li and "for field in form" would work as now.
> But if you want to really use fieldsets,
On Thursday 03 June 2010 08:59:31 Roald wrote:
> > One reason against this is it makes it harder to re-use other
> > views from within the View.
>
> I don't really understand what you mean. Do you mean re-using
> 'good' old function-views?
Yes, or new ones, or any callable that returns an HttpRe
On Thu, Jun 3, 2010 at 7:10 PM, Ben Firshman wrote:
> One advantage of using __call__ over __new__ is passing arguments to
> __init__. That's handy for lazily configuring views:
>
> (r'', DetailView(queryset=Thing.objects.all())
Why can't you use this instead:
(r'', 'views.DetailView', {'querys
On Thu, Jun 3, 2010 at 12:10 PM, Ben Firshman wrote:
>
> On 3 Jun 2010, at 17:45, Carl Meyer wrote:
>
>> On Jun 2, 6:20 pm, Ben Firshman wrote:
>>> Yeah, this idea came up at the sprints, but it's a little too magic for my
>>> tastes.
>>
>> I dunno... is __new__ really more magic than having a _
On 3 Jun 2010, at 17:45, Carl Meyer wrote:
> On Jun 2, 6:20 pm, Ben Firshman wrote:
>> Yeah, this idea came up at the sprints, but it's a little too magic for my
>> tastes.
>
> I dunno... is __new__ really more magic than having a __call__ method
> that magically copies the instance you call i
On Jun 2, 6:20 pm, Ben Firshman wrote:
> Yeah, this idea came up at the sprints, but it's a little too magic for my
> tastes.
I dunno... is __new__ really more magic than having a __call__ method
that magically copies the instance you call it on? That certainly
breaks my expectations.
Django do
On Jun 3, 2:57 pm, Russell Keith-Magee
wrote:
> On Thu, Jun 3, 2010 at 7:41 PM, petr.marhoun wrote:
> > Hello,
>
> > I would like to propose some improvements for django.forms. But it is
> > seven quite independent proposals - one mail would be to long, seven
> > emails would too many emails. So
Hi all,
I've written a prototype, and put it on
http://github.com/buriy/django-configurator.
It has few good design decisions, and few maybe not that good.
Anyway, I consider it as a good addition to app loading GSoC Proposal,
which is currently being worked on.
The key highlights of the implemen
Ok yes seems like a slam dunk.. hell how about an --install-media for
python setup.py install ;)
On Jun 3, 10:18 pm, Jannis Leidel wrote:
> Am 30.05.2010 um 05:54 schrieb BrettH:
>
> > +1 on Option 2.
>
> > I have written a basic deployment app (not quite ready for release
> > yet) that deploys a
Hi,
what about adding one more layer on top of forms:
a page object
why?
1) because it would be nice to have other widgets besides forms, too (e.g. a
(ajax-)table (like in the admin views)
2) having a page object could ease the mess with media files from forms and the
rest of a page (e.g. avoid
On Thu, Jun 3, 2010 at 7:41 PM, petr.marhoun wrote:
> Hello,
>
> I would like to propose some improvements for django.forms. But it is
> seven quite independent proposals - one mail would be to long, seven
> emails would too many emails. So I have created wiki page - is it a
> good procedure?
It'
I think grouping issues and features requests is always a good
thing :)
Now about the "Model fields with not-default values".
With 1.2 something like that landed to override the widget for fields
on ModelForms, but I agree that sometimes you need to change a label
or help text for a specific form
I tend to agree that #6362 should be reconsidered. Realistically
speaking, almost all form fields aren't going to want leading or
trailing spaces. The default case, therefore, should strip them,
while allowing the app writer to override that behaviour in the small
minority of cases where the whit
On Thu, Jun 3, 2010 at 4:38 AM, Russell Keith-Magee
wrote:
> [...]
> Regarding #13480 specifically -- I haven't dug into the problem in
> detail, but the approach of telling exceptions apart by inspecting the
> number of arguments doesn't fill me with joy. One of the changes in
> 1.2 was to improv
Am 30.05.2010 um 05:54 schrieb BrettH:
> +1 on Option 2.
>
> I have written a basic deployment app (not quite ready for release
> yet) that deploys a virtualenv for each version of your project,
> roughly equivalent to Google App Engine. I specifically need to split
> out the USER_MEDIA so that i
Am 28.05.2010 um 01:27 schrieb burc...@gmail.com:
> Hi all,
>
>> - a media files path resolver -- following a similar directory structure as
>> the app templates loader (/media/ vs. /templates/)
>> - build_static -- a mangement command that'll collect media files from apps
>> from various loca
Hello,
I would like to propose some improvements for django.forms. But it is
seven quite independent proposals - one mail would be to long, seven
emails would too many emails. So I have created wiki page - is it a
good procedure?
The wiki page:
http://code.djangoproject.com/wiki/ImprovementsForDj
Hi Russ,
> I've just given your patch on #8901 a quick inspection, and it looks
> good enough to me to progress to RFC (which I've done). I'm hoping to
> have some time tonight to commit some patches; I'll try to put this on
> the list.
Thanks for taking a look at it - I was just wanting to make
On Thu, Jun 3, 2010 at 4:23 PM, Matt Hoskins wrote:
> I haven't had a reply to this, which could have been bad timing
> posting it around when the conference was happening, or it could be as
> I gave the background first rather than summarising what I was after
> first so people skipped over readi
On Thu, Jun 3, 2010 at 5:33 PM, Thomas Guettler wrote:
> Hi,
>
> will there be a SVN branch releases/1.2.X?
>
> For 1.0 and 1.1 it exists:
>
> http://code.djangoproject.com/browser/django/branches/releases
Yes - a 1.0.X and 1.1.X branch exists - but they weren't created until
some time after the
Hi,
will there be a SVN branch releases/1.2.X?
For 1.0 and 1.1 it exists:
http://code.djangoproject.com/browser/django/branches/releases
Thomas
--
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de
--
You received this message because you are subscrib
I haven't had a reply to this, which could have been bad timing
posting it around when the conference was happening, or it could be as
I gave the background first rather than summarising what I was after
first so people skipped over reading it :).
The ticket's languished for a couple of years now
On 2 jun, 23:22, Luke Plant wrote:
> On Wednesday 02 June 2010 16:08:24 Roald wrote:
> > class View(HttpRequest):
> > def __init__(self, request, *args, **kwargs):
> > ...
> > super(View, self).__init__(self.content())
> > ...
>
> You mean:
>
> clas
On "strip keyword arg for CharField"
>From http://code.djangoproject.com/ticket/4960
09/14/07 11:28:49 changed by adrian
{{{
Marking as wontfix -- it's too specialized for inclusion in the main library. A
bunch of us in #django-sprint agreed.
}}}
We should think about this decision again. The cc
33 matches
Mail list logo
