date:20110524

Re: RFC: Templatetag API for form rendering

2011-05-24 Thread Benoît Bryon


Hi,

I am the author of the django-formrenderingtools package, which focuses 
on a template tag library to render forms.

Currently widgets and formsets are not supported, but they could be.
I guess it matches the subject of the GSoC.

So I would be glad if you had a look at my work. It is certainly not 
perfect, but I did my best.
Although the code is available since some time now (2009 as I remember) 
I really miss feedback from other users. I do not know if others are 
using the application, and if not, I do not know why.

I recently worked on the following items so that you can review it quickly :
* documentation
* packaging
* a demo project to discover the application and try it in a sandbox
The version 0.2.1, released on last sunday, is tagged as "beta", but I 
am using it in production. I mainly miss feedback to be sure.


I am open to any suggestions if I can help:
* I can switch to Github if it helps
* I can adapt the license
* I will try to follow this GSoC and contribute to discussions

I would be glad to share my work and contribute to this topic...

Some links :
http://pypi.python.org/pypi/django-formrenderingtools/
http://packages.python.org/django-formrenderingtools/
https://bitbucket.org/benoitbryon/django-formrenderingtools/src

About the particular topic of your original post :
http://packages.python.org/django-formrenderingtools/reference/template_tags.html
http://packages.python.org/django-formrenderingtools/reference/template_names.html

--
Benoît Bryon
Makina Corpus

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Template.origin

2011-05-24 Thread Jeremy Dunck

On Tue, May 24, 2011 at 12:14 PM, Carl Meyer  wrote:
> On 05/24/2011 11:53 AM, Jeremy Dunck wrote:
>> I was wondering how people would feel about template origin being an
>> attribute of the Template instance.
>>
>> The point to me would be to make it easier to see which location a
>> template is coming from; I think the compile_string func could do it--
>> after constructing the template, the loader would annotate with
>> origin.
>>
>> It seems obviously useful, so I think there must be a good reason it
>> wasn't already done.  :)
>
> Looking at the code only briefly, it seems pretty reasonable to me.
>

Eh, I was looking at the 1.2 tree, and in any case, misread some code.

So, Template.__init__ in the 1.3 tree, anyway:
+ self.origin = origin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Template.origin

2011-05-24 Thread Carl Meyer

On 05/24/2011 11:53 AM, Jeremy Dunck wrote:
> I was wondering how people would feel about template origin being an
> attribute of the Template instance.
> 
> The point to me would be to make it easier to see which location a
> template is coming from; I think the compile_string func could do it--
> after constructing the template, the loader would annotate with
> origin.
> 
> It seems obviously useful, so I think there must be a good reason it
> wasn't already done.  :)

Looking at the code only briefly, it seems pretty reasonable to me.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Template.origin

2011-05-24 Thread Jeremy Dunck

I was wondering how people would feel about template origin being an
attribute of the Template instance.

The point to me would be to make it easier to see which location a
template is coming from; I think the compile_string func could do it--
after constructing the template, the loader would annotate with
origin.

It seems obviously useful, so I think there must be a good reason it
wasn't already done.  :)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: RFC: Templatetag API for form rendering

2011-05-24 Thread Carl Meyer

On 05/24/2011 09:35 AM, Gregor Müllegger wrote:
>> Which templates are involved in a form layout?
> 
> This is not yet defined in detail. I would suggest a schema like:
> 
> forms/layouts//.html
> 
> Resulting in templates for the layout "table" like:
> 
> forms/layouts/table/row.html
> forms/layouts/table/label.html
> forms/layouts/table/field.html
> forms/layouts/table/errors.html
> forms/layouts/table/help_text.html

This looks like a pretty good starting point to me.

Since we're building on top of Bruno's templated widgets, I think it
would also be quite useful if you could override the default widget
templates in your layout, just by placing the properly named file at the
right location. So if a widget uses the template
forms/widgets/textarea.html, and you're using "mycustom" layout, it
would first look for a template at
"forms/layouts/mycustom/widgets/textarea.html".

