Re: Process discussion: reboot

[Gregor Müllegger]

Also a +1 from me on the proposal for a tutorial for contributing and
how to get into the process of using Django's trac. I also tried to
get into triaging tickets a few times but I was very unsure in most
cases how to handle the status of the tickets, how to decide what
needs to be done or if this what I wanted to do is more a competence
of a core developer.

Gregor

On 20 Apr., 19:36, Bmheight  wrote:
> +1 to Stephen Crosbys' proposal, although I think this would be a bit
> difficult to perform as the Framework evolves and the documentation on this
> would be a bit outdated as time goes on (And have to yet again maintain
> another Document to keep up to date).
>
> It it still none the less a good idea in my opinion.
>
> On Tue, Apr 20, 2010 at 9:43 AM, Stephen Crosby wrote:
>
>
>
> > What could be very helpful here is some education for would-be Django
> > developers. The tutorial format has worked so well for educating new Django
> > users, why not apply it also to Django developers also? After the 1.2
> > release, why don't we come up with a Django developers tutorial that walks
> > us through the process of solving issues and working on Django. The goal of
> > this would be to help would-be developers understand the Django development
> > process by getting their hands dirty with a real issue.
>
> > It could begin with a short explanation of the process, go through finding
> > a real (old) example issue in Trac (already solved), it could run down what
> > type of Trac activity is helpful and what is not. Then the tutorial could
> > instruct the reader to checkout an old revision of Django (with the unsolved
> > issue) and how to reproduce the issue.
>
> > We could show the reader how to apply a bad patch (attached by some
> > less-informed Trac user), then how to run the test suite and notice that
> > some tests fail. Some instruction on how to politely note that fact on Trac
> > might be in order as well as how the patch was rewritten in order to pass
> > the tests.
>
> > Another bit on proper documentation, some notes on quality, where to get
> > help, what types of issues need discussion on this list would be great and
> > I'm sure there's more that could be included with this type of tutorial.
>
> > On Tue, Apr 20, 2010 at 9:09 AM, Jacob Kaplan-Moss 
> > wrote:
>
> >> On Mon, Apr 19, 2010 at 3:34 PM, Gabriel Hurley  wrote:
> >> > When I finally did submit my first patch, I was terrified of getting
> >> > it wrong and having it rejected. I'd seen it happen on other tickets.
> >> > It wasn't until I got *more involved* and started keeping up with the
> >> > trac timeline--watching the ebb and flow of tickets--that I started to
> >> > understand how the tone on trac had a reason. Until you get that
> >> > perspective, it's hard to know what's right or wrong, and easy to take
> >> > things personally. The core devs can seem imposing or scary simply
> >> > because you don't know them.
>
> >> This is *really* good feedback, and thank you very much for it.
>
> >> Clearly scaring people isn't our intent, but if that's the result...
> >> well, we're doing something wrong. I really don't want people to be
> >> scared off, and I'm hearing from you and a few others that that's
> >> already happening.
>
> >> I don't think I need to enumerate why the tone on a ticket tracker
> >> tends towards the terse -- lack of time, repetition, yadayada -- but
> >> regardless I don't like our process being scary.
>
> >> > If anything, my point is that getting started as a Django contributor
> >> > *can* be difficult, and the core team just being aware of that fact is
> >> > a good thing.
>
> >> I hear you loud and clear, and I'd love any suggestions you might have
> >> about how we might improve in this area.
>
> >> Jacob
>
> >> --
> >> 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.
>
> > --
> > Stephen Crosby
> > Web Developer
> > lithostech.com
>
> > --
> > 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 
> athttp://groups.go

Re: django template revision (for 1.4?)

[Gregor Müllegger]

Hi Daniel,

I think your suggestion might make sense for some people using
autoclosing brackets etc. But having better support for writing
templatetags is just an issue with a text editor which might be
configurable and easy to write a plugin or using a snippet completion
to make life easier for you typing things.

So in my opinion its unlikely that your proposal will be intergrated
into django because it breaks backwards compatibility without having
any functional improvement. You would need to update all existing
django templates and it also breaks compatibility with implementations
of the DTL in other programming languages.

Gregor


disclaimer: I'm not a core-developer and are not responsible for any
design decisions.

On 26 Mai, 20:24, Daniel  wrote:
> Hi, I was just referred here with a suggestion I posted on the django
> ticket tracker. I've been studying the way we do template tags, and
> had a suggestion for how to revise them to make them a bit easier. I
> was thinking that out of the tags, I like the variable syntax the best
> -- {{ variable.attribute }}. I realize that if we were to use the
> double curly brackets on all of the tags, they might conflict with the
> namespace, but it seems like having "block", "if", "elsif", "else",
> "for", and "extends" and their respective 'end'ings as keywords would
> not be burdensome. It's really unpleasant typing {%%} and left arrow
> twice, space, the item name, and space for every tag and for its
> closing tag.
>
> An alternative that wouldn't affect the namespace but would still be
> more convenient for both plain typing and possibly for code completion
> (I don't know why eclipse pydev doesn't close these tags) would be
> triple brackets --  {{{ block head }}}.
>
> Thanks for your time,
> -Dan
>
> p.s. not sure if the code will show up appropriately in the above, but
> hopefully you get the picture.  Also, I'm on Windows and/or Linux...
>
> Here's the initial reply:
> -
> Change History
> 05/26/10 14:01:25 changed by adamnelson
> status changed from new to closed.
> needs_better_patch changed.
> resolution set to invalid.
> needs_tests changed.
> needs_docs changed.
>
> I think it's a reasonable request but this would require a rigorous
> discussion on django developers newsgroup before even having a ticket
> and would be more like a 1.4 thing:
>
> http://groups.google.com/group/django-developers
>
> You may want to try TextMate Django bundles to make this easier on a
> Mac - I don't have any other suggestions though.
>
> Cheers.

-- 
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: Replace django.contrib.formtools.wizard

[Gregor Müllegger]

Storing the file in a temporary directory is elegant but brings up
some new problems.

IMO it's critical - if you want to support file uploads - to put these
files into MEDIA_ROOT. Otherwise you wouldn't be able to show previews
of uploaded images etc.

2010/5/30 TiNo :
> On Sat, May 29, 2010 at 22:07, Stephan Jäkel  wrote:
>>
>> I already discussed this ticket with Jannis during the sprints and hope to
>> start a discussion here to find the right way to allow file uploads and see
>> if my approach takes the right direction.
>
> Couldn't you just use python's tempfile.NamedTemporaryFile[1]? That way the
> file will get cleaned by the filesystem itself, unless you move it somewhere
> else in your ``done`` method. If you pass delete=False, you will be able to
> open the file again in the last step, as long as you properly closed it
> before.
> TiNo
> [1] http://docs.python.org/library/tempfile.html#tempfile.NamedTemporaryFile
>
> --
> 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: Feature idea

[Gregor Müllegger]

I also needed this functionality in one of my apps and just went the
way of copy and pasting the existing solution that is already
implemented in django.contrib.admin. But making this code reuseable
would IMO be a benefit for some app developers.

But I think the approach of using an setting for this purpose is not
the ideal way. Admin does a great job in that way, because it only
uses the autodiscover functionality on demand. My need for an
autodiscover functionality was directly tight to a management command.
I don't want to load these modules unless I invoke the management
command, which is possible with the admin like autodiscover() function
instead of using a setting.

My proposal would go into the direction of pulling the autodiscover
function out of the django.contrib.admin module and putting it
somewhere in the core. Since the admin needs some special
functionality on errors while loading an admin.py module from an app,
I would suggest a Autodiscover class that provides some hooks to be
better customizable.

Something like:


class Autodiscover(object):
def __init__(self, module_name):
self.module_name = module_name

def __call__(self):
# existing autodiscover code from django.contrib.admin

def pre_load(self, app_label):
# gets called directly before trying to load an app's module

def post_load(self, app_label):
# gets called after trying to load an app's module even if the
# import failed

def on_success(self, app_label, module):
# gets called if the module was imported successfully

def on_error(self, app_label):
# gets called if the module didn't exist or import failed


In django.contrib.admin or in any other app we can use:

from django.core.autodiscover import Autodiscover

autodiscover = Autodiscover('admin')


This also provides backwards compatibility since the following snippet still
works:

from django.contrib import admin

admin.autodiscover()


Yours,
Gregor Müllegger

-- 
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: Feature idea

[Gregor Müllegger]

I would volunteer for the development needed to get this into django.
I will start working on it right after a core developer has looked
into this discussion and points out if my proposal is at least the
right direction.

--
Servus,
Gregor Müllegger

2010/6/1 Dj Gilcrease :
> On Tue, Jun 1, 2010 at 3:02 PM, Gregor Müllegger  wrote:
>> My proposal would go into the direction of pulling the autodiscover
>> function out of the django.contrib.admin module and putting it
>> somewhere in the core. Since the admin needs some special
>> functionality on errors while loading an admin.py module from an app,
>> I would suggest a Autodiscover class that provides some hooks to be
>> better customizable.
>>
>> Something like:
> 
>
> I like this idea better then mine provided the startup.py proposal
> goes forward. I very much dislike having autodiscover stuff being
> loaded in urls.py as a hack to get an app bootstrapped and part of
> what I am trying to solve is the need for app consumers (End
> Developers) to bootstrap your app in urls.py.
>
>
> I figured a setting was slightly more explicit then the bit of magic
> that would go on by having your own autodiscover sub-class being
> initiated in startup.py (I really think that should be named
> bootstrap.py but I digress). Even with the setting there is nothing
> preventing you from adding your module to the autodiscover setting
> when you call your management command, but as I said I like the class
> approach provided a application bootstrap system is provided.
>
> If the class based approach is chosen then I think it should love in
> django.utils.autodiscover as it is something the application developer
> must subclass if they want to use it, and if it is in core I would
> expect it to be something used internally and only to be tinkered with
> by advanced users.
>
> --
> 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: Feature idea

[Gregor Müllegger]

Hi Jacob,

I don't know much about the startup proposal, but I expect it to be a
startup.py file in an application folder that gets loaded right after
the django internals are ready and before the models have been loaded.
The mechanism we ask for in this thread is something different.

It would be nice to have a way to load modules from applications
excatly like the startup.py file, but that the loading component is
reusable and can be used for other modulenames specified by the app
developer. This could be used by django.contrib.admin to load all
admin.py files or by haystack to load all search_indexes.py files and
so on.

If this is also covered somehow by the startup proposal, just ignore
me and I wait until this is written down somewhere.
Thanks.

--
Servus,
Gregor Müllegger

2010/6/2 Jacob Kaplan-Moss :
> Aat EuroDjangoCon Russ and I discussed a "startup" mechanism that'd
> cover this use case, as well as a whole lot more. There's a few hints
> in the logging discussion a few threads down.
>
> So I'm -1 on this specific proposal, but only because I expect it to
> be obsoleted by me and Russ' startup proposal. Which one of us really
> should write up :)
>
> Jacob
>
> --
> 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: Proposal: {% include_partial %} template tag

[Gregor Müllegger]

Also +1 from me for extending the include tag instead of having a new one.

Bye default it should keep its behaviour and use the current context
for the included template. Marco's use of a new, clean context
(demonstrated with the snippet below) is also possible to support.

   {% if label %}
   {{ label }}
   {% else %}

 You can just pass in an empty string, like one of the following three examples:

{% include "part.html" with label= title=obj.title %}
{% include "part.html" with label="" title=obj.title %}
{% include "part.html" with "" as label and obj.title as title %}

(I don't want to propose the implementation of all three syntaxes. I
just want to demonstrate that all possible syntaxes can handle Marco's
usecase.)

--
Servus,
Gregor Müllegger

2010/6/8 burc...@gmail.com :
> I'd suggest to change both include and with/blocktrans syntax into
> more programmer-friendly style:
>
> {% include "part.html" title=obj.title|capfirst main_class="large" %}
>
> This is both more dense, and from quick grasp you can see where are
> the delimiters ("as" is not so good for this).
>
> Also I think we need an argument to tell that outer context is passed inside.
>
> On Tue, Jun 8, 2010 at 11:30 PM, Gonzalo Saavedra
>  wrote:
>> I'm +1 on the optional "with" parameter for {% include %}. -1 on
>> adding a new tag for this.
>>
>> I also use {% with %}{% include %} a lot in templates but we should
>> follow with/blocktrans syntax for consistency:
>>
>>  {% include "part.html" with obj.title|capfirst as title and "large"
>> as main_class %}
>>
>>
>> A related proposal for the "with" tag: It'd be nice to support more
>> than one variable definition (as blocktrans does):
>>
>>  {% with "a" as var1 and "b" as var2 %}...{% endwith %}
>>
>> The current solution is nesting "with" tags, which is not very pretty.
>>
>>
>> gonz.
>>
>>
>> 2010/6/8 Marco Louro :
>>> Gabriel,
>>>
>>> I only made that decision because I didn't see the need to have whole
>>> context, and the only time I have needed it was because of the {%
>>> csrf_token %}. This is just my use-case, but I understand that other
>>> people might want to use it differently. I don't think it makes much
>>> of a difference, a clean context may avoid some collisions from time
>>> to time, but it may have bigger drawbacks for other people.
>>>
>>> Hi Jeliuc,
>>>
>>> No, I don't.
>>>
>>> On Jun 7, 7:59 pm, Gabriel Hurley  wrote:
>>>> Extending the include tag seems like a fantastic idea! I end up
>>>> writing the {% with %}{% include %} combo all the time for my reusable
>>>> template snippets.
>>>>
>>>> However, I feel like selectively clearing the context inside a
>>>> template tag is asking for trouble and/or confusion. It also sounds
>>>> like it goes against Django's "templates require no knowledge of
>>>> programming" principle. While I can see how you might run into context
>>>> name collisions in a *very* large or complicated project, the right
>>>> solution there seems like it ought to be to clean up your context and/
>>>> or templates outside of the template itself... Even in projects with
>>>> dozens of installed apps (both my own and third-party ones mixed
>>>> together) I've never had that problem where two minutes of tweaking
>>>> couldn't fix it for good.
>>>>
>>>> I'm certainly not saying you don't have a use case for it, or that it
>>>> wouldn't be extremely helpful to you. Just that having a tag that
>>>> clears the context sounds fishy to me...
>>>>
>>>> All the best,
>>>>
>>>>     - Gabriel
>>>>
>>>> On Jun 7, 10:52 am, Marco Louro  wrote:
>>>>
>>>>
>>>>
>>>> > I'd prefer extending the {% include %} tag actually, but didn't of
>>>> > that in the first place.
>> [...]
>>
>> --
>> 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.
>>
>>
>
>
>
> --
> Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
> MSN: bu...@live.com
>
> --
> 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.contrib.admin.ModelAdmin.formfield_for_manytomanyfield

