#3400 -- ModelAdmin.list_filter improvements
A gentle reminder to anyone who would like to review the recent patch uploaded for #3400 [1]. I have come across quite a number of people who consider list_filter's current inability to span relationships (e.g. as search_fields can) to be one of the more obvious/annoying of Django's limitations and would love to see it implemented. [1] http://code.djangoproject.com/ticket/3400 -- 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: a new template algorithm
> I've just joined this group. The reason is that I've recently > developed a new django template system (and I'm still working on it) There's only one Django template system, but there is a lot of others excellent python template engines (Jinja, Genshi, Mako, etc.), you can release yours (which looks like the Tornado's template language) as a free software project different of Django, and this could be usefull to a lot of people. Florent -- 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: Any interest in adding a navigation helper to Django?
On Sat, Aug 28, 2010 at 12:32 AM, Yo-Yo Ma wrote: > I think the thing that would be helpful to most django users is bit > really a navigation helper per se. I think what I need could be solved > with a more generic tool. Russell, tell me what you think about > providing a way to make a view a "child" of another. I'm not speaking > in the CMS sense (e.g. /accessories/hair/brushes/) as this is very > proprietary and can be aconploshed using a number of different > algorithms (Django TreeBeard for example). I'm speaking in terms of > software views. (e.g. /configuration/settings/billing/), etc. I want > to have a way to know that I should show "settings" tabs when I'm at / > configuration/, and without having to create 2 new templates (one for > list and one for forms) for "configuration" that just overrides the > menu. This works until you have a lot of views and then it gets to the > point where you have 50 templates just for menus. Imagine a theme > update with that. What's your thoughts on that? django-treenav[1] accomplishes what you're looking for without proliferating a huge mess of templates and lives a perfectly happy life outside the django core. Tobias [1] http://code.google.com/p/django-treenav/ -- Tobias McNulty, Managing Partner Caktus Consulting Group, LLC http://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.
Re: a new template algorithm
2010/8/28 Alex Gaynor : > With all due respect: no. The template system is intentionally not > Python, this is a strong design decision and I see no compelling > argument against it here. If you're just generally interested in the > compilation of Django templates to PYthon (without changing the > current semantics) I suggest you take a look at : > http://www.mail-archive.com/django-developers@googlegroups.com/msg25147.html, > which was a GSOC proposal I wrote (and ultimately withdrew in favor of > my query-refactor work), it presents a method for translation of > Django templates into Python code, while maintaing the current > semantics. Frankly, this is not what I did and I'm not interested about that. > As a small sidenote, when proposing a change a patch should contain a > single change, rather than a number of unrelated ones. Thank you very much for the lesson But I already knew. It would have taken time to produce different patches and test every single one (as many of them are NOT unrelated) when what I just wanted to know was if you were interested in my template system, and this was only a demostration version. Then if you were interested, I would have refined the work and then produced the single patch. As a small sidenote, I was not proposing a change but something to add if you would have read carefully my email. As a second small sidenote, I'm glad that I didn't waste my time. Thanks, Gabriele -- 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: Statistic app. Any suggestion?
Hi, django-developers is group about developing django, not about developing our projects. Please ask your question on django-users. Thanks. On Sat, Aug 28, 2010 at 6:38 AM, Lucian Romi wrote: > I want to make a statistic. There is a float field in my model(table). > I want to use a chart to show what's the percentage in each range. > Any suggestion to make such and app that can fit into django model. Thanks. > > -- > 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: a new template algorithm
On Sat, Aug 28, 2010 at 11:47 AM, Gabriele Fantini
wrote:
> Hi,
>
> I've just joined this group. The reason is that I've recently
> developed a new django template system (and I'm still working on it)
> and I'm currently using it for my new sites.
> I hope this is the right place to discuss of such things.
>
> This is the basic idea of my templates:
>
> * The Template class turned into a Python code generator
> * The compilation of a template string (Template.compile_string
> method) consists in the generation of python code that when will be
> evaluated will generate the html source.
>
> Basic steps of the algorithm are:
> * When a template rendering is required, a new Template instance is created.
> * The __init__ method generates a python code, compiles it using
> compiler.compile (python compiled module) and stores the result in a
> class attribute `__compiled` (the standard Template class instead
> generates and store the nodelist)
> * As the rendering is requested the previously compiled python
> code is evaluated using builtin function `eval`, passing context as
> "globals" environment ( eval(compiled, context) ).
>
> Pros of this solution:
> * The implementation is clear and short; 250 lines of code do the magic
> All the statements are exactly the python statements
>
> * Python code and HTML/CSS/Javascript can be mixed together
>
> * No more need to extend with tags and filters; you can use all that
> python provides and extend with modules.
> You can do things like:
> 1) for statement example:
> {% for i in [1, 2, 3] %} {{i}}{% end %}
>
> 2)
> {% for k, v in {'a': 1, 'b': 2} %}
> {{k}} {{v}}
> {% end %}
>
> 3) import a module and use it
> {% import datetime%}
> {{ datetime.datetime.utcnow().isoformat() }}
>
> 4) define functions (and classes) and use it
> {% def myfunction(arg) %}
> return arg.lower()
> {% end %}
> {{ myfunction("TEST STRING") }}
>
> * The only things that were missing were the django specific
> statements (extends, block, ...)
>
> * A new "block" type called "fblock" as been introduced; it is like a
> block that can have arguments.
>
> Well, this is in brief the idea, it can do much more.
> I hope I explained it clearly.
> You can find attached the patch from the latest version 1.2.1 and also
> a test site that shows the power of this solution.
>
> The patch also include:
> 1) A bug fix for the makemessages: code syntax for the xgettext was
> Perl instead of Python
> 2) A compiled template cache
> 3) A few lines changes in order to obtain the exception class in the
> 500 error handler (so that the 500 page message can be exception
> dependent)
>
> If you find this interesting we can work to include it in the django
> repository as an alternative from the current template system.
> Otherwise I'll keep it for my own use.
> The template syntax has a few changes but the backward compatibility
> can be improved.
> If someone wants to try it and have problems or questions I'll be glad
> to answer to any question.
> I can send an already patched version if someone want it.
>
> Hope to have feedback soon,
> Gabriele
>
> --
> 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.
>
>
With all due respect: no. The template system is intentionally not
Python, this is a strong design decision and I see no compelling
argument against it here. If you're just generally interested in the
compilation of Django templates to PYthon (without changing the
current semantics) I suggest you take a look at :
http://www.mail-archive.com/django-developers@googlegroups.com/msg25147.html,
which was a GSOC proposal I wrote (and ultimately withdrew in favor of
my query-refactor work), it presents a method for translation of
Django templates into Python code, while maintaing the current
semantics.
As a small sidenote, when proposing a change a patch should contain a
single change, rather than a number of unrelated ones.
Thanks,
Alex
--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
--
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: Statistic app. Any suggestion?
On Sat, Aug 28, 2010 at 12:38 AM, Lucian Romi wrote: > I want to make a statistic. There is a float field in my model(table). > I want to use a chart to show what's the percentage in each range. > Any suggestion to make such and app that can fit into django model. Thanks. > > -- > 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. > > Hi Lucian, This mailing list is for discussing the development of Django itself, not development with Django. Messages like this can be sent to the django-users mailing list, or the #django channel on IRC. Thanks, Alex -- "I disapprove of what you say, but I will defend to the death your right to say it." -- Voltaire "The people's good is the highest law." -- Cicero "Code can always be simpler than you think, but never as simple as you want" -- Me -- 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.
Statistic app. Any suggestion?
I want to make a statistic. There is a float field in my model(table). I want to use a chart to show what's the percentage in each range. Any suggestion to make such and app that can fit into django model. Thanks. -- 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 Model Related Manager Enhancements
Hi Nowell, First off -- apologies for taking so long to get back to you. On Sun, Jul 11, 2010 at 10:54 PM, Nowell Strite wrote: > Hey Russ, > > In the Artist example there are actually two many to many fields > pointing to songs (songs, and best_songs) so currently when you call > artist.songs or artist.best_songs, a new related manager for the Song > model is created, however, it does know know from where it was > created, only that self.core_filters = > 'some_filter_to_return_the_desired_results'. Ideally, programatically, > a manager that can be assigned to any model, should be able to upon > being accessed in a related fashion, know the details of the calling > model, which currently is not the case. I'm not sure I necessarily agree with this last point. For one thing, it wouldn't be consistent with the rest of Django; a Field instance doesn't know which model it belongs to, for example. The field contains everything it needs to know in order to format/handle data; it knows everything about itself; but it knows nothing about where it is being used. > For an example of the use case for why I want to access this type of > meta-data dynamically you could take a look at > http://github.com/nowells/django-versions/blob/master/versions/managers.py. > The basic case here is that I need to version the state of models and > their relationships. In order to be able to do that, I rely on when > you access a related manager (i.e. artist1.songs) that the resulting > manager, can then filter and alter the results to return the state of > the manytomany relationship based on what object is calling it (in > this case, at revision 1 of the artist object, it may only have had 5 > songs, and 1 best song, but at revision 10, it may have had 50 songs > and 5 best songs). So my desire would be that when I call > artist1.songs, the songs related manager knows from where it is being > called, and can interrogate arbitrary metadata about the calling > object, and alter it's behavior accordingly. > > I hope that I didn't dive too deep into my current use case, since > that use case if fairly complex. > > Does that make sense? I think I understand the use case, but I'm not sure I agree that the metadata you're expecting should be exposed in the way you describe. My take on your situation is that you're not really capturing the state of the manager, because the manager by itself doesn't have state. It's been constructed with the variables it needs to know about in order to execute the appropriate queries to add/remove objects from the relations that it represents. However, it's ultimately just a way to wrap functionality into an object that behaves a bit like an attribute. The object with state is the instance; that's the thing that should be versioned, and the metadata you need is already available there. The best analogy I can think of is the following: class MyObject(object): @property def foo(self): return 'bar' foo is a property of MyObject instances; it exists, but it doesn't really have state outside the context of a specific object instance. It doesn't embody anything about MyObject by itself. If you were going to record the state of MyObject, you might use foo to determine that state, but you wouldn't really be recording the state of an instance of foo. Does that make any sense? Or have I missed the point again? Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
