Re: Proposal: Revised form rendering

[Tai Lee]

On Jul 14, 11:15 pm, Russell Keith-Magee 
wrote:
>
> I'm not wildly enthusiastic about this. You've posted this snippet (or
> something like it) a couple of times, and every time my immediate
> reaction has been "You're in a twisty maze of endtemplatedir tags, all
> alike" :-)
>
> I can see what you're trying to do in terms of setting default
> directories; but the syntax you are proposing:
>
>  * makes the representation of setting a default over a wide range quite 
> elegant
>  * makes the representation for overriding a default on a single
> field/form quite verbose.
>
> To me, this seems like priorities the wrong way around. Overriding a
> single default should be the simple case, not the verbose case.
> Consider the template where you want to override the default widget on
> every field on a form - your entire form will potentially be a nest of
> {% templatedir %}{% endtemplatedir %} tags.

Thanks for the feedback, Russ. I'm not set on any particular syntax, I
just wanted to demonstrate the idea of augmenting the path that
template loaders use as a way of customising presentation for a group
of pages, a single page, a group of elements on a page, or a single
element on a page.

I admit that several instances of {% templatedirs "mypath" %}
{{ form.field %}{% endblock %} or nested calls to {% templatedirs %}{%
endtemplatedirs %} in a template could get messy. I'm not sure how
else it could be done though, without tying it to a positional
argument to {% form %} and {% field %} tags, in which case it would
need to be added to every template tag you might want to override
templates for in this way. It might also be more difficult to override
when you have pluggable apps that include templates which already use
the {% form %} and {% field %} templates.

One thing to keep in mind is that you could actually wrap your entire
form (or page, or master template) in a {% templatedirs %} block tag
and then simply add/remove templates from your file system, without
having to make any other changes to existing or pluggable templates in
order to explicitly replace the templates for specific elements.

The {% form %} and {% field %} template tags could even be updated to
look for multiple templates, based on their name as well as their
type. I'm thinking of something like the admin here, where you can
define templates at different locations in order to apply them with
more or less granularity.

For example:

In your projects master template you wrap the whole thing in {%
templatedirs "myforms" %}{% endblock %}. Then, in any of the templates
derived from your master template (but not templates that belong to
pluggable apps that extend their own master template), the template
engine will look there first when loading templates. Effectively
adding a folder to the TEMPLATE_DIRS setting, but only for templates
that extend your master template, without affecting other pluggable
apps that you might be using.

Then, if you tried to render a form that had been assigned a name or
id of "contact", it would try to load:

myforms/django/forms/contact.html
myforms/django/forms/default.html
django/forms/contact.html
django/forms/default.html

And if you tried to render a field on the contact form that has a name
of "email", it would try to load:

myforms/django/formfields/contact/email.html
myforms/django/formfields/contact/default.html
myforms/django/formfields/email.html
myforms/django/formfields/default.html
django/formfields/contact/email.html
django/formfields/contact/default.html
django/formfields/email.html
django/formfields/default.html

Perhaps the block tag could either accept multiple paths to search, to
avoid ugly nesting. Or alternatively it could require two arguments,
the first being the path to search, and the second a filter so that
search paths are not searched unecessarily. E.g. if you knew you only
wanted to load temlates from "myforms" instead of "django/forms", you
could do {% templatedirs "myforms" "django/forms" %}...{%
endtemplatedirs %}? Or, perhaps it doesn't need to be a block level
tag. Perhaps it just just applies to the whole template, like {% load
%}?

Just food for thought.

Cheers.
Tai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Revised form rendering

[Carl Meyer]

On Jul 14, 4:15 pm, SmileyChris  wrote:
> We also need d) Media hooks for a single widget - whether this can be
> done in only the template layer is a tricky problem...
>
> I'm still struggling with how you'd be able to render all the media at
> the top of your template for the form. I guess you'd have to define
> any field widget overrides in that block, before rendering the form
> media.