[Gregor Müllegger]

2010/6/28 Massimiliano della Rovere :
> I'd modify http://docs.djangoproject.com/en/dev/ref/contrib/admin/
> page by myself but I do not know how to.

You can provide documentation patches the same as you would create a
source patch:

 * Download django's current trunk: svn co
http://code.djangoproject.com/svn/django/trunk/
 * Edit the files in the documentation you want to improve (its
docs/ref/contrib/admin/index.txt in your case)
 * Create a simple patch by calling "svn diff >
admin_doc_improvement.patch" and submit it to a ticket in trac.

Hope this helps.

--
Servus,
Gregor Müllegger

-- 
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.

[1.3 Proposal] Cleanup Signal

[Gregor Müllegger]

Hi,

its very convenient for most projects to have cleanup-tasks that run
out of a request-response cycle. The best example is in django core.
The `cleanup` management command deletes expired session instances.
But in most cases there are more tasks like this: deleting expired
registrations/email verification codes, removing expired codes for
captchas, removing thumbnails of images that don't longer exists etc.

The list is endless. Until yet most applications provide
their own management command for this (cleanup_thumbnail,
cleanup_registrations...) - IMO there should be a better way to only
need one cronjob that can do all the work.

My suggestion is to add a cleanup signal that is called in django's
cleanup management command. This would make custom cleanup code easier
to use.


What are your opinions about a cleanup signal?

Maybe it would even make sense to have a more generic signal that fires
when a management command is called and one when the command finishes.
This would make sense e.g. for `validate` management command to have
custom validation logic etc.


(Sorry if the mailing-list is the wrong list to propose this feature
request, is it better to open a ticket first?)

--
Servus,
Gregor Müllegger

-- 
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: Cleanup Signal

[Gregor Müllegger]

On 2 July 2010 05:44, hcarvalhoalves  wrote:
> Besides that, I don't see the need for anything to integrate inside a
> single "clean" command. It's not like the management commands provided
> by Django are hooks, you can and should be making yours for each
> specific need.

My intention was to make the cleanup command more generic since it has such a
generic name. Beeing able to register additional actions with this command can
make pluggable apps even more pluggable since you don't need to setup
yet-another-cronjob.

@hcarvalhoalves
Thanks for mentioning django-extensions. I agree that the job system
integrated there could also solve this problem.

--
Servus,
Gregor Müllegger

-- 
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 and the Eyjafjallajökull eruption

[Gregor Müllegger]

By coincidence I blogged last night right about read permissions how you need
them [1]. My solution is like what you explain as "dirty hack" ;)

It provides this functionality:

* Every user with is_staff=True can read all objects in the admin.
* View permission means: You can see the usual change form but you cannot save
  the form

There is a small drawback: If a user has no other permissions (like
change/add/delete permissions) the model will not show up in admin's index
page. Maybe this is not a problem for you if you have a custom admin index
page.

[1] http://gremu.net/blog/2010/django-admin-read-only-permission/

--
Servus,
Gregor Müllegger

2010/7/2 Josh Ourisman :
> All of this stuff is absolutely doable, and in fact I've implemented much of
> it myself. I don't know if it will cover everything you want, but I've
> written up some of my most similar Django Admin hacks (I've done quite a bit
> over the years...) on my blog
> here: http://joshourisman.com/2009/10/15/django-admin-awesomeness/
> That said, 1.2 introduced object-level permissions hooks which are not used
> in my (Django 1.1) code
> above: http://docs.djangoproject.com/en/dev/releases/1.2/#object-level-permissions
> But above all, thanks for sharing this awesome story! I love hearing about
> the amazing ways that people are using Django, and the way it can facilitate
> rapid response to actual, serious problems (I think perhaps my favorite,
> most inspiring Django story was Andy McCay's on how it's being used to fight
> malnutrition in Africa from
> DjangoCon http://www.slideshare.net/andymckay/fighting-malnutrition-with-sms-and-django).
> As an aside, is there much of a Django community in Iceland? I was there for
> the first time last Fall and absolutely loved the country; would love to
> spend more time there.
>
> On Fri, Jul 2, 2010 at 9:30 AM, Ramsey D'silva 
> wrote:
>>
>> I believe all the things you mentioned, can be done! It's just a matter of
>> finding a competent developer.
>>
>> Cheers!
>>
>> On 2-Jul-10, at 7:03 AM, Helgi Borg wrote:
>>
>>> Remember the Eyjafjallajökull eruption that stopped air traffic over
>>> parts of Europe?  The staff at the Icelandic Meterological Office had
>>> a seriously busy time the first days of the eruption. When I arrived
>>> at work the first morning, I quickly realized that we needed a simple
>>> msg-software so the teams of meteorologists, geologists, hydrographers
>>> and the executives could better synchronize their work. In a few
>>> hours, I had implemented, tested and deployed a Django app that helped
>>> a lot. - Django is truly an amazing piece of software. Thank you for
>>> Django!
>>>
>>> The Django app was reasonable good although not perfect. Let me
>>> explain why…
>>>
>>> I needed every user to be able to view messages from anyone. Members
>>> of the same teams (users of the same Auth. group) needed to be able to
>>> correct messages from each other for some time until the messages
>>> automatically locked for changes.
>>>
>>> The obvious choose was to use the Contrib Admin. It is robust, fast,
>>> easy for developers to use, easy for users to get used to and has a
>>> persistent user interface. In other words it is almost perfect for all
>>> our data registration usage except that it doesn’t have view
>>> permissions. The ModelAdmin class would be perfect if it only had view
>>> permissions (perhaps read permission is a better word).
>>>
>>> A dirty solution is to apply change permission to “view only
>>> permission-users” and then use save_model() to deny these users  to
>>> actually change view-only instances. The practical problem with this
>>> is that the UI indicates that the user can change something that he/
>>> she may not change.
>>>
>>> One could argue that I should use something else than Contrib Admin.
>>> The problem is that there is nothing else as good available. Mixing
>>> Contrib Admin with other app for view-only purposes results in bad
>>> usability. Further it doesn’t adhere to the DRY principle to create
>>> something new when you have something as good as Contrib Admin.
>>>
>>> I’ve also created other apps where I’ve needed view permission. These
>>> are Avalanche registration, Registration of ash fall, Sea ice
>>> registration, Warning registration and Weather forecasters self
>>> quality monitoring. Other apps will most likely follow.
>>>
>>> I would really appreciate if you could answer the following q

Re: Accessible Command Output using self.stdout & self.stderr

[Gregor Müllegger]

Related to the issue with stdout/stderr:

It is ofcourse possible to have wrapper in the Command class for stdout and
stderr output that redirect all data to system's stdout in most cases. But
this might not work for all output since we don't have control about all
management commands of thirdparty apps. A more "secure" approach of capturing
output is to overwrite `sys.stdout` and `sys.stderr` with your own file like
objects. A short example:

import sys

class MyStdout(object):
def __init__(self):
self.data = ''

def write(self, s):
self.data += s

myout = MyStdout()
sys.stdout = myout

print "Hello, World!"

assert myout.data == "Hello, World!\n"


This is not as clean as the self.stdout approach but will capture *all* output
instead of only the ouput of commands that will support the new API - which
might be what you want if you provide a webinterface.

I'm aware that Russ is not a big fan of Monkeypatching :) but I think this
would be a legal case - since there is no other way of intercepting the real
stdout output (I'm not sure but this might be even documented in python docs,
that its ok to overwrite sys.stdout and sys.stderr with your own objects).


Just want to point out that its possible - not that its the only way to go :)

Gregor


2010/7/13 Russell Keith-Magee :
> On Tue, Jul 13, 2010 at 2:23 PM, maxweld  wrote:
>> I would like to propose that all commands in core.management be
>> modified to enable command output to be directed to self.stdout and
>> self.stderr so that the command output can be captured and made
>> accessible to an application.
>>
>> I use a virtual web hosting environment where no shell access is
>> permitted. I would like to set up an administrative web interface
>> which enables commands to be executed and the command output
>> redisplayed to the user. However, as commands currently send output
>> directly to stdout or stderr, the comand output is not readily
>> accessible (Django 1.2.1).
>>
>> Discussions with Russ McGee on Django Users suggested that some
>
> Magee. I'm not Scottish :-)
>
>> commands, for testing system purposes, are now sending to self.stdout
>> and self.stderr, allowing the target to be redefined and the output to
>> be captured. Only dumpdata and loaddata commands have currently been
>> converted in trunk. I am proposing extending this to all commands in
>> core.management, and suggest that this should be promoted as the norm
>> for custom developed commands also.
>>
>> If agreed, the work required to implement would be:
>> a) convert existing commands
>> b) document the feature
>> c) improve documentation of the existing feature allowing applications
>> to construct their own commands
>> d) improve documentation of how to execute commands programatically
>> (as opposed to in a shell)
>
> Seconded, and carried. I've already said I'll accept any patch that
> implements any (or preferably all) of these points.
>
>> If there is agreement, I am happy to undertake the above although
>> would appreciate a mentor being available for advice from time to time
>> as this would be my first contribution.
>
> I'm happy to give you any feedback you need; if you post to django-dev
> when you need assistance or feedback, I'll try to respond; if I don't,
> someone else hopefully will.
>
>> Longer term, if an administrative web interface to commands is to be
>> provided, we would need to devise an interface that adapted well into
>> the existing administrative interface. However, I see this as a second
>> stage in the process. First we need the command output to be
>> available.
>
> There may well be a place for these commands to be exposed via a web
> interface (especially if you're building a shared hosting type
> environment), but I'm not convinced that this is something that is
> appropriate to be baked into Django's core.
>
> Firstly, it's a bit of an edge case; the biggest use case for this
> sort of facility is to support a virtual server for which you don't
> have shell access. I don't have any firm numbers, but I suspect that
> this is an edge case of Django deployments.
>
> Secondly, some management commands aren't really well suited to
> execute on the same server that is serving them. It may be fine to
> have one server executing management commands on another, though
> (especially if you're setting up some sort of push-button hosting
> environment).
>
> Thirdly, some management commands can be time consuming or have the
> potential for introducing database locks; as such, they aren't well
> suited to execution in the request/response cycle. This means you
> should be looking at implementing this using a job queue, and Django
> is agnostic when it comes to such issues.
>
> That said, if such an administrative interface were to be introduced,
> it would almost certainly be as a contrib application. The usual path
> for adding new contrib applications is for them to start as a
> standalone projec

Re: request.is_ajax() and hidden iframe kludge => request.is_framejax()?

[Gregor Müllegger]

I think Florian meant that its not possible to change HTTP headers by
Javascript XSS attacks (or am I wrong here as well?).

Athor attacks that doesn't use a browser as their client can ofcourse
manipulate what is_ajax() returns.


To the actual proposal: I have the same opinion here as Florian. It's an
workaround for an edgecase that isn't defined in a standard. The best way -
if you really need it - to have it, is to implement the method your self and
inject it to the request object in a middleware.


--
Servus,
Gregor Müllegger

2010/7/17 David :
>> This input field is easily fakeable. An attacker can't fake your
>> browsers XHR requests, which makes request.is_ajax somewhat secure and
>> trustable. I don't see how your solution could achieve that.
>
> is_ajax() simply checks an HTTP header. It is easily set by an
> attacker.
>
> On Jul 16, 2:30 pm, Florian Apolloner  wrote:
>> Hi,
>>
>> On Jul 16, 7:25 pm, David De La Harpe Golden
>>
>>  wrote:
>> > People doing ajax have probably hit the "XMLHttpRequest doesn't do file
>> > uploads (at least not non-browser-specifically), use a hidden iframe
>> > kludge or flash" issue. Anyway, maybe that will change one day
>>
>> It's already changing, modern browsers can do what you want (google
>> for html5 file uploads). I don't see any reason to support something
>> like you suggest; we should support standards and not workarounds
>> (just my opinion). Imo the best way currently is to use the new apis
>> and fallback to flash or whatever if needed (I actually guess flash is
>> the best fallback here).
>>
>> > The hidden-iframe requests will AFAIK show up with request.is_ajax() ==
>> > False to django.  So a "done thing" (I think) to distinguish between the
>> > non-ajax and hidden-iframe requests seems to be to just have an extra
>> > field to act as a pseudo-header, i.e.
>>
>> > 
>>
>> This input field is easily fakeable. An attacker can't fake your
>> browsers XHR requests, which makes request.is_ajax somewhat secure and
>> trustable. I don't see how your solution could achieve that.
>>
>> > or "?X-Requested-With=ScriptedIFrame"
>>
>> Same as above.
>>
>> > It might nonetheless be nice for django to have some support for
>> > checking for some particular pseudo-header.
>>
>> -1, mostly due to the fact that it's something most people won't need
>> and you can easily inject that info using a middleware yourself. Hence
>> I am for solution A.
>>
>> Cheers,
>> Florian
>
> --
> 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: Patch: Indefinite args for simpletags and inclusion tags

[Gregor Müllegger]

Hi,

a quick +1 from me - the patch doesn't seem to introduce
backwards-compatibility issues or implement a YAGNI feature - since there is
already a usecase.

Only documentation and tests are missing.

--
Servus,
Gregor Müllegger

2010/7/16 Stephen Burrows :
> I went ahead and made a ticket with the patch. Thanks!
> http://code.djangoproject.com/ticket/13956
>
> --Stephen
>
> On Jul 16, 1:25 pm, Tobias McNulty  wrote:
>> On Fri, Jul 16, 2010 at 1:07 PM, Stephen Burrows <
>>
>> stephen.r.burr...@gmail.com> wrote:
>> > Before posting the patch to django's ticketing system, I wanted to
>> > check whether this would be a non-trivial patch and whether there
>> > might be any good alternatives.
>>
>> Hard to tell without seeing the patch. :-)
>>
>> Could you stick it somewhere we can see it?  Personally I like to see them
>> in Trac, since it comes with pretty colors.  If there isn't a ticket already
>> out there for this I see no problem with creating one.  We can always close
>> it if it gets rejected.
>>
>> Cheers
>> Tobias
>> --
>> Tobias McNulty
>> Caktus Consulting Group, LLC
>> P.O. Box 1454
>> Carrboro, NC 27510
>> USA: +1 (919) 951-0052http://www.caktusgroup.com
>
> --
> 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 Security