> A note on something different: We haven't specified yet how it will look like
> to render just parts of a single field like errors. If we keep the
> {{ field.errors }} syntax (which is unlikely since the template variable has
> no access to the layout set by {% formlayout %}) or if we use an extra
> templatetag for that. A proposal for these details will follow after we have
> agreed on the higherlevel things like described in the RFC.

Yeah. I guess it would be possible to squeeze this into the {% form %}
(nee {% renderform %}) tag with some syntactical modifiers, e.g.:

{% form "myfield:errors" %}

Or even with a filter?

{% form "myfield"|fielderrors %}

But it may be cleaner just to do it as a separate tag.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: RFC: Templatetag API for form rendering

2011-05-24 Thread Carl Meyer

Hi Gregor,

On 05/24/2011 09:25 AM, Gregor Müllegger wrote:
>
> Yes, defining a global default is really useful, we shouldn't skip that.

Yep, I'm definitely converted to that position ;-)

>> For the case-by-case override, though, I'd still much rather write
>>
>> {% form "table" %}
>>  {% renderform myform %}
>> {% endform %}
>>
>> than
>>
>> {% form %}
>>  {% formlayout "table" %}
>>  {% renderform myform %}
>> {% endform %}
>>
>>
>> What if instead of allowing form modifier tags to appear unenclosed, and
>> making them then implicitly global, we had a {% formdefaults %} tag that
>> paralleled the {% form %} tag, except it defined your defaults for form
>> rendering:
>>
>> {% formdefaults "table" %}
>>  {% widget ... %}
>> {% endformdefaults %}
>>
>> This is much more explicit, which means that a) a random new designer
>> reading your templates is more likely to notice that global defaults are
>> being defined, and b) you're less likely to accidentally define global
>> defaults because you omitted an enclosing block tag.
> 
> A question for my own understanding: The difference between your
> {% formdefaults %} variant and my "modify a global scope" is just a
> syntactical difference i.e. the following examples are equal?

That's right.

> (using your syntax)
> {% formdefaults %}
> {% widget ... %}
> {% endformdefaults %}
> 
> {% form %}
> {% renderform my_form %}
> {% endform %}
> 
> (using the RFC syntax)
> {% widget ... %}
> 
> {% form %}
> {% renderform my_form %}
> {% endform %}
> 
> And you propably want to raise a TemplateSyntaxError if the {% widget ... %}
> tag is used outside a {% formdefaults %} or {% form %} enclosed block?

Also correct.

The other difference is that if we have {% formdefaults %} we can
specify the layout as an argument to {% formdefaults %} as well as an
argument to {% formconfig %} or whatever we name it (presuming we listen
to Russ on that naming, and I think he's right), and that means we
really wouldn't need {% formlayout %} as a separate tag anymore. Which I
think is a plus.

> I'm not sure yet, if it's worth the extra {% formdefaults %} tag. Ofcourse it
> prevents template authors from excidentally overriding defaults, but I think
> who will use these utilities must know about these implications anyway. It's
> somehow just reflecting the behaviour of a python module scope.
> But maybe I'm a bit too much programmer here and reflecting too much
> of my habits
> onto the template authors mind.

There are some key differences between this and Python module scope,
besides the usual "template authors aren't necessarily Python
programmers." The main one is that Python module scope is contained
within a single file; here we're talking about a global scope that
potentially extends across many template files, what with inheritance
and includes, and even into Python code files too. I think because of
this action-at-a-distance factor, there's a much greater need to make
the modification of global scope explicit, clear, and hard to do by
accident or overlook.

It also makes it easy to "grep" for places where the global defaults are
being set. Otherwise, there'd be no easy way to find them and separate
them out from scoped uses of the modifier tags.

Given that this is something you'd likely only do once in your project,
not over and over again, I think the downside of typing the extra tag is
minimal.

> After all I have no objections against the {% formdefaults %} proposal and
> would be happy implementing it if thats your prefered way.

I do think it's clearly better, though if you disagree of course you
should argue, not just do it my way ;-)

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: RFC: Templatetag API for form rendering