Yeah, this is tricky. For JS generally it shouldn't be rendered until
the bottom of the template, for page-speed reasons, but the reverse is
true for CSS. I don't think there's yet been a proposal in this thread
for how to enable rendering widget media before the form is rendered,
both proposals so far would have you specifying/overriding chrome (or
widget templates) only at form-render time.

Obviously it'd also be good to be able to split CSS from JS, like the
Media framework allows.

One half-baked idea: what about annotating the form object itself with
information about customizations you've made: paths to form-rendering
templates and widget templates? So you could use the same
customization syntax when rendering the form or rendering the form
media, whichever you do first, and it would remember those
customizations for later?

This introduces a little more cleverness than I'd prefer, but if the
only other option is repeating every customization twice... I'm also
not sure how this would interact with the idea that the "form media
render" tag should accept multiple form objects, so even if you use
the same widget/chrome in multiple forms on a page, its media still
only gets rendered once.

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-develop...@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: Revised form rendering

[SmileyChris]

On Jul 15, 1:14 am, Russell Keith-Magee 
wrote:
> We need to be able to define templates for:
>
>  a) The layout for a single widget (e.g., a DateWidget)
>  b) The layout for a single row of a form
>  c) The layout for an entire form (top errors, fields, hidden fields)
> in as_* style.

We also need d) Media hooks for a single widget - whether this can be
done in only the template layer is a tricky problem...

I'm still struggling with how you'd be able to render all the media at
the top of your template for the form. I guess you'd have to define
any field widget overrides in that block, before rendering the form
media.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Revised form rendering

[Russell Keith-Magee]

