Re: Could not import man.credit.views, python 2.6.5. "No module named dl" error

It's an import issue with your app unrelated to django core. Someone here will eventually tell you to direct that to django-users, so you might as well hop over there now. On Jul 12, 4:31 pm, pacman wrote: > Hi, > > I've upgraded our python from 2.4 to 2.6.5.  When

Could not import man.credit.views, python 2.6.5. "No module named dl" error

Hi, I've upgraded our python from 2.4 to 2.6.5. When connecting to django server (1.2.1), it shows the following error: I assume it's still searching for deprecated dlmodule.so (py 2.4) or dl.so (py 2.6). We didn't compile that module in py 2.6.5. Anyone has seen this error and knows fix on

Proposal: namespaces for template tags/filters

Hi everyone, templatetags namespacing is a recurring topic that has been brought up quite a few times [1, 2, 3, 4]. Once per year now since 2006. It has appeared in relation to other topics, or on it's own. The idea was approved by a core commiter once [5] and now it has re emerged with Russ' new

Re: Regression problem on admin date format

> On Sun, Jul 11, 2010 at 10:36 AM, Antoni Aloy wrote: >> Hi, >> >> I have confirmed the bug with other non speaking people and I have >> sent an e-mail to django-i18n group to point out the problem. >> >> I have also contacted Marc and he has confirmed that the problem

Re: New admin feature: Delete and replace with existing object

On Tue, Jul 13, 2010 at 1:37 AM, Ric wrote: > hi russ i have been on a wedding! > > ok, now i see the point. > > but what i was tring to say is that adding a simple version of this > feature would be a plus to the actual version of django, with hooks it > would be a

Re: Proposal: Revised form rendering

Russ/Carl: Finally got a chance to catch up on the thread, and found Carl penned a (lovely, much more detailed) version of what I had in mind. In the end, forms is a repository of unusually common fail because designers must figure out Python and a lot of how django works in order to customize

Re: Regression problem on admin date format

Did the patch that is attached to this issue work for you? It would really be nice to get some feedback on it :-) From what I've heard in other posts on this and the django-users list so far it seems to do the job. -- Horst P.S.: Sorry if this mail reaches you a second time. Somehow Google

Re: Proposal: Revised form rendering

Hi Russ, First of all, thanks very much for this proposal! Form rendering has been a major pain point for us (thus the existence of django-form-utils), and improving it is tops on my 1.3 wishlist. I will also be at DjangoCon and eager to sprint in this area. Django has a really good template

Re: Proposal: Revised form rendering

Hi all, I'm certainly excited to see improvements in the form rendering arena, so thanks Russ for putting in the work here! I work with Django plenty as a programmer, but in truth I work more as a designer. And as a designer, I've spent more than my share of time wrangling Django's existing

Re: New admin feature: Delete and replace with existing object

hi russ i have been on a wedding! ok, now i see the point. but what i was tring to say is that adding a simple version of this feature would be a plus to the actual version of django, with hooks it would be a great plus. i think that definition of public API is something that should be done

Re: LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL and SCRIPT_NAME.

Hi Russ, On Jul 10, 8:24 am, Russell Keith-Magee wrote: > On Sat, Jul 10, 2010 at 12:49 AM, Carl Meyer wrote: > > Wouldn't it be most sensible to treat the URL mount point similarly to > > hostname, since they are really just two pieces of the

Re: Proposal: Revised form rendering

Hey Russ, I think this is a great proposal so far! Is there a way with the proposed solution for the template designer to add custom attributes to a form field? If so, do you envision that happening in the chrome layer? Here's a use case: The designer wants to render an email input field. They

Re: Enhanced URL Resolver Match

Hey Nate, This actually doesn't touch handling lazy reversing of urls, this deals strictly with enhancing the result of the resolve(...) function to provide more detail than just func, args, kwargs. Nowell On Jul 12, 9:57 am, Nate wrote: > If I'm not mistaken, this

Re: Proposal: Revised form rendering

It appears my reply got eaten so I'm trying again. On Jul 12, 3:43 pm, Russell Keith-Magee wrote: > I'm having difficulty reconciling these two positions. My template tag > is too complex because it requires you to remember the idiom FORM X > FIELD Y USING Z; but a

Re: Proposal: Revised form rendering

On 07/12/2010 07:03 AM, Russell Keith-Magee wrote: On Mon, Jul 12, 2010 at 5:43 AM, Tim Chase wrote: [please excuse the slight chop-up-and-reordering of your original into my quoting] Only if you grant me the same liberty :-) Fair's only fair :) and

Re: Proposal: Revised form rendering

On Jul 12, 3:43 pm, Russell Keith-Magee wrote: > > Andre's idea is interesting and is certainly more readable. > > I'm having difficulty reconciling these two positions. My template tag > is too complex because it requires you to remember the idiom FORM X > FIELD Y USING

Re: Proposal: Revised form rendering

