I really like the idea of using Django templates instead of generating
markup in Python, which should enable designers (who don't know and
don't want to know Python) to customise markup in almost any way they
like. We just need to add a few hooks that will make it easier to
override specific templa
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 connecting to django
> server (
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 the
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 p
> 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 exists.
>>
>> Sorry for the
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 great plus.
>
> i think that de
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 fo
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
Groups
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 syst
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 templ
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
afte
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 same data: the
> > deployed root URL of the applicat
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
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 sort of lazy url reversing co
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 nested tag structure with 4 dif
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 REALLY -1.0e1 on this syntax-soup. Do
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 Z; but a nested tag struct
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 maybe several included
>> by default). in my ex
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
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 class can take advantage
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
> > ending tag, as well as sub-tags:
>
> > {% form
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 sent-mail folder and rese
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 birthdate using calendar important %}
>
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
>>> the massive parameter list of {% form %} is to opti
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
>> ending tag, as well as sub-tags:
>>
>> {%
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:
{% form myform %}
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
> templates.
>
> It doesn't make sens
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
>> manually rolling out every field on a form, th
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 birthday=calendar %}
> {% rend
> 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
"D
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 the same page? {%
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 class based generic views
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:
* i
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 %}
> {% renderer "as_
34 matches
Mail list logo