[Gregor Müllegger]

2010/7/19 Craig Younkins :
> Hello there! My name is Craig Younkins. I'm an intern at OWASP, the
> Open Web Application Security Project, and this summer I'm focusing on
> web security in Python. My mission is to help developers make more
> secure applications.
>
> [snip]
>
> Second, I'd like to help the developers take a look at the security of
> Django. I've created a template page for Django on our wiki
> with a number of questions developers can answer that will help
> clarify the security of the framework. 
> http://www.pythonsecurity.org/wiki/django/
> Of course, that page links to the broader security topics including
> XSS, CSRF, Cryptography, and more.

At first: Thank you very much for your work. The OWASP is a great project and
have made great attempts in the past to help developers. Keep going and I'm
sure most django developers will be happy about your feedback related to
django's security.

I tried to answer some of your questions quickly. Please tell me if you need
more detailed information or if some answers are not clear enough.

> I'd be quite happy to offer some security analysis of Django. I've
> already made security contributions to Pylons, web2py, Mako, and more.
> I did a brief analysis of Django templating and note a few potential
> pitfalls: http://www.pythonsecurity.org/wiki/django/templating/

I had a look at your potential pitfalls and it seams that the only
vulnerability is exposed if template authors don't quote their attributes. In
my opinion its very obvious and well know to designers that quoting attributes
is 1. better coding style since its more readable and 2. necessary to make
your code more robust against XSS.

However IMO there is no easy (or even *any*) way to automatically add quotes
for attributes. So this is something that must be delegated to the end users
of django. Maybe this can be clearified in the documentation.

Is this correct or have I missed another issue with the templating language?

> If any developers are concerned about security or have a security-
> related question, we'd love to help. Join our Google Group:
> http://groups.google.com/group/python-security/topics
>
> Thanks!

Thanks you too!

I'm sure most of django developers will be happy about help from security
experts to proove that django is as secure as we want it to be.


(Disclaimer: I'm not a core developer of django or have any "previliges"
related to django's development.)


--
Servus,
Gregor Müllegger

-- 
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: New context template tag

[Gregor Müllegger]

I'm a huge fan of Alex Gaynor's templatetag sugar syntax for defining
template tags:

# from the docs:

@tag(register, [Constant("for"), Variable(), Optional([Constant("as"),
Name()])]):
def example_tag(context, val, asvar=None):
if asvar:
context[asvar] = val
return ""
else:
return val


However I don't know how mature this is to be included in the core. It's also
a matter of taste if you like the syntax or not. But its quite intuitive after
you get the concept.

Maybe this clashes with the 1.3 goal of focusing on bug fixes, but it could be
worth to look at it again for the 1.4 release. In the long run there should
really be a much more easier way to define semi complex tags than with the
current Node approach.

So a +1 from me for every approach making template tags easier.

--
Servus,
Gregor Müllegger


2010/7/22 Alex Robbins :
> Eric,
>
> Thanks for the reply! django-template-utils does help some but, like
> you say, you still end up writing a function and a custom node.
>
> Is there a reason we couldn't add another template tag helper like
> simple_tag or inclusion_tag? (I'll write the code and tests) Adding to
> context seems (to me) to be a very common use case. With a helper like
> this, I'd be able to write most of my template tags without needing to
> drop down into the function/node paradigm. Maybe django does
> eventually need to incorporate one of the third party solutions to
> making template tags nice, but this could be a quick win that would
> address a lot of the pain now.
>
> Or maybe most people don't write lots of add_to_context type tags, or
> the current third-party solutions are sufficient. If it isn't a common
> problem for people, then it definitely doesn't belong in the core.
>
> Thanks,
> Alex
>
>
> On Thu, Jul 22, 2010 at 10:23 AM, Eric Holscher  wrote:
>> I usually use James Bennett's django-template-utils for this purpose. It has
>> a nice, simple implementation:
>> http://bitbucket.org/ubernostrum/django-template-utils/src/tip/template_utils/nodes.py#cl-11
>> It still requires the annoying Node/function split though.
>> I know there have been a multitude of third party attempts at improving
>> Django's template tags, and I think it's commonly agreed that they are one
>> of the more boilerplatey bits. Sadly none of the third party libraries have
>> really become defacto, so it's hard to think about including any of them in
>> core. It does seem like a place that could use some expose either in the
>> docs or in the general community though.
>> Cheers,
>> Eric
>>
>> On Thu, Jul 22, 2010 at 9:26 AM, Alex Robbins
>>  wrote:
>>>
>>> I am a huge fan of simple_tag and inclusion_tag. They take a common
>>> template tag use case and make it very easy to write. It seems like a
>>> common use case that isn't represented is adding a value to context. I
>>> find myself writing tags to add a variable to context very often and
>>> it seems like we should be able to abstract this out.
>>>
>>> I'm thinking it would work like this, but would love to get feedback
>>>
>>> @register.add_to_context_tag
>>> def tag_name():
>>>    do_some_python()
>>>    return context_value
>>>
>>> This would turn into a tag that worked like this:
>>>
>>> {% tag_name as variable %}
>>>
>>> Which puts context_value into the context as variable.
>>> 
>>>
>>> It could optionally take takes_context, and work like this. This would
>>> make context the required first argument to the function, like
>>> inclusion_tag.
>>>
>>> @register.add_to_context_tag(takes_context=True)
>>> def tag_name(context):
>>>    do_some_python_that_needs_context(context)
>>>    return context_value
>>> --
>>>
>>> Finally, it could take arguments like simple_tag or inclusion tag.
>>>
>>> @register.add_to_context_tag
>>> def tag_name(some, arguments, it, takes):
>>>    some_func(some, arguments)
>>>    return context_value
>>>
>>> which would yield a tag that worked like this:
>>>
>>> {% tag_name some arguments it takes as variable %}
>>>
>>> -
>>> Is this a use case other people have? Can anyone think of a better
>>> name than add_to_context_tag?
>>>
>>> Thanks,
>>> Alex
>>>
>>> --
>>> You received this message

Re: Documenting new features: built-in obsolescence of the "versionadded" tag.

[Gregor Müllegger]

That would be also my intend. We could keep the tags in the
documentation but could stop the output in the HTML generation.

2010/7/23 Jeremy Dunck :
> On Fri, Jul 23, 2010 at 11:18 AM, Tobias McNulty  
> wrote:
>> I agree.  It's a little odd seeings things flagged "New" that have been
>> around since 1.0.  I also like your proposal of removing the notes for
>> unsupported versions.
>> Tobias
>
> I think maybe the rendering can just be altered to ignore tags with
> the old values?
>
> --
> 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: contrib/admin/validation.py

[Gregor Müllegger]

I ran into the same problem as George before. And it always hits when I try to
modify my admin pages in undocumented ways. So I would also be for some
changes in this area.

But I think we cannot simply remove it. Most constraints make much sense and
usually help avoiding problems in your admin pages. I'm also quite sure that
all these validation things help Django beginners to not run into errors with
messages that cannot be understand.


I've not looked into the validation code yet, but I assume that the validation
takes place as soon as you register your ModelAdmin with admin.site.register.

Maybe its worth to introduce a parameter here to disable the sanity checks:

admin.site.register(ModelAdmin, Model, validate=False)


Just my 2cents.

--
Servus,
Gregor Müllegger

2010/9/1 George Karpenkov :
> There is a file called "validation.py" which attempts to do validation
> checking for the admin.
>
> Though I realize it might be useful for the beginners (as a basic
> sanity check) quite often I find it standing in my way and being
> annoying.
> The reasons are:
> 1) Python does not have interfaces. It relies on "duck typing". This
> file attempts to check whether the class follows the interface, yet in
> a very naive way.
> 2) All the check_isseq calls stop you from turning attributes into
> properties, which can be useful for inheritance purposes
> 3) sometimes the developer does not want a particular sanity checking.
> My recent problem was trying to create a widget for a many-to-many
> field with a custom through table. At the moment it is completely
> impossible - validation.py will just raise an error, and there is no
> way to go around it (if you won't count monkey-patching django).
> Without validation.py I would've been able to specify the widget in
> the admin settings and just do my own POST-data processing.
>
> In my personal opinion this whole file needs either removal, or
> sufficient relaxation of many constraints.
>
> Any thoughts?

-- 
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.

"sl" as language code for slovenian translation incorrect?

[Gregor Müllegger]

Hi,

I just discovered some oddity in the naming of the "sl" (SL -
slovenian) locale. The company I'm currently working for has in-house
translations of some of their apps into the slovenian language and
they use the ISO code "si" (SI) -- which differs from django, which
uses "sl" (SL).

According to the URL that is referenced in django's project
settings.py-template [1] and Wikipedia [2][3] is the correct ISO code
for the slovenian language "si" (SI) which means django might differ
here from the ISO standard. The "sl" (SL) code should be reserved for
"Sierra Leone".


Is there any reason why the ISO codes are different here from their
use in django? Maybe there is some historical background.

Thanks for your efforts,
Gregor

[1] http://www.i18nguy.com/unicode/language-identifiers.html
[2] http://en.wikipedia.org/wiki/ISO_3166-1
[3] http://en.wikipedia.org/wiki/Slovenia

-- 
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: "sl" as language code for slovenian translation incorrect?

[Gregor Müllegger]

Ay, makes sense :-)

Thanks to both of you.