On Wed, Jul 14, 2010 at 8:42 AM, Tai Lee  wrote:
> Hi Russ and Carl,
>
> On Jul 14, 5:55 am, Carl Meyer  wrote:
>> Hi Russ,
>>
>> On Jul 13, 12:11 pm, Russell Keith-Magee 
>> wrote:
>>
>> > My manifestation of this problem is slightly different -- it's the
>> > issue of how to ship a widget library that can be used anywhere. I
>> > suppose one argument here is that you just need to advertise your
>> > chrome with doctype support notes.
>>
>> > Alternatively, since this is a template language, you could always
>> > introduce an {% if %} block and render conditionally on doctype...
>>
>> Exactly. I can imagine a number of different ways a reusable widget
>> library might approach this problem: simply advertise support for a
>> certain doctype (don't discount the value of supporting this low-
>> barrier-to-entry option, even if it isn't ideally reusable), or use
>> template conditionals, or provide separate widget templates for
>> separate doctypes... I find it preferable to make the full power of
>> the template language available, and then let template authors use the
>> tools they know to iterate towards best practices in this area, rather
>> than hardcoding into Django particular ideas of which doctypes are
>> relevant and what changes have to be made in templates to support
>> them. It's not just a matter of closing slashes, also which attributes
>> are valid (of which there may be more added later that we don't even
>> know about now)... I think hardcoding current assumptions about
>> doctypes is just asking for maintenance headaches. I'd much rather
>> leave that concern where it belongs, fully in the hands of template
>> authors.
>
> I wouldn't like to see widget libraries being packaged up with
> templates including conditional templates based on doctype. This seems
> messy, not friendly to override in your own templates, and effectively
> combining what should be multiple separate templates into one.
>
> Wouldn't a mechanism that allows the path from which templates are
> loaded to be changed benefit both widget libarary authors and the
> designers who are implementing those widget libraries? A widget
> library author would include and advertise templates for each doctype
> they support, e.g. "html4/mywidgetlibrary/forms/datetime.html" and
> "xhtml1/mywidgetlibrary/forms/datetime.html", then the designer would
> use:
>
> {% templatedirs "html4/mywidgetlibrary" %}
>    {{ myform }}
> {% endtemplatedirs %}
>
> or:
>
> 
>    {{ form.myregulartextfield %}
>    ...
>    {% templatedirs "html4/mywidgetlibrary" %}
>        {{ myform.mydatetimefield }}
>    {% endtemplatedirs %}
> 

I'm not wildly enthusiastic about this. You've posted this snippet (or
something like it) a couple of times, and every time my immediate
reaction has been "You're in a twisty maze of endtemplatedir tags, all
alike" :-)

I can see what you're trying to do in terms of setting default
directories; but the syntax you are proposing:

 * makes the representation of setting a default over a wide range quite elegant
 * makes the representation for overriding a default on a single
field/form quite verbose.

To me, this seems like priorities the wrong way around. Overriding a
single default should be the simple case, not the verbose case.
Consider the template where you want to override the default widget on
every field on a form - your entire form will potentially be a nest of
{% templatedir %}{% endtemplatedir %} tags.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Revised form rendering

[Russell Keith-Magee]

On Wed, Jul 14, 2010 at 5:58 AM, Nick Phillips
 wrote:
> On Wed, 2010-07-14 at 00:11 +0800, Russell Keith-Magee wrote:
>
>> What exactly is your use case for something that designers want to
>> customize in the raw widget that widget.render() doesn't expose?
>
> That reminds me of one thing I'd very much like to see in any
> refactoring of form/widget handling.
>
> I'd like to be able to get at the "rendered" data (I say rendered, what
> I suppose I really mean is "transformed" either due to rendering needs
> or conversion from a graphical representation in the widget to something
> that could be resubmitted), without any of the surrounding chrome. There
> are various cases in which this can be useful, the most obvious of which
> is to tell whether the data in the form has been edited before
> submission. It's currently not possible to work this out from the
> "before" and "after" data, as you don't know how any particular field's
> data might have been munged by the widget (e.g. how is empty data
> rendered, any forcing to unicode, Python boolean to textual
> representation, date format transformation etc.).

Sounds like a reasonable request; and one that may almost be a
necessity if we're planning to make widgets rendered by template,
since we're going to need to expose most of the internals of a widget
to make them available for any possible rendering scheme.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Revised form rendering

[Russell Keith-Magee]

On Wed, Jul 14, 2010 at 3:55 AM, Carl Meyer  wrote:
> Hi Russ,
>
> On Jul 13, 12:11 pm, Russell Keith-Magee 
> wrote:
>> My concern about doing this entirely in templates is that it makes the
>> process of sharing a widget library a little more difficult. If it's
>> just code, then it just needs to be in the PYTHONPATH. If there are
>> templates too, then the templates need to be somewhere that they can
>> be accessed.
>
> So I think this is very much a programmer's perspective, almost
> humorously so :-) "Just code" may seem easy to you, but from the
> perspective of at least one experienced Django-template designer I've
> talked to, being able to do it entirely in templates makes the idea of
> sharing a widget library conceivable, as opposed to almost impossibly
> intimidating if its "just code."

By "just code", I don't mean "code is easy", I meant "code, and
nothing else". Anything you can do in template you can also do in
code. The same is not true the other way around. I'll concede that the
intended audience may not see code as an easy option, but that doesn't
change the fact that code offers solutions that aren't otherwise
available.

> The app_directories template loader is installed by default. Getting
> templates "somewhere they can be accessed" means creating a directory
> on the PYTHONPATH with an empty models.py, an empty __init__.py, and a
> "templates/" subdirectory, then putting that in INSTALLED_APPS. That's
> it. How is that harder than following exactly the same steps for an
> app that includes Python code? From the perspective of a non-
> programmer, it's much easier.

Fair point.

> The key issue is familiarity and ease-of-use. For template authors,
> not programmers. Template authors know perfectly well how to add
> classes and attributes to HTML elements. Why should they have to use a
> special API to do the same thing for form input elements? Again: if
> the goal is for Django template authors to create an ecosystem of
> reusable widgets, the system needs to be geared around the tools they
> are comfortable with, not the ones programmers are comfortable with.
> That means templates. And not Python code.

Ok. I can certainly see that a template-based solution is the popular
solution, especially amongst designers. I still have some
reservations, but they're almost entirely about technical feasibility
and complexity of representation, not about desirability.

