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

l.com>: > On 11 April 2014 01:11, Gregor Müllegger <gre...@muellegger.de> 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 &quo

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

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

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

or name, value in attrs.items %} {{ name }}{% if value %}="{{ value > }}"{% endif %}{% endfor %} > > > Tino > > > On Wed, Apr 9, 2014 at 11:53 PM, Gregor Müllegger <gre...@muellegger.de>wrote: > >> Hi, >> >> I recently had the need to check for &qu

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

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

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

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 th

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

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

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

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

Re: Form Rendering API Proposal

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

Re: Form Rendering API Proposal

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

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

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

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

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

Re: Form Rendering API Proposal

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

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

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

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

cludes 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/37

Re: Form Rendering API Proposal

n 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

Re: Form Rendering API Proposal

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 rece

Re: Form Rendering API Proposal

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 unsubscr

Re: Form Rendering API Proposal

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

Re: Form Rendering API Proposal

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

Re: Form Rendering API Proposal

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

[GSoC form-rendering] Weekly Check-in

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

Re: Ability to change dismissRelatedLookupPopup on my own callback function

... 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" <harrislapir...@gmail.com> wrote: > I think this is a great idea! I would cer

Re: Better error message for django.core.urlresolvers.reverse

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 <webfact...@tomviner.co.uk>: > Hi, > > This is the current error message when a url name or argument doesn't > exist: > >>&g

RFC: Templatetag API for form rendering - Second Edition

. :-) -- 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...@google

[GSoC form-rendering] Weekly check-in 1.0

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

Re: RFC: Templatetag API for form rendering

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

Re: RFC: Templatetag API for form rendering

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

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

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

RFC: Templatetag API for form rendering

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

Re: Re : [GSoC form rendering] Weekly check-in -1.0

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

[GSoC form rendering] Weekly check-in -1.0

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

[GSoC form rendering] Weekly check-in -3.0

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 f

Re: [GSoC] Revised form rendering

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

Re: [GSoC] Revised form rendering

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

Re: [GSoC] Revised form rendering

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

Re: [GSoC] Revised form rendering

Hi, 2011/4/2 Russell Keith-Magee <russ...@keith-magee.com>: > On Fri, Apr 1, 2011 at 11:57 PM, Gregor Müllegger <gre...@muellegger.de> > wrote: >> I suggest reading this proposal online: https://gist.github.com/898375 >> It's exactly the same as below but forma

Re: [GSoC] Revised form rendering

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,

Re: Revised form rendering

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

Re: [GSoC] Revised form rendering

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

[GSoC] Revised form rendering

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

Re: Proposal: switch to HTML5 for bundled templates

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

"sl" as language code for slovenian translation incorrect?

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

Re: contrib/admin/validation.py

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 <true.chesh...@gmail.com>: > There is a file called "validation.py&q

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

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

Re: New context template tag

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

Re: Django Security

cure 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

Re: Patch: Indefinite args for simpletags and inclusion tags

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 <stephen.r.burr...@gmail.com>: &g

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

. 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 <djfis...@gmail.com>: >> This

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

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

Re: Django and the Eyjafjallajökull eruption

010/django-admin-read-only-permission/ -- Servus, Gregor Müllegger 2010/7/2 Josh Ourisman <j...@joshourisman.com>: > 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 u

Re: Cleanup Signal

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

[1.3 Proposal] Cleanup Signal

?) -- 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-developer

Re: django.contrib.admin.ModelAdmin.formfield_for_manytomanyfield

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

Re: Proposal: {% include_partial %} template tag

tml" 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 <burc...@gmail.com>: > I'

Re: Feature idea

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 <ja...@jacobian.org>: > Aat EuroDjangoCon Russ and I discussed a

Re: Feature idea

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 <digitalx...@gmail.

Re: Feature idea

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

Re: Proposal: Replace django.contrib.formtools.wizard

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,

Re: django template revision (for 1.4?)

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

Re: Process discussion: reboot

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