2011/3/7 Kenneth Gonsalves :
> On Mon, 2011-03-07 at 09:46 +0100, Jannis Leidel wrote:
>> > Is there any reason why the ISO codes are different here from their
>> > use in django? Maybe there is some historical background.
>>
>> No historical reason needed, Django has the correct language code. As
>> with any other language we rely on ISO 639 ("Codes for the
>> representation of names of languages") [1] (and it's children), which
>> lists "sl" for Slovanian (ISO 639-1 [2]), according to Wikipedia [3].
>
> country code is SI, language code is sl
> --
> regards
> KG
> http://lawgon.livejournal.com
> Coimbatore LUG rox
> http://ilugcbe.techstud.org/
>
> --
> 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.
>
>

-- 
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: switch to HTML5 for bundled templates

[Gregor Müllegger]

Using HTML5 tags in IE _will_ break it at some point. There is ofcourse the
work around with "document.createElement('article')" etc used by modernizr
But:

1. This will not work for IEs' that have JS disabled
2. Will break if you insert HTML5 tags by javascript into the "innerHTML"
   attribute of tags (even those that were created with the workaround above).

Point 2 hit mit just a few weeks ago and is even valid for IE 8. The problem
is that even jQuery is using the innerHTML attribute in it's .append() method
and others which are very common to must jQuery users.
To be honest, there is a workaround for this as well. But it requires either
patching jQuery or to change ALL YOUR CODE that uses .innerHTML (including
all your uses of jQuery.fn.append()). [1]

Input types are not effected by this bug afaik.

Gregor

[1] http://jdbartlett.github.com/innershiv/


2011/3/29 Matt Harasymczuk :
> How about delivering http://www.modernizr.com/ library.
> In my case it solves all problems with non existing tags (nav,
> section, header, article, footer) in such browsers as IE.
>
> We ship jQuery with admin, why not use modernizr to support legacy
> browsers.
>
> I am positive, about input types fallback to text.
> I have tested this for a long time and it works.
>
> Generally speaking converting contrib apps to html5 would be a very
> good idea! Most django deployments does not depend on whether it has
> html4 or 5.
> Those who stick with 4, should have the same functionality provided by
> fallback in their browsers, however the largest part of the remaining
> group should benefit from transition.
>
> Google dropped support for IE6 legacy browsers more than year ago!
> http://googleenterprise.blogspot.com/2010/01/modern-browsers-for-modern-applications.html
>
> Even microsoft wants IE6 dead
> http://ie6countdown.com/
>
> I think we should join this movement, and provide modernizr, for
> example in conditional css tag
> 
>
> It works for me, hence all should benefit from it.
>
>
> --
> Matt Harasymczuk
> http://www.matt.harasymczuk.pl
>
> --
> 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.
>
>

-- 
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.

[GSoC] Revised form rendering

[Gregor Müllegger]

I suggest reading this proposal online: https://gist.github.com/898375
It's exactly the same as below but formated nicely.


GSoC 2011 Proposal - Revised form rendering


Hi my name is Gregor Müllegger. I'm a Computer Science student in Germany at
the University of Augsburg currently in the fourth year of my studies. I first
came to django shortly before 0.96 was released and a lots of awesomeness was
introduced with the magic removal branch.

I'm also doing some django freelancing work since 2008 to finance my studies
and attended DjangoCon EU in 2011. This year I would like to apply to
Google Summer of Code helping to improve Django with something that bugs me
since quite a while: It's builtin ability to render a form straight away into
HTML.

Motiviation
---

Why would I like to change the current behaviour? There are some reasons for
this:

1. It's hard to change the default rendering.

   It is very easy to use e.g. django's builtin rendering of a ``ul`` based
   output like ``{{ myform.as_ul }}``. But what if you want to use your own
   *layout* like ``{{ myform.as_dl }}``? You can create a new method on your
   existing forms, but that involves writing python code (out of the designers
   hand) and might not be possible for thirdparty forms.

2. Maybe the ``as_ul`` rendering is fine for me. But maybe I want to skip that
   unnecessary field that the thirdparty form is providing. The solution would
   be to write down every single field in your template, reimplementing the
   ``ul`` layout::

{{ form.field.label_tag }}: {{ form.field }}
{{ form.field.help_text }} {{ form.field.errors }}
{# skipping field2 here #}
{{ form.field3.label_tag }}: {{ form.field3 }}
{{ form.field3.help_text }} {{ form.field3.errors }}
...

   We all love DRY, so this is not acceptable.

3. The designers I worked with are often interested on adding custom css class
   or an attribute to a form field. Most of the time this is really a pain to
   do if you don't have control over the python form code. Imagine a reusable
   app that ships with urls, views, forms. To add a single class you would
   need to: (a) overwrite the predefined url because you want (b) to specify
   an additional parameter for the view which is (c) your custom subclass of
   the thirdparty form::

   class ChangedAttributeForm(ThirdPartyForm):
   field = forms.CharField(max_length=50,
   widget=TextInput(attrs={'class': 'fancy-text-input'}))

   btw: This also violates the DRY principle since you have to redefine the
   used field type, it's attributes (like ``max_length=50``) and the widget.

   I want to tell the designer how he can do this without my help in the
   template.

Goals I want to accomplish
--

After showing some of the problems that I see, are here the higher goals I
want to achieve during the summer:

1. All of the rendering formats should be extracted from django's python source
   into a well defined structure of customizable templates.
2. Make it possible to reorder the use of form fields in the template without
   needing to write down the complete form.
3. Support for *chrome* that can be added dynamically in the template to a set
   of fields, changing some aspects of the form output.
4. Ensuring that the DRY principle is applyable to your form templates (in
   case of reordering/skipping some fields, like shown above)
5. Ensuring total backwards compatibility for ``{{ form.as_p }}`` etc. but
   deprecating it.
6. Converting the admin to use all of the new goodness. First, to make django
   eating its own dogfood. Second, to prove that the stuff I have developed is
   really a step forward and to show up big problems that occur in reallife
   scenarios, not taken into account in the blueprint.
7. Documenting all the newly introduced templatetags, the builtin chromes,
   how to write custom chrome, how to create your own form layout etc...

Let's get a bit more detailed. How do I want to implement these goals?

**1. No HTML in python source**

I will push the formating of ``as_table``, ``as_ul`` and ``as_p`` into a
specified template structure. A formating (e.g. ``ul``) will be called a
layout and will live in the template directory ``forms/layouts//...``.
This directory will contain a single file (e.g. for the table layout)::

forms/layouts/table/row.html

Creating a new layout is as simple as putting a new directory into your
template path and adding one file. Why putting the file into a directory? The
reason is because we can make the layout even more customizable. You are able
in the ``row.html`` to ``{% include %}`` a ``errors.html`` and a
``helptext.html`` that can be overriden by the designer without completely
rewriting the whole layout.

Ok, but how will this look in the template where I use the

Re: [GSoC] Revised form rendering

[Gregor Müllegger]

Hi, thanks for your fast feedback. I was really looking forward to your input,
I haven't reached you in IRC before.

2011/4/1 Carl Meyer :
> Hi Gregor,
>
> As you've probably seen in past threads, this is an area where I'm quite
> motivated to see some improvement. I think you've got quite a strong
> proposal here in general, and you've clearly done your homework, so my
> comments below dive directly into the details:

(I've shorten my proposal a bit in the quotes to make the whole email more
readable)

> On 04/01/2011 11:57 AM, Gregor Müllegger wrote:
>> I suggest reading this proposal online: https://gist.github.com/898375
>> It's exactly the same as below but formated nicely.
>>
>>
>> GSoC 2011 Proposal - Revised form rendering
>> 
>>
>> ...
>>
>> Motiviation
>> ---
>>
>> ...
>>
>>    I want to tell the designer how he can do this without my help in the
>>    template.
>
> I agree with your Motivations section - in particular this final line,
> which sums up the core motivation as I see it.
>
>> Goals I want to accomplish
>> --
>>
>> ...
>>
>> **1. No HTML in python source**
>>
>> ...
>>
>
> This all looks quite good to me.
>
>> **2. Reordering/skipping fields**
>>
>> ...
>>
>> The goal will be to make these modifiers defineable. Which means that you
>> can create your own modifiers to support some of your extravagant form
>> rendering needs. To support this we will need to have a rendering modifier
>> *registry* or something similiar, where you can ideally load new ones with 
>> the
>> existing ``{% load %}`` tag. The same will apply for custom *chrome*,
>> described below.
>
> This last bit worries me; it has the potential to add unneeded
> complexity. Do you have any actual use cases for the "custom rendering
> modifier" that can't be handled adequately by your proposal otherwise?
> The concept of what a "rendering modifier" actually _is_ and what it can
> do both seem poorly defined here. I'd rather see this level of
> flexibility left out (and potentially added later) than done without a
> clear driving concept and motivation.
>

I understand your worries and I clearly don't want to invent a YAGNI case. But
I think it fits nicely into the proposal (of it's current state). The reasons
are chrome. Chrome are just a specialized versions of "rendering modifiers"
(btw: I don't like the name but it's the best I came up with yet). And if you
can make it possible to register your own chrome, then it might be only a very
small overhead (if any) to do the same for rendering modifiers.


I want to make clear what a rendering modifier would be on the python level. I
thought about a FormRenderer class that handles the rendering of the form
based on the some predefined rules like what default layout is used. How to
render widgets and so on.

Rendering modifiers are then decorated around the FormRenderer. An example:
In the template::

{% form myform using layout "p" and widget "CalendarInput" for
myform.birthday %}

The FormRenderer iterates over the fields in myform and wants to render them
with layout "default" and with the widgets defined in the form itself. It
asks then the form modifiers "layout" and "widget" that were used in the form
tag how they want to modify the rendering of a specific field. The "layout"
modifier would always return "use layout p", the "widget" modifier always
returns "use the default widget" except when FormRenderer reaches the birthday
field, then "widget" would return "use CalendarInput widget".

(Sorry for the very easy language, maybe my english is to limited to express
it in a not so verbose way.)


I haven't thought in detail about additional usecases for the rendering
modifiers that might life in the app ecosystem. But while writing this
response, there came some of the possibilities into my mind. Maybe there is
the potential for a doctype modifier::

   {% form myform using doctype "html4" %}

This will add a new template directory to the template path while rendering
the form. So that it renders HTML4 compatible widgets if available in the new
template directory. And if not it falls back to the default templates used by
the new template based widgets.

Something more exotic (and complex to implement but still possible) is a
"validation" rendering modifier::

   {% form myform using validation %}

This will walk through the form and outputs at the end some javascript that
validates the form 

Re: Revised form rendering

[Gregor Müllegger]

2011/4/2 Russell Keith-Magee :
> I think this would be a good way to structure the project -- i.e.,
> keep a clear conceptual separation between hooks and configuration
> options that need to be added to Django in order to make an external
> form rendering library possible, and the library that actually
> exploits those hooks and configuration options.
>
> Alex took a similar approach with the NoSQL work last year -- there is
> a fairly clear separation between the "query refactor" changes, and
> the "MongoDB module" that exploits those changes.
>
> I don't think this needs to change the scope of Gregor's proposal very
> much. If we change the focus to be just on the "Django side", we run
> the risk of architecture astronauting. Developing a non-trivial
> implementation that demonstrates the need for any given refactor helps
> to clarify exactly why any given change to Django's APIs are needed.
>
> Yours,
> Russ Magee %-)

I agree on this. The best practice seems to keep changes outside of django if
possible until proven useful. Which can be done cleanly with the templatetag
at least. I didn't integrate plans on what goes inside django and what will be
outside of it since I didn't know if GSoC projects are accepted that work most
of the time on an app than on django itself. But if thats possible like with
Alex's work last year, thats fine for me.

Let me split up quickly what might go into django directly and what could live
outside if my proposal gets accepted:

1. Layouts
The form layouts should be included in django itself, refactoring
{{ form.as_table }}, labels, errorlists etc to make django code HTML free :-)

2. The template tag
This one clearly goes outside of django. Including a template tag is pretty
easy. Merging this in later would be also a no brainer.

3. Rendering modifiers
Thats also something that will go into an app. It's tight pretty closely to
the template tag. But this might require some internal changes to forms to
support all of the aspects described in the proposal (I don't see any
necessary changes yet, but it's like Russell describes, we don't know what
needs to be done until we have a full featured, non-trivial implementation).

4. Changes to widgets
I could see some additional APIs to widgets that get included into django
directly. Like a clean API to add attributes (instead of modifying attrs
directly), an API to add classes, an API to change the template that is used
to render the widget ...
All thirdparty apps that provide additional form features like
"django-widget-tweaks" would benefit.

5. Admin integration
This is a big point that is difficult to do. Creating a "admin" form layout is
still possible. But using the template tag and its mechanics inside of the
admin might not be useful until the template tag is merged into django.
However we might use the admin just as proof of concept, developing
integration of the app in another branch of django. But thats not ideal IMO.

6. Documentation
Writing documentation is ofcourse straight forward for the stuff that goes
into django directly. The thirdparty stuff will be documented like any other
reusable app. I don't see very big problems there. It might just generate some
extra work merging it in afterwards if the app code is accepted for django
core. But thats really the tiniest problem and acceptable if we can produce a
more mature product.


Gregor

-- 
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: [GSoC] Revised form rendering

[Gregor Müllegger]

Hi Yuri,
thanks for your toughts.

2011/4/2 burc...@gmail.com :
> Gregor,
>
> Regarding proposal itself,
>
> the idea to make django form rendering based on templates is good, but
> I think it should be simple, modular and not much verbose.
> I'd like more to see more modular, but easier syntax:
> 1) If you have to render form in your custom way, you have to write
> all form fields (you'll tweak their order and widgets anyway later, so
> it's a plus).
> 2) If you have to render field in your custom way, you have to write
> your own widget or widget template.
> 3) Any advanced form customization can be made using templates.
>
> Something like this:
> {% renderform form1 using layout "uni_form" %} {# errors output could
> be changed with layout templates only #}
>  {# will use template layouts/app1/uni_form/charfield/x.html if it
> was charfield. #}
>  {% render field1 using widget template "x" set class="field1" %}
>  {% render field3 %}
>  {% render field2 %}
> {% endrenderform %}

If I get your ideas right, then my proposed {% form %} and {% formblock %}
tag already supports what you suggested. I try to rewrite your example with
my proposed syntax:

{% formblock form1 using layout "uni_form" %}
{% form form1.field1 using widget template "x" and addclass "field1" %}
{% form form1 using fields "field3" "field2" %}
{% endformblock %}

The things that are different to your example are just some minor syntax
things. Additionally, the "rendering modifiers" (in this case "widget" and
"addclass") are not specified yet and I don't settled on a fixed set yet. I
would like to defer this until a later point because thats something that need
a broader discussion and IMO shouldn't take place in this thread, discussing
the more basic concerns regarding my proposal.

Or did I misunderstand what you tried to express? If thats the case, sorry for
that and please clarify that for me. I would appreciate your feedback.

(btw: a difference to your example is that I use the form tag to render forms
and single fields. I will include why I choose to do this in my response later
to Russell's post -- sorry I need to get offline but will respond again in the
next few hours)

-- 
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: [GSoC] Revised form rendering

[Gregor Müllegger]

Hi,

2011/4/2 Russell Keith-Magee :
> On Fri, Apr 1, 2011 at 11:57 PM, Gregor Müllegger  
> wrote:
>> I suggest reading this proposal online: https://gist.github.com/898375
>> It's exactly the same as below but formated nicely.
>>
>>
>> GSoC 2011 Proposal - Revised form rendering
>> ========
>>
>> Hi my name is Gregor Müllegger. I'm a Computer Science student in Germany at
>> the University of Augsburg currently in the fourth year of my studies. I 
>> first
>> came to django shortly before 0.96 was released and a lots of awesomeness was
>> introduced with the magic removal branch.
>
> Hi Gregor,
>
> Firstly, I'd like to echo Carl's sentiments -- this is a strong
> proposal that shows you've researched the history of Django
> discussions on this topic, and given it some thought of your own.
>
> Carl has already raised several of the points that I noticed on my
> read through. However, I do have some of my own queries.
>
> Syntax
> ~~
>
> You've proposed a syntax that goes something like:
>
> {% form myform using layout "p" and fields "firstname" "lastname" %}
> {% form fancyform.favourite_color using layout "p" %}
>
> I have two questions about this syntax.
>
> Firstly, while it looks fine for a small example, I can see how it
> would rapidly deteriorate if you have lots of fields, or lots of
> custom field requirements for each field. Django's template language
> doesn't allow you to split tags over multiple lines, so what happens
> when my tag runs over 80 characters (this simple example is already a
> 69 characters)?

(Having the possibility of multiline tags would be nice in many other cases as
well ... but that's another topic :-)

I don't see the use of more than two or three modifiers in a template tag in a
day to day use. However it's ofcourse possible to produce complex statements
that would need to span multiple lines. And it's already possible with the
syntax described in the proposal.

You can use a {% formblock %} to extract the modifiers out of the form tag:

{% formblock using layout "uni_form" %}
{% formblock using widget template "calendar" for myform.birthday %}
{% form myform using fields "firstname" "lastname" "birthday" %}
{% endformblock %}
{% endformblock %}

Some might not like the syntax since you would encourage another level of
indention and another two lines for the closing tags. But you can use the
"configure" statement as described in the media handling section of my
proposal:

{% form myform configure layout "uni_form" %}
{% form myform configure widget template "calendar" for myform.birthday %}
{% form myform using fields "firstname" "lastname" "birthday" %}

> Secondly, you appear to be using a single template tag for rendering
> both forms *and* fields. Is there a motivation behind this?

Yes there is :-) The motiviation is, that {% form myform.birthday %} is just a
shorthand for {% form myform using fields "birthday" %}. You can also use it
to iterate over a form (like in your example below) and outputting it field by
field:

{% for field in myform %}
{% form field %}
{% endfor %}

I also don't see a need for an extra {% formfield %} tag. I don't see any
cases in which a {% formfield %} would be shorter, more flexible, easier to
use. It might be more readable, but I think it would end up as a stripped down
copy/alias of the form tag.

> Rendering modifiers
> 
>
> I share Carl's concern about exactly how and why these are necessary;
> even after your most recent post, I'm still not completely clear on
> what they mean in practice.
>
> On the one hand, I can see that there may be a use case for passing
> arguments into the template rendering process. However, you seem to be
> proposing a mechanism by which developers could define Python code
> that alter widget rendering by performing such tasks as:
>
>  * selecting a different rendering directory
>  * changing the template that is used for a widget
>  * changing the layout scheme
>  * prepending/appending content onto a widget
>
> I think I understand your motivation here, but my inclination is that
> this will end up being a very complex system that won't end up being
> useful in practice.

The rendering modifiers came up in the proposal because I thought about the
possible implementations of the {% form ... using ... and ... %} syntax. I had
the idea that these modifiers after "using" could be seperated from the tag
itself. I had the analog

Re: [GSoC] Revised form rendering

[Gregor Müllegger]

2011/4/4 Daniel Greenfeld :
> Anyway, as the current lead on Django Uni-Form I think its great that Gregor
> is picking up the torch for refactoring form rendering in Django 1.40. He's
> obviously done his homework and put a lot of thought into this critical part
> of Django.
> I'm not a core developer my vote doesn't count, but I'm giving it anyway. +1
> from me.
> Daniel Greenfeld

Hi Daniel, I really appreciate your support. It shows that I might be on the
right path for a successfull refactoring. Thanks.

@all:

I've updated my proposal. Mainly the media tag part and the timeline estimates
(nothing really exciting for the moment). A revision of the chrome section
will follow tomorrow. Have a look at the proposal online [1] or look below,
I've included the changed bits:



GSoC 2011 Proposal - Revised form rendering


...

Media aka. JS/CSS
-

One of the other mainpoints in the discussions I reviewed for this proposal was
the use of JS and CSS files that must be maintained somehow to display them
how we already do through the media framework (e.g. ``{{ form.media }}``).

The problem with this is that with the new template tag we can change some
of the widgets in the template and introducing new dependencies. Thats why I
would like to have an alternative for the ``using`` argument in the
``{% form %}`` tag.

If ``using`` is replaced with ``configure``, the ``{% form %}`` tag will _not_
output the HTML in the current place. However it will record and remember the
usage of widgets and fields to determine which media files are required. An
example template would look like::

{% block extrahead %}
{% form myform configure widget "CalendarInput" for myform.birthday %}
   ^--- The new widget for the field birthday will be
recorded, but the form will not be rendered.
{{ myform.media.css }}
   ^--- Outputting all necessary css files.
{% endblock %}

{% block content %}
{% form myform %}
   ^--- The form will be rendered as usual but with the
"CalendarInput" widget that was specified in the other tag.
{% endblock %}

{% block footer %}
{{ myform.media.js }}
   ^--- Outputting all necessary js files at the end of the document.
{% endblock %}

I will also check the possibility and difficulty of a new ``{% formmedia %}``
tag that hooks into the template parsing system, reading until the end of the
template and analyzing the use of the ``{% form %}`` tag. This way it could
determine all changes that will be applied to the form before it gets
rendered, including all the necessary CSS dependencies that needs to be
imported in the header of the page.

It is not clarified yet, if the ``{% formmedia %}`` is possible at all with
the current template parsing implementation. There might be some risks that
need to be sorted out before starting with the implementation:

* By parsing from the ``{% formmedia %}`` tag until the end of the template
  might result in that all content after this tag is represented as a child
  node of it. What side effects are implied? Does it produce backwards
  incompatibilities with thirdparty template tags?

* What happens if the ``{% form %}`` tag is changing the widget of the form
  based on a context variable?

Estimates
-

...

1st week: Starting to layout the documentation. The form tag syntax based on
discussions from the mailing list should already be finalized.

2nd week: Examing what unittests are available for the current form rendering
and making sure they are stable for testing backwards compatibility during the
project.

3rd week: I will attend DjangoCon EU, hopefully giving a talk about the
revised form rendering and collecting more feedback in an open space.

4th week: Converting the current layouts into template based renderers, ensuring
backwards compatibility.

Goal: no HTML should be left now in the python source.

5th week: Mainly working on documentation and integrating the very last changes
based on discussions from DjangoCon EU.

Goal: All public APIs should be stable.

6th week: Starting to write tests and implementing the ``{% form %}`` tag to
be able to emulate all the rendering that is currently possible.

7th week: Implementing the necessary rendering modifiers like "fields",
"layout" etc. and the API for chrome.

8th week: Implementing the ``{% formmedia %}`` tag.

Goal: Project should be feature complete.

9th - 11th week:

* Validating backwards compatibility for the ``{% formmedia %}`` parsing
  implementation with thirdparty modules (see Media section).
* Converting the admin to use the new form rendering.
* Integrating lessons learned from the admin.
* Bugfixes and regression tests for problems that showed up in the work with
  the admin.

Goal: Code should be ready to be used in sample projects.

12th week: Finalizing, bugfixes and tweaking the document

Re: [GSoC] Revised form rendering

[Gregor Müllegger]

Sorry for the quite late response, everything is getting pretty close to the
deadline. I'm not happy with it but I need to tackle some personal issues at
once.

2011/4/5 Russell Keith-Magee :
>
> ...
>
> In particular, I have two objections:
>  * it feels like it's trying to cram too much into a single template tag.
>  * it requires a lot of duplication of "form myform configure" or
> "formblock myform using"
>
> Consider a slight variation that uses more tags:
>
> {% form myform configure %}
>    {% layout "uni_form" %}
>    {% widget "calendar" for DateField %}
>    {% autocomplete "lastname" from "/users/lastnames" %}
> {% endform %}

Yes that looks clean and easy to follow. I just don't like the lone keyword
'configure' (or 'using') at the end of the tag. But I guess we need it to
determine if we search for a closing endform tag or if it's a standalone one
(or we use the 'trick' you described for the media handling).

> Then, when it comes time to render:
>
> {% form myform using %}
>    {% field "firstname" %}
>    And some HTML decoration
>    {% field "lastname" %}
> {% endform %}

Looks good. A problem would be with using multiple forms:

{% form myform using %}
{% form another_form using %}
{% field "name" %}
{% endform %}
{% endform %}

Is "name" a field of "myform" or "another_form"? But thats easy to work around
by using {% field myform.name %} for example.

> or, using an iterative approach:
>
> {% form myform using %}
>    {% for field in myform %}
>        {% field field %}
>    {% endfor %}
> {% endform %}

I wonder how it would look like to change the layout and outputting the whole
form like {{ form.as_ul }}. Your example is for more than basic scenarios good
but very verbose for just changing the layout. Maybe using the form tag would
inherit the configuration from the wrapping form tag::

{% form myform using %}
{% layout "ul" %}
{% form myform %}
{% endform %}

Skipping the wrapping {% form myform using %} is also possible, layout would
configure the whole template by setting a context variable. However this might
have sideeffects on included templates etc. Explicit is usually better than
implicit. But we will find a way to deal with it.

> or, using default layout:
>
> {% form myform %}
>
> This approach:
>  * cuts down on the duplication, either in the form of indented form
> blocks, or in duplicated 'tag opening' content
>  * avoids the need for a DSL embedded in the tag definition
>  * avoids potential grammar ambiguities -- the less grammar there is
> in a tag, the less likely there will be edge cases in the parsing.
>
> ...
>
>>> Rendering modifiers
>>> 
>>>
>> But like I already wrote above: I see your concerns with adding yet another
>> registry that might not be used very often. I would agree on dropping that
>> feature if you think its better to skip this until users demand it 
>> afterwards.
>
> I think this might be the better approach. Your proposal is already
> fairly ambitious, especially if it's going to include a reworking of
> admin's rendering. And, to that end, reworking admin's rendering
> should prove a useful testbed for whether it is needed at all.
>
> Also -- some food for thought; the reason that a registry is needed
> here is because you're defining an extension api for a monolithic {%
> form %} tag. If the rendering strategy used multiple tags, modifiers
> could also be defined as template tags:
>
> {% form myform %}
>    {% mymodifier foo %}
> {% endform %}
>
> Then you don't need a separate registry; a "modifier" just becomes a
> template tag operating on the API exposed by the form rendering API
> (presumably a set of known objects in the local context of the form
> tag). If an end user wants a rendering modifier, they just define
> their own template tag and use it in a {% form configure %} block.

Ha! That makes me happy to have a possibility for custom behaviour in the form
rendering and you happy because we don't need another abstraction. I like this
approach and will go for it.

>>> Form rows
>>> ~
>>>
>>> If you look at the existing as_* form layout tools, there is a
>>> distinction between gross form layout, and the layout of an individual
>>> form row.
>>>
>>> {{ form_header }}
>>> {% for field in form %}
>>>    {{ pre_field }}}
>>>    {{ field }}
>>>    {{ post_field }}
>>> {% endfor %}
>>> {{ form_footer }}
>>>
>>> Conceptually, the rendering for pre/post field could vary depending on
>>> the field. How is this handled in your proposal? Is it part of the
>>> form renderer? Or part of the widget rendering? This overlaps with
>>> your discussion about error templates -- since errors (and their
>>> rendering) is one of the major pre/post rendering activities for both
>>> forms and fields.
>>
>> I'm not sure if I get your example right. Is it representing the output of a
>> "as_*" method? I looked into the django/forms/forms.py code again and I'm
>> quite sure that there is 

