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
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 yo
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
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ü
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, 2
d 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" mechan
.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
unk: 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.
cket 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
g 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...@g
log/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 m
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
orian. 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 i
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 tic
xperts 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
&
ing 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
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 si
Admin 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 d
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
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 need
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
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 Germ
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
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 act
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:
>
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.
>>
>>
>> GS
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 devel
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 si
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 dro
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 y
regmuellegger/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
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 samp
(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. T
Fform-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-deve
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. Bu
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
Fform-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" gr
d 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-developer
s.
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('co
...
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.
>
>
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.
--
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 layo
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" gro
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
.? 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=&
menting 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!
>
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 bec
t 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:
on 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 sub
th 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
c 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 e
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 th
uot; 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 l
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.h
rt 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 pos
et 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
&q
eld
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.
T
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':
t;
> {% 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 i
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 v
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 :
>
61 matches
Mail list logo