Part of the problem is that we've spent a lot of time talking about
the template tag/filter, but almost none on what the templates would
look like, and how the multiple layers of templates will knit
together.

Here's my first cut at a list of the use cases we need to support:

We need to be able to define templates for:

 a) The layout for a single widget (e.g., a DateWidget)
 b) The layout for a single row of a form
 c) The layout for an entire form (top errors, fields, hidden fields)
in as_* style.

In each of these templates, (b) will need to render instances of (a),
and (c) will need to render multiple instances of (b) -- and not
necessarily the same instances, either.

Each of templates could be applied:

 1) As a background system default - what you get if you don't override anything
 2) As a specified default for the entire rendered page
 3) As a specified default for a single form on a page
 4) As a specified override for a field on a form (a/b) or a form as a whole (c)

There's also the issue of doctypes; If I have a document that is html4
document, I need to ensure I only get html4 snippets; ideally without
having to specify html4 every time I use a snippet.

If anybody has any other use cases or points worth considering, please speak up.

I'd like to spend a couple of days digesting what's been said in this
thread; I also want to look at some existing template-based projects
(like django-form-utils), and play around with a couple of ideas that
are lurking in the back of my brain. Hopefully, I'll be back in a week
or so with a revised proposal.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Django Unit Test on urls / views

[David P. Novakovic]

Hi,

This is the mailing list for discussion around developing the actual django
framework, not the use of the framework.

Your request would be better discussed over at django-users
http://groups.google.com/group/django-users .

Cheers,

D

On Wed, Jul 14, 2010 at 2:22 PM, Pradnya  wrote:

> Hello,
>
> I am want to write django 1.1 test case on fedora 12 x86_64.
> To test the url I want to session to be persistent so that the next
> test can use the same context. I can use client.login() method becoz
> in the application login is rewritten.
>
> If I directly use
> kwargs = {'HTTP_X_REQUESTED_WITH':'XMLHttpRequest'}
> response = self.client.post('/login/', {'username': 't...@test.com',
> 'password': 'test01', 'domain':'demo1'}, **kwargs)
> This works fine but I am not able to test the next url. It's trowing
> following error
> WARNING:root:Caught an exception while processing permission:
> {'content': 'MSHTML', 'name': 'GENERATOR', 'group_name': ''}
> ERROR:root:Permission matching query does not exist.
> Traceback (most recent call last):
>  File "/home/sungard/Portals/trunk/django/portal/../portal/auth.py",
> line 143, in authenticate
>perm = Permission.objects.get(codename = codename)
>  File "/usr/lib/python2.6/site-packages/django/db/models/manager.py",
> line 120, in get
>return self.get_query_set().get(*args, **kwargs)
>  File "/usr/lib/python2.6/site-packages/django/db/models/query.py",
> line 305, in get
>% self.model._meta.object_name)
> DoesNotExist: Permission matching query does not exist.
>
>
> Please suggest.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Django Unit Test on urls / views

[Pradnya Pawar]

Oh Thanks, I have moved it to Django Users
Any clue / suggestions on the bug.

Thanks & Regards
Pradnya

On Wed, Jul 14, 2010 at 12:25 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> On Wed, Jul 14, 2010 at 12:22 PM, Pradnya  wrote:
> > Hello,
> >
> > I am want to write django 1.1 test case on fedora 12 x86_64.
> > To test the url I want to session to be persistent so that the next
> > test can use the same context. I can use client.login() method becoz
> > in the application login is rewritten.
>
> Django-developers is for discussing the development of Django itself.
> If you have a user query, it should be directed to django-users.
>
> Yours
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@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.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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: Django Unit Test on urls / views

[Russell Keith-Magee]

On Wed, Jul 14, 2010 at 12:22 PM, Pradnya  wrote:
> Hello,
>
> I am want to write django 1.1 test case on fedora 12 x86_64.
> To test the url I want to session to be persistent so that the next
> test can use the same context. I can use client.login() method becoz
> in the application login is rewritten.

Django-developers is for discussing the development of Django itself.
If you have a user query, it should be directed to django-users.

Yours
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.