Re: [GSoC] Revised form rendering

[Gregor Müllegger]

I finally submitted my proposal to the google melange homepage. The core of
the proposal is very much unchanged to the first draft, however I've included
passages that indicate that the syntax might change in further discussions
about this topic and that the concept of a chrome will be propably dropped in
favour of more flexible template based widgets -- I didn't wanted to
include a new detailed view on this topic without knowing how the final
implementation for template based widgets will look like.


For all that are interested, here are some links with more information about
my submission:

1. The official submission on the google-melange.com homepage:

http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/gregmuellegger/1

2. The latest revision (and its change history) of the proposal on github
(maybe also nicer formated):

https://gist.github.com/898375


I will get back to the list kicking of some more discussions about the syntax
next week and doing some syntax "testing" like we previously discussed in this
thread.

Gregor

-- 
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.

[GSoC form rendering] Weekly check-in -3.0

[Gregor Müllegger]

Hi,

let me introduce myself a bit before I start talking about my upcoming work
during the summer. My name is Gregor Müllegger and I was accepted as a Google
Summer of Code Student for Django, doing the project called "Revised form
rendering". Next Monday will start my fourth year at the university, I'm
studying Computer Science at the University of Augsburg which is 60km West of
Munich, Germany. I'm also doing freelancing work with Django to finance my
studies.

My project will basically try to make the current form rendering possibilities
more flexible and to remove all the hardcoded HTML from the django source
related to forms. You can have a look at the django-dev mailing list
discussion about my proposal online [1].

My mentor is Carl Meyer, I already spoke to him and I'm very sure that we will
make a great team in bringing this project to a successful ending in August.
We will use the next weeks to speak intensively about the design issues that
still needs to be resolved and other things that needs to be done before the
GSoC time starts in May.

Today we discussed how we want to approach the design phase. We still need to
finalize for example the exact syntax of the proposed form template tag. We
came up with the idea of a sample project that we will put online in a
repository on github. This repo will first contain some scenarios in the
possible usage of the form tag, exploring it's behaviour in edge cases etc.
Others could fork the repo and contribute different syntax ideas, making it
easy to compare all variations. In the end we will have a resource were we can
point at in questions about why we have chosen this API.

In an IRC chat between Carl, Jannis and me on #django-dev, we choose to
develop the project directly against django's trunk. This means that we
decided against the alternative of developing the proposed API
as an external app. We still want to find an easy way for interested testers
to check out the current state in an already existing django project.


Here are some resources you might want to track during the summer if you are
interested in this GSoC project:

* My django fork on github will have a soc2011/form-rendering branch that will
  contain my updates that might get merged into django's trunk at the end of
  summer [2]. My changes compared to django's trunk will be visible there as
  well [3].

* Keep track of the django-form-rendering-api repository if you want to know
  how things go in the design process. [4] There's nothing in there yet, but
  this will change during the next week.

* Join us in #django-dev on Freenode! Carl and I will use this as our IM
  solution so that you can jump into the discussion if you are interested.

That's it so far this week. Thanks for your attention :-)


| [1] 
http://groups.google.com/group/django-developers/browse_thread/thread/8eb1f07bfd949ab7
| [2] https://github.com/gregmuellegger/django/tree/soc2011%2Fform-rendering
| [3] 
https://github.com/gregmuellegger/django/compare/django:master...gregmuellegger:soc2011/form-rendering
| [4] https://github.com/gregmuellegger/django-form-rendering-api

--
Servus,
Gregor Müllegger

-- 
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.

[GSoC form rendering] Weekly check-in -1.0

[Gregor Müllegger]

Hi,

I used the last week to setup the 'test environment' for proof-of-concept'ing
the API we will be implementing. The first thing there is that I setup a (yet)
simplistic template for

1. the form tag, the monolithic approach how I have proposed it
2. multiple tags like proposed by Russell.

Both can be found in the form-rendering-api repo on github [1 & 2].
Feel free to fork the repo, adding more of these proposals or changing the API
of already proposed syntaxes.

The other thing I did was a quick proof-of-concept of the idea that came up
for a revised media handling. The problem with media handling is, that there
might arise the need in the middle of the template to inject some CSS
definitions in the head of the page. It turned out that this can be done with
the current template engine. See the github repo for implementation details
[3]. It also contains tests where you can see the tag in action.

Here a short teaser for the {% media %} tag::

{% load media_tags %}

{% media "css" %}


{% addmedia "css" %}