2011-05-24 Thread Gregor Müllegger

Hi Preston,

2011/5/23 Preston Timmons :
> This looks interesting so far.
>
> How does setting the form layout affect rendering individual fields in
> a form?
>
> Is the output of {% renderform my_form "first_name" %} equivalent to
> {{ form.first_name }}, or is it more like the output of "as_p" or
> "as_table"?

It's not really equivalent to {{ form.first_name }} because the template
variable would only render the widget. The {% renderform %} is meant to
render complete rows, including field errors, help text, the label etc.

This means you could list all the fields of a form by hand and it would
result in the same output, i.e. the following examples would result in the
same output:

(assuming my_form only has two fields)

{% rendeform my_form "first_name" %}
{% rendeform my_form "last_name" %}

-- or --

{% rendeform my_form %}

> Which templates are involved in a form layout?

This is not yet defined in detail. I would suggest a schema like:

forms/layouts//.html

Resulting in templates for the layout "table" like:

forms/layouts/table/row.html
forms/layouts/table/label.html
forms/layouts/table/field.html
forms/layouts/table/errors.html
forms/layouts/table/help_text.html

But this might change if we see it fit while using it in sample projects
during the summer.


A note on something different: We haven't specified yet how it will look like
to render just parts of a single field like errors. If we keep the
{{ field.errors }} syntax (which is unlikely since the template variable has
no access to the layout set by {% formlayout %}) or if we use an extra
templatetag for that. A proposal for these details will follow after we have
agreed on the higherlevel things like described in the RFC.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: RFC: Templatetag API for form rendering

2011-05-24 Thread Gregor Müllegger

2011/5/23 Carl Meyer :
> I guess I was comparing
>
> {% form %}
>  {% renderform myform %}
> {% endform %}
>
> to
>
> {% form "table %}
>  {% renderform myform %}
> {% endform %}
>
> and thinking the latter didn't seem too comparatively onerous, even if
> you were doing it for every form render. But I'd forgotten that for
> simple cases you could otherwise just do {% renderform myform %} with no
> block tag; it is unfortunate to require the block tag every time in case 3.
>

Yes, defining a global default is really useful, we shouldn't skip that.

> For the case-by-case override, though, I'd still much rather write
>
> {% form "table" %}
>  {% renderform myform %}
> {% endform %}
>
> than
>
> {% form %}
>  {% formlayout "table" %}
>  {% renderform myform %}
> {% endform %}
>
>
> What if instead of allowing form modifier tags to appear unenclosed, and
> making them then implicitly global, we had a {% formdefaults %} tag that
> paralleled the {% form %} tag, except it defined your defaults for form
> rendering:
>
> {% formdefaults "table" %}
>  {% widget ... %}
> {% endformdefaults %}
>
> This is much more explicit, which means that a) a random new designer
> reading your templates is more likely to notice that global defaults are
> being defined, and b) you're less likely to accidentally define global
> defaults because you omitted an enclosing block tag.

A question for my own understanding: The difference between your
{% formdefaults %} variant and my "modify a global scope" is just a
syntactical difference i.e. the following examples are equal?

(using your syntax)
{% formdefaults %}
{% widget ... %}
{% endformdefaults %}

{% form %}
{% renderform my_form %}
{% endform %}

(using the RFC syntax)
{% widget ... %}

{% form %}
{% renderform my_form %}
{% endform %}

And you propably want to raise a TemplateSyntaxError if the {% widget ... %}
tag is used outside a {% formdefaults %} or {% form %} enclosed block?