On Mon, Jul 12, 2010 at 8:16 AM, Russell Keith-Magee wrote: > On Mon, Jul 12, 2010 at 11:27 AM, Javier Guerra Giraldez > wrote: >> no, the P, UL (and my hypothetical left_table) would each one be a >> class; you could import each one separately (or

Re: Enhanced URL Resolver Match

If I'm not mistaken, this sort of lazy url reversing could make it possible to reverse URLs in settings, which has effect upon issues such as the following: http://groups.google.com/group/django-developers/browse_thread/thread/fa3661888716f940 Is that correct? On Jul 11, 11:02 am, Nowell Strite

Re: ModelView

On Mon, Jul 12, 2010 at 2:13 PM, Roald wrote: > Hi all, > > > There is a discussion 'Class based generic views in 1.3?' in this > list. I would like to suggest an alternative: ModelViews. There > normally are multiple standard views associated with one model, and > such a

Re: Proposal: Revised form rendering

On Jul 12, 8:12 am, Russell Keith-Magee wrote: > On Mon, Jul 12, 2010 at 10:31 AM, André Eriksson wrote: > > Good proposal overall. One thought I have in order to try and combat > > the massive parameter list of {% form %} is to optionally add an > >

Re: Proposal: Revised form rendering

On Mon, Jul 12, 2010 at 9:47 PM, Russell Keith-Magee wrote: > On Mon, Jul 12, 2010 at 9:38 PM, Tim Chase >> Looking back over the thread, I'm the only Tim, but I don't seem to see your >> response (neither in my email nor via gmane).  If you could disinter it from >> your

Proposal: Revised form rendering

On Mon, Jul 12, 2010 at 5:43 AM, Tim Chase wrote: > [please excuse the slight chop-up-and-reordering of your > original into my quoting] Only if you grant me the same liberty :-) > On 07/11/2010 10:36 AM, Russell Keith-Magee wrote: >> {% form myform field

Re: Proposal: Revised form rendering

On Mon, Jul 12, 2010 at 9:38 PM, Tim Chase wrote: > On 07/12/2010 08:12 AM, Russell Keith-Magee wrote: >> >> On Mon, Jul 12, 2010 at 10:31 AM, André Eriksson  wrote: >>> >>> Good proposal overall. One thought I have in order to try and combat >>>

Re: Proposal: Revised form rendering

On Mon, Jul 12, 2010 at 3:11 PM, mattimust...@gmail.com wrote: > > > On Jul 12, 12:31 pm, André Eriksson wrote: >> Good proposal overall. One thought I have in order to try and combat >> the massive parameter list of {% form %} is to optionally add an >>

Re: Proposal: Revised form rendering

On 07/12/2010 08:12 AM, Russell Keith-Magee wrote: On Mon, Jul 12, 2010 at 10:31 AM, André Eriksson wrote: Good proposal overall. One thought I have in order to try and combat the massive parameter list of {% form %} is to optionally add an ending tag, as well as sub-tags:

Re: Proposal: Revised form rendering

On Mon, Jul 12, 2010 at 1:05 PM, Tai Lee wrote: > Regarding the DOCTYPE problem, I don't think it's appropriate to set > the DOCTYPE as a setting for an entire project. As many have pointed > out, each bundled app could define a different DOCTYPE in their base >

Re: Proposal: Revised form rendering

On Mon, Jul 12, 2010 at 11:27 AM, Javier Guerra Giraldez wrote: > On Sun, Jul 11, 2010 at 9:23 PM, Russell Keith-Magee > wrote: >>  * Duplication. The 'left_table' flag needs to be applied to every use >> of the {% form %} tag on a page. If you're >>

Re: Proposal: Revised form rendering

On Mon, Jul 12, 2010 at 10:31 AM, André Eriksson wrote: > Good proposal overall. One thought I have in order to try and combat > the massive parameter list of {% form %} is to optionally add an > ending tag, as well as sub-tags: > > {% form myform %} >    {% using

Re: ModelView

> Anybody likes the idea? Sounds good. Unfortunately I didn't read long-long thread about class-based views :( > - I'm no fan of 'class Meta' myself, but I've chosen it here to be > compatible with ModelForm I'm too -- You received this message because you are subscribed to the Google Groups

Re: Proposal: Revised form rendering

k On Mon, Jul 12, 2010 at 5:38 AM, Idan Gazit wrote: > What a fantastic proposal. I have some concerns, but I'm not sure if > any of them have to do with my misunderstanding. > > 1. The {% load %} mechanism can get ugly, fast. What if I am rendering > multiple different forms on

Re: Class based generic views in 1.3?

On 17 jun, 22:45, Jacob Kaplan-Moss wrote: > Okay, folks: at this point the discussion has pretty much descended > into bikeshedding territory. This is no bikeshedding territory, but a new idea. I just started a new thread on this list, 'ModelView'. It's very similar to

ModelView

Hi all, There is a discussion 'Class based generic views in 1.3?' in this list. I would like to suggest an alternative: ModelViews. There normally are multiple standard views associated with one model, and such a class can take advantage of that. Its use should look something like this: *

Re: Proposal: Revised form rendering

On Jul 12, 12:31 pm, André Eriksson wrote: > Good proposal overall. One thought I have in order to try and combat > the massive parameter list of {% form %} is to optionally add an > ending tag, as well as sub-tags: > > {% form myform %} >     {% using birthday=calendar %} >