p { color: #ff; }

{% endaddmedia %}
This text will be red.


... will render to ... ::



p { color: #ff; }



This text will be red.


| [1] 
https://github.com/gregmuellegger/django-form-rendering-api/blob/master/formapi/templates/api_samples/single_tag.html
| [2] 
https://github.com/gregmuellegger/django-form-rendering-api/blob/master/formapi/templates/api_samples/modifier_tags.html
| [3] 
https://github.com/gregmuellegger/django-form-rendering-api/blob/master/formapi/media_framework/templatetags/media_tags.py

--
Servus,
Gregor Müllegger

-- 
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: Re : [GSoC form rendering] Weekly check-in -1.0

[Gregor Müllegger]

Thanks Mathieu,

I already knew this library, however I wanted to have a quick implementation
that doesn't use classytags or any other thirdclass library. But thanks to
your link I looked in the documentation of sekizai again and saw the
restrictions page [1]. And after having a look at the my sample
implemenation... I think we obviously experiencing the same.

I need to investigate a bit more here and see how we can deal especially
with the limitation that the {% media %} tag might not be usable inside a
block tag.
Maybe we can also trick the parser here a bit, but this would result in a
pretty hacky solution that also will likely break anyway when Armin exchanges
the parser with a new implementation.

[1] http://django-sekizai.readthedocs.org/en/latest/restrictions.html

--
Servus,
Gregor


2011/5/14 Mathieu AGOPIAN :
> Hello Gregor,
>
> just FYI, one of the guy from django-cms created django-sekizai, which is
> used just for that (injecting stuff in template blocks) :
> https://github.com/ojii/django-sekizai
>
> Mathieu
>
> --
> 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.
>

-- 
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.

RFC: Templatetag API for form rendering

[Gregor Müllegger]

(You can read this RFC online if you prefer:
https://github.com/gregmuellegger/gsoc2011-stuff/blob/master/rfc_syntax.rst )


Hi,

like you might know I've prepared as pre-work to my GSoC project a repository
[1] with examples for two different approaches to my upcoming work on the form
rendering. The first approach is called "single_tag" [2] the second one
"modifier_tags" [3]. I agreed with my mentor Carl that we will follow a
"hybrid" style of both proposals [4].

I tried here to summarize a bit how the new tags will look like. I call now
for comments and will really appreciate any feedback on them. Being it about
their naming or if you have ideas for other tags. Be picky, this is something
lots of people will use -- and though we want it to be as easy as possible to
get started with.

::

{% renderform  [ ...] [hidden  ...] [exclude  ...] %}

The renderform tag renders the complete form::

{% renderform my_form %}

You can influence which fields will be used, sparing some fields out
if you want that. Examples::

{% renderform my_form "username" "password" %}

Renders only my_form.username and my_form.password and ignoring all other
fields on the form. ::

{% renderform my_form exclude "first_name" "last_name" %}

Render all fields but my_form.first_name and my_form.last_name. ::

{% renderform my_form hidden "honeypot" %}

Render all fields but outputs the my_form.honeypot field as a hidden field.

Thats it in what the renderform takes on arguments. You can influence it's
rendering behaviour in more detail by using *form modifier tags*.

One such modifier tag is the formlayout tag::

{% formlayout  %}

Every {% renderform %} that is following in the templates will use the
specified layout for rendering. We will provide layouts called "table", "ul"
and "p". Users can specify new layouts just by putting some templates in the
right template path.

The {% form %} tag is limiting the scope of these modifier tags. If a modifier
tag is wrapped in such a form-block, then it will lose its influence on form
rendering outside of the form tag. ::

{% form %}
{% formlayout "table" %}
{% renderform my_form %} {# will use table layout #}
{% endform %}

{% renderform my_form %} {# will use default layout #}

The description of the form tag implies that the modifier tags are able to
set/modify the global state in the current template. That is something that is
explicitly wanted. This way you can set a "formlayout" in the head of your
base template and any other extending template will have this default for the
form rendering.

Another tag to modify the rendering is the widget tag::

{% widget [] [using ] for
 [with = ...] %}

In this syntax description  means that you can specify one of
three things as argument:

1. A bound field, means that the widget will be rendered only for this field.
2. A field class/type that will match for all fields that are using this
   formfield class. Example::

{% widget widgets.PasswordInput for formfields.CharField %}

   will render a  for all charfields.

3. A field name (string). This will apply to all fields that have that
   particular field name. It's only useful if the option should apply to more
   than one form or as convenience for short reference of a field.

Some examples::

{% widget widgets.Textarea for my_form.comment %} (1. case)
{% widget widgets.DatePicker for formfields.DateField %} (2. case)
{% widget widgets.PasswordInput for "password" %} (3. case)

You can also change the template that will be used to render the widget with
the using keyword (we assume at this point that until this GSoC project is
finished we will likely have template based widget rendering like currently
developed by Bruno [5]), an example::

{% widget using "my_textarea_widget.html" for my_form.comment %}

It's actually possible to specify a special template for the widget *and* to
change the widget class itself with the tag::

{% widget widgets.DatePicker using
"widgets/alternative_datepicker.html" for my_form.birthday %}

The "with varname=varvalue" bit in the widget tag is meant as possibility to
pass extra arguments into the template that will be used to render the widget.
This will use the same syntax as django's ``include`` tag [6]::

{% widget for my_form.text with rows=10 cols=20 %}

{% widget using "widgets/tinymce.html" for my_form.comment with
theme="advanced" %}


At the end a short word to the meanings of widgets.Textarea etc. This
will basically be a template variable referencing the Textarea widget. So we
don't use special syntax for this in the tag, we just pull out the "widgets"
template variable that will be passed in via a context processor.

The "widgets" and "formfields" variables will be modifiable by users, so that
they can register their own widgets in their reusable apps, then usable in all
templates.


Thanks if you have read so far. Now please start commenting :-)

Gregor

| [1] https

[GSoC form-rendering] Weekly check-in -0.0

[Gregor Müllegger]

Hi,

Carl and me had a vital discussion about the syntax that we will
propose for a RFC.
There is already a mailing list thread to which I warmly invite you to join:

http://groups.google.com/group/django-developers/browse_thread/thread/e4836b5a9d36349e

Read the templatetag syntax proposal there and give your feedback!


I also changed the planed timeline of my project slightly. I will push the
start of writing documentation right after DjangoCon.eu. Hopefully there will
be more comments on that topic that I can integrate then into the project.
Before DjangoCon I will totally focus on backwards compatibility, extending
the test suite, converting the current form rendering to use templates etc.

This Monday is the official start of the GSoC project phase.
So let's get the coding started :-)

Watch my progress on github:
https://github.com/gregmuellegger/django/tree/soc2011%2Fform-rendering

--
Servus,
Gregor Müllegger

-- 
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

[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: RFC: Templatetag API for form rendering

[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.

[GSoC form-rendering] Weekly check-in 1.0

[Gregor Müllegger]

Hi,

this week was the first week with official coding for my GSoC project. I
merged Bruno Renié's template based widget rendering branch in my django fork.
This will be the base of my on going work. I also made sure that all tests are
passing, since there were some issues with changes in the whitespace and
ordering of HTML attributes in the new widget rendering.

I except that my upcoming changes will propably change also some attributes
ordering and lots of whitespace. I took this as a motivation to write a
assertHTMLEqual TestCase method that compares two strings that contain HTML
markup. It parses the HTML into a object structure which can be easily
compared without beeing too pickey about e.g. trailing whitespace, attribute
ordering, closing tags etc.. See the tests to get an impression on how it
looks in action:
https://github.com/gregmuellegger/django/blob/soc2011%2Fform-rendering/tests/regressiontests/test_utils/tests.py#L121

Watch my progress on github:
https://github.com/gregmuellegger/django/tree/soc2011%2Fform-rendering

--
Servus,
Gregor Müllegger

-- 
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.

RFC: Templatetag API for form rendering - Second Edition

[Gregor Müllegger]

Hi,

this is the second RFC regarding template form rendering API/syntax. The first
one defined how a complete form or a subset of fields will be rendered. I'm
now proposing more tags to render more details like only the label of a form
field.

Currently we haven't discussed how we will substitute what we currently do
with using::

{{ form.non_field_errors }}
{{ form.errors }}
{{ form.field.errors }}
{{ form.field.help_text }}
{{ form.field.label_tag }}


We will implement these with template tags that are aware of the currently
used layout:

Substituting {{ \*.errors }}::

{% formerrors  %}

Some examples:
Display *all* errors of a form::
{% formerrors my_form %} (equals current {{ my_form.errors }})

Non-field errors::
{% formerrors my_form.non_field_errors %} equals {{ my_form.non_field_errors }}

Single-field errors::
{% formerrors my_form.firstname %} equals {{ my_form.firstname.errors }}

Basically it will render the error list/dict that is available in the *errors*
attribute of the passed in object. As an alternative (e.g. the
non_field_errors) you can pass in directly a error list that gets rendered::

{% formerrors my_custom_error_list %}
{% formerrors my_form.field.errors %}


Substituting ``{{ form.field.label_tag }}``

This one might be pretty obvious::
{% formlabel my_form.field %}


Substituting {{ form.field.help_text }}

Also pretty obvious::
{% formhelp my_form.field %}

But the naming is IMO not ideal. {% helptext %} as alternative is reasonable,
but Carl and I agreed on that we wanted the tag to start with form* but
{% formhelptext %} is to long. So we settled on {% formhelp %}
Better suggestions are welcome.


That's it basically. I don't see any controversies in here, but as usual
with a RFC: comments are requested and will be integrated. :-)


--
Servus,
Gregor Müllegger

-- 
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: Better error message for django.core.urlresolvers.reverse

[Gregor Müllegger]

Hi Tom,

currently it seems that the url resolver that is actually raising the
error doesn't know about in which namespace he acts. However I think
as well that this might be a usefull addition to the error message.

I would suggest adding a ticket to django's bugtracker [1] for this.
Ideally write a patch for this issue and attach it to the ticket.

[1] https://code.djangoproject.com/

--
Servus,
Gregor Müllegger

2011/6/9 tomv :
> Hi,
>
> This is the current error message when a url name or argument doesn't
> exist:
>
>>>> reverse('core:non_existant')
> NoReverseMatch: Reverse for 'non_existant' with arguments '()' and
> keyword arguments '{}' not found.
>
> Is there support for adding the namespace into the error message?
>
> Tom
>
> --
> 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.
>
>

-- 
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: Ability to change dismissRelatedLookupPopup on my own callback function

[Gregor Müllegger]

Hi I needed to do the same in my own projects, however I just
decorated the functions which I wanted to modify. Like:

original_dismissRelatedLookupPopup = window.dismissRelatedLookupPopup;
window.dismissRelatedLookupPopup = function () {
// put your own code here ...
original_dismissRelatedLookupPopup.apply(this, arguments);
};

Maybe this helps until a way is introduced in django to modify this behaviour.

--
Servus,
Gregor Müllegger

On Jun 13, 2011 4:23 PM, "Harris Lapiroff"  wrote:
> I think this is a great idea! I would certainly benefit from it.
>
> It might be worth considering if there are any methods for passing a
> callback function that are better than GET parameters—though I can't
> think of any off the top of my head.
>
> H.
>
> On Jun 13, 12:16 am, Alex Kamedov  wrote:
>> Hi all!
>>
>> I make integration with warehouse system and want to reuse existing
>> functionality in django.contrib.admin to manage links between this system
>> and catalog on site.
>> I can't get access to warehouse system database, I have only export file. I
>> write some views to represent its items in django admin. And now I need
>> something like related field in django admin forms, but has some filters
>> applied to changelist and has some other user interface.
>>
>> I think, the best solution for this case is put some links with
>> showRelatedObjectLookupPopup javascript function on admin changelist, but
>> after user choose the object, my own javascript function must
>> be called instead of dismissRelatedLookupPopup javascript function.
>>
>> Execution of dismissRelatedLookupPopup is hard coded in python code now. The
>> easiest way to implement use case described higher is adding new GET
>> argument "_callback" to changelist view.
>>
>> What are you think about this? If this solution was accepted I can write
>> patch and tests for it.
>>
>> Cheers!
>> --
>> Alex Kamedov
>> skype: kamedov    www: kamedov.ru
>
> --
> 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.
>

-- 
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.

[GSoC form-rendering] Weekly Check-in

[Gregor Müllegger]

Hi,

I unfortunatelly missed the last weekly check-in. However during this time I
was already on my travel to Amsterdam for DjangoCon Europe. During this
Conference and mostly during the sprints have I spoken to some of the core
contributors to get their opinion about my current form rendering proposal in
person. Idan had some really fantastic ideas about how we can improve on what
Carl and I came up with. He is also a professional designer and really knew
what was bugging him with forms he is writing.

He is also volunteering in writing up a description on how this will look
like and sending it to this mailinglist. So stay tuned and look out for his
message!

I got also some small work done during the sprints in improving the test
suite. Peter van Kampen and I removed the last remaining doctest in django's
test suite. I also mocked the tests for URLField's with verify_exists=True.
They used to access the internet which made the tests fail if you are on a
plane (for example ;-)

So let's see how Idan's wrap up will look like. This will be open for
discussion at the time its posted. If there are no major concerns with it I
will start writing documentation for this approach at the end of next week.

I cannot response to any message in the next five days since I'm involved in a
trip for university and a paper I need to write.

Thanks again to the really well organized Djangocon and espescially the
sprints. It was a great place to get things done.

--
Servus,
Gregor Müllegger

-- 
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: Form Rendering API Proposal

[Gregor Müllegger]

Hi Harro,

2011/6/23 Harro :
> Two things:
> - Will the as_* methods on forms be deprecated? They seem to be a nice
> shorter version then the new way to do it.

The plan is to deprecate them. First reason is that the new approach
is more explicit of what happens. The second and main reason is, that
as_* are methods on the form. IMO the form shouldn't know much about
its representation or how it's rendered. I see it like a model that
doesn't know about its view (in the MVC sense, not model in django
sense).

> - I assume the formconfig calls are for the current context, but can I set
> them in the base.html and then automatically have them used in all templates
> extending the base.html and templates included in a template?

They are limitted in the scope of the tag where they are used. So
formconfig tags cannot break out of a form tag, or the template that
is included by the form tag. You are not able to set global defaults
as of configuring all forms in your base.html, since using them
outside of a {% form %} will raise a TemplateSyntaxError. However you
can achieve something similiar for having a generic base template for
all your form layouts.

--
Servus,
Gregor Müllegger

-- 
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: Form Rendering API Proposal

[Gregor Müllegger]

Hi Benoît,

2011/6/24 Benoît Bryon :
>
> Le 23/06/2011 13:25, Idan Gazit a écrit :
>>
>>
>> http://www.scribd.com/doc/57270484/Djangocon-EU-2011-Revised-Form-Rendering-Lightning-Talk-by-Gregor-Mullegger
>>
>
> I'm still not convinced by the {% form myform hidden "honeypot" %} syntax.

I have also not convinced Idan for this :-) (including many other aspects of
my earlier proposal). So we sat down, creating the new proposal you've read in
the first message in this mailing thread. The "old" proposal, as in my
lightning talk, is outdated now. We want to discuss the new one here.

> Isn't it a duplicate of {% widget HiddenInput for form.honeypot %} and its
> {% formconfig %} equivalent?

Yep :)

> With a similar syntax we would write shortcuts like {% form not hidden
> "honeypot" %} or {% form textarea "honeypot" %}... I guess those are bad
> ideas.
>
> Benoit

We should have mentioned that in a clear way. Sorry for the confusion.

--
Servus,
Gregor Müllegger

-- 
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: Form Rendering API Proposal

[Gregor Müllegger]

Hi Jonas,

2011/6/23 Jonas H. :
> On 06/23/2011 02:11 PM, Harro wrote:
>>
>> - Will the as_* methods on forms be deprecated? They seem to be a nice
>> shorter version then the new way to do it.
>
> I'd rather provide a shorter version of {% form %} for built-in layouts:
>
> {% form foobar 'table' %}
> as shorthand for
> {% form foobar 'forms/layouts/table.html' %}
>
> This behaviour could even be extended to automagic template selection, so if
> you do {% form ... 'foo' %} Django searches for a 'foo.html' template in
> "project/current_app/templates/current_app/forms/layouts/", then
> "project/templates/forms/layouts/", falling back to
> "django/forms/templates/forms/layouts/" if none of those directories
> contains the desired file.  Your proposal doesn't tell anything about where
> form templates are searched, is something similar to this intended?

Basically we wanted to avoid automagical behavior. The plan is to load the
templates like any another template, just with the installed template loaders.
We will add a form-template-loader that you can add to your TEMPLATE_LOADERS
setting that is simply a directory based template loader looking for
templates in
django/forms/templates -- making the default "shipped with django" form
layouts available.

--
Servus,
Gregor Müllegger

-- 
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: Form Rendering API Proposal

[Gregor Müllegger]

Hi Preston,

2011/6/23 Preston Timmons :
> This looks excellent so far.
>
> Do {% formfield %} and {% formrow %} accept context like {% form %}
> does?
>
> Is there a way with {% formfield %} or {% formrow %} to set custom
> attributes like placeholder, autocorrect, etc.? I find this common
> requirement when optimizing forms for mobile devices.
>
> Thanks,
>
> Preston

Yes that will be possible. We plan to have this somehow available in the
widget configuration e.g. with the current proposal:
{% formconfig widget for myform.myfield attr placeholder="Type here ..." %}

--
Servus,
Gregor Müllegger

-- 
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: Form Rendering API Proposal

[Gregor Müllegger]

Hi Jacob,

2011/6/23 Jacob Kaplan-Moss :
> Hi Idan et al. --
>
> Thanks for putting this all together!
>
> In general, I like this a lot, and I'm always going to defer to the
> eyes of someone like Idan who spends more time wrangling templates
> than I do. So I like the general gist, and I most don't mind the {%
> formconfig %} business.
>
> However, I do have a few concerns:
>
> 1. Performance: it looks, to me, like rending a basic form is going to
> cause dozens of template includes and dozens of sub-renders (the form
> loads a form template which loads row templates which load widget
> templates). That's dozens of disk hits, and a lot of overhead for form
> rendering. I worry about this overhead a lot. Django's performance has
> slipped lately, and I'm really afraid this'll make things a lot worse.
>
> So I'm going to need to see some benchmarks -- particularly in how a
> simple {% form myform %} compares to {{ form.as_* }}.
>
> The wrong performance benchmarks could result in a veto from me; this
> is important.

Unfortunatelly we don't have any implementation yet, except of what Bruno did
with floppyforms, what we can benchmark. But I think we could minimize disk
hits or template-loader work by caching the rendered templates ourself. For a
form with many fields it's very likely that most of them use the same row
level template, so we can reuse this a couple of times during the rendering. I
will do my best to make things as fast as possible. Benchmark was not yet part
of my GSoC timeline but I agree that this should have a high priority.

However based on the feedback I got on djangocon and on the mailinglist yet,
the anticipation for this feature is really big. And we won't make code slower
that already exists. You only get a bit slower form rendering if you are going
to use the new mechanics, but you trade that for a much more flexible and
faster template designing. And as Benoît described in the current thread: Most
designers already use something like the proposal suggests but with a custom
{% include %} hierachy. Introducing a "special" syntax can only open up the
possibilities for performance tweaking.

>
> 2. Verbosity: There's a lot of tags (well, 4, but that's a lot to me)
> wall-of-code stuff like
> https://github.com/idangazit/formrendering/blob/master/djangocon_sketch.html#L62-83
> doesn't particularly give me the warm fuzzies. I think  part of the
> problem is that all the tags are `form*` which makes for a bit of
> "bork bork bork" there.
>
> I think it might be possible to simplify things somewhat here, so
> here's my rough thoughts:
>
> * Keep {% form %} -- it's obvious.
> * Rename {% formfield %} to {% field %} -- it won't conflict, and it's
> (fairly) obvious we're talking about a *form* field since we'll
> usually be saying {% field myform.whatever %}.
> * Drop {% formrow %} entirely. Instead, have {% field %} generate the
> whole thing you're calling a "row".