I'm not sure yet, if it's worth the extra {% formdefaults %} tag. Ofcourse it
prevents template authors from excidentally overriding defaults, but I think
who will use these utilities must know about these implications anyway. It's
somehow just reflecting the behaviour of a python module scope.
But maybe I'm a bit too much programmer here and reflecting too much
of my habits
onto the template authors mind.

After all I have no objections against the {% formdefaults %} proposal and
would be happy implementing it if thats your prefered way.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Template Engine Compilation and Runtime Refactoring Progress

2011-05-24 Thread Armin Ronacher

Hi,

The repository with my changes will be here:
  https://github.com/mitsuhiko/django-template-compilation

As this proposal implements a 'newtemplates' module in Django instead
of modifying the existing one until it's proven to be compatible in
every single regard, I will have it as a separate repository. The idea
is that it can then easily be tested with other changes in Django
itself.

Regards,
Armin

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: remove "Change" links on admin index page

2011-05-24 Thread Daniel Moisset

On Tue, May 24, 2011 at 3:48 AM, Anshuman Aggarwal
 wrote:
> Luke,
>  I completely agree on the need for change and personally +1 this as
> it is a completely confusing historical annoyance.
>
> However, as in all deprecation, I would suggest that we start with a
> global setting that allows these links to be hidden on an installation
> by installation basis and the default made to true for now.
> With the next release, the default can be made False and eventually
> when there is an enhancement available, that can be the option
> available.
>
> e.g.
> ADMIN_SHOW_CHANGE_LINKS  = True (defaults to False)
>

Users won't guess the existence of this setting, so any user who found
this was reading the release notes/upgrading docs (which he should :)
). So rather than adding "use the ADMIN_SHOW_CHANGE_LINKS setting" to
the docs, I'd rather add "update template X, adding line YY to get
the old behavior", instead of cluttering the setting list.

I'm +1 to the change as long as it's documented and there's an easy
and documented way to edit the template to re-add the old behavior...
maybe adding a {% block %} inside the  to make it easy to override
with template inheritance.

Regards,
D.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: remove "Change" links on admin index page

2011-05-24 Thread Idan Gazit



On Tuesday, May 24, 2011 9:48:43 AM UTC+3, Anshuman Aggarwal wrote:
>
> However, as in all deprecation, I would suggest that we start with a 
> global setting that allows these links to be hidden on an installation 
> by installation basis and the default made to true for now. 
>

-1, if only because we shouldn't add settings that are truly necessary. I 
don't think this case warrants Yet Another Setting.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Template inheritance and duplicated content.

2011-05-24 Thread Jonathan Slenders

Even more confusing, but extremely great to abuse!


base.html
{% block a %}{% endblock %}
{% block b %}{% endblock %}
{% block c %}{% endblock %}
{% block d %}{% endblock %}
{% block e %}{% endblock %}

index.html
{% block a %}
{% block b %}
{% block c %}
{% block d %}
{% block e %}
duplicate
{% endblock %}
{% endblock %}
{% endblock %}
{% endblock %}
{% endblock %}


This will print "duplicate", 5 times, and cover cases that a for-loop
can't because all the different blocks in base.html can be spread over
the whole template, whereever you want. :)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Template inheritance and duplicated content.

2011-05-24 Thread Jonathan Slenders

Hi all,

This seems like a weirdness in template inheritance...

base.html

{% block title %} ... {% endblock %}
{% block content %}... {% endblock %}


index.html
{% extends "base.html" %}
{% block content %}
  {% block title %}
  some text
  {% endblock %}
{% endblock %}


The paragraph is shown twice in the output. Once, because the block
'title' is copied into the 'title' of the parent during the
inheritance, and once because the block 'content' is copied.

I guess this is a flaw in the inheritance algorithm, only the most
outer blocks should be used during the resolving of inheritance.