This was Idan's main point in iterating over my earlier proposal. He saw it as
a very basic usecase that fields aren't necessary one per row. He had some
excellent examples of fields, like firstname surname, that should fit into one
row. I think we should be able to make these rowdesigns reusable.

I for myself had a few situations in which I really wanted to have the feature
while implementing designs a client gave me.

> * Add {% widget %} which rendered just the field (i.e. what {%
> formfield %} does now).
> * Keep {% formconfig %}.
>
> This is verging dangerously close to bikeshedding, so the syntax
> either way won't change my vote much.
>
> Thanks!
>
> Jacob

Thanks for your input Jacob!

--
Servus,
Gregor Müllegger

-- 
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: Form Rendering API Proposal

[Gregor Müllegger]

Hi Benoit, hi Bruno,

2011/6/26 Benoît Bryon :
> Hello,
>
> Le 25/06/2011 12:05, Bruno Renié a écrit :
>>
>> * If you want template-base widgets *now*, use django-floppyforms.
>> * If you want to use the new forms / templates API as soon as it's
>> done… how do you do it? Is it going to be packaged as an app, as a
>> patched version of django?
>
> One option could be to use django-formrenderingtools and adapt it to the
> proposed API.
> Formrenderingtools does not cover exactly the proposed API yet, but I guess
> it could.
> In fact, formrenderingtools will be deprecated in next Django releases. So
> there is no interest in maintaining it "as is". Offering backward
> compatibility for the form rendering API may be the best way to go.
>
> The main repository is
> https://bitbucket.org/benoitbryon/django-formrenderingtools
> I just pushed it to github too (let's try hg-git) :
> https://github.com/benoitbryon/django-formrenderingtools
>
> Forks are welcome!
>
> This is only a suggest, so if most of you think we'd better fork another app
> or build a brand one... please let me know. I would stop committing on
> formrenderingtools and contribute to the other app instead ;)
>
> Benoit

If the need for the new form rendering is big enough or requested by lots of
people (I think that criteria is already matched :-)), will I port the API to
an external re-usable library. However I would create a new library that only
contains the things that will be included in a future django version so that
upgrading from that library to the django-builtin form rendering is as
painless as possible.

--
Servus,
Gregor Müllegger

-- 
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: [GSoC form-rendering] Weekly Check-in

[Gregor Müllegger]

Hi Mikhail,

2011/6/22 Mikhail Korobov :
> Hi Gregor & others,
> I've noticed the https://github.com/idangazit/formrendering and it reminds
> me the approach I'm using for all my django 1.3 projects:
> {# forms/fields/as_dl.html #}
>   {{ field.label_tag }}}   {{ field }}
> {% include "forms/fields/errors.html" %}  
>
> and then:
>  {% csrf_token %} {% include
> 'forms/fields/as_dl.html' with field=product_form.title %} {% include
> 'forms/fields/as_dl.html' with field=product_form.conditions %}
>  
>
> This can be used in a loop:
> {# forms/my_as_ul.html #}
> {% include "forms/non_field_errors.html" %}
> 
> {% for field in form %}
> {% include 'form/fields/as_dl.html' %} {% endfor %}
> 
> and then:
> {% include 'forms/my_as_ul.html' with form=product_form %}
> If individual field should be changed then django-widget-tweaks can be used:
> {% load widget_tweaks %}
>  {% csrf_token %} {% include
> 'fields/as_dl.html' with field=form.title|attr:"autofocus" %}
> {% include 'fields/as_dl.html' with
> field=form.conditions|add_class:"foo"|attr:"type:search" %}
> {% include 'forms/buttons/submit.html' with value="Save" %} 
>
> This approach does not provide all the sugar from the Idan's and Gregor's
> proposals (namely, it forces developer to list all fields if one field is to
> be tweaked) but it is quite simple, introduces no new concepts and can be
> used in existing django 1.3 projects.

Idan, me and all the other guys at the sprints were discussing exactly
something like this. We used the syntax from the current proposal because we
thought that matches the already existing includes as close as possible and
let's you utilize template inheritance, while still having the opportunity to
have some extra behaviour.

Look at the final result what Idan wrote down and is currently discussed in
another thread:
http://groups.google.com/group/django-developers/browse_thread/thread/3791152616fd95ae

--
Servus,
Gregor Müllegger

-- 
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: [GSoC form-rendering] Weekly Check-in

[Gregor Müllegger]

Hi,

we finally found (IMO) a really good API for the form rendering related
template tags. There is currently an ongoing discussion on the mailinglist
[1]. Jacob raised some concerns related to the performance impact that future
form rendering will have. I will make this a more important point in my
thoughts while going to implement the mechanisms.

I also documented my already made changes in my github branch, like the
assertHTMLEqual method and more. I've also changed assertTemplateUsed to work
as context manager, which I will need to check what templates are touched
during the form rendering. I'm currently working on the code that will
actually render the form in the end but not on the form tags themselves, since
their API is still under discussion.

I will look over the mailinglist thread tomorrow, trying to get to a
conclusion and will start then writing documentation for the form tags.

[1] 
http://groups.google.com/group/django-developers/browse_thread/thread/3791152616fd95ae


btw: I will use this thread for my following weekly updates to unclutter
the mailinglist timeline a bit.

--
Servus,
Gregor Müllegger

-- 
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: Form Rendering API Proposal

[Gregor Müllegger]

Hi Chris,

2011/6/27 Chris Beaven :
> How do I override a field's label or help text?
> Specifically, help text may need to look something like: [[Can this person
> manage {{
> site.name }}?]]

This isn't addressed with the proposed template tags. You can still write out
a single row by hand if you need to tweak it in the low level details. I know
this is not ideal and exactly what we want to avoid with the new rendering.
Because of this I will try to design the code that spits out the form in the
end to be very modular. Basically it should be possible in the end to have
your own "formconfig" template tags that change the rendering a bit, like
changing a label or the help text (label is also my sample usecase).

However I think these templatetags could go into a thirdparty app. First
reason is to show-case that thirdparty rendering modifications are possible,
second to not clutter the builtin tags with too many possibilities. I would
like more to provide a framework for rendering, than all the tiny details you
propably could plugin into it your self.

BTW: even without the thirdparty apps it's already possible to change the
label for a field in an (somehow) easy way. Just extend from the row template
you use for your other rows in the form and override the {% block label %}.

Another option is to have something like this in your row template:

{% firstof label field.label %}

label is usually not in the row's scope so field.label is choosen. Now you can
modify the label with:

{% formrow myform.field with label="My new label" %}

> How are HTML classes specified for rows which are required / contain errors?
> (and one more slightly obscure one, probably out of scope...)

This can be achieved in the row template:



> How does a row know whether it contains HTML block elements?
> For example, a "p" row needs to render differently if it contains HTML block
> elements, such as a field represented as an unordered list of checkboxes.

This is not addressed, and I have no clue how we should do this -- or if we
should do this at all :o)

2011/6/27 Chris Beaven :
> Oh, and one more critical one:
> How does the form in python have knowledge of the widget which the field was
> rendered with as picked by the template?
> This is critical since building the form's data requires using the widget's
> value_from_datadict.

I think thats conceptually not possible. We simply can change the widget during
template rendering time, which makes it impossible to decide in the python
code with which widget we end up. And theoretically we could even render the
form twice with different widgets. Or throw the rendered template away without
using the widget at all.

So I think we must make clear that the used widgets must be somehow
compatible. I agree that we need to document this in one or the other way.

--
Servus,
Gregor Müllegger

-- 
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: [GSoC form-rendering] Weekly Check-in

[Gregor Müllegger]

Hi,

I wrote mainly documentation in the last week for how to use the new form
rendering as well as references in the template tag listing. I've also
implemented the form, formrow and formfield tags, I thought we might want to
have something to play with sooner than later. The docs/tests etc can be found
in my github branch.

--
Servus,
Gregor Müllegger

-- 
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: [GSoC form-rendering] Weekly Check-in

[Gregor Müllegger]

Hi, Chris.

Seems that I'm now unemployed as GSoC Student,
looks like you already did all the work! ;-)

Besides this, great work. If I understand the source code right (haven't run
it yet), then it's already feature complete, isn't it?

I also like the idea of "extends", I will definitely bring this up to Carl's
attention. I don't know if it's in the core devs taste to change the meaning
of a {% block %} slightly in the context of a form tag.

I try to keep you posted.


2011/7/5 Chris Beaven :
> Hi Gregor, I've just put up a new version of django-forms [1] which 
> implements a similar version of the proposal with the main difference being 
> "extends". Take a look.
>
> 1. https://github.com/SmileyChris/django-forms

-- 
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: Form Rendering API Proposal

[Gregor Müllegger]

Hi Chris,

2011/6/29 Chris Beaven :
>>
>> I think thats conceptually not possible. We simply can change the widget
>> during
>> template rendering time, which makes it impossible to decide in the python
>> code with which widget we end up. And theoretically we could even render
>> the
>> form twice with different widgets. Or throw the rendered template away
>> without
>> using the widget at all.
>
> In this case, why do we even have this format: {% formconfig widget
> widgets.Textarea for "comment" %} and the terminology of widgets?
> It seems like that should really just boil down to {% formconfig field using
> "some/textarea.html" for "comment" %} and just referring to fields only. A
> widget to me encompasses the backend logic of decoding the data, etc.
> I think it'd be a great plus if we *could* make it work for different
> widgets. This would really give power to change forms dynamically at the
> template layer.
> I remember thinking a while ago about some kind of widget repository
> available to the templates, combined with a hidden input per field that
> could notify the python form of the alternate widget used (the hidden input
> only used if the widget differed than the default for that field). This
> would allow for the same form to be used with different templates which used
> completely different widgets.

So I spoke to Carl yesterday about some of the ideas you brought up and we
agreed on how we want to handle them :-)


You've mentioned if being able to change the widget in the template it would
be cool to let the python source also know which widget should then be used to
parse the data. My concern about this was that an HTML data value should not
be allowed to exchange code parts on the server. Sure we would limit that to
specific widget classes, but with that power in HTML you would be able to
break the server side code, either by being evil or not understanding widgets
in total.
The same of course is true if we just change the widget without letting the
python form know what is happening, this makes it also possible to break the
server … we talked then about what a widget actually is: It has two purposes,
first is parsing the data making it usable for the field, second is
representational -- rendering an HTML input that is compatible with the
widget's data format.

So we decided to skip changing a widget totally in the form rendering.
Displaying a form and anything else that happens in the template has a
representational purpose, so we saw it would be out of scope for the project.
However changing the template that is used to render a widget will of course
still be possible (also passing in extra arguments etc.)


Now that we drop the idea of exchanging widgets we also don't longer need the
widgets template variable that holds the possible widget implementations you
can drop in. But the formfields var would be left to decide cases like:

{% formconfig widget using "textarea.html" for formfields.CharField %}

We decided to drop that variable as well, replacing it with a string that can
match the class name of a field:

{% formconfig widget using "textarea.html" for "CharField" %}

We justified it because this concept of matching a string to python structure
already exists. Examples are {% load mytemplatelib %} that loads a file named
after the argument, or some app.Model arguments used in third party libs.
There might be the concern that "CharField" is ambiguous if some else also
implements a "CharField". But this might be even a feature … if someone
implements also a CharField it might be very similar to django's built-in
one, otherwise you would name it differently.