Because: if we would extend index.html, and override the block
"title", the current template engine will replace the title-block from
base.html, instead of the nested title-block of index.html which is
completely counter-intuitive.

Is this behaviour documented or on purpuse? We should have a clear
definition of how inheritance should work, especially now the Jinja-
guy is working on a compatible template engine. (And also the template
preprocessor does resolve inheritance at compile time.)

It is otherwise possible that people will start using this flaw as a
kind of macro-feature, to intentionally duplicate content.

Jonathan


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Formalizing manage.py's relationship to settings.py

2011-05-24 Thread graham_king

manage.py has an ambiguous relationship to settings.py: It requires it
to be present, imports it, passes it to core.management.setup_environ,
uses it's location to set your python path, but doesn't necessarily
use it as your settings. You can override that final part via --
settings or DJANGO_SETTINGS_MODULE.

I'd like to change that relationship to be either always REQUIRED or
always OPTIONAL.

1. REQUIRED: manage.py always uses settings.py. It no longer accepts --
settings and DJANGO_SETTINGS_MODULE.
Currently manage.py exits with an warning if settings.py is not found
(the warning encourages you to use django-admin), so I think this is
the current intended behavior. This behavior also fits with the docs
at http://docs.djangoproject.com/en/dev/ref/django-admin/

2. OPTIONAL: manage.py looks in order for a --settings, then a
DJANGO_SETTINGS_MODULE, and finally a settings.py, and only imports
the first one it finds, passing that one to
core.management.setup_environ to set your path and be used as your
settings.

This is in the context of #13612.

What do you think?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Proposal: remove "Change" links on admin index page

2011-05-24 Thread Anshuman Aggarwal

Luke,
 I completely agree on the need for change and personally +1 this as
it is a completely confusing historical annoyance.

However, as in all deprecation, I would suggest that we start with a
global setting that allows these links to be hidden on an installation
by installation basis and the default made to true for now.
With the next release, the default can be made False and eventually
when there is an enhancement available, that can be the option
available.

e.g.
ADMIN_SHOW_CHANGE_LINKS  = True (defaults to False)

Any other way of doing this could be very very harsh to users,

My 2,

Anshu
On May 24, 2:16 am, Luke Plant  wrote:
> On 23/05/11 19:45, Idan Gazit wrote:
>
> > I agree that it's redundant and unnecessary, but absent a particular
> > *need* to remove it, I'd say leave it until the admin gets an overall
> > refresh.
>
> > While having two links may be marginally confusing for new users,
> > _removing_ an existing bit of functionality is akin to a breaking
> > change, IMO. It's not that we shouldn't do it, just that we should treat
> > it with due gravity.
>
> OK, no probs.
>
> While I agree that we don't want to make people re-learn things, I also
> think that user interface improvements are not going to be possible if
> we have a policy of just keeping everything we've already got.
>
> However, I do understand the concern, and I'm perfectly happy for this
> to be added to the list of "things we should fix when we've got
> something more positive to add to the admin".
>
> Luke
>
> --
> "The first ten million years were the worst. And the second ten
> million, they were the worst too. The third ten million, I didn't
> enjoy at all. After that I went into a bit of a decline." (Marvin
> the paranoid android)
>
> Luke Plant ||http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: RFC: Templatetag API for form rendering

Re: Template.origin

Re: Template.origin

Template.origin

Re: RFC: Templatetag API for form rendering

Re: RFC: Templatetag API for form rendering

Re: RFC: Templatetag API for form rendering

Re: RFC: Templatetag API for form rendering

Re: Template Engine Compilation and Runtime Refactoring Progress

Re: Proposal: remove "Change" links on admin index page

Re: Proposal: remove "Change" links on admin index page

Re: Template inheritance and duplicated content.

Template inheritance and duplicated content.

Formalizing manage.py's relationship to settings.py

Re: Proposal: remove "Change" links on admin index page

15 matches

Site Navigation

Mail list logo

Footer information