btw I also plan to use "field" as argument for formconfig instead of "widget"
to match more the {% form[row|field] %} tags:

{% formconfig field using "textarea.html" with placeholder="type here
…" for "CharField" %}


Now to your django-forms implementation that has the "extends" argument for
the {% form %} tag. I still totally like the idea behind that, but like I
already said in the other message -- it might be confusing to have two
different meanings of the block tag. Carl has the same opinion here so we
won't include that into our implementation.


Thanks a lot again for your input, it created some vital think processes for
me and resulted in good improvements on the proposal (hope you see it the
same). Keep posting.

--
Servus,
Gregor Müllegger

-- 
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: Form Rendering API Proposal

[Gregor Müllegger]

Hi Chris, thanks Carl,

2011/7/9 Carl Meyer :
> Hi Chris,
>
> On 07/08/2011 04:00 PM, Chris Beaven wrote:
>> ...
>> I guess this means that rendering a field as "hidden" in the template is
>> also out, since this needs to modify more than just the field's
>> representation (specifically, non_field_errors).
>
> Yes. I mean, you're fully free to render a field as hidden yourself (via
> template), but anytime you make a change in the HTML that implies any
> change in server-side data handling, you're on your own to figure out
> the right solution for your case (which is no different than now).

Hm, hidden fields are something that I have not taken into account after our
latest iteration. I think they are a bit special-cased and might need
attention even if we drop changing-the-widget feature. I think it is also
technically something different than just exchanging widgets since any form
field is already aware about how it can be rendered with a hidden widget. That
also solves the don't-break-my-python-from-the-template issue since we only
use the hidden widget which is supported by the normal form field. See the
"hidden_widget" attributes:

https://code.djangoproject.com/browser/django/trunk/django/forms/fields.py#L45

> ...
>
>>     Now to your django-forms implementation that has the "extends"
>>     argument for
>>     the {% form %} tag. I still totally like the idea behind that, but
>>     like I
>>     already said in the other message -- it might be confusing to have two
>>     different meanings of the block tag. Carl has the same opinion here
>>     so we
>>     won't include that into our implementation.
>>
>> (Note that 'extends' also applies the formconfig, row and field tags too)
>>
>> I understand the potential for confusion, but I think it really does
>> bring something big to the table which is unfortunate to miss out on.
>> For example, if I just want to customize one field template on a form
>> then without this I have to redefine the whole form template.
>> It also allows for complex redefinition of a field's label and help text
>> without having to redefine the entire field template.
>
> Why would you otherwise have to redefine the whole form template? A form
> template is a normal template; you can put blocks in it and have another
> form template extend it and override those blocks. I don't think it's
> onerous (in fact, I think it's clearer and more maintainable) to do this
> in a separate file rather than "inline" as your proposal does. And I'm
> strongly in favor of reusing existing template language features and
> conventions rather than inventing new and confusing syntax for "inline
> extends"; IMO redefining the meaning of {% block %} contextually is
> simply a non-starter due to the extra difficulty in quickly
> comprehending template structure.
>
> AFAICT, your proposal doesn't actually bring any new capabilities to the
> table, it just lets you do the same thing inline rather than in a
> separate form template file that you reference with "using".
>
>> Here's real-life example off the top of my head we had the other day. A
>> client had a multi-step registration form. Usually, our rows show a *
>> next to the label of required fields but all of the first step was
>> required so the client didn't want the stars to show. I envision this
>> would look like this in django-forms (lets assume we've customised
>> 'forms/field/base.html' to conditionally conditionally change the label
>> class or just conditionally add the * after it):
>>
>> {% form form extends "forms/p.html" %}
>>     {% block config %}
>>         {% formconfig field with required=0 %}
>>     {% endblock %}
>> {% endform %}
>>
>> What would this look like with the current form proposal?
>
> You would just create a template "forms/p-no-stars.html" (or whatever)
> that {% extends "forms/p.html" %} and overrides the config block in the
> same way, and then you'd just say {% form form using
> "forms/p-no-stars.html" %}.

Your example is already achieveable without introducing a new template:

{% form form using %}
{% formconfig field with required=0 %}
{% include "forms/p.html" %}
{% endform %}

This of course only works since you don't want to change actual markup from
"forms/p.html". Otherwise you must define a new template.

And because the following examples are the same ...

{% form myform using "forms/p.html" %}
{% form myform using %}{% include "form

Re: [GSoC form-rendering] Weekly Check-in

[Gregor Müllegger]

So I did most of the actual implementation work for the tags which were
proposed on the mailing list. Only some small bits are missing and some edge
cases needs to be tested. But I'm quite happy with the progress so far.

Next will be completing the documentation and going on to the second part of
the summer. I still need to decide with my mentor on what comes next. Taking
care of media rendering, dog-fooding the API in the admin etc...

--
Servus,
Gregor Müllegger

-- 
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: [GSoC form-rendering] Weekly Check-in

[Gregor Müllegger]

Unfortunately I was not very productive in the last week. The reason are the
three exams for this term that kept me busy. The second bad news is that I
will be on vacation for the next week.

So I will definitely need some serious sprinting after I'm back. The admin
will be mainly the target of that work. To dog-food the API, validating that
the API is flexible for all the usecases in the admin and to later benchmark
how the new rendering will influence the performance.

--
Servus,
Gregor Müllegger

-- 
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: [GSoC form-rendering] Weekly Check-in

[Gregor Müllegger]

So after the exams, vacation and a short illness have I completed a week of
productive work.

All the parts that were discussed in detail on the mailing list a while back
are implemented. The new rendering API is completely in place and well tested.
I've manly added more documentation in the last week on how to create custom
form layouts, the new template tags and the template based widgets.

Also work on the admin has started to dog-food the new form API, but this is
still far from finished yet. Add and change forms use the template based
rendering but that hasn't brought any real benefits yet. But it should be
possible to further refactor it to make some of the
django.contrib.admin.helpers.* classes superfluously.

I found some use cases that are not yet possible with the form rendering
template tags. The biggest issue is that it's not possible to exchange field
labels with translated text. Currently there is no way of storing a translated
string in the templates as variable, like {% trans "foo" as var %}

--
Servus,
Gregor Müllegger

-- 
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.

Should there be a "is" comperator: {% if A is B %}?

[Gregor Müllegger]

Hi,

I recently had the need to check for "value is not True" (as an identity
check, not
on equality) in django-floppyforms. The template should generate the HTML
attributes for an HTML element from a python dict, but leave out the
attribute
value if the dict's value is True. Like:

  {'required': True, 'name': 'fieldname'} => 

If there would be an "is" identity check in the Django template language it
would look like:

{% for name, value in attrs.items %} {{ name }}{% if value is not True
%}="{{ value }}"{% endif %}{% endfor %}

But since there is none, the if case looks now like this:

{% if value|stringformat:"s" != "True" or value != 1 %}

See:
https://github.com/gregmuellegger/django-floppyforms/blob/master/floppyforms/templates/floppyforms/attrs.html

The template previously checked with {% if not value %}, but that would
break if
you pass in the integer 1. Since "True == 1", but "True is not 1".


I do get why there is no "is" comperator in the DTL yet. It might be
confused
with the equality check by designers that don't know the underlying
concepts of
equality and identity. And I think that's totally reasonable.

However I still want to bring this up since there is this real usecase I
described above. Ofcourse I could introduce a custom filter or tag to
scratch
that itch, but IMO this is something very fundamental that I would expect
to have
as a python developer.

So here are a few solutions I can think of:

1. Have an "is" and "is not" comperator in the {% if %} tag. Could lead to
confusion.

2. Have a "===" and "!==" comperator in the {% if %} tag. This is something
nearer to
   Javascript than python and makes it clear that it's different to == but
would
   still confuse someone who did't read the DTL documentation.

3. Have a "is_identical" builtin filter. So it would be {% if not
value|is_identical:True %}.


My favourite is option 3. It's very readable and doesn't introduce possible
confusions for non-python programmers.

What is your opinion on this?


Gregor

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALjSGCPsE3TTr2zzkUZboADpSOCymCue1HVC_SqB6mLMfpfwWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should there be a "is" comperator: {% if A is B %}?

[Gregor Müllegger]

Hi,

thanks for your input. Unfortunatelly this would fail for int(0):

{'value': 0} => 

Gregor


2014-04-10 11:41 GMT+02:00 Tino de Bruijn :

> Wouldn't this be easier?:
>
> {'required': "", 'name': 'fieldname'} =>  />
>
> {% for name, value in attrs.items %} {{ name }}{% if value %}="{{ value
> }}"{% endif %}{% endfor %}
>
>
> Tino
>
>
> On Wed, Apr 9, 2014 at 11:53 PM, Gregor Müllegger wrote:
>
>> Hi,
>>
>> I recently had the need to check for "value is not True" (as an identity
>> check, not
>> on equality) in django-floppyforms. The template should generate the HTML
>> attributes for an HTML element from a python dict, but leave out the
>> attribute
>> value if the dict's value is True. Like:
>>
>>   {'required': True, 'name': 'fieldname'} => > name="fieldname" />
>>
>> If there would be an "is" identity check in the Django template language
>> it
>> would look like:
>>
>> {% for name, value in attrs.items %} {{ name }}{% if value is not
>> True %}="{{ value }}"{% endif %}{% endfor %}
>>
>> But since there is none, the if case looks now like this:
>>
>> {% if value|stringformat:"s" != "True" or value != 1 %}
>>
>> See:
>> https://github.com/gregmuellegger/django-floppyforms/blob/master/floppyforms/templates/floppyforms/attrs.html
>>
>> The template previously checked with {% if not value %}, but that would
>> break if
>> you pass in the integer 1. Since "True == 1", but "True is not 1".
>>
>>
>> I do get why there is no "is" comperator in the DTL yet. It might be
>> confused
>> with the equality check by designers that don't know the underlying
>> concepts of
>> equality and identity. And I think that's totally reasonable.
>>
>> However I still want to bring this up since there is this real usecase I
>> described above. Ofcourse I could introduce a custom filter or tag to
>> scratch
>> that itch, but IMO this is something very fundamental that I would expect
>> to have
>> as a python developer.
>>
>> So here are a few solutions I can think of:
>>
>> 1. Have an "is" and "is not" comperator in the {% if %} tag. Could lead
>> to confusion.
>>
>> 2. Have a "===" and "!==" comperator in the {% if %} tag. This is
>> something nearer to
>>Javascript than python and makes it clear that it's different to ==
>> but would
>>still confuse someone who did't read the DTL documentation.
>>
>> 3. Have a "is_identical" builtin filter. So it would be {% if not
>> value|is_identical:True %}.
>>
>>
>> My favourite is option 3. It's very readable and doesn't introduce
>> possible
>> confusions for non-python programmers.
>>
>> What is your opinion on this?
>>
>>
>> Gregor
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CALjSGCPsE3TTr2zzkUZboADpSOCymCue1HVC_SqB6mLMfpfwWA%40mail.gmail.com<https://groups.google.com/d/msgid/django-developers/CALjSGCPsE3TTr2zzkUZboADpSOCymCue1HVC_SqB6mLMfpfwWA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CANQFsQDXR7FcfdgaF4w6G_9uaS7e-W_Y7FnxG3%2BxFTR4h4n7OA%40mail.gmail.com<https://groups.google.com/d/msgid/django-developers/CANQFsQDXR7FcfdgaF4w6G_9uaS7e-W_Y7FnxG3%2BxFTR4h4n7OA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALjSGCOwL%3DvAD%2Bj3vRyNBFTjFOonHRzz9PebgSbBTuZsiQSERw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: #22383 Add the HTML5 required tag to the input fields which are required for database entry

[Gregor Müllegger]

I think adding the `required` attribute but ignoring the other possible
html form validations (like `min` and `max` [1] for  that are used
by the forms.IntegerField) seems a bit half-hearted.

My opinion is that having the required attribute is pretty cool, but should
come with all other possible validations baked in then.
django-floppyforms already includes those validations already in the HTML
output of forms and it turns out to be quite useful in many situations.
Even if you turn of the browser validation by adding the novalidate
attribute to the  tag, it's good to have this meta data in the HTML
representation, e.g. for styling.

Gregor

[1]
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms/Data_form_validation


2014-04-10 20:00 GMT+02:00 anubhav joshi :

>
>
> On Thursday, April 10, 2014 11:19:18 PM UTC+5:30, anubhav joshi wrote:
>>
>> A ticket has been opened asking to add HTML5 required tag in forms for
>> the fields which are required for database entry.
>>
>> Better wording:
> "required for database entry" --> fields have *required* attribute as
> *True*
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/f7f8a915-8cc4-4505-8bc3-770599afeb30%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALjSGCP3oS%2BmKRMs%3DJ%3D1z0R%2BcP7FNGfx%2B65%3DN9Pu44iJXkhVaw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Should there be a "is" comperator: {% if A is B %}?

[Gregor Müllegger]

Casting to strings would make this example work. But will break in other
cases:

dict((key, str(val)) for key, val in {'value': None}.items())
  => 

I don't want to say that this problem is impossible to solve without a "is"
check in the templates, I only want to point out that this basic comparison
that is very handy in python on many ocassions is not available in the
template. And having something like this in core might just make the
template language a bit rounder and nicer to use for pythonistas.

· Gregor ·


2014-04-11 7:44 GMT+02:00 Łukasz Rekucki :

> On 11 April 2014 01:11, Gregor Müllegger  wrote:
> > Hi,
> >
> > thanks for your input. Unfortunatelly this would fail for int(0):
>
> Not if you encode all values to strings before passing to the
> template, so it's "0" instead of 0.
>
> >
> > {'value': 0} => 
> >
> > Gregor
> >
> >
> > 2014-04-10 11:41 GMT+02:00 Tino de Bruijn :
> >
> >> Wouldn't this be easier?:
> >>
> >> {'required': "", 'name': 'fieldname'} =>  name="fieldname"
> >> />
> >>
> >> {% for name, value in attrs.items %} {{ name }}{% if value %}="{{ value
> >> }}"{% endif %}{% endfor %}
> >>
> >>
> >> Tino
> >>
>
> --
> Łukasz Rekucki
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAEZs-EL%2BNqWuo-F6AkAWCBb5rn_7GKGXkfD35uyfF%2Bqbvss5Sw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALjSGCNDMC1q7LhamQaf%3D9jEW0bXPn5gdpmDL88dVQgKsNb__Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.