Re: Decision for ticket #6362 - Remove blank spaces with strip when validating the data

[burc...@gmail.com]

Hi Dmitry,

I think we could have combination of "validators" + "processors":
they will return either exception or cleaned value.

For example,
SomeField(cleaners=[clean_and_validate_email()])

Did you mean exactly this or rather separated SomeField(validators=[...],
processors=[...]) ?

On Mon, Jul 11, 2011 at 6:31 PM, Dmitry Gladkov wrote:

> I don't see what's wrong with 'strip' attribute for models.Field,
> we've already non database-related 'blank' attribute, but I agree that
> it does not solve the general problem.
>
> What I'm thinking about is something like django.core.validators [1],
> but called 'processors' with the only and main difference that
> processor returns value which gets passed to the next processor in
> chain.
>
> I'm not sure that it plays nice with existing clean_[fieldname]
> methods and that 'processor' is a good name either, but I'd like to
> hear what do you think about this idea.
>
> Thanks.
>
>
> [1]
> https://docs.djangoproject.com/en/dev/ref/forms/validation/#using-validators
>
>
> --
> Best wishes,
> Dmitry Gladkov, mailto:dmitry.glad...@gmail.com
>
> +380 91 303-37-46
>
>
>
> On Mon, Jul 11, 2011 at 12:26 AM, Chris Beaven 
> wrote:
> > To clarify, didn't even notice we were talking about models.Field, I'm +0
> > for a 'strip' attribute on the form's field, nothing on the model.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django developers" group.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msg/django-developers/-/r9DLUCsK6rUJ.
> > 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.
>
>


-- 
Best regards, Yuri V. Baburov, 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-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: Consistent exception handling in templates.

[burc...@gmail.com]

Could we summarize in few words?

   | DEBUG (development)   | not DEBUG (production)
TEMPLATE_DEBUG | raise TemplateSyntaxError | ?
not  TEMPLATE_DEBUG| ? | ?

On Sat, Jul 9, 2011 at 12:53 PM, Tai Lee  wrote:
>
>
> On Jul 9, 12:24 pm, Karen Tracey  wrote:
>> I'm strongly against that idea. Swallowing errors makes it incredibly
>> difficult to debug errors. I would prefer for the `TEMPLATE_DEBUG`
setting to
>> turn off much of the error-silencing currently done in template
processing.
>> Yes, that means different behavior during development compared to
>> production. But running with DEBUG (template or otherwise) on IS
different
>> from production, that's a given. And it this case it would allow for more
>> effective development since errors wouldn't be hidden away in nearly
>> impossible-to-find places. In my mind that's a tradeoff well worth
making.
>>
>> See ticket #13167 for one example of where "template errors" have not
been
>> silenced since before 1.0. If that case is to be be "fixed" now, I would
>> very much want that silencing to ONLY happen when TEMPLATE_DEBUG is
False.
>> In my opinion silencing these during development would be a huge step
>> backwards.
>
> I think we are in agreement here. Swallowing errors makes it
> incredible difficult to debug errors. I would like to see the
> circumstances when exceptions are swallowed be more clearly defined,
> and ensure that only exceptions that are expected to be swallowed, are
> swallowed. If we can do that, then there should be no need for the
> behaviour to change based on the `TEMPLATE_DEBUG` setting.
>
> The problem with the inconsistent behaviour associated with this
> setting is exceptions that are expected to be swallowed, that we want
> to be swallowed, are not being swallowed in some cases when
> `TEMPLATE_DEBUG = True`. This can make it impossible to access some
> URLs on a website where such a condition is present, even though there
> is no actual error and the exception is expected to be silenced. It
> also results in some exceptions being transformed into
> `TemplateSyntaxError` sometimes, and the true exception raised other
> times.
>
> See ticket #16147 for an example where `TemplateDoesNotExist` is
> raised when the template DOES exist, because a template tag inside the
> template being loaded raises `TemplateDoesNotExist` at compile time,
> only when `TEMPLATE_DEBUG = True`.
>
> This can make it impractical to develop locally with `TEMPLATE_DEBUG =
> True`, because it can prevent access to working pages, which means you
> miss out on all the enhanced debugging that `TEMPLATE_DEBUG = True`
> provides when you encounter an actual error that needs developer
> attention.
>
> With the intent being that template authors should not be able to
> trigger HTTP 500 errors on a production site, couldn't we achieve that
> by silencing exceptions raised when an invalid argument was passed to
> a template tag (e.g. `ValueError` or `TypeError` in the template tag
> code), but allowing exceptions raised in the code for the object that
> was passed in to the template tag as an argument?
>
> For example, if an object that calculates and returns a number when
> evaluated is passed to `{% widthratio %}`, but there is a bug in the
> code of that object and it raises some kind of exception when
> evaluated, that should not be silenced. It should bubble up so that
> the developer is alerted to a problem in the code for that object (not
> an error that the template author has made by passing an invalid
> argument). However, if there was no exception raised in evaluating the
> object, but it simply returned something other than a number, then
> that should behave the same as if an empty string or missing template
> variable was passed in and no exception should be raised.
>
> I think that a `TemplateSyntaxError` should be raised at compile time
> if an invalid template tag is used (unknown, too few or too many
> arguments). The `render()` function for a template tag should silence
> exceptions raised when arguments with the incorrect type or value are
> provided, but should not silence exceptions raised when evaluating the
> arguments themselves (or properties on the arguments).
>
> Cheers.
> Tai.
>
> --
> You received this message because you are subscribed to the Google Groups
"Django developers" group.
> To post to this group, send email to django-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.
>
>



-- 
Best regards, Yuri V. Baburov, 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-developers@googlegroups.com.
To unsubscribe from this 

Re: Named tuples queryset

[burc...@gmail.com]

I was told that for Python 2.5 nametuples "emulation" is 8 times
slower than regular tuples and dicts.
That's why I'm interested in benchmarks. If it's significantly slower
(at least for Python 2.4 and 2.5), this should be mentioned in docs.

On Mon, Jul 4, 2011 at 5:19 PM, Paul Miller <paulmi...@me.com> wrote:
> Hi Yuri,
>
> I have not tested them for speed, but:
>
> - Named tuples have no instance dictionary, so their instances take no more 
> space than a regular tuple (for example, casting thousands of sql records to 
> named tuples has zero memory overhead).
> - They also use C-speed attribute lookup using property() and itemgetter()
>
> I don’t really think that speed of collection (which is built into python 
> 2.6+) is much slower than dicts etc.
>
>
> On Jul 4, 2011, at 7:41 AM, burc...@gmail.com wrote:
>
>> Hi Paul,
>>
>> Is it correct that nametuple construction is much slower than for
>> normal ones or is this true only in older python versions?
>>
>> On Mon, Jul 4, 2011 at 1:47 AM, paulpmillr <paulpmi...@gmail.com> wrote:
>>> Hello.
>>>
>>> I've added an implementation for named tuples query set, see
>>> https://code.djangoproject.com/ticket/15648
>>>
>>> - Named tuples could be iterated over with order saving (like lists /
>>> tuples).
>>> - Properties there could be accessed with dot notation - post.topic
>>> (almost like dicts).
>>> - They could be converted both to dicts and lists
>>> - Easy debugging (pros over queryset.deferred())
>>> - I've provided a fallback implementation of named tuple for python
>>> 2.5 users
>>> - Tests are there too.
>>>
>>> Named tuples eliminate neediness in values & values_list because they
>>> have all their features.
>>>
>>> What do you think about it?
>>
>> --
>> Best regards, Yuri V. Baburov, 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-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.
>
>



-- 
Best regards, Yuri V. Baburov, 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-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: Named tuples queryset

[burc...@gmail.com]

Hi Paul,

Is it correct that nametuple construction is much slower than for
normal ones or is this true only in older python versions?

On Mon, Jul 4, 2011 at 1:47 AM, paulpmillr  wrote:
> Hello.
>
> I've added an implementation for named tuples query set, see
> https://code.djangoproject.com/ticket/15648
>
> - Named tuples could be iterated over with order saving (like lists /
> tuples).
> - Properties there could be accessed with dot notation - post.topic
> (almost like dicts).
> - They could be converted both to dicts and lists
> - Easy debugging (pros over queryset.deferred())
> - I've provided a fallback implementation of named tuple for python
> 2.5 users
> - Tests are there too.
>
> Named tuples eliminate neediness in values & values_list because they
> have all their features.
>
> What do you think about it?

-- 
Best regards, Yuri V. Baburov, 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-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: Removal of DictCursor from raw query.. why??

[burc...@gmail.com]

Hi Cal,

Why not just put your helper to django snippets?

On Fri, Jun 17, 2011 at 12:25 AM, Cal Leeming [Simplicity Media Ltd]
 wrote:
> Okay, fair enough.
> At the very least, would you accept a documentation patch which would guide
> other users who come up against this same problem? Maybe it's own little
> space near the raw() stuff, which shows the example code for dictfetchall()
> but with a disclaimer saying YMMV??
> Cal
> On Thu, Jun 16, 2011 at 6:14 PM, Alex Gaynor  wrote:
>>
>>
>> On Thu, Jun 16, 2011 at 10:10 AM, Cal Leeming [Simplicity Media Ltd]
>>  wrote:
>>>
>>> In fact let me extend off this a little further.
>>> If I was to provide a code and documentation patch, which allows for an
>>> easy way to return back values with their field names (via a simple
>>> field_names=True), would you guys be willing to consider it for the core?
>>> Cal
>>>
>>> On Thu, Jun 16, 2011 at 6:07 PM, Cal Leeming [Simplicity Media Ltd]
>>>  wrote:

 @Andy / @ Alex:
 Yup, I know how to get this, but the point is, it took me 30 minutes of
 searching to find this information out.
 What I'm asking, is for consideration of an *EASY* way to get this
 format, via something like cursor.fetchall(field_names=True), or
 cursor.dictfetchall(), and for that feature to be well documented.


 On Thu, Jun 16, 2011 at 4:42 PM, Andy Dustman 
 wrote:
>
> You can do something like:
>
> for row in cursor:
>    dictrow = dict( (d[0], c) for d, c in zip(cursor.description, row) )
>
> (izip may be better than zip. Your call.)
>
> Or for the whole result set:
>
> result = [ dict( (d[0],c) for d, c in zip(cursor.description, row) )
> for row in cursor ]
>
> On Thu, Jun 16, 2011 at 10:03 AM, Cal Leeming [Simplicity Media Ltd]
>  wrote:
> > Okay, let me put it another way.
> > Are there any plans to give developers an easy way to retrieve values
> > from a
> > cursor.fetchall(), in a DictCursor style?
> > Default: ((Decimal('0'), Decimal('52'), Decimal('4159'), 9998L),)
> > What I'm looking for:
> > [{
> >  'f1' : Decimal('0'),
> >  'f2' : Decimal('52'),
> >  'f3' : Decimal('4159'),
> >  'f4' : 9998L
> > }]
> > Maybe something like cursor.fetchall(field_names=True), or
> > cursor.dictfetchall() - which is what the removed function did.
> > Cal
> > On Thu, Jun 16, 2011 at 2:54 PM, Luke Plant 
> > wrote:
> >>
> >> On 16/06/11 14:10, Cal Leeming [Simplicity Media Ltd] wrote:
> >> > Okay, er.
> >> >
> >> > In reference to the original problem (cursor's not default to
> >> > DictCursor), thus no field names are returned, is there a specific
> >> > reason for this? If not, I'll probably raise a ticket to have it
> >> > considered for change.
> >>
> >> I'm not sure exactly what you are asking, because this is about
> >> default
> >> behaviour. The choice of a default is usually made according to what
> >> is
> >> thought to be the most useful, or according to the way it happens to
> >> have been done in the past.
> >>
> >> I also don't know what exactly you are suggesting. Our backwards
> >> compatibility policy means that we aren't going to change the
> >> default,
> >> unless other people's code is going to work transparently (which
> >> wouldn't be the case here), so it doesn't really matter what the
> >> original reason was, if there was one. If you are suggesting that we
> >> add
> >> some functionality to make use of DictCursor more useful, then
> >> certainly
> >> the suggestion is valid.
> >>
> >> Regards,
> >>
> >> Luke
> >>
> >> --
> >> The probability of someone watching you is proportional to the
> >> stupidity of your action.
> >>
> >> Luke Plant || http://lukeplant.me.uk/
> >>
> >> --
> >> 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 

Re: ImportError catching in urlresolvers.py

[burc...@gmail.com]

Hi Russell,

and what do you say about showing call stack properly?

The problem is not ViewDoesNotExist itself, but throwing away useful traceback.

If we do instead:
import sys
try:
self._callback = get_callable(self._callback_str)
except ImportError, e:
mod_name, _ = get_mod_func(self._callback_str)
raise ViewDoesNotExist("Could not import %s. Error was: %s" %
(mod_name, str(e))), None, sys.exc_info()[2]

This way we will not only see not only exception where was required
module that was not imported, but also how it was attempted to be
imported -- often there's cyclic imports, few other imports or
initializations causing other imports, which are hidden with simple
raise.

Few exceptions wrappers patched in my fork:
https://github.com/buriy/django/commit/72b7a7350022a4a0a9cb1f01be62b117dedf89e2.

On Wed, Jun 15, 2011 at 11:46 AM, Russell Keith-Magee
 wrote:
> On Wed, Jun 15, 2011 at 11:51 AM, David Cramer  wrote:
>> This is currently a problem all over in the Django codebase, and I'd
>> love to see a generic/reusable approach at solving this everywhere.
>
> We already have a generic/reusable approach -- it's just not used
> everywhere that it could be used.
>
> Almost all the places that we are catching ImportError, we're using it
> as part of an implementation of module discovery or dynamic loading.
> In the case of RegexURLPattern, it's the resolution of a string-based
> view specification to a view callable. Catching ImportError is the
> easiest way to establish that a named module doesn't exist, and
> assuming that the code is otherwise sound, it's 100% accurate.
> However, that's a big assumption that doesn't play out in reality, and
> so "couldn't import module due to error in code" errors get confused
> with "module does not exist" errors, leading to the confusion reported
> by the original message.
>
> This is a case where we need to do better at eating our own dogfood.
> Wherever we are using the ImportError trick to catch 'specified module
> does not exist', we should be using a combination of
> django.utils.module_loading.module_has_submodule and
> django.utils.importlib.import_module. Any patch implementing this
> pattern (wherever it occurs) would be looked upon favourably for
> trunk.
>
> 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-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.
>
>



-- 
Best regards, Yuri V. Baburov, 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-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: Django Error Display Page

[burc...@gmail.com]

Hi Mateusz,

I think, adding a link at top, getting you to the end of traceback
would be suitable and would work 96% of times.

e.g, top line with exception type and URL could be a link moving you
to the end of traceback, where the exception happened.

What do you think?

Smart (colored) traceback could change that to moving to the last
piece of code which is not django code, but to be really usable, one
would have to customize it (i.e, to add info what 3rd-party packages
you use), which I feel is wrong.
Tabs would also have this problem, and also that without django lines
traceback would be much less readable.

On Wed, Jun 8, 2011 at 11:44 PM, Mateusz Harasymczuk
 wrote:
> Colored output of the trackeback does not solve my problem of scrolling few
> screens in order to find whats happening, or use cmd-F key to quick jump.
> I think this is not a good way to do this.
> What's I am thinking is a tabs at the top which manipulates with visibility
> of certain divs of error page.
> A quick temporary fix, before complete redesign of error page.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/d0F2R2NvWkJNQ3NK.
> 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.
>



-- 
Best regards, Yuri V. Baburov, 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-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

[burc...@gmail.com]

On Sat, Apr 2, 2011 at 10:45 PM, Russell Keith-Magee
 wrote:
> Secondly, it may be possible to play a trick on the template compiler.
> Jonas Obrist suggested this trick to me at Djangocon (US) last year;
> however, I haven't had a chance to dig into it any more.
>
> The trick goes something like this:
>
> When you parse a template tag like an {% if %}, the template parser
> scans forward until it reaches an {% endif %}. All the node content
> that is discovered is then provided to the if node as the subtemplate
> for the if.
>
> However, there's no specific requirement that you need to parse until
> you reach a specific tag -- you could just scan to the end of the
> document, and treat the rest of the document as if it were the nested
> content of an if that runs to the end of the page.
>
> So -- you should be able to write a "CSS" template tag that reads to
> the end of the template, and in the process, discovers all the {% form
> %} nodes on the template. From that, you can determine all the CSS
> requirements that your HTML document has.
>
> It requires a bit of a twist in the document tree -- the entire
> document effectively becomes a child of the CSS node in the template
> -- but it should allow you to get access to form rendering
> requirements before the form is actually rendered on the page.

Hi Russell,

Maybe a bit different thing, but if we're talking about forms media
customization,

I'd love the following solution implemented for css and js:
Tag {% media for form1 %} or {% css for form1 %} which would remember
all previous css/js references, displaying only ones not rendered yet.
For example, lots of my widgets are referring jquery js and css, and
there's no need to load jquery 10 times.
And if I loaded jquery before forms, I would like to be able to say
{% js "{{STATIC_URL}}/media/jquery-1.4.2.min.js" %} or {% css
"/media/css/jquery-tweaks.css" %}

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

-- 
Best regards, Yuri V. Baburov, 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-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: Migrating to class-based views and django.core.urlresolvers.reverse

[burc...@gmail.com]

Hi Daniel,

I'm not core developer, but I think
http://docs.djangoproject.com/en/dev/topics/http/urls/#defining-url-namespaces
should be used.

you can use reverse("yournamespace:someview"), and it's also cool to
do things like this in settings.py:

reverse_lazy = lazy(reverse, str)
LOGIN_REDIRECT_URL = reverse_lazy('yournamespace:your_main_page')

Perhaps it's not advertised as it should, and people continue to
invent their tricky namespace schemes...

On Tue, Dec 7, 2010 at 3:42 PM, Daniel Swarbrick
 wrote:
> I have been tracking the development of class-based views for a few
> weeks now, and am just starting to adapt some of my work-in-progress
> sites. This post is in a bit of a grey area between django-users and
> django-developers, but I'm curious what is suggested for sites that
> make heavy use of django.core.urlresolvers.reverse() and {% url %} in
> templates.
>
> Obviously with the old function-based views, we could simply do this:
>
> from django.core.urlresolvers import reverse
>
> def my_view(request):
>   ... do something useful ...
>   return response
>
> my_view_url = reverse('my_app.views.my_view')
>
> And likewise we could also reference that view using the {% url %} tag
> in templates.
>
> What is the recommendation for using reverse() and {% url %} when we
> migrate to class-based views? So fat the only solution I have come up
> with is naming the the URL patterns in urls.py, for example:
>
> urlpatterns = patterns('',
>    (r'^$', TemplateView.as_view(template_name='main/index.html'), {},
> 'home'),
> )
>
> In the above case, we can now reverse('home') or {% url "home" %} -
> but is this the only way? If so, one would have to give some careful
> thought to the names of the URL patterns, so that it was readily
> obvious what view each named URL actually was. For example, one might
> end up using names like "myapp.IndexView" - a pseudo-hierarchical
> naming scheme, to essentially bring us back to the place we were with
> function-based view names.
>
> I look forward to people's ideas about this...
>
> --
> 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, 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.

Re: RFC: #12815/#12816 -- TemplateResponse and render() shortcut

[burc...@gmail.com]

Hi Russell,

On Wed, Dec 1, 2010 at 4:03 PM, Russell Keith-Magee
 wrote:
> On Wed, Dec 1, 2010 at 3:55 PM, Mikhail Korobov  
> wrote:
>> Just for the record: I'm with Ivan here and think that
>>
>> from django.template.response import TemplateResponse
>> def my_view(request):
>>    return TemplateResponse(request, 'foo.html')
>>
>> is worse than
>>
>> from django.shortcuts import render
>> def my_view(request):
>>    return render(request, 'foo.html')
>>
>> I think that the cases where user should prefer 'render' returning
>> HttpResponse over 'render' returning TemplateResponse are rare so the
>> API by itself should suggest TemplateResponse. TemplateResponse is
>> more flexible and can provide a performance benefit (the template
>> rendering can be prevented in some cases).
>>
>> I don't see much value in adding 'render' shortcut that just use
>> RequestContext after TemplateResponse is introduced - one can still
>> use render_to_response if TemplateResponse is undesired and one
>> shouldn't use such 'render' in other cases.
>>
>> 'render' as alias for TemplateResponse seems fine for me: it is a
>> shortcut and it adds value by simplifying the API.
>
> I'd argue it doesn't simplify anything. It saves you a grand total of
> 10 characters (plus a couple more on import), but at the cost of the
> added complexity of having two ways of doing *exactly* the same thing.
> There is also a loss of explicitness -- there's no doubting what
> TemplateResponse will return.
>
> On the other hand, there *is* value in adding a render() shortcut --
> because there will be a subset of cases where a TemplateResponse isn't
> needed, but a HttpResponse with a RequestContext is.
>
> Yours,
> Russ Magee %-)

If I got it right, you want to make default shortcut render() that
would not use TemplateResponse.
But then how one will alter 3rd-party rendered responses in middleware?
I suggest people use TemplateResponse by default, and making render =
TemplateResponse just to be sure of this,
and render_to_response is "just 10 more characters" or a line to make
your own render that uses RequestContext.
I think, talking about "saving few characters" is not constructive.
So I'm talking about good architecture and code beauty.
I think your will to make render=render_to_response with
RequestContext means you want people to use render_to_response by
default.
But I'd like if we have a way to make template creators to use
TemplateResponse by default. That would encourage better view reusing
in django. And that means we would have render=TemplateResponse.

However, render_to_response has another feature -- ability to use
custom context, and the one real use case is using Context for Http500
when you can't rely on anything.

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

Re: contrib.sites and multitenancy

[burc...@gmail.com]

Hi Carl, Russell,

I think any settings.py option will help us a lot,

but doesn't the overall solution mean that one would still need to
have the Site model installed even if we use our custom callable?
I'd also like if someone could explain correct interfaces and if we're
going to change them.
Isn't Site/RequestSite the only possible interface right now?
The more I thinking on it, the more I see we have the same problem
like with the Users model:
the only way to write reusable 3rd party app is to do item_site =
ForeignKey(Site) which bounds us to the Site object.

Also, will the request be passed to SITE_ID if it become a callable?
If not, I'd like if we take get_current_site(request) instead of
Site.get_current(), and deprecate the last one.

On Sun, Nov 21, 2010 at 3:14 PM, Russell Keith-Magee
 wrote:
>
>
> On 21/11/2010, at 12:41 PM, Carl Meyer  wrote:
>
> Hi all,
>
> I've recently been exploring simple multitenancy options in Django
> using contrib.sites, and have some thoughts on how core could make it
> easier.
>
> ...
>
> A few options for how such a hook could be implemented:
>
> ...
>
> 1a) Same as above, but reuse SITE_ID; i.e. it can either be an
> integer, or a string path to a get_current_site function. It ends up a
> bit misnamed.
>
> This approach - or a variant of it - seems like the best idea to me. Rather
> than providing a custom hook for get_current_site(), I'd argue that we
> should make SITE_ID a callable that is used internally by
> Site.objects.get_current().
> My reason for this is to avoid confusion over Site.objects.get_current(). At
> present, it only returns the right answer if the Sites model is installed.
> However, it is a method on a model, so this makes a certain amount of sense.
> If the extension point is get_current_site(), we could end up in a situation
> where the method exists, but may give you the wrong answer if you have a
> custom get_current_site() method.
> So - I'd propose the following:
>  * add an optional request argument to Site.objects.get_current()
>  * allow SITE_ID to be a callable that accepts the request as an argument
>  * raise an error if SITE_ID is a callable, but Site.objects.get_current()
> is called without a request object being provided.
>  * get_current_site() remains the preferred public interface for getting the
> current site.
> Essentially, this just means changing line 18 of sites/models.py [1] to
> check for a callable, and invoke that callable if required.
> [1] http://code.djangoproject.com/browser/django/trunk/django/contrib/sites/models.py?rev=13980#L18
> The question this leaves is whether a SITE_ID callable returns an ID, or a
> full site object. I agree that returning an object from a method called _ID
> is less than ideal, but that's a relatively small wart given the corner that
> we're in, IMHO.
> The alternative, of course, is to completely
> deprecate Site.objects.get_current(), and use a new setting to configure
> get_current_site(). To be honest, this really wouldn't bother me either.
> This is the sort of area where a setting is the right solution, and
> deprecating Site.objects.get_current() avoids the confusion over the "right"
> way to get the current site.
> 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.
>



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

Re: making URL resolving/reversing gradually more flexible

[burc...@gmail.com]

Hi Sam,

On Fri, Nov 12, 2010 at 2:45 PM, Sam Lai <samuel@gmail.com> wrote:
> On 12 November 2010 19:14, burc...@gmail.com <burc...@gmail.com> wrote:
>> Ah, sorry, tl;dr happened to me in previous message.
>>
>> I used to do the following:
>>
>> alternatives = {'html': '/', 'xml': '.xml', 'json': '.json'}
>> for name, alt in alternatives.iteritems():
>>    urlpatterns += ('^newitems'+alt+'$', 'views.newitems', {'format':
>> name}, 'newitems-'+name)
>
> Then you're cluttering urls.py through code. You need to repeat that
> for every API-enabled URL.
You can hide this with your_patterns() method, or with your_reverse.
It won't be more complex than your URL fix.

>> You can make your own method that will do this.
>> Anyway, only your code can know how to select one of the suggested
>> alternatives for reverse, so your suggested approach has no
>> advantages.
>
> ... and that's the point. It is the pattern's job to suggest
> alternatives, not the resolver's.
Well, such change is meaningful, because of
bits = normalize(p_pattern)
lookups.appendlist(pattern.callback, (bits, p_pattern))
lookups.appendlist(pattern.name, (bits, p_pattern))

appendlist method call convinced me immediately.

>>>This approach requires no changes to existing urls.py
>> But you have to update all django 3rd party libraries to realize every
>> url pattern they use can have get_possibilities !
>
> How many third-party libraries out there use custom URL pattern
> classes, ones that don't subclass from RegexURLPattern?
>
> I doubt there are many. But to cater for this fact, the resolver can
> simply check for the existence of get_possibilities, and if it isn't
> there, revert to the existing behaviour. For example,
>
> if hasattr(pattern, 'get_possibilities'):
>    bits = pattern.get_possibilities()
> else:
>    bits = normalize(p_pattern)
>
>> And you now can't pass secondary pattern into django libs that are not
>> aware of your feature.
>
> Not sure what you're talking about here. I can't see how my changes
> will break anything, unless a library is using a URLPattern that
> doesn't extend RegexURLPattern. And again, as above, a small fix can
> solve that.
I was talking about reverse with more than one result to the same name.
But they do exist already!

> Just so I'm clear, this is a *backwards-compatible* change. Nothing
> should break if the above change is incorporated into the original
> proposal.
>
>> So, many-to-many relation between urlpatterns entry and view name only
>> complicates things.
>
> I am not suggesting a many-to-many relationship between urlpatterns
> and view names. Each urlpattern can still only match 1 view name. It
> is a many-to-one relationship. Not that this case already exists if
> you use ? in a regexp in a URL pattern.
First I thought you're going to return some instance with reverse
which has get_possibilities.
And you just want RegexURLPattern to register 3 usual regexes for you
instead of one.

Could you please create a patch now -- at least someone will use it.

Maybe you also thought of a patch for this specific case of simple
reversible ORs in the urls?
Examples: (a|b|c) and (?Pa|b|c)

>> On Fri, Nov 12, 2010 at 1:56 PM, burc...@gmail.com <burc...@gmail.com> wrote:
>>> Hi Sam,
>>>
>>> what's the problem with regexp = '^newitems'+SUFFIX+'$' where
>>> SUFFIX='(/|\.xml|\.json)' ?
>>>
>>> And if you need more shortcuts, there are surlex (
>>> http://codysoyland.com/2009/sep/6/introduction-surlex/ ) and
>>> alternatives.
>>>
>>> On Fri, Nov 12, 2010 at 11:25 AM, Sam Lai <samuel@gmail.com> wrote:
>>>> [First timer participating in the Django dev process, so apologies if
>>>> I have missed some protocol etc.]
>>>>
>>>> First up, this is not about adding an alternate URL
>>>> resolution/reversal method to the core; I've noticed a fair bit of
>>>> resistance to that.
>>>>
>>>> PROBLEM:
>>>> I want to make my website available via an API with URLs like this -
>>>> http://example.com/newitems/ => returns HTML
>>>> http://example.com/newitems.xml => returns XML
>>>> http://example.com/newitems.json => returns JSON.
>>>>
>>>> To represent this in urls.py, I have to either:
>>>> a) write a separate url entry for each one
>>>> b) write 2 url entries, one for newitems/ and another for
>>>> newitems\.(?P\w+). This is the better option, but still
>>>> annoying. Plus it forces my view to validate wh

Re: making URL resolving/reversing gradually more flexible

[burc...@gmail.com]

Ah, sorry, tl;dr happened to me in previous message.

I used to do the following:

alternatives = {'html': '/', 'xml': '.xml', 'json': '.json'}
for name, alt in alternatives.iteritems():
urlpatterns += ('^newitems'+alt+'$', 'views.newitems', {'format':
name}, 'newitems-'+name)

You can make your own method that will do this.
Anyway, only your code can know how to select one of the suggested
alternatives for reverse, so your suggested approach has no
advantages.

>This approach requires no changes to existing urls.py
But you have to update all django 3rd party libraries to realize every
url pattern they use can have get_possibilities !
And you now can't pass secondary pattern into django libs that are not
aware of your feature.

So, many-to-many relation between urlpatterns entry and view name only
complicates things.

On Fri, Nov 12, 2010 at 1:56 PM, burc...@gmail.com <burc...@gmail.com> wrote:
> Hi Sam,
>
> what's the problem with regexp = '^newitems'+SUFFIX+'$' where
> SUFFIX='(/|\.xml|\.json)' ?
>
> And if you need more shortcuts, there are surlex (
> http://codysoyland.com/2009/sep/6/introduction-surlex/ ) and
> alternatives.
>
> On Fri, Nov 12, 2010 at 11:25 AM, Sam Lai <samuel@gmail.com> wrote:
>> [First timer participating in the Django dev process, so apologies if
>> I have missed some protocol etc.]
>>
>> First up, this is not about adding an alternate URL
>> resolution/reversal method to the core; I've noticed a fair bit of
>> resistance to that.
>>
>> PROBLEM:
>> I want to make my website available via an API with URLs like this -
>> http://example.com/newitems/ => returns HTML
>> http://example.com/newitems.xml => returns XML
>> http://example.com/newitems.json => returns JSON.
>>
>> To represent this in urls.py, I have to either:
>> a) write a separate url entry for each one
>> b) write 2 url entries, one for newitems/ and another for
>> newitems\.(?P\w+). This is the better option, but still
>> annoying. Plus it forces my view to validate whether or not the format
>> value is acceptable (e.g. is either xml or json).
>>
>> I have to do this for every URL I wish to make available via an API,
>> bloating out my urls.py file. (I'm aware I can use the HTTP-ACCEPT
>> header instead, but there is a need to be able to force the response
>> format in the URL for certain uses.)
>>
>> MY DESIRED SOLUTION:
>> Subclass RegexURLPattern, and override the resolve method so that it
>> will replace a placeholder, e.g. (?#format), with the appropriate
>> regexps (/|\.xml|\.json). Effectively it will perform something
>> similar to this regexp instead -
>> ^newitems(/|(?P(\.xml|\.json))) where the list of accepted
>> formats will be defined in settings. This subclass will be returned
>> using an alternate url(...) call, e.g. murl(...).
>>
>> So my urls.py will look like -
>> urlpatterns = patterns('project.app.views',
>>    murl(r'^/(?P\d+)(?#format)$', AppView.as_view(),
>> name='app_view1'),
>> )
>>
>> (For completeness, the view is a CBV, and uses the format arg to
>> determine which template to render, and using what MIME type to
>> respond.)
>>
>> This is a proven way of extending the URL system, as demonstrated by
>> the various projects out there for alternative URL specification
>> syntaxes, e.g. django-easyurls.
>>
>> ROADBLOCK:
>> The issue with this solution is that while resolving will work fine,
>> reversing will not. The list of possible URLs for a particular view is
>> determined by _populate in RegexURLResolver, and is based on the
>> regexp pattern alone. Django doesn't support | in regexps
>> (understandably), and there is no way to supplant this with additional
>> regexps or possibilities at the moment, even though the infrastructure
>> is there during reversal.
>>
>> RESOLUTION - PHASE 1:
>> Because of the friction and work required to fully revamp the URL
>> resolution system, this phase is a short, simple fix that will suffice
>> for most cases where people want to extend the URL resolution system.
>>
>> Refactor out line 218 (in trunk) in django/core/urlresolvers.py:
>>
>> bits = normalize(p_pattern)
>>
>> ... into a separate method in RegexURLPattern:
>>
>> def get_possibilities(self):
>>    return normalize(self.regex.pattern)
>>
>> ... and replace line 218 in django/core/urlresolvers.py with:
>>
>> bits = pattern.get_possibilities()
>>
>> That's it. I'll create a patch for this later if the consensus is
>> positive. The above change allows subclassed RegexURLPattern cla

Re: making URL resolving/reversing gradually more flexible

[burc...@gmail.com]

Hi Sam,

what's the problem with regexp = '^newitems'+SUFFIX+'$' where
SUFFIX='(/|\.xml|\.json)' ?

And if you need more shortcuts, there are surlex (
http://codysoyland.com/2009/sep/6/introduction-surlex/ ) and
alternatives.

On Fri, Nov 12, 2010 at 11:25 AM, Sam Lai  wrote:
> [First timer participating in the Django dev process, so apologies if
> I have missed some protocol etc.]
>
> First up, this is not about adding an alternate URL
> resolution/reversal method to the core; I've noticed a fair bit of
> resistance to that.
>
> PROBLEM:
> I want to make my website available via an API with URLs like this -
> http://example.com/newitems/ => returns HTML
> http://example.com/newitems.xml => returns XML
> http://example.com/newitems.json => returns JSON.
>
> To represent this in urls.py, I have to either:
> a) write a separate url entry for each one
> b) write 2 url entries, one for newitems/ and another for
> newitems\.(?P\w+). This is the better option, but still
> annoying. Plus it forces my view to validate whether or not the format
> value is acceptable (e.g. is either xml or json).
>
> I have to do this for every URL I wish to make available via an API,
> bloating out my urls.py file. (I'm aware I can use the HTTP-ACCEPT
> header instead, but there is a need to be able to force the response
> format in the URL for certain uses.)
>
> MY DESIRED SOLUTION:
> Subclass RegexURLPattern, and override the resolve method so that it
> will replace a placeholder, e.g. (?#format), with the appropriate
> regexps (/|\.xml|\.json). Effectively it will perform something
> similar to this regexp instead -
> ^newitems(/|(?P(\.xml|\.json))) where the list of accepted
> formats will be defined in settings. This subclass will be returned
> using an alternate url(...) call, e.g. murl(...).
>
> So my urls.py will look like -
> urlpatterns = patterns('project.app.views',
>    murl(r'^/(?P\d+)(?#format)$', AppView.as_view(),
> name='app_view1'),
> )
>
> (For completeness, the view is a CBV, and uses the format arg to
> determine which template to render, and using what MIME type to
> respond.)
>
> This is a proven way of extending the URL system, as demonstrated by
> the various projects out there for alternative URL specification
> syntaxes, e.g. django-easyurls.
>
> ROADBLOCK:
> The issue with this solution is that while resolving will work fine,
> reversing will not. The list of possible URLs for a particular view is
> determined by _populate in RegexURLResolver, and is based on the
> regexp pattern alone. Django doesn't support | in regexps
> (understandably), and there is no way to supplant this with additional
> regexps or possibilities at the moment, even though the infrastructure
> is there during reversal.
>
> RESOLUTION - PHASE 1:
> Because of the friction and work required to fully revamp the URL
> resolution system, this phase is a short, simple fix that will suffice
> for most cases where people want to extend the URL resolution system.
>
> Refactor out line 218 (in trunk) in django/core/urlresolvers.py:
>
> bits = normalize(p_pattern)
>
> ... into a separate method in RegexURLPattern:
>
> def get_possibilities(self):
>    return normalize(self.regex.pattern)
>
> ... and replace line 218 in django/core/urlresolvers.py with:
>
> bits = pattern.get_possibilities()
>
> That's it. I'll create a patch for this later if the consensus is
> positive. The above change allows subclassed RegexURLPattern classes
> to alter what is returned as possible URLs from that pattern. I'm
> hoping this simple change can be made in Django 1.3.
>
> Of course, the possibilities returned still have to be regexps, which
> leads to phase 2...
>
> RESOLUTION - PHASE 2:
> The ultimate goal should be a URL resolution system that allows
> alternate URL spec syntaxes to be first-class citizens, allowing
> regexp based URL specs and say, URI Template specs to exist
> side-by-side.
>
> My plan would be to create an abstract base class for all URLPatterns,
> which RegexURLPattern will extend. The existing behaviour will mostly
> stay, except the get_possibilities from phase 1 will be deprecated in
> favour of a new reverse method. The reverse method will be called by
> the new universal URLResolver class for matches when reversing URLs,
> and if a match exists, that will be returned. During _populate(), the
> new universal URLResolver class will group URLPattern objects by view
> callback and name, instead of the output of
> get_possibilities/normalize.
>
> This approach requires no changes to existing urls.py; in fact, from a
> dev perspective, they would only notice the difference if they choose
> to use alternate URL spec syntaxes. The existing regexp system will
> work as it has always worked. And it makes sense that the URLPattern
> object is responsible for resolving and reversing itself, and not the
> resolver.
>
> Until this phase is reached, the API should be considered private so
> devs are on notice that things 

Re: Ticket #7817: Extending "with" and "include" tags.

[burc...@gmail.com]

On Wed, Nov 3, 2010 at 5:18 PM, Jannis Leidel <jan...@leidel.info> wrote:
> On 03.11.2010, at 12:01, burc...@gmail.com wrote:
>
>> Hi Jannis,
>>
>> On Wed, Nov 3, 2010 at 3:03 PM, Jannis Leidel <jan...@leidel.info> wrote:
>>> On 27.10.2010, at 09:46, SmileyChris wrote:
>>>
>>>> On Oct 27, 5:35 am, Łukasz Rekucki <lreku...@gmail.com> wrote:
>>>>> I would like to bring this up again, because this is something that
>>>>> would really improve readability of my templates. I'm mainly
>>>>> interested in ticket #7817 (the include tag changes), but extending
>>>>> "with" tag (ticket 9456) would keep things consistent.
>>>>
>>>> Here's a link to the ticket for the lazier ones among us:
>>>> http://code.djangoproject.com/ticket/7817
>>>>
>>>> The main decision which needs to be made is one of syntax.
>>>>
>>>> The current proposal uses:
>>>> {% include "name_snippet.html" with name="Joe" greeting="Hello" %}
>>>> but this introduces an inconsistency with the {% with %} tag.
>>>
>>> I'm feeling strongly against moving from the "value as name" to the 
>>> "name=value" notation, since I think the former is actually more readable 
>>> than the latter for the targetted audience (template authors).
>>
>> If you are not asking real people, it's a speculation anyway.
>
> Heh, so you are saying my gut feeling is speculative, I'm not sure what to 
> respond to that. In any case, you are implying that I'm not "real people" -- 
> what ever that is -- I can assure you that I use templates as a programmer 
> and a designer. In case you think "we programmers can do whatever we want, 
> the designer won't even notice the api change", I have to admit the designer 
> in me feels a little insulted.
>
> It does make a difference to use a mathamatical sign in a commonly used 
> aspect of the template language than prose.  Note, I'm not saying that I 
> disagree with getting rid of warts (#7817, #9456), but actually proposed a 
> compromise that was already mentioned by another core dev.
I also don't disagree, just not completely agree with your reasoning.

Sorry for being harsh. Just "my inner designer" gets confused when
someone calls "as" and "and" much useful for purpose of setting
variables rather than "=". Hm Maybe because HTML uses "=" for
setting attributes? :)

>>>> Consistency would be nice, but I think this starts to look a bit
>>>> confusing, static tokens outnumbering actual functional ones:
>>>> {% include "name_snippet.html" with name as "Joe" and greeting as
>>>> "Hello" %}
>>>
>>> Well, I think that's actually not a bad notation at all (if using the 
>>> correct order :), so for #7817 I propose the following syntax (as 
>>> analogously proposed by #9456 for {% with %}):
>>>
>>> {% include "name_snippet.html" with "Joe" as name and "Hello" as greeting %}
>
> --
> 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.

Re: Ticket #7817: Extending "with" and "include" tags.

[burc...@gmail.com]

Hi Jannis,

On Wed, Nov 3, 2010 at 3:03 PM, Jannis Leidel  wrote:
> On 27.10.2010, at 09:46, SmileyChris wrote:
>
>> On Oct 27, 5:35 am, Łukasz Rekucki  wrote:
>>> I would like to bring this up again, because this is something that
>>> would really improve readability of my templates. I'm mainly
>>> interested in ticket #7817 (the include tag changes), but extending
>>> "with" tag (ticket 9456) would keep things consistent.
>>
>> Here's a link to the ticket for the lazier ones among us:
>> http://code.djangoproject.com/ticket/7817
>>
>> The main decision which needs to be made is one of syntax.
>>
>> The current proposal uses:
>> {% include "name_snippet.html" with name="Joe" greeting="Hello" %}
>> but this introduces an inconsistency with the {% with %} tag.
>
> I'm feeling strongly against moving from the "value as name" to the 
> "name=value" notation, since I think the former is actually more readable 
> than the latter for the targetted audience (template authors).

If you are not asking real people, it's a speculation anyway.

I'm also target audience (since I write initial Django templates
structure for HTML from designer), even though I'm a programmer.
I think there are even more programmers than designers that use django
templates.
Our designer don't care at all, because she will just use any solution
to do her job.
So of two people, one voted for "=", second abstained from voting.

I think for most people "=" is slightly better than "as" because:
 - All of them had math classes at school and they know "=" already.
 - Not every Django template author knows English.

"Slightly" because:
   - they have to spend some minutes to understand "how the tag works"
anyway, and it's much more time than they would think of "what does
'=' do here" or "what does 'as' means here".
   - they just don't care. they didn't choose html, they didn't choose
css, they didn't choose django templates. it's so minor question.

Why I'm for "=":

I think, "and" + "as" are too verbose for this regular task.
They just make fast scanning through the template seeking for some
variables much harder and don't help at all.

>> Consistency would be nice, but I think this starts to look a bit
>> confusing, static tokens outnumbering actual functional ones:
>> {% include "name_snippet.html" with name as "Joe" and greeting as
>> "Hello" %}
>
> Well, I think that's actually not a bad notation at all (if using the correct 
> order :), so for #7817 I propose the following syntax (as analogously 
> proposed by #9456 for {% with %}):
>
> {% include "name_snippet.html" with "Joe" as name and "Hello" as greeting %}
>
>
> Jannis
>
> --
> 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.

Re: contrib.staticfiles app concerns

[burc...@gmail.com]

Hi Waldemar,

So, we agreed, it's not a problem with django, it's problem with those
3rd-party apps.
Perhaps, you can write emails to their authors now explaining your position?

Actually, it's not a problem that 70% of those apps are broken -- in
other areas, the percent of "wrong" solutions can be up to 90-100% ;)

On Sat, Oct 30, 2010 at 4:36 PM, Waldemar Kornewald
 wrote:
> On Fri, Oct 29, 2010 at 10:32 PM, Jacob Kaplan-Moss  
> wrote:
>> There's no way I'm adding text like that to the staticfiles
>> documentation. Not in a million years. It's confusing to me, and
>> *I've* been following this discussion. Can you imagine how confusing
>> that's going to be to people who *haven't*? The vast majority of users
>> aren't going to know what the heck an "asset manager" is, what this
>> "standards-complient" business is, or why they should care. They're
>> reading this document because they want to get a CSS file up onto a
>> production server somewhere. That's it.
>
> Why do you think was the patch named "ridiculous-patch.diff"? I'm
> trying to communicate the *problem* because you haven't understood
> that, yet. But for some reason you expect me to send the *solution*
> (that's why you ask for a patch). That makes no sense at all because
> you don't know what the *problem* is.
>
>> As far as I can understand from the vast reams you've written so far,
>> what you're basically saying is "if you use url() in a CSS file it
>> needs to point to an URL that actually exists." I'm pretty sure most
>> people are smart enough to figure that out.
>
> No, you're looking at this from the wrong perspective. When people use
> django.contrib.staticfiles then of course they will use URLs that
> exist. Anything else is ridiculous. Why would anyone write URLs that
> don't work? :)
>
> But is it so difficult to understand that a lot of developers use some
> *other* asset manager? More than 70% of those other asset managers
> *force* you to write *broken* URLs. Most asset managers are broken!
> The problem is not staticfiles, but the large number of broken
> 3rd-party asset managers.
>
> Why are they broken? Because they combine your files and once your
> files are combined the URLs suddenly work. IOW, those asset managers
> convert *broken* URLs into *working* URLs. That's their convention and
> their standard. Is this stupid? Yes. It's still reality. A very large
> number of developers use this stupid broken convention.
>
> Now what do you think, how likely is it that open-source developers
> will use such a *broken* asset manager (not staticfiles) and release
> *broken* CSS code that is *incompatible* with
> django.contrib.staticfiles? It's far too likely for Django to ignore
> this.
>
> This is the last time I try to explain this. As you said, let's just
> wait for the first users to report a bug. I hope that then you'll
> realize that Django's *3rd-party* asset managers have to be fixed, not
> staticfiles.
>
> I'll do my part and at least convert django-mediagenerator to a
> staticfiles-compatible URL scheme.
>
> Bye,
> Waldemar
>
> --
> Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source:
> http://www.allbuttonspressed.com/blog/django
>
> --
> 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.

Re: contrib.staticfiles app concerns

[burc...@gmail.com]

Hi Waldemar,

> A standard for a problem related to Django: How can we have reusable
> apps that come with media files? How is that possible if everyone uses
> a different asset manager?
Ok, this is a problem related to Django, but it shouldn't be solved
with scope of Django because nothing in Django depends on this
decision. Now it is better?

> Unless I've misunderstood something, the Django team added
> django.contrib.staticfiles exactly because this app is supposed to
> solve the reusable-apps-with-media-files problem. We need a standard
> URL rewriting scheme for this.
>> Related to your media compressor, i'd prefer not (2) or (4), i prefer
>> this one I described above:
>> 1. Your compressor starts after media is gathered with staticfiles
>> into a single place. (All relative paths are valid at this moment!)
>> 2. You read css files, transform their url paths to absolute, merge
>> files, and then write back into user specified directory with paths
>> rewritten as relative to merged files location.
>> 3. If you're copying images, you can put images to whatever folder you
>> want, but they should still work.
>> Your compressor should make it possible to work after your compression
>> if you'll just put that folder to media server.
>
> This is method (2). :)
> It rewrites the URLs relative to the source files before merging
> (which is your step 2).
>
>> That way, every compressor is compatible with each other if their
>> output is set to compressor-specific folder.
>> This doesn't impose any standard of writing urls in their files on
>> django users -- they do what they did before they have any staticfiles
>> support.
>
> You say that you don't want a standard, but what you describe in your
> mail is a standard. :) What else would you call your three
> instructions above? They describe how to rewrite URLs according to
> (2).
I clearly said it's my preference.

> If you still don't agree then see it for yourself: Try to use
> *exactly* the same reusable app with *exactly* the same CSS files with
> three different asset managers which combine those app CSS files into
> a single file. Tell me if it works. You'll see it's impossible.
Who said this should work?

I understand you wants to get everyone happy, by taking a decision
instead of users.

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

Re: contrib.staticfiles app concerns

[burc...@gmail.com]

Hi Waldemar,

On Fri, Oct 29, 2010 at 4:19 PM, Waldemar Kornewald
<wkornew...@gmail.com> wrote:
> Hi Yuri,
>
> On Fri, Oct 29, 2010 at 10:37 AM, burc...@gmail.com <burc...@gmail.com> wrote:
>> Hi Waldemar,
>>
>> On Fri, Oct 29, 2010 at 2:05 PM, Waldemar Kornewald
>> <wkornew...@gmail.com> wrote:
>>> Hi Carl,
>>>
>>>> As I read it, your option 4 means putting URLs into CSS files that
>>>> will not resolve correctly if static files are served directly,
>>>> unmodified, from their source locations (after being collected from
>>>> apps) under STATICFILES_URL (because the URLs you give don't begin
>>>> with a slash, so they will be interpreted as relative to the current
>>>> location; and if they did begin with a slash, that would break anytime
>>>> STATICFILES_URL is not a path-less domain). In other words, you are
>>>> proposing to write CSS files that _depend_ on being run through some
>>>> kind of combiner/compressor/filter that will intelligently rewrite all
>>>> their URLs relative to STATICFILES_URL. As a proposal for a
>>>> "standard," this is a non-starter for several reasons:
>> Do you agree with that "you are proposing to write CSS files that
>> _depend_ on being run through some kind of combiner/compressor/filter
>> that will intelligently rewrite all their URLs relative to
>> STATICFILES_URL"?
>
> I keep getting misunderstood, so I'll just simplify it. Forget all my
> proposals. My primary proposal is:
> "Let's have exactly one official standard, no matter if it's (2) or (4)."
> What I don't want is (1), (2), and (4) living side-by-side as they do now.
>
> Do you agree that we should have a standard?
Just a standard? Or standard for some problem related to django?

> If the answer is "yes", then which one should it be?
> A: (4) for CSS and Sass/etc.
> B: (2) for CSS, (4) for Sass/etc.
>
>> If you do, then you understand that you're trying to impose a standard
>> for django users that is really unnecessary for them?
>> You're free to allow such perversion with your app, but please don't
>> try to put this into django.
>>
>> Why can't you read css files, transform their paths to absolute, merge
>> files, and then write paths back as relative to merged files?
>
> That's method (2) which only works well for CSS.
Django doesn't support Sass.
Django doesn't support media compression.
Why django should have this stupid standard?

Related to your media compressor, i'd prefer not (2) or (4), i prefer
this one I described above:
1. Your compressor starts after media is gathered with staticfiles
into a single place. (All relative paths are valid at this moment!)
2. You read css files, transform their url paths to absolute, merge
files, and then write back into user specified directory with paths
rewritten as relative to merged files location.
3. If you're copying images, you can put images to whatever folder you
want, but they should still work.
Your compressor should make it possible to work after your compression
if you'll just put that folder to media server.

That way, every compressor is compatible with each other if their
output is set to compressor-specific folder.
This doesn't impose any standard of writing urls in their files on
django users -- they do what they did before they have any staticfiles
support.

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

Re: contrib.staticfiles app concerns

[burc...@gmail.com]

Hi Waldemar,

On Fri, Oct 29, 2010 at 2:05 PM, Waldemar Kornewald
 wrote:
> Hi Carl,
>
>> As I read it, your option 4 means putting URLs into CSS files that
>> will not resolve correctly if static files are served directly,
>> unmodified, from their source locations (after being collected from
>> apps) under STATICFILES_URL (because the URLs you give don't begin
>> with a slash, so they will be interpreted as relative to the current
>> location; and if they did begin with a slash, that would break anytime
>> STATICFILES_URL is not a path-less domain). In other words, you are
>> proposing to write CSS files that _depend_ on being run through some
>> kind of combiner/compressor/filter that will intelligently rewrite all
>> their URLs relative to STATICFILES_URL. As a proposal for a
>> "standard," this is a non-starter for several reasons:
Do you agree with that "you are proposing to write CSS files that
_depend_ on being run through some kind of combiner/compressor/filter
that will intelligently rewrite all their URLs relative to
STATICFILES_URL"?

If you do, then you understand that you're trying to impose a standard
for django users that is really unnecessary for them?
You're free to allow such perversion with your app, but please don't
try to put this into django.

Why can't you read css files, transform their paths to absolute, merge
files, and then write paths back as relative to merged files?

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

Re: contrib.staticfiles app concerns

[burc...@gmail.com]

Hi Waldemar,

it seems I just don't get what does "relative to" mean in your (1)-(4).
Could you please explain better, what do you mean by that?
Starting with what path does your "css/main.css" have?
I think you've missed some important bits in your explanations, or
just not covering every possible choice.
I presumed that with making css/main.css you're just copying that
image over to your new location like staticfiles does (or symlinking
images folder).

On Thu, Oct 28, 2010 at 1:29 PM, Waldemar Kornewald
<wkornew...@gmail.com> wrote:
> Hi Yuri,
>
> On Thu, Oct 28, 2010 at 6:19 AM, burc...@gmail.com <burc...@gmail.com> wrote:
>> Hi Waldemar,
>>
>> On Wed, Oct 27, 2010 at 9:05 PM, Waldemar Kornewald
>> <wkornew...@gmail.com> wrote:
>>> 2010/10/27 Mikhail Korobov <kmik...@googlemail.com>:
>>>> Why isn't it fine to have different URL rewriting schemes for
>>>> different assets bundlers?
>>>
>>> OK, sorry for not having explained it well. What I mean is this:
>>> Imagine this code snippet in a reusable app's CSS file:
>>>
>>> /* myapp/style.css */
>>> div.icon {
>>>  background-image: url(img/icon.png);
>>> }
>>>
>>> Now this file gets combined into "css/main.css". Depending on which
>>> asset manager and URL rewriting scheme you use the URL can be:
>>> 1. unmodified: "img/icon.png"
>>> 2. relative to the current file: "/static/myapp/img/icon.png"
>>> 3. relative to the combined file: "/static/css/img/icon.png"
>>> 4. relative to STATICFILES_URL "/static/img/icon.png"
>
> Which conflict do you mean? If you want to refer to some app's image
> from "app/css/style.css" you'd use "app/img/icon.png" with (4) and
> "../img/icon.png" with (2). Each path with (4) maps to exactly one
> path with (2) and the other way around, so any conflict that applies
> to (4) also applies to (2).
>
>>> (1), (2), and (3) would already be compatible with the current
>>> staticfiles implementation. (4) would require a little modification.
>>> I've seen (1), (2), and (4) used in practice when combining CSS files.
>>>
>>> Which behavior should be the standard for all asset managers?
>>
>> I think, in a compressor, you shouldn't rely on STATICFILES_URL but on your 
>> own
>> DJANGO_MEDIAGENERATOR_FILES_URL and DJANGO_MEDIAGENERATOR_FILES_ROOT,
>> which can be set up to implement necessary strategy from (1)-(4).
>
> Whether URLs are rewritten with STATICFILES_URL or
> DJANGO_MEDIAGENERATOR_FILES_URL doesn't make a real difference for
> this discussion. I'm fine with either setting, but let's first focus
> on the general URL rewriting solution, please.
>
> Bye,
> Waldemar
>
> --
> Django on App Engine, MongoDB, ...? Browser-side Python? It's open-source:
> http://www.allbuttonspressed.com/blog/django
>
> --
> 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.

Re: contrib.staticfiles app concerns

[burc...@gmail.com]

Hi Waldemar,

On Wed, Oct 27, 2010 at 9:05 PM, Waldemar Kornewald
 wrote:
> 2010/10/27 Mikhail Korobov :
>> Why isn't it fine to have different URL rewriting schemes for
>> different assets bundlers?
>
> OK, sorry for not having explained it well. What I mean is this:
> Imagine this code snippet in a reusable app's CSS file:
>
> /* myapp/style.css */
> div.icon {
>  background-image: url(img/icon.png);
> }
>
> Now this file gets combined into "css/main.css". Depending on which
> asset manager and URL rewriting scheme you use the URL can be:
> 1. unmodified: "img/icon.png"
> 2. relative to the current file: "/static/myapp/img/icon.png"
> 3. relative to the combined file: "/static/css/img/icon.png"
> 4. relative to STATICFILES_URL "/static/img/icon.png"
>
> If one developer who uses an asset manager based on (2) publishes a
> reusable app and another developer who uses an asset manager based on
> (4) publishes a reusable app there is no way to put both apps into
> your project and have both work correctly with the same asset manager.
>
> Note, in practice, (1) and (3) have pretty much the same result.
> Anyway, (1) and (3) would be very bad ideas if you want to support
> combined files, so let's leave them out of this discussion.
>
> (2) is what everyone is used to, but it's inconsistent if you use Sass
> or other CSS compilers because they allow importing other files which
> might also contain URLs and there's no way for the asset manager to
> rewrite URLs relative to the imported file's path (the asset manager
> only gets one big result file which already contains all imported
> files). This inconsistency is annoying e.g. when you develop both with
> CSS and Sass.
>
> (4) is fully consistent and easy to understand, but obviously behaves
> differently from what most people are used to when developing .
> However, this way all URLs look the same, no matter if you use Sass or
> CSS or both.
(4) is no good because you might have file name conflicts when used
with multiple reusable applications.
Why haven't you mentioned this problem?

> (1), (2), and (3) would already be compatible with the current
> staticfiles implementation. (4) would require a little modification.
> I've seen (1), (2), and (4) used in practice when combining CSS files.
>
> Which behavior should be the standard for all asset managers?

I think, in a compressor, you shouldn't rely on STATICFILES_URL but on your own
DJANGO_MEDIAGENERATOR_FILES_URL and DJANGO_MEDIAGENERATOR_FILES_ROOT,
which can be set up to implement necessary strategy from (1)-(4).

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

Re: It is real to add ticket #8054 to 1.3 milestone?

[burc...@gmail.com]

Hi Mikhail,

On Wed, Oct 27, 2010 at 5:45 PM, Mikhail Korobov <kmik...@googlemail.com> wrote:
> Hi Alex and Yuri,
>
> To make it clear: is this only a syntax change and all other benefits
> can be achieved with current implementation?
>
> The benefits from the wiki:
>
> 1. ability to customize and localize 3rd-party application without
> fork it - it is as easy with current ModelAdmin. ModelAdmin looks up
> it's own methods so 'get_bar_column' in wiki can be put into
> AccountAdmin.
>
> 2. ability to apply custom template filters on field value or model
> method returned value without any magic - it is also possible:
> template filters are just functions and @register.filter decorator
> doesn't harm them.
>
> 3. ability to specify witch field will be used in order for column
> based on model method - this is also totally possible with current
> implementation
>
> 4. beautifully API to admin change list customization - as I can see
> it is the only benefit here
>
> Am I correct and the goal is only to change list_display syntax?
Yes, I don't see any other goal either, so I have controversial
feelings about the issue.
It has only syntax sugar, but that sugar is very sweet.

> On 27 окт, 10:58, "burc...@gmail.com" <burc...@gmail.com> wrote:
>> Hi Alex,
>>
>> Patch is looking good, except few small things.
>> Wiki docs are also very good, but they are quite incomplete.
>> Replied to the ticket.
>>
>>
>>
>>
>>
>> On Tue, Oct 26, 2010 at 11:23 PM, Alex Kamedov <kame...@gmail.com> wrote:
>> > Can anybody rewiew the patch?
>>
>> > On Wed, Oct 13, 2010 at 6:35 PM, Alex Kamedov <kame...@gmail.com> wrote:
>>
>> >> Hi All,
>> >> I uploaded patch with tests and little improvements
>>
>> >>http://code.djangoproject.com/attachment/ticket/8054/8054-list-column...
>> >> I think it ready for review.
>> >> I really sorry, but I couldn't write good documentation because English
>> >> isn't my own language. The maximum of my possibility in writing docs is
>> >> here http://code.djangoproject.com/wiki/ListColumns   For more examples 
>> >> see
>> >> folder admin_listcolumn in regression tests provided by last my patch.
>> >> Cheers,
>> >> Alex Kamedov
>> >> On Wed, Oct 13, 2010 at 2:12 AM, Gabriel Hurley <gab...@gmail.com> wrote:
>>
>> >>> Hi alekam,
>>
>> >>> This is certainly the kind of ticket that we want to deal with in 1.3
>> >>> since it's been around so long and deferred a couple times. Starting
>> >>> the discussion here is definitely the right way to make it happen.
>>
>> >>> That said, at the very least it needs a thorough code review, a full
>> >>> set of tests, and good documentation before it can be included.
>>
>> >>> I'm not personally sold on the way the functionality is implemented,
>> >>> but I'd have to think on what would be preferable. I'm sure others
>> >>> will have stronger opinions on it one way or the other.
>>
>> >>> All the best,
>>
>> >>>    - Gabriel
>>
>> >>> On Oct 12, 9:47 am, alekam <kame...@gmail.com> wrote:
>> >>> > Hi All,
>>
>> >>> > I found very useful ticket #8054. This ticket has accepted status and
>> >>> > assigned to brosher about 2 years. The problem describes on ticket
>> >>> > detail page and in the
>> >>> > wikihttp://code.djangoproject.com/wiki/ListColumns
>> >>> > The ticket has patch witch passes all existing regression tests and I
>> >>> > plan to write unit tests for it.
>> >>> > It is real to add ticket #8054 to 1.3 milestone?
>>
>> >>> > Cheers,
>>
>> >>> > Alex Kamedov
>>
>> >>> --
>> >>> 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

Re: It is real to add ticket #8054 to 1.3 milestone?

[burc...@gmail.com]

Hi Alex,

Patch is looking good, except few small things.
Wiki docs are also very good, but they are quite incomplete.
Replied to the ticket.

On Tue, Oct 26, 2010 at 11:23 PM, Alex Kamedov  wrote:
> Can anybody rewiew the patch?
>
> On Wed, Oct 13, 2010 at 6:35 PM, Alex Kamedov  wrote:
>>
>> Hi All,
>> I uploaded patch with tests and little improvements
>>
>> http://code.djangoproject.com/attachment/ticket/8054/8054-list-column.5.diff
>> I think it ready for review.
>> I really sorry, but I couldn't write good documentation because English
>> isn't my own language. The maximum of my possibility in writing docs is
>> here http://code.djangoproject.com/wiki/ListColumns   For more examples see
>> folder admin_listcolumn in regression tests provided by last my patch.
>> Cheers,
>> Alex Kamedov
>> On Wed, Oct 13, 2010 at 2:12 AM, Gabriel Hurley  wrote:
>>>
>>> Hi alekam,
>>>
>>> This is certainly the kind of ticket that we want to deal with in 1.3
>>> since it's been around so long and deferred a couple times. Starting
>>> the discussion here is definitely the right way to make it happen.
>>>
>>> That said, at the very least it needs a thorough code review, a full
>>> set of tests, and good documentation before it can be included.
>>>
>>> I'm not personally sold on the way the functionality is implemented,
>>> but I'd have to think on what would be preferable. I'm sure others
>>> will have stronger opinions on it one way or the other.
>>>
>>> All the best,
>>>
>>>    - Gabriel
>>>
>>> On Oct 12, 9:47 am, alekam  wrote:
>>> > Hi All,
>>> >
>>> > I found very useful ticket #8054. This ticket has accepted status and
>>> > assigned to brosher about 2 years. The problem describes on ticket
>>> > detail page and in the
>>> > wikihttp://code.djangoproject.com/wiki/ListColumns
>>> > The ticket has patch witch passes all existing regression tests and I
>>> > plan to write unit tests for it.
>>> > It is real to add ticket #8054 to 1.3 milestone?
>>> >
>>> > Cheers,
>>> >
>>> > Alex Kamedov
>>>
>>> --
>>> 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.
>



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

Re: Sites Framework: RequestSite and get_current

[burc...@gmail.com]

Hi Gabriel,

looking good!

On Mon, Oct 4, 2010 at 2:59 PM, Gabriel Hurley  wrote:
> There is now a ticket and a patch for this, which includes the utility
> method and a rollup of fixes for the aforementioned tickets as
> appropriate. Tests and docs included. Details are in the ticket
> description:
>
> http://code.djangoproject.com/ticket/14386
>
> I'd love to get some feedback on it when possible.
>
> Thanks!
>
>    - Gabriel
>
> On Oct 1, 4:12 am, Luke Plant  wrote:
>> On Thu, 2010-09-30 at 23:48 -0700, Gabriel Hurley wrote:
>> > I went to triage a few tickets tonight, and noticed that #8960,
>> > #10235, #10608 and #13814 have all arrived at essentially the same
>> > conclusion: there needs to be a single idiomatic way to get either the
>> > current Site object if contrib.sites is installed, or a RequestSite
>> > object if not. All four tickets use the same bit of code, the argument
>> > really only lies in where to put it.
>>
>> > #10235 adds it as a utility function in contrib.sites.models, #13814
>> > as a separate method on SiteManager, and #8960 and #10608 basically
>> > just copy and paste where needed. I'm of the opinion it should have
>> > its own home in contrib.sites, but where, and under what name?
>>
>> I think a stand-alone function in contrib.sites.models is fine, called
>> `get_current_site` (or some other sensible colour of your choosing).
>> Since both Site and RequestSite already live there, it seems a good
>> place.
>>
>> Thanks for your work on this,
>>
>> Luke

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

Re: rethinking raw_id_fields

[burc...@gmail.com]

Hi everyone,

Anyway, I'd like to see notes from core devs regarding adding such
feature to Admin interface (so please don't say -1 if you think it's
just not mature enough!).

Or maybe all interested parties should work on some kind of
django-admin-extensions instead of improving admin itself.

Actually, it seems there is still no consensus in the django community
of what ideal admin interface should look like.
It's very controversial question!
I remember django core devs repeatedly said that django.contrib.admin
should be simple, and they intends it should be useful only for few
use-cases like observing your data, adding at most few initial model
instances, editing users and permissions, and being example of how to
(not) create reusable django application with UI, and how to create
poll application with no use of db explorer like phpmyadmin.

Different people tried to say many times that admin instead should be
extensible and have all sort of features to be really useful.

How do you see django admin in 5 years? This is the question to be
asked first of all.

Personally, I see django admin completely outside of django project in
5 years, like django debug toolbar and the rest, and I'd say, django
core team time should use their time to review and apply patches, fix
bugs and add new features to django itself, so admin development
should be stopped, admin docs must contain: "admin app is not much
useful -- we just don't have enough time to add features into it, and
we don't think we should do this -- but it can be used as an example
for django beginners of how (not) to do reusable django applications".

On Fri, Oct 1, 2010 at 5:45 AM, tyrion-mx  wrote:
> I've tried implementing Autocomplete for the admin using jQuery (new)
> Autocomplete,
> here's the code: http://bitbucket.org/tyrion/django
> and here's a live demo (without css for the autocomplete, so it looks
> kinda ugly): http://djangoac.tyrion.mx/admin/ login with test/test.
>
> Let me know what you think about it.
>
> --
> 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.

Re: rethinking raw_id_fields

[burc...@gmail.com]

On Thu, Sep 30, 2010 at 10:27 PM, subs...@gmail.com  wrote:
> At that point its not really raw_id_fields, is it? =)

After all, what's the purpose of these fields?

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

Re: rethinking raw_id_fields

[burc...@gmail.com]

Hi Subsume,

why not just replace them with some proper implementation of ajax completion ?

http://djangopackages.com/grids/g/auto-complete/

On Thu, Sep 30, 2010 at 12:34 PM, subs...@gmail.com  wrote:
> Hello all,
>
> I was browsing the tickets and saw a few of them nagging about some
> restrictions to raw_id_fields. That they are limited to other objects
> registered in admin, that they are limited arbitrarily (relative to a
> regular FK) by the permissions of the user, etc. Personally, I find
> the little changelist window that pops up a bit awkward and hackish-
> looking.
>
> Might a better approach be to have a django-admin view which uses
> content-types to generate a list of the objects in question? If
> someone can give me a simple yes, no, etc, I'd be willing to do the
> necessary ticket-work and come up with a patch for review.

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

Re: Something.is_live instead of implementation specific is_live settings

[burc...@gmail.com]

On Sat, Sep 25, 2010 at 3:50 AM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
>
> What if I want dev settings in version control?
Please write in details.
Do you have single development configuration or multiple? Single
development PC or multiple?

> What if I want "explicit"?
Aren't they explicit enough?
Ok, version 3.

settings.py (in version control):
-->8
if DEBUG:
     KEY1 = 'value1'
     KEY2 = 'value2'
else:
KEY3 = 'value3'

Is that now what you want?

> On Sep 24, 11:09 am, "burc...@gmail.com" <burc...@gmail.com> wrote:
>> How it's better from both of the following:
>>
>> 1)
>> try:
>>     from dev_settings import *
>> except ImportError:
>>    pass
>>
>> 2)
>> if DEBUG:
>>     from dev_settings import *
>>
>> Because to have "project.is_dev" you'll have to write it somewhere already!
>>
>> It's bootstrapping problem.
>>
>>
>>
>>
>>
>> On Sat, Sep 25, 2010 at 12:01 AM, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
>> > I read that article. The problem is that it's deployment specific. I
>> > dint even know what host name "omh.cc" is, but I have a feeling that
>> > you couldn't work on that from your laptop to your desktop without
>> > changing something. What I propose isn't a is_production variable. I'm
>> > proposing an explicit is_development variable so that I can choose my
>> > settings "explicitly" instead of trying to import something and then
>> > something else if that's not there. That is very un-pythonic. If I can
>> > say something to the effect of:
>>
>> > if project.is_dev:
>> >    import dev_settings
>> > else:
>> >    # is live
>>
>> > just example. I'm not suggesting "project" as a global. It's just to
>> > show the type of setting I want.
>>
>> > That's much cleaner, and far more explicit than "import os, socket,
>> > etc".
>>
>> > On Sep 23, 7:41 pm, Yo-Yo Ma <baxterstock...@gmail.com> wrote:
>> >> Thanks for the link David. I'm gonna check it it now.
>>
>> >> On Sep 23, 6:16 pm, "David P. Novakovic" <davidnovako...@gmail.com>
>> >> wrote:
>>
>> >> > This link and the comments suggest some good stuff... particularly the
>> >> > comment from Malcolm and the original post.
>>
>> >> >http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-p...
>>
>> >> > On Fri, Sep 24, 2010 at 10:01 AM, David P. Novakovic
>>
>> >> > <davidnovako...@gmail.com> wrote:
>> >> > > The thing is, in production mode you normally have to define where
>> >> > > your settings are anyway, so you pass the unusual settings file name
>> >> > > there, and just use the regular settings.py for your development.
>>
>> >> > > So then you are passing the settings configuration information once in
>> >> > > the production server's configuration, not every time you run your
>> >> > > development server.
>>
>> >> > > I think people with any decent sized project have addressed this issue
>> >> > > in their own way that suits their own needs.
>>
>> >> > > For example we have lots of settings files and just import the
>> >> > > relevant settings into a final file.
>>
>> >> > > For testing I do what i mentioned in my previous email.
>>
>> >> > > Like anything on here, you need to ask whether what you are suggesting
>> >> > > would actually be better off as part of the core or if it works just
>> >> > > fine as something that people can choose to use themselves...
>>
>> >> > > I think most people use whatever system they are happy with and it
>> >> > > doesn't get in the way of deployment/development. Thus this fails to
>> >> > > meet one of the critical requirements for consideration for inclusion
>> >> > > into core.
>>
>> >> > > D
>>
>> >> > > On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma <baxterstock...@gmail.com> 
>> >> > > wrote:
>> >> > >> Thanks David, but I'm talking about having something built in. For
>> >> > >> instance, passing a variable to the "Development" server to tell it
>> >> > >> you're in &quo

Re: Something.is_live instead of implementation specific is_live settings

[burc...@gmail.com]

On Sat, Sep 25, 2010 at 12:46 AM, Chuck Harmston
 wrote:
> their project (with the help of a programming language). That is powerful.
...But is not very practical for 90% of django users, who have to
invent their own bikes.

> However, that flexibility isn't solely restricted to the method of defining
> settings; it could also be applied in the selective determination and
> loading of settings. Now, consider the problem you're trying to solve. It
> will work great on simple sites that have one development server and one
> production server. However, if it is implemented we would be forcing a
> specific server setup and workflow on Django's users, and not all Django
> projects are deployed in the same way.
Why everyone talking about improvement of settings insists on forcing
anything and forgets about "backends" way completely?

> Django's settings are able to accommodate edge cases like this because they
> are generic and flexible.
I think you are mistaken here. Writing sites with Python is more
flexible than with Django, so why people are using Django?
Everyone prefers fine-grained framework to powerful command line and
missing libraries!
Django settings are kept *simple*, not *powerful*. Backends that
support different ways of configurations is what is *powerful*.

> You have the power to (and should!) find a solution that makes sense for your 
> project, as it seems you've done.
> However, that sort of thing belongs in a project, not in Django itself.
And not everyone agrees on that decision!

> On Fri, Sep 24, 2010 at 1:01 PM, Yo-Yo Ma  wrote:
>>
>> I read that article. The problem is that it's deployment specific. I
>> dint even know what host name "omh.cc" is, but I have a feeling that
>> you couldn't work on that from your laptop to your desktop without
>> changing something. What I propose isn't a is_production variable. I'm
>> proposing an explicit is_development variable so that I can choose my
>> settings "explicitly" instead of trying to import something and then
>> something else if that's not there. That is very un-pythonic. If I can
>> say something to the effect of:
>>
>> if project.is_dev:
>>    import dev_settings
>> else:
>>    # is live
>>
>> just example. I'm not suggesting "project" as a global. It's just to
>> show the type of setting I want.
>>
>> That's much cleaner, and far more explicit than "import os, socket,
>> etc".
>>
>>
>> On Sep 23, 7:41 pm, Yo-Yo Ma  wrote:
>> > Thanks for the link David. I'm gonna check it it now.
>> >
>> > On Sep 23, 6:16 pm, "David P. Novakovic" 
>> > wrote:
>> >
>> >
>> >
>> > > This link and the comments suggest some good stuff... particularly the
>> > > comment from Malcolm and the original post.
>> >
>> >
>> > > >http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-p...
>> >
>> > > On Fri, Sep 24, 2010 at 10:01 AM, David P. Novakovic
>> >
>> > >  wrote:
>> > > > The thing is, in production mode you normally have to define where
>> > > > your settings are anyway, so you pass the unusual settings file name
>> > > > there, and just use the regular settings.py for your development.
>> >
>> > > > So then you are passing the settings configuration information once
>> > > > in
>> > > > the production server's configuration, not every time you run your
>> > > > development server.
>> >
>> > > > I think people with any decent sized project have addressed this
>> > > > issue
>> > > > in their own way that suits their own needs.
>> >
>> > > > For example we have lots of settings files and just import the
>> > > > relevant settings into a final file.
>> >
>> > > > For testing I do what i mentioned in my previous email.
>> >
>> > > > Like anything on here, you need to ask whether what you are
>> > > > suggesting
>> > > > would actually be better off as part of the core or if it works just
>> > > > fine as something that people can choose to use themselves...
>> >
>> > > > I think most people use whatever system they are happy with and it
>> > > > doesn't get in the way of deployment/development. Thus this fails to
>> > > > meet one of the critical requirements for consideration for
>> > > > inclusion
>> > > > into core.
>> >
>> > > > D
>> >
>> > > > On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma 
>> > > > wrote:
>> > > >> Thanks David, but I'm talking about having something built in. For
>> > > >> instance, passing a variable to the "Development" server to tell it
>> > > >> you're in "Development" seems a bit redundant, no?
>> >
>> > > >> On Sep 23, 3:39 pm, "David P. Novakovic" 
>> > > >> wrote:
>> > > >>> As for running different configs:
>> >
>> > > >>> manage.py runserver --settings=settings_test
>> >
>> > > >>> etc..
>> >
>> > > >>> On Fri, Sep 24, 2010 at 7:25 AM, Jacob Kaplan-Moss
>> > > >>>  wrote:
>> > > >>> > On Thu, Sep 23, 2010 at 3:33 PM, 

Re: Something.is_live instead of implementation specific is_live settings

[burc...@gmail.com]

How it's better from both of the following:

1)
try:
from dev_settings import *
except ImportError:
   pass

2)
if DEBUG:
from dev_settings import *

Because to have "project.is_dev" you'll have to write it somewhere already!

It's bootstrapping problem.

On Sat, Sep 25, 2010 at 12:01 AM, Yo-Yo Ma  wrote:
> I read that article. The problem is that it's deployment specific. I
> dint even know what host name "omh.cc" is, but I have a feeling that
> you couldn't work on that from your laptop to your desktop without
> changing something. What I propose isn't a is_production variable. I'm
> proposing an explicit is_development variable so that I can choose my
> settings "explicitly" instead of trying to import something and then
> something else if that's not there. That is very un-pythonic. If I can
> say something to the effect of:
>
> if project.is_dev:
>    import dev_settings
> else:
>    # is live
>
> just example. I'm not suggesting "project" as a global. It's just to
> show the type of setting I want.
>
> That's much cleaner, and far more explicit than "import os, socket,
> etc".
>
>
> On Sep 23, 7:41 pm, Yo-Yo Ma  wrote:
>> Thanks for the link David. I'm gonna check it it now.
>>
>> On Sep 23, 6:16 pm, "David P. Novakovic" 
>> wrote:
>>
>>
>>
>> > This link and the comments suggest some good stuff... particularly the
>> > comment from Malcolm and the original post.
>>
>> >http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-p...
>>
>> > On Fri, Sep 24, 2010 at 10:01 AM, David P. Novakovic
>>
>> >  wrote:
>> > > The thing is, in production mode you normally have to define where
>> > > your settings are anyway, so you pass the unusual settings file name
>> > > there, and just use the regular settings.py for your development.
>>
>> > > So then you are passing the settings configuration information once in
>> > > the production server's configuration, not every time you run your
>> > > development server.
>>
>> > > I think people with any decent sized project have addressed this issue
>> > > in their own way that suits their own needs.
>>
>> > > For example we have lots of settings files and just import the
>> > > relevant settings into a final file.
>>
>> > > For testing I do what i mentioned in my previous email.
>>
>> > > Like anything on here, you need to ask whether what you are suggesting
>> > > would actually be better off as part of the core or if it works just
>> > > fine as something that people can choose to use themselves...
>>
>> > > I think most people use whatever system they are happy with and it
>> > > doesn't get in the way of deployment/development. Thus this fails to
>> > > meet one of the critical requirements for consideration for inclusion
>> > > into core.
>>
>> > > D
>>
>> > > On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma  
>> > > wrote:
>> > >> Thanks David, but I'm talking about having something built in. For
>> > >> instance, passing a variable to the "Development" server to tell it
>> > >> you're in "Development" seems a bit redundant, no?
>>
>> > >> On Sep 23, 3:39 pm, "David P. Novakovic" 
>> > >> wrote:
>> > >>> As for running different configs:
>>
>> > >>> manage.py runserver --settings=settings_test
>>
>> > >>> etc..
>>
>> > >>> On Fri, Sep 24, 2010 at 7:25 AM, Jacob Kaplan-Moss 
>> > >>>  wrote:
>> > >>> > On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma  
>> > >>> > wrote:
>> > >>> >> I'm simply proposing the idea of having the development server
>> > >>> >> explicitly set something to indicate a "in development" status, so
>> > >>> >> that if that does not exist you can make the assumption that the
>> > >>> >> project is live.
>>
>> > >>> > This is exactly what the settings.DEBUG flag is for. Use it. Love it.
>>
>> > >>> > 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 
>> > >>> > athttp://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.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 

Re: Inclusion of easy-thumbnails into Django Contrib

[burc...@gmail.com]

Hi everyone,

I think thumbnailing functionality is much closer to django core
rather than to django.contrib, and that is the most important reason
for inclusion.

Django provides ImageField out of the box, but why it doesn't provide
ThumbnailImageField out of the box?
Django provides  {% lorem %} tag, but why it doesn't provide {%
thumbnail %} tag?

Thumbnails are very common pattern.

Maybe this application (easy_thumbnails) is not the best choice, but
the general idea of having good and popular reusable thumbnail
solution distributed with django is very attractive to me.

On Fri, Sep 17, 2010 at 12:35 AM, Justin Lilly  wrote:
> One of the criteria for django.contrib is that the item for inclusion
> is a "de facto standard implementation of common patterns"[0]. From
> your own admittance there are conflicting views about how this should
> be handled. Perhaps if someone abstracts this out a bit and has
> something like image processing backends, it may make a bit more sense
> for inclusion, but as it stands, I'm -1.
>
>  -justin
>
> [0]: http://jacobian.org/writing/what-is-django-contrib/
>
> On Thu, Sep 16, 2010 at 1:26 PM, ptone  wrote:
>>
>>
>> On Sep 16, 9:43 am, Patrick Altman  wrote:
>>> Another "community voice" contribution on this thread...
>>>
>>> I am of the opposite opinion.  I think it would be better for Django as a 
>>> whole if django.contrib approached zero.  In fact, I would have no problem 
>>> with seeing it go away completely and promote auth and sessions to core but 
>>> done in a way that is pluggable.  The reasoning behind this opinion is that 
>>> it leaves the surface area in the project smaller to maintain and it's 
>>> really not that hard to add a sorl-thumbnail external app to a Django 
>>> project.  Furthermore, it provides more freedom for these apps to mature 
>>> and develop at their own pace.
>>>
>>> I realize I could very well be in a minority opinion here, but thought I'd 
>>> throw it into the mix nonetheless.
>>
>> Another vote for evolving away from contrib.
>>
>> My hope is that one day http://djangopackages.com/ will become
>> packages.djangoproject.com
>>
>> (and along with that a management command startapp-dist which starts a
>> distributable skeleton)
>>
>> -Preston
>>
>>>
>>> On Sep 16, 2010, at 11:33 AM, Brian O'Connor wrote:
>>>
>>>
>>>
>>> > I have absolutely no pull in decision making, but maybe my message will 
>>> > count towards a "community voice".
>>>
>>> > I think that including an image thumbnail package that integrates into 
>>> > the database as easily as sorl.thumbnail and easy_thumbnail are is a 
>>> > great idea.  From what I can tell, sorl.thumbnail was the de facto 
>>> > standard for getting thumbnails in to Django, and I think it has just as 
>>> > much of a place in Django contrib as some of the other contrib apps do.  
>>> > I don't think it belongs in the core, but contrib seems like an excellent 
>>> > place for it to go along with the other batteries in the pack.
>>>
>>> > On Thu, Sep 16, 2010 at 12:24 PM, Yo-Yo Ma  
>>> > wrote:
>>> > I have no data to support the following assertion, but it's not too
>>> > unreasonable: More people probably need thumbnail images than they
>>> > need comments. Comments are most used on blogs, whereas thumbnails can
>>> > be used on blogs, e-commerce, photo hosting, social networking,
>>> > project management, et al. It's not to say that we don't need
>>> > "contrib.comments", just that I wouldn't want to lose easy_thumbnails.
>>>
>>> > On Sep 15, 11:32 pm, "David P. Novakovic" 
>>> > wrote:
>>> > > Actually, that really did sound negative. Sorry :)
>>>
>>> > > Is there a trac ticket open to address this issue? Generally it'd be
>>> > > better to get discussion happening over a ticket and if there are
>>> > > serious issues that need to be addressed then they can be discussed
>>> > > here.
>>>
>>> > > I know it'd be nice to get things like easy-thumbnails accepted into
>>> > > django.contrib , but the truth is that this probably falls outside of
>>> > > things that that should be in contrib. Contrib isn't really an easier
>>> > > way to get stuff into django, it still has to satisfy a bunch of
>>> > > conditions like the rest of the code in the core.
>>>
>>> > > The real question is not "can it be included?" but why is it a problem
>>> > > that this is a third party lib at the moment? Is there a strong case
>>> > > that it be better if it was part of django core or does it do its job
>>> > > just fine the way it is now?
>>>
>>> > > David
>>>
>>> > > On Thu, Sep 16, 2010 at 3:09 PM, David P. Novakovic
>>>
>>> > >  wrote:
>>> > > > I don't want to sound negative, but answering your own question before
>>> > > > anyone else can doesn't change the answer ;)
>>>
>>> > > > D
>>>
>>> > > > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma  
>>> > > > 

Re: parameterized apps (was: Re: Eric Florenzano's presentation slides)

[burc...@gmail.com]

Hi Javier,

after GSoC 2010, we have
http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/django/t127230758002
feature at 
http://code.djangoproject.com/browser/django/branches/soc2010/app-loading

Not that good syntax, but this solution can help you!

P.S. The more testers we have, the faster the branch will be
integrated into the trunk!

On Thu, Sep 9, 2010 at 9:24 PM, Javier Guerra Giraldez
 wrote:
> from Eric Florenzano's slide 41:
>
>  In models.py:
>
>  class Favorite(models.Model):
>      item = LazyForeignKey(‘fave’)
>      user = ForeignKey(User)
>      date = DateTimeField(default=utcnow)
>
>
>  In settings.py:
>
>  LAZY_FKS = {‘fave’: ‘pages.models.Page’}
>
>
> I share the dislike for generic relationships; but don't think this
> solution is particularly elegant, nor flexible enough.
>
> what about giving parameters to the apps?  something like:
>
> INSTALLED_APPS = (
>        'django.contrib.auth',
>        'django.contrib.contenttypes',
>        'django.contrib.sessions',
>        'django.contrib.sites',
>        'django.contrib.admin',
>        ('debug_toolbar', {
>                'INTERCEPT_REDIRECTS': False,
>                'INTERNAL_IPS': ('127.0.0.2',),
>        }),
>        'django_extensions',
>        ('favorites', {
>                'fave': ‘pages.models.Page',
>        }),
>        'comercial',
>        'specs',
> )
>
>
> and in favorites.models.py:
>
>  class Favorite(models.Model):
>      item = LazyForeignKey(args[‘fave’])
>      user = ForeignKey(User)
>      date = DateTimeField(default=utcnow)
>
>
> this helps to reduce global settings pollution, simply by binding a
> global ('args' in this example) to the respective app's parameter
> dictionary.
>
> it could even allow a project to import a single app twice with
> different parameters:
>
> INSTALLED_APPS = (
>        ...
>        ('favoritebooks', {
>                'APP_MODULE': 'favorites',
>                'fave': ‘pages.models.Book',
>        }),
>        ('favoritepages', {
>                'APP_MODULE': 'favorites',
>                'fave': ‘pages.models.Page',
>        }),
>        'comercial',
>        'specs',
> )
>
> here, APP_MODULE tells Django where to import the app from, by default
> it would be the app name (as now), but specifying it separately allows
> the user to give a different name to the app in the project's context.
>
> toughts?
>
> --
> Javier
>
> --
> 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.

Re: #13870: Correctly handling database isolation (in PostgreSQL)

[burc...@gmail.com]

Hi Patryk,

This was done to make Django faster, so it doesn't create connection
to database every time new SQL is executed.
Do you mean you wanted to set up timeouts for idle database connections?
I guess, nobody asked this before.

On Mon, Sep 6, 2010 at 5:20 PM, Patryk Zawadzki  wrote:
> On Mon, Sep 6, 2010 at 11:20 AM, Kirit Sælensminde (kayess)
>  wrote:
>> Strange. We use Postgres and don't see any problem with this. We do
>> encounter complications occasionally with the lack of composition of
>> Django transaction handling, but other than that find the transaction
>> handling adequate.
>>
>> Are you actually using transactions in your code? You need to be. The
>> transaction middleware does a good enough job for most things, but for
>> external processing you will need to carefully design your transaction
>> handling. With the transaction middleware we see fully isolated
>> updates until the transaction is committed using psycopg2.
>
> I'm not sure you understand the problem at all. The problem is not
> lack of the isolation. The problem is permanent isolation. The
> isolating transaction is never terminated, thus remaining alive for
> indefinite amounts of time.
>
> You can check this by creating a fresh project using psycopg2 and
> creating a model. Then write a view that queries the database and
> invoke it. Now, leaving the server running, open up your database
> shell. The pg_stat_activity table will report " in transaction"
> for hours.
>
> BTW: This has nothing to do with Django transactions or TransactionMiddleware.
>
> --
> Patryk Zawadzki
>
> --
> 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.

Re: Inline template rendering in admin shouldn't silence errors

[burc...@gmail.com]

On Thu, Sep 2, 2010 at 6:27 PM, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
> On Thu, Sep 2, 2010 at 5:04 PM, burc...@gmail.com <burc...@gmail.com> wrote:
>> Russell,
>>
>> Sorry, we didn't understand each other,
>>
>> You're talking about additional problems for templates with variable names.
>>
>> However main point that George made was that he wanted template
>> rendering to break when including templates fails, no matter if that
>> was in the parse time or rendering time.
>>
>> To address your "original point -- that runtime template errors are
>> considered unacceptable" I suggested that we have 2 different template
>> tags instead of include, one that will break, another one that will
>> not, because me and George wanted to have not the current version of
>> include tag but one that breaks on errors.
>
> First off, I'm not about to add a second template tag for including
> subtemplates. One is more than sufficient.
>
> Secondly, I still don't see how what you're describing is possible.
> The name of the template to be included is not determined until the
> template is *rendered*. This is a completely to when the template is
> *parsed*, and it is the *parsing* process that generates
> TemplateSyntaxErrors. If we can't work out which subtemplate is to be
> used until rendering, we can't raise a syntax error when the parent
> template is parsed.
Russell,

Sorry. One more try.

We don't need a error to be raised exactly on parsing stage, it's
enough if parse error is raised on rendering.

Do you mean we can't raise a syntax error when the included template
is *rendered*?

How to do this:
If error was raised on parsing:
 Parser instruments parsed tree with a *raise error here* node to be
raised on rendering this node later.
If error was raised on rendering but you inserted current template
into parent one:
 Included template is guarded with special node that saves the
included template name for debugging purposes and re-raises parse
error.

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

Re: Inline template rendering in admin shouldn't silence errors

[burc...@gmail.com]

Russell,

Sorry, we didn't understand each other,

You're talking about additional problems for templates with variable names.

However main point that George made was that he wanted template
rendering to break when including templates fails, no matter if that
was in the parse time or rendering time.

To address your "original point -- that runtime template errors are
considered unacceptable" I suggested that we have 2 different template
tags instead of include, one that will break, another one that will
not, because me and George wanted to have not the current version of
include tag but one that breaks on errors.

Implementation could look like the following: wrapper in the render()
part of include node, that uses some internal "current template"
variable. Another variable in the parser for this purpose.

P.S. This improvement is also related to my syntax coloring feature,
since I wanted to improve template errors display as well.

On Thu, Sep 2, 2010 at 1:41 PM, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
> On Thu, Sep 2, 2010 at 2:30 PM, burc...@gmail.com <burc...@gmail.com> wrote:
>> Hi Russell,
>>
>> I'd define
>>> {% for templ in template_list %}
>>>    {% include templ %}
>>> {% endfor %}
>> as a special case, for which special command or pattern should exist.
>>
>> Should it be
>> {% for templ in template_list %}
>>    {% try-include template %}
>> {% endfor %}
>> or the opposite to be called
>> {% require template %} instead of include,
>> or maybe this whole pattern should be written as
>>    {% include-first templ %}
>>
>> But in most cases {% include %}  is used as "require", so in my
>> opinion it should raise errors!
>>
>> I'd also consider a require-once pattern to fix common widget chrome
>> problems (i.e. different parts of the page might include jquery in
>> headers).
>
> Either I'm completely missing the point you're trying to make, or
> you've completely missed the point I was making.
>
> Template rendering is a two step process:
>  1. Parse the template
>  2. Render the template.
>
> The point I was trying to make is that at step 1, we *can't* know the
> name of the subtemplate used in an {% include %}. This isn't a matter
> for negotiation or something we are in a position to design -- it's
> simply the way that the tag is implemented.
>
> I don't see how changing the name of the include tag to  "require" or
> "try-include" changes anything, or how an alternate tag with those
> names would behave differently.
>
> 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.
>
>



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

Re: Inline template rendering in admin shouldn't silence errors

[burc...@gmail.com]

Hi Russell,

I'd define
> {% for templ in template_list %}
>    {% include templ %}
> {% endfor %}
as a special case, for which special command or pattern should exist.

Should it be
{% for templ in template_list %}
{% try-include template %}
{% endfor %}
or the opposite to be called
{% require template %} instead of include,
or maybe this whole pattern should be written as
{% include-first templ %}

But in most cases {% include %}  is used as "require", so in my
opinion it should raise errors!

I'd also consider a require-once pattern to fix common widget chrome
problems (i.e. different parts of the page might include jquery in
headers).

On Thu, Sep 2, 2010 at 1:00 PM, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
> On Thu, Sep 2, 2010 at 1:42 PM, burc...@gmail.com <burc...@gmail.com> wrote:
>> Hi George,
>>
>> I believe this is a bug since any other errors in admin (not related
>> to inlines) don't pass silently.
>>
>> Silencing errors should always be documented, especially if error is
>> silenced when DEBUG is turned on.
>>
>> So it's either documentation or implementation bug.
>
> IMHO, it's a documentation issue, not a bug. It all comes down to how
> you interpret the operation of the {% include %} tag.
>
> In one interpretation, you can look at at the {% include %} as a major
> structural node in the template, whose role is to substitute the
> contents of a subtemplate. In this case, the {% include %} doesn't
> actually exist in the final template; it's just a placeholder that
> gets expanded as part of the original parsing process. In this
> interpretation, any syntax error in the include node would be surfaced
> as a syntax error in the main parent template doing the including.
>
> Alternatively, you can look at {% include %} as being just like any
> other tag. It exists as a normal template node, and the parsed parent
> template contains a node that represents the {% include %}. At
> runtime, the {% include %} tag substitutes it's content; and if that
> raises an error, then the rendering process swallows that error.
>
> The second interpretation what actually happens in implementation. {%
> includes %} are actual nodes in the parsed template tree. The reason
> for this is that the name of the template that is rendered is actually
> a variable - For example, consider the following:
>
> {% for templ in template_list %}
>    {% include templ %}
> {% endfor %}
>
> The included template isn't actually loaded and resolved until time of
> render. As a result, we aren't in a position to raise a
> TemplateSyntaxError when we parse the original document tree. We only
> parse the included template when we render the parent template with a
> specific context.
>
> For the record, this distinction is also why {% cycle %} tags don't
> persist over iterated {% include %}s -- each {% include %} is an
> independent rendering context, so a cycle in one include doesn't
> affect subsequent iterations.
>
> So - this is a documentation issue. However, it's a pretty subtle
> point, so it's not easy to explain. If anyone wants to take a swing at
> trying to explain the issue, it would certainly be a valuable
> contribution to the docs, and would possibly reduce the number of
> invalid bug reports that are logged against the behavior of the
> include tag.
>
> That said: if anyone has any bright ideas on how to improve error
> handling when rendering templates, we're open to suggestions. However,
> my original point -- that runtime template errors are considered
> unacceptable -- still stands, and any suggestion needs to honor that.
>
> 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.
>
>



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

Re: Inline template rendering in admin shouldn't silence errors

[burc...@gmail.com]

Hi George,

I believe this is a bug since any other errors in admin (not related
to inlines) don't pass silently.

Silencing errors should always be documented, especially if error is
silenced when DEBUG is turned on.

So it's either documentation or implementation bug.

By the way, does it show 500 error page if DEBUG is on?

On Wed, Sep 1, 2010 at 1:03 PM, George Karpenkov
 wrote:
> Steps to reproduce:
> 1) Specify a custom admin class (say A) which mentions a custom inline
> with a custom template, say "a.html"
> 2) Write anything to "a.html" which will raise TemplateSyntaxError -
> ie "{% extends "a.html" %}
> 3) Observe the change_form for A. Note that you do not see any errors,
> but instead the whole inline does not appear at all.
>
> I find this behavior extremely confusing and annoying. Is it just a
> bug or is there any reasoning behind that?

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

Re: a new template algorithm

[burc...@gmail.com]

On Sat, Aug 28, 2010 at 10:47 PM, 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

Hi Gabriele,

Why you patched Django instead of making a connector so everyone would
be able to use your template engine without patching django?

Looking at your django patch, you also seems to have a typo in your
Http500 page rewrite:
-Request Method: {{ request.META.REQUEST_METHOD }}
-Request URL: {{ request.build_absolute_uri|escape }}
+Request Method: {{ request.META['RQUEST_METHOD'] }}
+Request URL: {{ escape(request.build_absolute_uri) }}

>From the engineering point of view, you did nothing important. In
fact, I think, you did a bad thing to Django:
By increasing the number of incompatible template engines for django,
you fraction the user base of each one, so you decrease the overall
quality of Django solutions, and Django plugins won't be that good (if
they provide any templates). I believe, new template engine should be
made only if it will be much better than old one (i.e, look at Razor
template engine from Microsoft ASP.NET team).
Your work also makes me think you haven't ever heard of Jinja2 and
Mako, both of which already do what you need (python programming in
templates), but have good documentation and have proper way to connect
to Django.

>From the teenager point of view, look, you created new cool template
engine! Wow! You rock!

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

Re: [gsoc/app-loading] final status report

[burc...@gmail.com]

Hi Arthur,

thanks for your work!

Is any syntax of setting keywords for app instances in INSTALLED_APPS
or somewhere in settings supported now?

On Mon, Aug 23, 2010 at 2:06 AM, Arthur Koziel  wrote:
> Hey there,
>
> the GSOC is over and I wanted to give you all a final status report.
>
> The AppCache was refactored and now creates app instances instead of just 
> loading models. An app is either an instance of django.core.apps.App or a 
> custom class. This depends on the entry in the INSTALLED_APPS setting. Here's 
> an example:
>
> INSTALLED_APPS = (
>        'django.contrib.auth',
>        'django.contrib.sites',
>        'myproject.poll.MyPollApp',
> )
>
> With this setting, three instances will be created. Two instances of the 
> django.core.apps.App class and one MyPollApp instance. The MyPollApp class 
> could look like this:
>
>        from django.core.apps import App
>        from django.utils.translation import ugettext as _
>
>        class MyPollApp(App):
>                def __init__(self, name):
>                        super(MyPollApp, self).__init__(name)
>                        self.verbose_name = _('Poll')
>                        self.db_prefix = 'foo'
>
> The first thing to note is the verbose_name attribute, which allows for a 
> more descriptive name of the app. Currently the app name is the app_label, so 
> "auth" would be used for "django.contrib.auth". However, something like 
> "Authentication" would fit better from a UI perspective. The name can be 
> passed to the ugettext function and translated in the projects .po file on 
> the next run of makemessages. I modified the admin to use the verbose_name 
> instead of the app_label.
>
> The db_prefix attribute allows the app to specify the prefix used when the 
> tables are created in the database. If the above app would have a "Poll" 
> model, it would be created as "foo_poll" instead of "poll_poll".
>
> There many more attributes than can be implemented like a fixture prefix or 
> admin permission prefix. The models app label is currently used for far too 
> many things.
>
>
>
> One thing I noticed was that a lot of code in Django itself or 3rd party apps 
> iterates over the installed apps and imports them. This won't work anymore as 
> an app can now also be a path to a class, so the import will raise an 
> exception.
>
> The ideal solution would be to change the code to iterate over the app 
> instances instead of the INSTALLED_APPS setting, but this might be a little 
> bit too much to ask. So, there's now an "installed_apps" attribute on the 
> AppCache that is a normalized version of the settings.INSTALLED_APPS variable 
> (with classnames removed). This makes the migration easier as this code:
>
>        for app in settings.INSTALLED_APPS:
>                import_module(app)
>
> simply needs to be changed to this:
>
>        for app in cache.installed_apps:
>                import_module(app)
>
> Applications with the same app label still cannot be created. The problem is 
> backwards compatibility, as the methods of the AppCache (get_model/get_app 
> etc.) all take the app_label as an argument. If, for example, there would be 
> two "auth" app instances (e.g. django.contrib.auth
> and myproject.auth) calling get_model('auth', ...) the function must still 
> return the first one. I don't see migration path from app label to full path 
> without breaking bc.
>
> Nevertheless, things have improved a little here. Previously, loading two 
> apps with the same app label would assign the models of the second app to the 
> first app, leaving the user with one auth app that mixed together the models 
> from both apps. That won't happen anymore. Now there will be only one auth 
> app, and the second will not be loaded. Hopefully this will clear up some 
> confusion.
>
>
>
> Overall, I'm happy with the result. Working on this project was a great 
> experience for me. I plan to continue my work on this branch after gsoc. 
> Jannis Leidel was a fantastic mentor, always available and really helpful.
>
> I have the next 2 weeks filled up with exams but I'll be in Portland for 
> DjangoCon in early September. I'm always open to feedback and planning on 
> attending the sprints to do some further work. So until then...
>
> Regards,
> Arthur
>
> --
> 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 

Re: #11834: colorized debug page. Assigned to buriy

[burc...@gmail.com]

Hi Thomas,

On Mon, Aug 16, 2010 at 8:12 PM, Thomas Guettler  wrote:
> Hi buriy,
>
> http://code.djangoproject.com/ticket/11834
>
> it would be nice, if the CSS could be customized. But how
> to do that?
>
> I think the debug html output should be self contained.
> It should not reference a CSS file. Example: I send the
> HTML output by mail to myself, to see if uncaught exceptions have
> happened on production sites.
>
> Maybe a new (optional) setting: DEBUG_PAGE_CSS_INCLUDE='/pathto/myfile.css'
>
> After we created a patch with configurable CSS, we could make a small
> contest, and the best gets commited to be the default.

Yes, thanks, I though of anything similar.
But don't you think developers should spend time to work on the
project, not make the debug page better?
So here one-size-fits-all solution is much better rather than
customization playground.
The only reason I'm working on this patch is that without colors it's
taking some time to understand what module caused the error if
traceback contains database access, querysets manipulations or
templates processing.
However, you can edit django http500 template and create your own
version, make a good screenshot and impress us.
Just replace default 500 debug response with yours!

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

Re: Trac issues review

[burc...@gmail.com]

Hi Russell,

Thanks for clarifications of the process, but it seems I explained
some things wrong.

I see some issues have the following problems:
1) second core developer review takes a year,
2) reviewers like me who are not core developers don't know if they
will be able to say something new a ticket without reading it, and how
to find such list of tickets.

When you have not much pairs of eyeballs, it's very important to have
good tickets coverage, and if some tickets don't get reviewed in a
year, it does mean these eyeballs distribution among tickets isn't
good.

By "curator" I meant core dev team member, who got feedback last time
(or sometimes someone else who can perform core team person job). This
is different from ticket owner (yes, few years ago the ticket owner
was "curator", but now tickets are assigned to patch developer).

When I mentioned "sorting by time" I meant time of ticket last change,
not ticket creation. I explain it that we currently don't have any way
to find "stale" tickets, which are waiting for some specific action,
but no one knows what exact action.

I see it like all developers can be divided into 2 categories:
 - core dev member, who can make serious decisions, and
 - regular developers, who can only check if patch works, if they like
syntax, if there's no any simple logical flaw, or if patch doesn't
work for them, but they can't approve if patch solves the problem is
right way. Usually one want to know if they patch solve the problem
correctly before they polished patch and it got to RFC.
And in this decision making i see the big difference before regular
and core dev developers.

Basically I want to know if I can do something on ticket without
reading it through. If I can't -- I want to tell that I can't review
ticket and who can.

So, yes, the additions I propose can be mostly done automatic, with
few exceptions:
 - ticket creator marks if issue can be reviewed by any developer or
only core dev (if decision making process is still ongoing). The only
current alternative now is django-dev mailing, I'm not sure if such
mailing should be done every time more core dev clarifications are
needed -- if it is so, I'll go through a couple of my bugs and lots of
other people bugs and start a dozen of threads here right now.
 - regular developer marks if they're done with reviewing issue, and
if the only issues left are decision making ones -- transforming to
DDN again might be considered as an alternative here.

On Mon, Aug 16, 2010 at 8:28 AM, Russell Keith-Magee
 wrote:
>To me, this points to a fairly glaring logical fallacy. If a robot can
fill in new "reviewing" fields based on existing data, then doesn't
that mean that the existing data is sufficient to determine reviewing
state?
Except these two differences marked above, yes, but you can't sort
trac issues based on such derived data.

...Or maybe I'm so selfish and tend to complicate things (both is
true), and my small ticket-being-able-to-review / ticket-read ratio
should be ignored as one of the life inconveniences.

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

Re: Trac issues review

[burc...@gmail.com]

Hi Jeremy,

On Sun, Aug 15, 2010 at 11:09 PM, Jeremy Dunck <jdu...@gmail.com> wrote:
> On Sun, Aug 15, 2010 at 2:03 AM, burc...@gmail.com <burc...@gmail.com> wrote:
>> Hi Russell,
>>
>> On Sat, Aug 14, 2010 at 2:03 PM, Russell Keith-Magee
>> <russ...@keith-magee.com> wrote:
>>> On Sat, Aug 14, 2010 at 1:39 PM, burc...@gmail.com <burc...@gmail.com> 
>>> wrote:
>>>> I had few useful thoughts about changing the way Django development
>>>> contributions gets accepted and committed -- but all I get from this
>>>> mailing list that all attempts to improve any process is just a waste
>>>> of time.
>>>
>>> That's not entirely fair.
> ...
>
> Sorry, I've missed some context here -- can someone point me to the
> beginning of this thread?

Thread "#11834: colorized debug page. Assigned to buriy" (
http://groups.google.com/group/django-developers/browse_thread/thread/bd43e2e040a17784
) is the beginning.

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

Trac issues review

[burc...@gmail.com]

Hi Russell,

On Sat, Aug 14, 2010 at 2:03 PM, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
> On Sat, Aug 14, 2010 at 1:39 PM, burc...@gmail.com <burc...@gmail.com> wrote:
>> I had few useful thoughts about changing the way Django development
>> contributions gets accepted and committed -- but all I get from this
>> mailing list that all attempts to improve any process is just a waste
>> of time.
>
> That's not entirely fair.
>
> We're acutely aware of the fact that there is a backlog of tickets
> that need attention. We're also aware that many people upload patches,
> but then don't get any feedback on them. We want to improve this in
> any way we can.
>
> If you have suggestions on how we can improve Django's development
> process and address these issues, we're happy to hear them.
>
> However, that doesn't mean we're going to immediately implement a
> suggestion just because it's been made. I don't know which suggestion
> in particular you're referring to, but if you've made a suggestion and
> we haven't acted on it, then I would suggest to you that this is
> because we (the core team) didn't agree that your idea was as useful
> or practical as you think it was.
>
> If you have a suggestion, please make it. We're listening.

Ok. I think the reviewing workflow should be improved in the way core
developers, triagers and patch developers should get a list of tickets
to work on. Please correct me if I'm wrong, but I don't see any
mechanism that will allow you:
a) to find issues that needs a review (not some issues, but all issues
ordered by importance or date sent to reviewing)
b) to mark issue as reviewed.
c) to mark someone (core dev/someone else) as a curator on an issue,
so core team doesn't repeat themselves reviewing each bug multiple
times when it's not required.
The problem issues don't get attention is that no one usually know
they need their attention.
Bug states don't help a lot: they mark the maturity of solution but
not who's move is now.
And current process from my point of view is a Monte-Carlo issue
picking. It's not broken -- speed is almost the same (cause it's the
speed of commit process), but absolutely no feeling of control.

Also after the review/commit separation, we'll be able to tell
exactly, if we need more reviewers, patch writers/rewriters, core dev
team members or just committers.

>> Core devs have no time even to accept working & looking good
>> patches -- and rarely have time to review patches not looking good or
>> working wrong!
>> So why should I bother to write patches fast?
>
> I would point out that the core team aren't the only people that can
> give feedback. Trac is an open resource for exactly that reason.

Yes, this is one more point. Regular developers, like me, also don't
know what to review, and for most of patches, they just can't write a
review: they have high risk of writing wrong suggestion. Patch author
or triagers usually know if people can write a review, but people
can't find such issues.
So probably "reviewers" bugs category should also exist, but should be
also treated differently.

If we agree with such a system, I can walk through all issues
(probably with scripts), and write who needs to respond on each issue.
Patch developers usually know whether everyone wants feedback from
them, but I'd love if we were able to reduce core developers load with
introduction of such system and adding more reviewers.
Think of the following: every personal django branch on github can be
considered as adding a reviewer & committer. Why not ask them to help
with tickets? But then they need to know how they can help. We outline
issues to write patches for, but not for review.
Since tickets with needs_better_patch=1 could be both reviewed or not
reviewed, I haven't find any way to get any reviewing queue.
On implementation side, I consider two checkboxes with "[ ] needs
public review" and "[ ] needs core dev review", and a button with
"(Set me as a curator on this issue)", or maybe a text input for
curator email.
That way, DDN stage might not be needed -- it's just "unreviewed" +
"needs core dev review".
Date of last ticket update can be also added to the trac reports -- to
sort tickets based on that date.

A robot can be written to fill these fields based on other fields,
comments authors, and knowledge of who are in core dev team. I would
also consider an external service for reviewing and triaging, but that
way you won't see review states in trac.

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

Re: #11834: colorized debug page. Assigned to buriy

[burc...@gmail.com]

Hi Russell,

> However, it does need to have it's UX issues sorted out. The most
> recent substantive comment on the ticket [1] indicates that the patch
> isn't ready for checkin. It also suggests that there are broader
> improvements that may need consideration. To the best of my knowledge,
> nobody has tried to start a django-dev discussion to address those
> improvements.
>
> [1] http://code.djangoproject.com/ticket/11834#comment:5

Regarding ticket improvements, do you remember that guy who sent a
beautiful screenshot of his templates errors rework in the django dev
about half a year or a year ago? Can't find it, but I wanted
desperately to include it!

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

Re: #11834: colorized debug page. Assigned to buriy

[burc...@gmail.com]

On Fri, Aug 13, 2010 at 7:38 PM, Thomas Guettler <h...@tbz-pariv.de> wrote:
> burc...@gmail.com wrote:
>> Hi,
>>
>> On Thu, Aug 12, 2010 at 9:54 PM, Thomas Guettler <h...@tbz-pariv.de> wrote:
>>> Hi,
>>>
>>> a colorized debug page helps a lot. More than 99% of errors
>>> are in my code, and not in django's. This patch gives "own" code
>>> a different color.
>>>
>>> It is assigned to "buriy" since 6 months.
>>>
>>>  http://code.djangoproject.com/ticket/11834
>>>
>>> Why not commit?
>>
>> I'm buriy. Patch creator.
>>
>> The agreement between core devs and me (or at least how i get it) was
>> that we decided that this patch needs to be a part of larger "debug
>> page usability improvement suite".
>> My decision is that until that, the patch is "incomplete" to allow
>> only in-house use.
>
> Django: The web framework for perfectionists with deadlines
> But where/when is the deadline?
It's for django jobs, not django development itself.
> I think with "release early, release often" you get perfect code
> faster.
Unfortunately,
1) I have a lot of hobbies,
2) typical commit time even for perfect patch is almost a year! and
almost no one applies patches from django tickets.
3) and current state of patch works excellent for my projects.

I had few useful thoughts about changing the way Django development
contributions gets accepted and committed -- but all I get from this
mailing list that all attempts to improve any process is just a waste
of time. Core devs have no time even to accept working & looking good
patches -- and rarely have time to review patches not looking good or
working wrong!
So why should I bother to write patches fast?

But, if I have fans waiting for this feature, this is one good reason!

>> I can do all development changes for all suite (and finish this patch
>> of course), if we discuss how it should be done.
>>
>> My issue needs few improvements:
>>  - docs & tests
>
> AFAIK the current debug page has no docs and tests, too.
At least we need tests for color choosing based on packages paths --
this can be customized by yourself.

>>  - ability to hide some traceback elements, keeping notice they are
>> hidden -- it's so easy to shot yourself in foot otherwise.
>
> Please explain this. What do you want to hide? The page is for developers 
> only.
The most of comments I got when developing this plugin were related to
hiding some non-interesting parts of traceback. While I for myself
tried this and find it confusing, i'm not sure if other should be able
to do this -- and they might already try to do this with current
patch.

>>  - better display for decorators -- i think they either don't deserve
>> separate line or should be displayed as @decorator in the short debug
>> output.
>
> I want to see the stacktrace the way it is (nested function calls)
You get it already.

>>  - grouping template tags together and pretty display for them --
>> please see below.
>>
>> At least, after my issue, there are 2 others:
>>  - DEBUG_SHOW_DJANGO_TRACEBACK option (
>> http://code.djangoproject.com/ticket/13148 )
>>  - output for template tags should be improved, since we're displaying
>> 4 traceback blocks instead of template tag itself. There was a code
>> written for this already somewhere, there was screenshot available,
>> and it was discussed in this group, but i can't find it right now. Can
>> anyone point me at it?
And don't you want pretty output for templates lines?

>> And yes, I don't know where to find designers to get a look at my
>> implemented improvements, I'd like contact them when I'm ready.
>
> I am not a designer, but here is my opinion: Your patch highlights
> own code quite good. But there are too many colors. I like the
> colors of http://www.djangoproject.com/
> Why not use or copy parts if this style?
>
> I would just increase the size of "own" code, no different colors.

> It would be nice if you could define a list of apps that
> you consider "stable" and which should be displayed small.

I'll try this, but colors are usually much better for visual
distinction of items.
I can make a special page, and show you and others resulting
screenshots after your suggestions, and everyone who wants to add
their 2cents.

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

Re: #11834: colorized debug page. Assigned to buriy

[burc...@gmail.com]

Hi,

On Thu, Aug 12, 2010 at 9:54 PM, Thomas Guettler  wrote:
> Hi,
>
> a colorized debug page helps a lot. More than 99% of errors
> are in my code, and not in django's. This patch gives "own" code
> a different color.
>
> It is assigned to "buriy" since 6 months.
>
>  http://code.djangoproject.com/ticket/11834
>
> Why not commit?

I'm buriy. Patch creator.

The agreement between core devs and me (or at least how i get it) was
that we decided that this patch needs to be a part of larger "debug
page usability improvement suite".
My decision is that until that, the patch is "incomplete" to allow
only in-house use.
I can do all development changes for all suite (and finish this patch
of course), if we discuss how it should be done.

My issue needs few improvements:
 - docs & tests
 - ability to hide some traceback elements, keeping notice they are
hidden -- it's so easy to shot yourself in foot otherwise.
 - better display for decorators -- i think they either don't deserve
separate line or should be displayed as @decorator in the short debug
output.
 - grouping template tags together and pretty display for them --
please see below.

At least, after my issue, there are 2 others:
 - DEBUG_SHOW_DJANGO_TRACEBACK option (
http://code.djangoproject.com/ticket/13148 )
 - output for template tags should be improved, since we're displaying
4 traceback blocks instead of template tag itself. There was a code
written for this already somewhere, there was screenshot available,
and it was discussed in this group, but i can't find it right now. Can
anyone point me at it?

And yes, I don't know where to find designers to get a look at my
implemented improvements, I'd like contact them when I'm ready.

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

Re: Ticket #14007: Automatically discover models within a package without using the app_label Meta attribute

[burc...@gmail.com]

Hi Mark,

> For 'polymorphic.polymorphic_model' it would be 'polymorphic'.
Is that correct this didn't work at all (or didn't work properly)
before your patch, and now works properly, so one can put
"polymorphic.polymorphic_model" into their INSTALLED_APPS and
everything would work?
Should one import polymorphic_model from polymorphic.__init__ and put
"polymorphic" into INSTALLED_APPS?
Should one import polymorphic_model from polymorphic.models and put
"polymorphic" into INSTALLED_APPS?

In few words, how does the models discovery work for this case with your patch?

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

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

[burc...@gmail.com]

Hi guys,

To support http://code.djangoproject.com/ticket/13476 ,

it'd be great if someone converted current prints to use self.stdout
and self.stderr.

Alternative suggestions are welcome...

On Fri, Jul 16, 2010 at 6:38 AM, Russell Keith-Magee
 wrote:
> On Fri, Jul 16, 2010 at 5:39 AM, Gregor Müllegger  
> wrote:
>> Related to the issue with stdout/stderr:
>>
>> I'm aware that Russ is not a big fan of Monkeypatching :)
>
> True :-)
>
>> 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).
>
> If you want to get really technical, there *is* another way it can be
> done -- at least, if you're on a *NIX; you can redirect the file
> descriptors that represent stdout/stderr. It's low-level plumbing, but
> it works.

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

Re: natural keys and dumpdata

[burc...@gmail.com]

Hi Chris,

you're not 100% correct with this statement:

370   When ``use_natural_keys=True`` is specified, the primary key is
no longer
371 provided in the serialized data of this object since it can be 
calculated
372 during deserialization::

since in other old fixtures (that don't use use_natural_keys yet)
foreign keys can rely on objects pks from this fixture.
Or you might want to load objects by their pk for some purposes.
There might be other cases, these two are the most simple ones.

New option to tell if one should save pk or not... seems an overkill.
I've no idea if this is important and what decision to choose, but
anyway, I want to bring attention to these (rare?) cases.

On Sat, Jul 10, 2010 at 2:13 AM, SmileyChris  wrote:
> On Jul 10, 1:47 am, Stijn Hoop  wrote:
>> Hi,
>>
>> I am trying to use the 'natural keys' feature of django to make a sort
>> of "future proof" fixture loading possible.
>> [...]
>> With the patch linked below[1] I have successfully used dumpdata and
>> loaddata for a .json export of my tables. Of course I would like to
>> see something like this accepted, but this is of course a sort of
>> "feature request".
>
> It seems that my ticket in http://code.djangoproject.com/ticket/13252
> covers this. It's ready for review if anyone wants to give it a
> spin...
>
> --
> 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.

Re: LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL and SCRIPT_NAME.

[burc...@gmail.com]

Tom,

HTTP_HOST and other don't solve the multiple-host deployment, and it
is a solution you can do by yourself if you need.

I'd like to see better solution: ability to make reverse work for such URLs.
I think, currently the problem is in the binding time:

The load order is typically the following:
settings.py
*/urls.py
*/models.py
*/admin.py
*/views.py

This is not mentioned anywhere (or is it?), but if this order is
broken, "cycle in imports" errors will probably occur.

So you can't put reverse now in settings.py unless there is some
late-binding construct, like

LOGIN_URL = RevLink('accounts:login', account_type='user')

which can be resolved in views.py or admin.py or models.py into
reverse in some way (__unicode__ or __call__?).

Magic prefixes can be used as
LOGIN_URL = MAGIC + RevLink('accounts:login', account_type='user')
or even better more explicit
LOGIN_URL = RevLink('accounts:login', path=PREFIX, host=HOST,
protocol=PROTOCOL, {'account_type': 'user'})

I'd like django to have better reverse, and better inter-module bindings!

On Fri, Jul 9, 2010 at 5:47 PM, Tom Evans  wrote:
> On Thu, Jul 8, 2010 at 3:40 PM, Russell Keith-Magee
>  wrote:
>> Personally, I see this as a case of explicit vs implicit.
>>
>> As currently defined, LOGIN_URL points to the login URL. Period.
>>
>> Under the proposed patch, the onus is on every possible script to
>> ensure that the script prefix has been set correctly. WSGI will do
>> this by default, but WSGI scripts aren't the only consumers of Django
>> code. Personally, I spend almost as much time on background processing
>> scripts for sites I support as I do on pages served via HTTP.
>>
>> So - is it more confusing to require that a settings file explcitly
>> define the full URL, or to expect every script to configure itself to
>> populate the magic SCRIPT_NAME variable? Jacob's position (and I find
>> myself agreeing with this position) is that it's less confusing to
>> require the settings file to be explicit.
>>
>
> (Apologies if I've trimmed some context, I hate untrimmed replies)
>
> I can understand this position, but this could also be considered a
> case of 'implicit/explicit' vs DRY. I have one way of specifying URLs:
> they go into my urlpatterns.
> The requirement to have to repeat the same URLs in my settings.py is
> tedious, and requires me to change multiple places if I modify the
> urlpatterns - the canonical definition of the URL.
> My login/logout urlpatterns are also named 'login' and 'logout'.
>
> I'm also glad you brought up background processing. One of the common
> things we do in the background is to process new data and generate
> emails for our users.
> These emails should link directly to the website, and to do this
> requires three additional bits of information that we can't get from
> the urlconf - the protocol to access via, the host name and port, the
> local path on the host.
> These are deployment specific and (effectively) mean that all scripts
> must populate some magic variables regardless.
> Again, it would be nice if I didn't have to repeat the local path in
> four places - LOGIN_URL, LOGOUT_URL, LOGIN_REDIRECT_URL,
> HTTP_LOCAL_PATH
>
> The LOCAL_PATH is taken care of by $MAGIC (get_script_prefix()) when
> using wsgi/fcgi - so reverse('login') returns a different value when
> used within the context of a request than it does from a background
> script.
>
> Ideally, we can solve both these issues in several backwardly compatible 
> steps.
>
> Define new settings:
> HTTP_HOST
> HTTP_PROTOCOL
> HTTP_LOCAL_PATH:
>  These define the local part of the deployment location - could be
> combined into one parameter.
> AUTH_URLS_USE_NAMED_PATTERNS=False
>
> Based upon the setting of AUTH_URLS_USE_NAMED_PATTERNS, the various
> places that use the LOG*_URL settings would instead look for named
> views called 'login', 'logout' and 'post_login'.
>
> The reverse function would be changed to create a complete absolute
> URI, regardless of the context it is called from. The logic here would
> be something along the lines of prepending get_script_prefix() if set,
> or HTTP_LOCAL_PATH otherwise.
> The reverse function would also gain an additional parameter,
> specifying whether to generate a fully qualified URL, defaulting to
> the old behaviour. This could then be used in situations where we know
> we want an fully qualified URL, eg generating links to be emailed.
>
> In release+1, we can cause setting LOG*_URL to raise a
> PendingDeprecationWarning, and turn AUTH_URLS_USE_NAMED_PATTERNS to
> True by default.
> In release+2, we drop support for LOG*_URL
>
> If you're interested in seeing what a solution like this would look
> like, I could make a patch.
>
> Cheers
>
> 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-develop...@googlegroups.com.
> To unsubscribe from this group, 

Re: Proposal: {% include_partial %} template tag

[burc...@gmail.com]

Hi Jonathan,

I don't believe you really need that complicated structure:

extends -> includes -> extends.

If I were you and had this problem, I'd rewrite it to something more simple.

However, you can use {% block %} with my
http://github.com/buriy/django-containers :

:: file.html ::

{% render "greetings.html" %}
{% part greetings %}{% block greet %}Hi{% endblock %}{% endpart %}
{% part object %}{% block obj %}man{% endblock %}{% endpart %}
{% endrender %}

:: second.html ::

{% extends "file.html" %}
{% block greet %}Hello{% endblock %}

I'm not sure if that does always work, but for few my cases (including
this one), it worked. However, I've rewritten those places and don't
use this any more. It's too complex and might cause confusion. Because
you can create second template for include:

:: common.html ::

{% render "greetings.html" %}
{% part object %}
man
{% endpart %}
{% endrender %}

:: file.html ::

{# this is that django built-in tag, you see it's still highly useful
in some cases! :) #}
{% include "common.html" %}

:: second.html ::

{% render "common.html" %}
{% part greet %}Hello{% endpart %}
{% endrender %}

P.S. You can use the second syntax of
{% render "common.html" greet="Hello" %}{% endrender %}
for this case, but that can be written now as
{% with "Hello" as greet %}{% include "common.html" %}{% endwith %}

So, my last proposal for django is the following:

{% include %} to get parameters: {% include "common.html" set greet="Hello" %}
{% render %} from django-containers to be added into django, it has a
killer feature: its parts can be blocks.
There's no way to do this now in django without templatetags, but I
believe there should be one.

On Fri, Jul 9, 2010 at 8:15 PM, Jonathan S <jonathan.slend...@gmail.com> wrote:
> Something related, that we could really use is passing not just
> variables to the include, but also blocks. I tried to implement a
> template tag for this, but it doesn't work together with how Django
> replaces blocks in the extended template at compile time instead of
> during the renderering.
>
> I would like to do:
>
> ## in the main template:
> ...
> {% include "decorator.html" %}
>   {% block "content" %}
>      ...
>   {% endblock %}
> {% endinclude %}
> ...
>
> ## In decorator.html
>
>
> 
>    {% block content %}{% endblock %}
> 
>
> ##
> So, the main templates includes decorator.html, but replaces the inner
> block "content", by the block it passes to the include.
> The decorator pattern, wraps the input in some nodes.
>
> There are use cases where this is required to keep the templates DRY.
> I think only a few templating languages are able to do this.
> The .NET framework supports the design pattern pretty well, as far as
> I remember.
>
> The alternative in this particular example is to use two include tags
> "before.html" and "after.html", but is ugly because the opening and
> closing html tag are separated over different files.
>
> -- Jonathan
>
>
> On 8 juin, 19:47, Gregor Müllegger <gre...@muellegger.de> wrote:
>> 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 <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 

Re: Proposal: {% include_partial %} template tag

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

Re: Proposal: modular django configuration

[burc...@gmail.com]

On Mon, Jun 7, 2010 at 4:39 PM, Tom Evans  wrote:
> Are you proposing to determine the host name and then dynamically
> import settings from that named configuration file? What a kludge -
> that would require having every configuration file for all your sites
> checked out in the same place.
I'm not requiring anything.
You can set your own DISCOVERY_ORDER for your settings files.
You can not use autodiscovery at all.

I'm talking not about requirements but abilities.

> Each of my deployments has its location specific configuration
> deployed from administration RCS repo by cfengine to
> settings_local.py, you can keep your 'state of the art'.
How about development?
Everyone's copy-pasting required settings from settings_local.py.template ?

>
>>> It is hardly a stretch to see how this kind of code could be extended
>>> to try to import settings_auto or settings_default from each app in
>>> installed apps.
>> Sorry, I'm not native speaker. Can't understand what's "hardly a
>> stretch" neither from context nor from dictionary.
>
> How about this - 'It is easy to see how this kind of code could be
> extended to try to import settings_auto or '
I still don't understand what do you mean by this.
Adding extra configuration files?
You are still able to do this, nothing changed for you unless you want
better autodiscovery.

>> I am of control. That's why god gave us ability to override.
>> It seems you are not aware what I suggest.
>
> I fully understand what you are suggesting, you cannot seem to
> comprehend someone understanding what you are asking for, and
> disagreeing with it.
You said a point that wasn't correct.
I doubted you understood what I suggested.

> One of your use cases for this is to allow a pluggable application to
> specify it's own database settings, which is unthinkable to me.
Ok, don't think about that use case then.
With every weapon you can shoot yourself in a foot.

Can't you do "from yourapp.settings import *"
and can't that settings.py set a database for you?

> Setting up, configuring and allocating databases is work for the
> project manager, not for the application developer.
>
> Similarly for any number of other settings that can have profound
> effects on the functionality of the app, eg:
> TEMPLATE_LOADERS
> MIDDLEWARE_CLASSES
> ROOT_URLCONF
> INSTALLED_APPS
> TEMPLATE_CONTEXT_PROCESSORS
>
> and any number of project specific settings that an application may be
> unaware of. The role of configuring a project is for the project
> manager, not for the application developer. This is hardly rocket
> science!
You have special person for configuring a project.
I'm configuring my projects myself.

You are happy with your "solution", I'm not.
I'm proposing a change that will make both of us happy.

I'm telling that every project configuration have the same steps in
its development.
single file -> two files -> machine dependent config files.

The same is for the app development:
no app-specific options -> app specific options

This evolution does never change its direction.

I suggest a solution that I think might spread.
Of the problem which is already widespread, but for which every
project config developer uses different solutions.

The solution is not obligatory, it's optional.
Like everything in Django.
You will still be happy.

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

Re: Proposal: {% include_partial %} template tag

[burc...@gmail.com]

Hi Marco,

Please also get a look at http://github.com/buriy/django-containers
Which implements exactly the same, but allows larger chunks:
{% part left%}{% trans "arbitrary contents" %}{% endpart %}.

On Mon, Jun 7, 2010 at 5:03 PM, Marco Louro  wrote:
> Hi all,
>
> I'd like to propose adding a tag that includes a template with clean
> context, but can accept parameters that will be added to that
> context.
>
> The use-cases are plenty, but I've been using it mostly with forms, as
> it helps to keep the template code DRY and very customizable. We could
> use the {% with %} and {% include %} tags to do the same of course,
> but I think something like {% include_partial "forms/textfield.html"
> field=person_form.first_name label="First Name:" %} is much cleaner.
>
> This is similar to a rails tag called "render_partial" and there's a
> draft at http://gist.github.com/427116 based on
> http://freeasinbeard.org/post/107743420/render-partial-in-django

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

Re: Proposal: modular django configuration

[burc...@gmail.com]

On Sat, Jun 5, 2010 at 5:07 PM, Tom Evans  wrote:
Hi Tom,
> I'm not going to reply again, Russell has quite clearly ruled this out
> but to reply to these points:
>
> As the project manager, you can already use automatic configuration -
> its python, you can do whatever the heck you like. Your scope is not
> limited in any way, and if you want to auto-discover default settings
> from your installed apps, do so. You could even formalize this into a
> django app, publish it on googlecode and see how widely it is used by
> people without requiring any changes to django itself. If such a
> feature where to become standardized, and popular, then it could
> potentially then be included into django.contrib, but it's completely
> orthogonal to django itself - this is the benefit of using python for
> configuration.
I did: http://github.com/buriy/django-configurator
> In our deployments, a project has a default configuration, which is
> then overridden by a site specific settings_local.py, which is checked
> out on a site by site basis alongside settings.py.
>
> This is then imported into our settings with code like so:
>
> try:
>  from settings_local import *
> except:
>  # It's ok to not have any local settings.
>  pass
>
> # Convert INSTALLED_APPS and MIDDLEWARE_CLASSES into lists,
> # so we can append any extra ones supplied in settings_local.py
> if EXTRA_APPS:
>  INSTALLED_APPS = list(INSTALLED_APPS) + EXTRA_APPS
> if EXTRA_MIDDLEWARE:
>  MIDDLEWARE_CLASSES = list(MIDDLEWARE_CLASSES) + EXTRA_MIDDLEWARE
These are exactly my hate patterns.
The goal of django-configurator was to get rid of them in the projects I have.

Btw, you are not yet using the "state of the art" python-based solution:
storing different local_settings in the version control system,
so do a dynamic import based on computer DNS name.

> It is hardly a stretch to see how this kind of code could be extended
> to try to import settings_auto or settings_default from each app in
> installed apps.
Sorry, I'm not native speaker. Can't understand what's "hardly a
stretch" neither from context nor from dictionary.

>>> For example - you say that your application needs to run in a separate
>>> database. My DB Admin (or hosting provider) won't let me have another
>>> database instance. How does your automated "add this extra database"
>>> approach handle the case where I don't want you to add another
>>> database?
>> Well, in some alternative reality, an app creator might really want to
>> define a router and a special database because it's cool, not because
>> it really needs to use its legacy database with its legacy table
>> names.
>>
>> If you're afraid of using configurations incorrectly, you might either:
>>  - turn off auto configuration as a whole
>>  - redefine the DISCOVERY_ORDER as you want.
>> options.lazy.INSTALLED_APPS is a function.
>>  - override the application option in conf/apps/app.py or
>> conf/global_overrides.py .
>
> It's not fear, its confidence. As the project manager, you should be
> in control of what configurations are set, not application developers.
> How do you propose that an application insert middleware? How do you
> solve the ordering issues for settings like that? These problems
> aren't insurmountable, but it is just easier to be in control of these
> settings yourself. How hard is it to read a README and configure the
> right settings for your project.
I am of control. That's why god gave us ability to override.
It seems you are not aware what I suggest.


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

Re: Proposal: modular django configuration

[burc...@gmail.com]

On Sat, Jun 5, 2010 at 3:53 PM, Vinay Sajip  wrote:
>
> On Jun 5, 8:08 am, Russell Keith-Magee 
> wrote:
>> in which a user will be using your app. Every single time in my life I
>> have made the statement "Nobody will ever want/need to..." I have been
>> proven wrong. Consider it a corollary of Rule 34 :-)
>>
>
> That's why the YAGNI principle needs to be applied with care ;-)
>
> On this topic, though, I fully agree with you. App configuration
> should always be at the mercy of site-wide (project) configuration,
> otherwise the app's usability is severely restricted. Maybe that's
> fine for some of Yuri's apps, but as a general principle, hardwired
> connections between specific databases and apps sounds broken to me,
> too.

Hardwired connections between specific databases and apps sounds
broken to me too.
But I'm talking about providing sensible defaults.

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

Re: Proposal: modular django configuration

[burc...@gmail.com]

On Sat, Jun 5, 2010 at 2:08 PM, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
> On Sat, Jun 5, 2010 at 2:53 PM, burc...@gmail.com <burc...@gmail.com> wrote:
>> On Sat, Jun 5, 2010 at 9:43 AM, Russell Keith-Magee
>> <russ...@keith-magee.com> wrote:
>>> On Fri, Jun 4, 2010 at 11:54 PM, burc...@gmail.com <burc...@gmail.com> 
>>> wrote:
>>>> Hi Russell,
>>>>
>>>> I strongly disagree with your and Adrian vision of whether conventions
>>>> are good or not.
>>>> But I won't comment that any further. There are your political
>>>> decisions, and I have no single bit of control on them.
>>>> I know that it's impossible to persuade you, so why should I spend my
>>>> time doing this.
>>>>
>>>> However, you didn't tell anything on the problem that was the main
>>>> reason why I wrote this app.
>>>> Additive variables.
>>>>
>>>> DATABASES, DATABASE_ROUTERS, MIDDLEWARE, etc.
>>>> Do you think situation will change with them?
>>>>
>>>> In example, I want few of my apps to work with their own databases.
>>>> They need to install their database into DATABASES and their router
>>>> into DATABASE_ROUTERS.
>>>>
>>>> How would you do that?
>>>
>>> Like Tom said - you don't solve it by configuring the app. You
>>> configure the way a project uses an app, not the way an app should be
>>> used in a project. His example for configuring DATABASES is right on
>>> the money.
>>>
>>> As an example of why the 'app configuration' approach fails, consider
>>> the case of reusable apps. A reusable app can suggest defaults for
>>> settings, but once a reusable app you wrote is in my project, I need
>>> to configure it to conform to my local conditions. Your app *cannot*
>>> know what database it needs to use when it's in *my* project. That's a
>>> project configuration issue for me.
>>
>> Actually, some of my apps know what database they need to use, cause
>> they always use the same databases at the same database server unless
>> these apps are used for development. These are well established
>> applications and they have fixed names for databases (you can override
>> the names, but the names are very specific so you will never need to
>> override the names).
>
> ... until the very first time that you *do* need to. Seriously - you
> simply *cannot* make any assumptions about the deployment environment
> in which a user will be using your app. Every single time in my life I
> have made the statement "Nobody will ever want/need to..." I have been
> proven wrong. Consider it a corollary of Rule 34 :-)
>
>> This is exactly why such app sets its own database options in global.py .
>> And for each development machine I have
>> conf/development_machine1__overrides.py which contains overrides.
>> I believe it's better than having "if socket.getfqdn() ==
>> 'development_machine1':" conditions in settings.py
>>
>> But, if *my* app doesn't know what database to use in *your* project, then:
>> 1. It will provide sensible and customizable defaults for app-specific
>> database and app name (let's call them app.LABEL and app.DB) in its
>> own options namespace (yes, GSoC app loading feature will handle
>> that).
>> 2. That variable will be used for its router.
>> 3. Router will add itself into DATABASE_ROUTERS
>> 4. No any settings will be added into DATABASES.
>> And if your used django-configurator, then the rules are pretty simple:
>> 5. Database will be added into the list of the databases in conf/global.py
>> 6. For development machine(s), this database will be overridden in
>> conf/development_machine1__overrides.py
>
> And to all of this, I'd fall back on the Zen of Python: explicit is
> better than implicit.
I can remember "sparse is better than dense" and a line that
namespaces are a good idea.

> IMHO, this is doubly true when dealing with something as critical as
> configuration -- personally, I want my configuration files to do
> *nothing* surprising or automatic.
It's just a tradeoff between DRY and explicitness, as everything else.
Suggested approach doesn't force you to use automatic configuration.
You may not use it. But why can't I use automatic configuration,
and why 3rd-party plugins creators can't?
This is a question of creditability to this configuration model at all.

> For example - you say that your application needs to run in a separate
> database. My DB Admin (or hosting provider) won't let 

Re: Proposal: modular django configuration

[burc...@gmail.com]

On Sat, Jun 5, 2010 at 9:43 AM, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
> On Fri, Jun 4, 2010 at 11:54 PM, burc...@gmail.com <burc...@gmail.com> wrote:
>> Hi Russell,
>>
>> I strongly disagree with your and Adrian vision of whether conventions
>> are good or not.
>> But I won't comment that any further. There are your political
>> decisions, and I have no single bit of control on them.
>> I know that it's impossible to persuade you, so why should I spend my
>> time doing this.
>>
>> However, you didn't tell anything on the problem that was the main
>> reason why I wrote this app.
>> Additive variables.
>>
>> DATABASES, DATABASE_ROUTERS, MIDDLEWARE, etc.
>> Do you think situation will change with them?
>>
>> In example, I want few of my apps to work with their own databases.
>> They need to install their database into DATABASES and their router
>> into DATABASE_ROUTERS.
>>
>> How would you do that?
>
> Like Tom said - you don't solve it by configuring the app. You
> configure the way a project uses an app, not the way an app should be
> used in a project. His example for configuring DATABASES is right on
> the money.
>
> As an example of why the 'app configuration' approach fails, consider
> the case of reusable apps. A reusable app can suggest defaults for
> settings, but once a reusable app you wrote is in my project, I need
> to configure it to conform to my local conditions. Your app *cannot*
> know what database it needs to use when it's in *my* project. That's a
> project configuration issue for me.

Actually, some of my apps know what database they need to use, cause
they always use the same databases at the same database server unless
these apps are used for development. These are well established
applications and they have fixed names for databases (you can override
the names, but the names are very specific so you will never need to
override the names).

This is exactly why such app sets its own database options in global.py .
And for each development machine I have
conf/development_machine1__overrides.py which contains overrides.
I believe it's better than having "if socket.getfqdn() ==
'development_machine1':" conditions in settings.py

But, if *my* app doesn't know what database to use in *your* project, then:
1. It will provide sensible and customizable defaults for app-specific
database and app name (let's call them app.LABEL and app.DB) in its
own options namespace (yes, GSoC app loading feature will handle
that).
2. That variable will be used for its router.
3. Router will add itself into DATABASE_ROUTERS
4. No any settings will be added into DATABASES.
And if your used django-configurator, then the rules are pretty simple:
5. Database will be added into the list of the databases in conf/global.py
6. For development machine(s), this database will be overridden in
conf/development_machine1__overrides.py

In your case the configuration will be like this:

FOO_APP_DB_NAME = 'fooapp'
FOO_APP_APP_LABEL = 'fooapp'
DATABASES = { 'default': { ... }, 'fooapp': { ... }, }
if socket.getfqdn() == 'development_machine1':
DATABASES['fooapp'] = { ... }
DATABASE_ROUTERS = ('fooapp.routers.Router',...)

I had this before django-configurator, and I don't think it was any
better than it is now.

You can't even do

from foo_app.settings import *

cause that won't let you to add a router or set up a database!

(well, you can do
import_from_file(locals(), socket.getfqdn().replace('.','_').replace('-','__'))
but it's effectively the same I do in configurator.autodiscover(locals())
hm... do you think this one is a common boilerplate for importing
machine-dependent settings?
)

As alternative, maybe, do we need a registry for routers instead of
settings variable?
The same question should be asked for other additive variables in
settings.py of course.

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

Re: Proposal: modular django configuration

[burc...@gmail.com]

Hi Russell,

I strongly disagree with your and Adrian vision of whether conventions
are good or not.
But I won't comment that any further. There are your political
decisions, and I have no single bit of control on them.
I know that it's impossible to persuade you, so why should I spend my
time doing this.

However, you didn't tell anything on the problem that was the main
reason why I wrote this app.
Additive variables.

DATABASES, DATABASE_ROUTERS, MIDDLEWARE, etc.
Do you think situation will change with them?

In example, I want few of my apps to work with their own databases.
They need to install their database into DATABASES and their router
into DATABASE_ROUTERS.

How would you do that?

On Fri, Jun 4, 2010 at 7:57 PM, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
> On Fri, Jun 4, 2010 at 3:30 PM, burc...@gmail.com <burc...@gmail.com> wrote:
>> Hi Russell,
>>
>> My writing style sometimes is really clumsy. I'm sorry about that.
>>
>> You might look at the end of the first message in the thread.
>> Or maybe the thread topic.
>>
>> The problem is that half of third party plugins write: "after install,
>> add this and this and this to settings.py".
>> The problem is that I have reusable applications and they have their
>> bits of default configuration, have their own options.
>>
>> Problem is that some of such settings are additive, like
>> MIDDLEWARE_CLASSES, DATABASES or DATABASE_ROUTERS, and you wanted to
>> give an app the possibility to configure their part of global
>> configuration, but not override settings which are set by another
>> applications.
>>
>> Problem is that, like everybody, I have different machines where i run
>> my projects, and they have different settings (DEBUG, DATABASES, etc).
>>
>> I'm not the first here. The problem and the common ways to solve it
>> are already observed in Django wiki under
>> http://code.djangoproject.com/wiki/SplitSettings section.
>
> And, as the wiki says:
>
> """
> We don't need a default solution for this. It's not within the scope
> of this project to tell people how they should organize their settings
> files. Take that opportunity to showcase your individualism.
> """
>
> I agree with Adrian -- this isn't an area where a complex set of
> builtin tools will improve the situation. Every situation will have
> slightly different requirements. The good thing about Django using
> Python for configuration is that just about anything is possible.
>
> That said, there are some common patterns, and we should do a better
> job at documenting these patterns -- if only to highlight how flexible
> the configuration system can be.
>
>> Probably, the problem with additive settings is the hardest one here.
>> Currently I don't see any alternative solution better than my.
>
> The wiki page you mention lists half a dozen approaches, and still
> doesn't mention the obvious option: from submodule.settings import *
>
> I'm simply not convinced that this is as big a problem as you make
> out. I have some large projects with lots of apps and lots of
> settings, but with some organizational discipline and the use of
> python imports, I've been able to manage that complexity.
>
> The only area in this that I might concede that there is need for
> major improvement is in applications providing default values for
> their own settings (i.e., contrib.admin default settings should be
> defined by contrib.admin, not in global_settings.py). However, I don't
> think this requires the introduction of a complex setting
> autodiscovery process -- it just requires a convention about where
> default values can be placed in an app so that they will be picked up
> by the settings initialization process.
>
> In fact, I would almost argue that it's a *good* thing that it's hard
> for applications to add default settings -- I'm not a big believer in
> the dictum that more settings necessarily make things better. Settings
> are required to point applications at specific services, or to
> configure specific extension points. However, IMHO, an application
> that requires dozens of carefully configured settings is often an
> indication of a poorly designed app.
>
> As for 'application configuration files' -- I think this is a
> misnomer. Whenever you deploy a Django project, you're deploying a
> project -- an amalgam of multiple apps. There's no such thing as the
> configuration for a single app. All apps are potentially dependent on
> other apps -- consider the potential impact of middleware and context
> processors on the operation of any application. When you configure a
> Django project, you really are configur

Re: Proposal: modular django configuration

[burc...@gmail.com]

Hi Russell,

My writing style sometimes is really clumsy. I'm sorry about that.

You might look at the end of the first message in the thread.
Or maybe the thread topic.

The problem is that half of third party plugins write: "after install,
add this and this and this to settings.py".
The problem is that I have reusable applications and they have their
bits of default configuration, have their own options.

Problem is that some of such settings are additive, like
MIDDLEWARE_CLASSES, DATABASES or DATABASE_ROUTERS, and you wanted to
give an app the possibility to configure their part of global
configuration, but not override settings which are set by another
applications.

Problem is that, like everybody, I have different machines where i run
my projects, and they have different settings (DEBUG, DATABASES, etc).

I'm not the first here. The problem and the common ways to solve it
are already observed in Django wiki under
http://code.djangoproject.com/wiki/SplitSettings section.

Probably, the problem with additive settings is the hardest one here.
Currently I don't see any alternative solution better than my.

However, GSoC app loading project could change situation drastically,
and maybe in the end of summer I'll change my mind of the better
solutions for configuration problems. But currently it aims to change
the way how per-application-instance settings are set, not global
settings. In the opposite, I'm interesting mainly in splitting global
settings into different modules.

Also please note, that the more different applications you want to
reuse, the more recognizable the problem is to you. I don't try to
accuse you that you don't seem to have a lot of reusable applications
in your projects -- you might already use some of the methods
described in SplitSettings wiki page, or you're just a fan of big
settings.py file -- I'm just telling you that I'm a big fan of modular
projects, and have dealt with them a lot, and so I wanted to have
really good and obvious solution for the configuration problem.

On Fri, Jun 4, 2010 at 7:04 AM, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
> On Thu, Jun 3, 2010 at 11:19 PM, burc...@gmail.com <burc...@gmail.com> wrote:
>> Hi all,
>>
>> I've written a prototype, and put it on
>> http://github.com/buriy/django-configurator.
>> It has few good design decisions, and few maybe not that good.
>> Anyway, I consider it as a good addition to app loading GSoC Proposal,
>> which is currently being worked on.
>
> Hi Yuri,
>
> I might be missing something really obvious, but I can't make any
> sense out of your proposals. After two quite lengthy emails, I haven't
> even been able to work out what what problem you are actually trying
> to solve.
>
> Your initial proposal consisted of pages of snippets of configuration,
> but no explanation of how those pieces fit together (or at least, I
> couldn't follow it). It might be helpful if you step back from the
> details and try to give a big picture view of what you're trying to
> do.
>
> 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.
>
>



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

Re: Proposal: modular django configuration

[burc...@gmail.com]

Hi all,

I've written a prototype, and put it on
http://github.com/buriy/django-configurator.
It has few good design decisions, and few maybe not that good.
Anyway, I consider it as a good addition to app loading GSoC Proposal,
which is currently being worked on.

The key highlights of the implementation are the following:

The first concept is the options object. Options can be global or
belong to applications:

>>> from configurator import options
>>> options.KEY = 1
>>> options.apps['myapp'].KEY = 2
>>> type(options)

>>> type(options.apps)

>>>  type(options.apps['myapp'])


If the key is missing, DictList is provided:

from configurator import options
>>> KEY = options.SOME_KEY
>>> type(KEY)

>>> id(KEY) == id(options.SOME_KEY)
True

Next concept is DictList. DictList is options holder and it allows one
to set a global option in advance, providing data from one module to
another, not having to deal with applications order in INSTALLED_APPS.

Can be used as an ordered set:

>>> KEY += 'xxx'
>>> KEY
['xxx']
>>> KEY -= 'yyy'
>>> KEY += 'yyy'
>>> KEY
['xxx', 'yyy']
>>> KEY -= 'xxx'
['yyy']

In Django, this can be used for AUTHENTICATION_BACKENDS,
TEMPLATE_CONTEXT_PROCESSORS, MIDDLEWARE_CLASSES, ADMINS, LANGUAGES and
other settings.

Or as an ordered dict:
>>> D = DictList()
>>> D['abc'] = 'def'
>>> D['key'] = 'value'
>>> D.default = '(default)'
>>> D
{default=(default), 'abc': 'def', 'key': 'value'}
In Django, this can be used for DATABASES setup, and, i hope, in 1.3,
for LOGGING setup and APP_MEDIA setup.

Currently I'm not using SortedDict for DictList implementation to not
depend on Django.

The next concept is autodiscover. It allows you to have different
configuration bits for every application or for different servers.
For basic use in django applications, you can put this call in the end
of the settings.py:

autodiscover(locals())

It does the following:
 1) puts all written in caps settings from settings.py into options,
wrapping lists, tuples and dicts into DictList
 2) iterates over options.DISCOVERY_ORDER, defined by default as the following:

options.DISCOVERY_ORDER = [
ListFiles(options.lazy.CONF, 'global'),# conf/global.py
ListFiles(options.lazy.CONF, options.lazy.SITE), # conf/.py
ListFiles(options.lazy.INSTALLED_APPS, 'conf'), # app1/conf.py
ListFiles(options.lazy.APP_CONF, options.lazy.INSTALLED_APPS), #
conf/app1.py
ListFiles(options.lazy.CONF, 'global', '_overrides'), #
conf/global_overrides.py
ListFiles(options.lazy.CONF, options.lazy.SITE, '_overrides'), #
conf/_overrides.py
]
Every application can update any option in such files.

Please note, that this DISCOVERY_ORDER is lazy, and you can set
options.CONF to your own folder in settings.py, or do the similar
thing with other options before DISCOVERY_ORDER will be evaluated.

3) writes updated settings back to settings.py

If you don't want to change anything in settings.py, you can do
autodiscover(), update_options() and update_back_settings() manually
in any moment of time.

Exceptions, raised in configuration modules, are isolated. If one of
your conf files failed to load, console message will appear, or, in
addition to the message, application will fail with traceback if
console is not a tty.

Known issues: since global django settings are read and set
independently from settings.py, they don't know anything about each
other. So if you do AUTHENTICATION_BACKENDS += 'logins.MyBackend', no
django.contrib.auth.backends.ModelBackend will be added.

On Fri, May 28, 2010 at 6:19 AM, burc...@gmail.com <burc...@gmail.com> wrote:
> Hi everybody,
>
> Everyone loves the way templates are discovered in django.
> No one loves settings.py that much.
>
> This is proposal on how to improve situation significantly.
>
> Configuration facility is suggested in addition to django.conf.settings.
> Configuration is going to be put into conf/ directory of the project
> (or settings/ -- just set config.global.CONFIG).
>
> :: settings.py ::
> from django.conf import config
> from os.path import dirname, abspath, join
> ROOT = dirname(abspath(__name__)) # type 'str'
> INSTALLED_APPS = ...
>
> config.global.ROOT = ROOT
> config.global.CONFIG = join(ROOT, 'conf')
> config.autodiscover()
> # config.global is in fact a synonym for settings
>
> :: conf/global.py ::
> # runs before the app settings
> from django.conf import config
> from os.path import dirname, abspath
> ROOT = config.global.ROOT # type 'str', empty if not set.
> config.global.JQUERY.default = JQUERY = ROOT +
> 'static/js/jquery-1.3.2-min.js' # type 'dict', setting default value
> for missing items
> config.global.JQUERY['1.3.2'] = JQUERY # type 'unordered dict with
> default value', now se

Re: Feature idea

[burc...@gmail.com]

Hi Dj Gilcrease,

I've almost implemented kinda similar proposal (draft here:
http://groups.google.com/group/django-developers/browse_thread/thread/b7339d8577567d95
),

and what worries me, is that in current Django you just can't do
autodiscover of django contribs in settings.py because of circular
dependency on django.db.utils.

On Wed, Jun 2, 2010 at 1:43 AM, Dj Gilcrease  wrote:
> 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.
>
>



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

Re: Static media handling - ticket 12323

[burc...@gmail.com]

Hi all,

> - a media files path resolver -- following a similar directory structure as 
> the app templates loader (/media/ vs. /templates/)
> - build_static -- a mangement command that'll collect media files from apps 
> from various locations using the media files path resolver and uses a file 
> storage backend to copy (or link to) the found files (file storage backend by 
> default), used during deployment
> - an extended media file serving view that uses the media files path resolver 
> (in debug mode), backwards compatible replacement for 
> django.core.servers.basehttp.AdminMediaHandler

Couldn't agree more. But three more points:
1) Media files are linked from applications forms, so what will happen
if user rename an app?
Do we need some config piece for this kind of reverse?
Something like app_media(app_name=None) function and APP_MEDIA?

2) More generally, we need per-application settings to handle this
sort of configuration problems.
One that will be autodiscovered like templates and admin. And it can
contain additive variables for MEDIA, like suggested in my
configuration proposal:
http://groups.google.com/group/django-developers/browse_thread/thread/b7339d8577567d95

3) I've seen a solution recently that generates apache and lighttpd
install scripts, found it much better than symlinks for media in
production.
But this one definitely needs additive variables and per-application
configuration!

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

Proposal: modular django configuration

[burc...@gmail.com]

Hi everybody,

Everyone loves the way templates are discovered in django.
No one loves settings.py that much.

This is proposal on how to improve situation significantly.

Configuration facility is suggested in addition to django.conf.settings.
Configuration is going to be put into conf/ directory of the project
(or settings/ -- just set config.global.CONFIG).

:: settings.py ::
from django.conf import config
from os.path import dirname, abspath, join
ROOT = dirname(abspath(__name__)) # type 'str'
INSTALLED_APPS = ...

config.global.ROOT = ROOT
config.global.CONFIG = join(ROOT, 'conf')
config.autodiscover()
# config.global is in fact a synonym for settings

:: conf/global.py ::
# runs before the app settings
from django.conf import config
from os.path import dirname, abspath
ROOT = config.global.ROOT # type 'str', empty if not set.
config.global.JQUERY.default = JQUERY = ROOT +
'static/js/jquery-1.3.2-min.js' # type 'dict', setting default value
for missing items
config.global.JQUERY['1.3.2'] = JQUERY # type 'unordered dict with
default value', now setting arbitrary key
config.global.MEDIA += [ROOT + 'static/js/'] # type 'ordered set with
default value'
config.global.DATABASES['default'] = {...} # backward-compatibility,
so using 'default' not .default!
# Note: after type is set for constant, the type can't be changed.
# Note: please set to tuple not list if you need a clear sign the
option won't be additive any more.

:: conf/global_overrides.py ::
# runs after all other settings but before _overrides, see below
# is now empty

:: conf/apps/myapp.py ::
# runs after all app-specific settings
app.DATABASES['db3'] = {...}
app.ROUTERS += ['Db3_is_readonly']

:: conf/www_server_com.py
# runs before app-specific settings
from django.conf import config
config.global.MEDIA_ROOT = '/var/site/www.server.com/site_media/'
config.global.MEDIA_URL = 'media.server.com'
app.MIDDLEWARE += ['caching.smart_caching_app.SmartCacher']

:: conf/www_server_com_overrides.py
# runs after app-specific settings
config.global.JQUERY['1.3.2'] = 'static/packed.js'
config.global.JQUERY['1.4.2'] = 'static/packed.js'

:: myapp/conf.py ::
# runs in order specified in INSTALLED_APPS
from django.conf import config
app = config.apps.myapp
app.DEPENDS += ['django.contrib.auth']
app.STATIC = app.global.ROOT + 'media/myapp/'
app.IMAGES = app.global.ROOT + 'media/uploads/images/'
app.THUMBS = app.global.ROOT + 'media/uploads/thumbs/'
config.global.MEDIA += [app.IMAGES, app.THUMBS, app.JSES, app.CSSES]
config.global.JQUERY['1.4.2'] = STATIC + 'js/'
config.global.TAGS += ['app1.templatetags.mytags']

:: myapp/forms.py ::
from django.conf import config

app = config.apps['myapp']
class MyForm:
class Media:
css = app.STATIC + 'css/base.css'
js = config.global.JQUERY['1.4.2']

The ultimate order:

django/conf/global.py
conf/__init__.py
conf/global.py#  -- you can also set your own personal order there
conf/.py
app1/conf.py # -- single pass is enough, cause applications can both
provide callbacks for later configuration stages.
app2/conf.py
...
appN/conf.py
conf/apps/app1.py
conf/apps/app2.py
conf/apps/appN.py
conf/global_overrides.py
conf/_overrides.py

* for www.my-site.com is www_my__site_com (dots replaced with
underlines, dash with double underline).
socket.getfqdn() is used for determining current site.

The motivation is simple:
the bigger your list of application grows, the larger configuration
you will have!
Django has more than 100 of different settings options.
They are not even grouped now.
I hope such django "built-in" type of configuration will suit 99% of
the possible Django projects, and will make django community much
stronger.

I'm going to create a prototype.

Expected benefits:
 - 3rd-party applications can be used without a bit of touching and
still customized perfectly.
 - Application can connect to each other in dynamic way, or provide
different kinds of plugin points.
 - Fixed models dependencies can be replaced with dynamic (i.e, each
application might ask for personal User or UserProfile replacement)
 - Really simple media setup for both development and production servers.
 - A number of development and production configurations can coexist
in the project, without single 'if'
 - Per-application configuration for middlewares, databases, routers,
context processors and other "additive" options
 - Preconditions for visual application settings (Needs another proposal)
 - Django core settings will be moved to namespaces and grouped semantically.
 - Sparse config is better than dense.

Why it needs to be in the django core, not just 3rd-party plugin:
 - Because "Namespaces are one honking great idea -- let's do more of those!"
 - Because config ubiquity between projects is the main project benefit.

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

Re: Template Tag Not Reinitialized in Loop

[burc...@gmail.com]

I bet context['page'] is different each time, but the tag
initialization is called only once.
So it's probably your programming error, not a bug in django.

On Tue, May 11, 2010 at 1:29 AM, patrick91  wrote:
> I've this problem too
>
> I created a custom template tag that renders info about a model
>
> but when I use that tag in a for the tag is used just one time. Like
> this
>
> {% for page in pages %}
> {% show_info page %}
> {% endfor %}
>
> ---
>
> page info #1
> page info #1
> page info #1
>
> should I provide my custom template tag code?
>
>
> Thanks for any reply :)
>
> --
> 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.

Re: Trac workflow assistance (commiter feedback needed)

[burc...@gmail.com]

Hi Russell, Jacob,

What do you think, is it good idea to write django-based bug tracker
as a trac replacement?
As we all know, Django would be a perfect fit for such project!

Current Trac templates & layouts can be used for prototyping the project.

On Sun, Apr 25, 2010 at 6:15 PM, Russell Keith-Magee
 wrote:
> On Sun, Apr 25, 2010 at 10:54 PM, yml  wrote:
>> Hello,
>>
>> On Apr 23, 12:32 pm, Russell Keith-Magee 
>> wrote:
>>> On Fri, Apr 23, 2010 at 3:04 PM, Jeremy Dunck  wrote:
>>> > Commiters and triagers,
>>> >  I've gone through the contributing doc and tried to identify places
>>> > that tickets might get stuck (or other places that automation might
>>> > smooth the process).
>>> >  If you could take a few minutes to give feedback on the list,
>>> > hopefully prioritizing in your named column with +/- 0/1, it'd help me
>>> > focus effort.
>>>
>>> Comments by row number from the spreadsheet:
>>>
>>> 2: Would be useful as a work list for people looking for. It would
>>> also be useful if tickets could be auto-disowned; i.e., if there's no
>>> activity from the owner after a month, post a comment asking for a
>>> status update; if no activity after another month, remove the
>>> ownership. This might get annoying for long-lived tickets with an
>>> owner that has a vested interest, though.
>>>
>>> 3: That's essentially just a list of people who can't (or won't) read
>>> the contribution guide. I'm not sure tracking that stat would help.
>>>
>>> 4: Is essentially a list of 'active tickets'. I keep track of that by
>>> manually eyeballing Trac updates; it might be a useful stat to have
>>> exposed for people who don't watch Trac as much as I do.
>>>
>>> 5-10: The most useful of the lot for me personally. An automated
>>> process that applies patches and runs tests would be nice; if it can
>>> autocheck the appropriate flags ("patch needs improvement", "needs
>>> tests" etc) that would be even better.
>>>
>>> There are edge cases that will make this difficult; e.g., patches that
>>> span multiple diffs, or tickets where the submitter provides multiple
>>> alternative patches.
>>>
>>> I would also add to this list checks that the test is actually a
>>> regression test - that is, that the contributed test fails unless the
>>> rest of the patch is applied.
>>>
>>> I'm also not sure if a direct email or adding a comment to the ticket
>>> in trac would be the best approach. I suspect a comment would be
>>> better, since it provides a public record of the automated reporting
>>> activity.
>>>
>>> 11: Useful as a working list for someone looking for something to do.
>>>
>>> 12-14: Nifty stats, but I'm not sure they would help much
>>>
>>> 15-17 would be useful if we wanted to audit the work of volunteers,
>>> but that's not really something we do. I keep a rough eye on every
>>> ticket change as they come in; if something looks way off, I'll jump
>>> on it, but otherwise I just live and let live and let the crowd sort
>>> it out.
>>>
>>> 18: I'd be interested to see what this produces. My gut tells me that
>>> tags aren't used often enough (or consistently enough) for this to
>>> provide any real patterns. However I might be wrong. If it works, it
>>> might be a handy way to work out common themes that need a broader
>>> approach.
>>>
>>> 19: Again, like 3; this is just a list of people who don't follow process.
>>>
>>> > Also, I'm planning on building the tool using the XMLRPC trac plugin
>>> > (I'm assuming the live app can't easily have access to the DB, or that
>>> > the RPC API's abstractions are useful at the app level).  Correct me
>>> > if I'm wrong.
>>>
>>> If you're looking to implement this as a standalone thing, it probably
>>> *could* access the Trac DB directly, but in the interests of
>>> everyone's sanity (including Trac's) it's probably best to keep to
>>> public interfaces like XMLRPC.
>>>
>>> However, it's also possible that some of these features would best be
>>> implemented as a Trac plugin.
>>>
>>> I'd also suggest that before you embark on a big Trac-specific
>>> tool-building exercise that we investigate what we could gain by
>>> moving to another bug tracking tool. I'm not a huge fan of Trac - it's
>>> got lots of quirks and bugs that annoy the bejezus out of me, and
>>> there are many aspects of Django's development process that aren't
>>> well suited to Trac's model (as the recent discussions about process
>>> have indicated). If there are tools out there that are better suited
>>> to our needs, I'm interested in hearing options.
>>>
>>> Caveat: This isn't an invitation for people to just start listing Trac
>>> alternatives. If we're going to change, we're going to change because
>>> of a compelling reason, not just so we can change the color of the
>>> furniture. If you want to propose an alternative, you need to provide
>>> a list of features that Trac doesn't have, but are well aligned to
>>> 

Re: Trac workflow assistance (commiter feedback needed)

[burc...@gmail.com]

Hi Jeremy,

And what about information on the page if the patch commits cleanly,
and if all tests pass after applying patch?
Not just sending email to the patch author, but making it visible to everyone.

On Fri, Apr 23, 2010 at 10:04 AM, Jeremy Dunck  wrote:
> Commiters and triagers,
>  I've gone through the contributing doc and tried to identify places
> that tickets might get stuck (or other places that automation might
> smooth the process).
>  If you could take a few minutes to give feedback on the list,
> hopefully prioritizing in your named column with +/- 0/1, it'd help me
> focus effort.
>  http://spreadsheets.google.com/ccc?key=0ApFMbbFef2aVdE1TZThZY01ValRKUUVOT1oxck1VaWc=en
>
>  I added people from the commiter page; we still don't have triagers
> named publicly, I think, and so didn't hazard an incomplete list of
> triagers. Please just add yourself if you're a triager and would like
> to vote.
>
> Also, I'm planning on building the tool using the XMLRPC trac plugin
> (I'm assuming the live app can't easily have access to the DB, or that
> the RPC API's abstractions are useful at the app level).  Correct me
> if I'm wrong.
>
> In any case, I'd like to have a local copy of the trac DB so that I
> can be abusive to the RPC API while testing/building, work offline,
> etc.
>
> Can a DB dump be shared?
>
> --
> 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.

Re: NoSQL Support for the ORM

[burc...@gmail.com]

Hi Waldemar, Alex,

why you didn't do different threads for the different issues? :\

Regarding getting .filter() to work, I suggest we will use explicit
and implicit indexes, something like this:

class User(models.Model):
   username = models.CharField(max_length=200, db_index=True) #
db_index=True should add the third line implicitly
   email = models.CharField(max_length=200) # db_index=True can help,
but we have to go explicit here.
   email = models.CharField(max_length=200, unique=True,
db_index='lowercase') # further ideas on lowercase support
   #username_index = models.Index(['username'], 'pk')  # line 3
   email_index = models.Index(['email'], 'pk',
filter={'email':'lowercase'}) # line 4
   ...

And user will write:
users = User.objects.filter(email_index__startswith='me@')

Or:

class UsernameIndex(models.Index):
model = User
keys = ['category', 'email']
values = ['id']

def clean_email(value):
return value.lower()

and the user writing:
users = UsernameIndex.objects.filter(email__startswith='me@', category='staff')

But I don't think it has related to GSoC at all.
And this can be made outside of Django.

The same for Counters:

class User(models.Model):
   username = models.CharField(max_length=200, db_index=True)
   email = models.CharField(max_length=200)
   category = models.CharField(max_length=20, choices=(('S', 'Staff'),
('U', 'User'))
   counter = aggregates.Counter('category') # count number of users by category

I think, we should go with a separate Django proposal(s), don't put
that on Alex's shoulders.

What Alex will need to provide, is a way to assign a hook for
.filter() from QuerySet, which probably should be put into some kind
of NosqlManager (which will replace Manager at User.objects).

On Thu, Apr 8, 2010 at 8:08 PM, Waldemar Kornewald  wrote:
> On Thu, Apr 8, 2010 at 6:14 PM, Alex Gaynor  wrote:
>> On Wed, Apr 7, 2010 at 4:43 PM, Waldemar Kornewald  
>> wrote:
>>> On Wed, Apr 7, 2010 at 5:12 PM, Alex Gaynor  wrote:
 No.  I am vehemently opposed to attempting to extensively emulate the
 features of a relational database in a non-relational one.  People
 talk about the "object relational" impedance mismatch, much less the
 "object-relational non-relational" one.  I have no interest in
 attempting to support any attempts at emulating features that just
 don't exist on the databases they're being emulated on.
>>>
>>> This decision has to be based on the actual needs of NoSQL developers.
>>> Did you actually work on non-trivial projects that needed
>>> denormalization and in-memory JOINs and manually maintained counters?
>>> I'm not making this up. The "dumb" key-value store API is not enough.
>>> People are manually writing lots of code for features that could be
>>> handled by an SQL emulation layer. Do we agree until here?
>>>
>>
>> No, we don't.  People are desiging there data in ways that fit their
>> datastore. If all people did was implement a relational model in
>> userland code on top of non-relational databases then they'd really be
>> missing the point.
>
> Then you're calling everyone a fool. :) What do you call a CouchDB or
> Cassandra index mapping usernames to user pks? Its purpose it exactly
> to do something that relational DBs provides out-of-the-box. You can't
> deny that people do in fact manually maintain such indexes.
>
> So, you're suggestion to write code like this:
>
> # --
> class User(models.Model):
>    username = models.CharField(max_length=200)
>    email = models.CharField(max_length=200)
>    ...
>
> class UsernameUser(models.Model):
>    username = models.CharField(primary_key=True, max_length=200)
>    user_id = models.IntegerField()
>
> class EmailUser(models.Model):
>    email = models.CharField(primary_key=True, max_length=200)
>    user_id = models.IntegerField()
>
> def add_user(username, email):
>    user = User.objects.create(username=username, email=email)
>    UsernameUser.objects.create(username=username, user_id=user.id)
>    EmailUser.objects.create(email=email, user_id=user.id)
>    return user
>
> def get_user_by_username(username):
>    id = UsernameUser.objects.get(username=username).user_id
>    return User.objects.get(id=id)
>
> def get_user_by_email(email):
>    id = EmailUser.objects.get(email=email).user_id
>    return User.objects.get(id=id)
>
> get_user_by_username('marcus')
> get_user_by_email('mar...@marcus.com')
> # --
>
> What I'm proposing allows you to just write this:
>
> # --
> class User(models.Model):
>    username = models.CharField(max_length=200)
>    email = models.CharField(max_length=200)
>    ...
>
> User.objects.get(username='marcus')
> User.objects.get(email='mar...@marcus.com')
> # --
>
> Are you seriously saying that people should use the first version of
> the code when they work with a simplistic NoSQL DB (note, it's how
> they work 

Re: [GSoC] Application Loading

[burc...@gmail.com]

Hi Nick,

I don't like your application creation syntax (why using dict-based
DSL instead of class-based?), but
I like how you approach the overall problem.
More than that, you have shown you do understand all the problems
you're going to solve, and that you have design skills required for
solution.
But I believe you can do even further with your proposal.

You said:
>Model classes will get a ``_meta.app`` attribute, which will be an instance
of the model's ``Application`` class. Models should only be associated with one
application.
This is very nice idea, and I think, it allows to come with further
design of how should multiple app copies work.
I don't want to push on you, or suggest a working solution, so I'd
like to see your ideas.

I've got questions that might help:
 * how will views know about their current application?
 * how will views get their app settings after your changes?
 * is it a good idea to make urls properties (namespace, app_name)
correspond with the same application properties?

Currently options are either "from django.conf import settings", and
those settings are singleton with configuration options, or put into
urls.

Should we say "go away" to view-as-a-function and go to rails-like
controllers like your Application class?

(I'm for this option actually, all views other than "hello world"
always take such a bloat of configuration options right now that needs
to be put into controllers anyway -- look at django.contrib.auth.views
for example!)

(Completely unrelated note, but I'd rather see a url routing right
near those views definition after update. because, 98% of times, you
won't need urls at all!)

Please also see the thread
http://groups.google.com/group/django-developers/browse_thread/thread/4cca2086dd485879?hl=en,
there's a question you avoided delicately, about what to do with
ForeignKey. It might also help.

On Thu, Apr 8, 2010 at 7:33 PM, Nick Sandford  wrote:
> An App Loading mechanism for Django
> 
>
> About Me
> --
> Hi everyone,
>
> My name is Nick Sandford, I'm an electrical engineering student at the
> University of Western Australia.
>
> Background
> ---
>
> I haven't been a particularly active contributor to any open source project -
> here is where I hope to change that. In my current work at Christ
> Church Grammar School we use Django heavily for most of our internal
> projects. I've
> followed django-dev closely for a couple of years and I have poked around with
> its internals on various occasions.
>
> Plan
> -
>
> Implement an improved application loading mechanism into Django.
>
> Rationale
> -
>
> Django current application loading code is inflexible in many cases. There
> exists a need for a number of extra features to be added to the way
> applications are handled such as:
>
>  * The ability to internationalise application names.
>  * The ability to customise application names similar to ``verbose_name`` in
>    ``model._meta``
>  * Deploy the same application multiple times in a single project.
>  * Deploy two different applications with the same name.
>  * Manage settings within applications.
>
> Method
> ---
>
> I don't intend to solve the third dot point of the previous list - it seems
> like a difficult problem, possibly to be tackled post-GSoC. What I do intend
> to do is to move towards 'application classes' more akin to
> ``django.contrib.admin``.
>
> New syntax in ``settings.INSTALLED_APPS`` will be introduced to address the
> previous issues. Some examples of accepted syntax:
>
> .. sourcecode:: python
>
>    INSTALLED_APPS = (
>        'django.contrib.auth',
>        app('blog.BlogApplication', 'blog_1', 'My blog', 'app1_'),
>        app('blog.BlogApplication', 'blog_2', 'Some other blog', 'app2_'),
>        app(path='tagging.Tagging', verbose_name='My tagging application'),
>        app('categories', db_prefix='cat_'),
>        app({'path': 'django.contrib.admin.AdminApplication',
>             'label': 'admin',
>             'verbose_name': 'Secret Admin'}),
>    )
>
> The ``app`` function will take four arguments, three of which are optional.
> These are ``path``, ``label``, ``verbose_name``, and ``db_prefix``. It will
> return an instance of an ``Application`` object, which will contain all of an
> installed application's information. ``path`` will be the dotted path to a
> subclass of ``Application``. The downside is that ``settings.py`` requires
> an import, which may be against style rules.
>
> .. sourcecode:: python
>
>    def app(path, label=None, verbose_name=None, db_prefix='')
>        if not path or not isinstance(path, basestring):
>            raise ImproperlyConfigured('Application path must be string.')
>        application_class = import_module(path)
>        return application_class(path, label, verbose_name, db_prefix)
>
> ``INSTALLED_APPS`` will then be a tuple containing strings or ``Application``
> instances. The application 

Re: GSoC: App Loading

[burc...@gmail.com]

On Thu, Apr 8, 2010 at 3:27 PM, Dagvadorj Galbadrakh
<dagvad...@gmail.com> wrote:
> Thanks for review.
>
> On Thu, Apr 8, 2010 at 3:15 PM, burc...@gmail.com <burc...@gmail.com> wrote:
>>
>> May I have few questions.
>> 1) And what if foo.gsoc has taiwan submodule already?
>
> There will be certain conventions on which names not to use as an
> instance name such as, views, models, etc. Plus, Django can check if a
> module with the same name  exists during deployment. And also, new
> instances can be stored in a special module called 'clone' for
> instance, hence, 'foo.gsoc.clone.taiwan'.
That's better.
"clone" is a horrible name for this purpose, but I got the idea.

>> 2) How will module know what name(s) it has got?
>
> Can be stored in dict in AppCache
>
>> 3) How will different application names to be referenced from outside?
>> 3) How will different application names to be loaded from outside?
>
> The apps and its modules will be referenced by its namespace (path - virtual).
I believe you don't quite understand all the problems,
so i'll add more details here.

I repeat fragments of Flo's post nobody has answered yet:

Assume an app1 which requires another app2 (gsoc in your case), and has some
ForeignKeys to it. Currently that's easy; just import the model and
ForeignKey it. How would those imports look like in your case (eg to
which models would app1 link)?!

Also, will app2copy (taiwan in you case) have different models than app2 (gsoc)?
(The same for views working with these models etc)

We don't have currently a way application's view knows about what
instance they work with.

This is a critical issue, and nobody yet suggested proper solution for that.

All that both of you can suggest us now is "I am suitable to make a
patch in an hour that will make multiple app copies work sometimes"
approach.

You need to question yourself about all possible problems.
And write your solutions to them.
Not wait when we will ask you those questions.
Because all those questions are already in this google group (not only
this thread).
Read all related topics, write questions, answer them.
And then come to us with a proposal.
I'm sure both of you can qualify if you do this.

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

Re: GSoC: App Loading

[burc...@gmail.com]

On Thu, Apr 8, 2010 at 2:56 PM, Dagvadorj Galbadrakh
 wrote:
> Good idea. Let INSTALLED_APPS be iterable, and let Django deployment
> do its job based on the configuration. Little to say though:
>
> INSTALLED_APPS = (
>    'django.contrib.auth',
>    'django.contrib.contenttypes',
>    'django.contrib.sessions',
>    'django.contrib.sites',
>    'django.contrib.admin',
>    'foo.gsoc',
>    ('foo.gsoc', 'taiwan', {'verbose_name': _('GSoC'), \
>                          'lang': 'zh-TW', \
>                          'name': 'gsoc_tw', \
>                          'db_prefix': 'gsoctw_', \
>                          'skin': 'orient'}),
> )
>
> So that app-level configuration would have been satisfied:
> Internationalization of the app name in admin, differentiated db
> prefices, default highlighting language for the app, etc.
>
> Every existence of an app will be defined as namespace URL in the
> code, thus no app with duplicate name. For instance: 'foo.gsoc' is
> named 'foo.gsoc' and models are accessed as 'from foo.gsoc.models
> import Idea', while '('foo.gsoc', 'taiwan', ..)' would be named as
> 'foo.gsoc.taiwan' if 'name' in dict is not existent, and like
> 'gsoc_tw' if 'name' attribute exists. Maybe 'name' and 'db_prefix'
> would be associated.

May I have few questions.
1) And what if foo.gsoc has taiwan submodule already?
2) How will module know what name(s) it has got?
3) How will different application names to be referenced from outside?
3) How will different application names to be loaded from outside?

I believe, the only way is to have a module for each application copy.

so you've got:
conf/gsoc.py

class App():
option1 = 'value1'
modules = 'apps.gsoc'
etc.

conf/taiwan.py:

import gsoc
class App(gsoc.App):
option1 = override

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

Re: [GSOC] NoSQL Support for the ORM

[burc...@gmail.com]

Hi all,

On Thu, Apr 8, 2010 at 12:55 AM, Waldemar Kornewald
 wrote:
> On Wed, Apr 7, 2010 at 5:22 PM, Alex Gaynor  wrote:
>>> Other issues that spring to mind:
[...]
> Well, you might be able to quickly adapt the MongoDB backend to GAE
> (within GSoC time constraints) due to their similarity. Anyway, there
> is common ground between the NoSQL DBs, but this highly depends on
> what problem we agree to solve. If we only provide exactly the
> features that each DB supports natively, they'll appear dissimilar
> because they take very different approaches to indexing and if this
> isn't abstracted and automated NoSQL support doesn't really make sense
> with Django. OTOH, if the goal is to make an abstraction around their
> indexes they can all look very similar from the perspective of
> Django's ORM (of course they have different "features" like sharding
> or eventual consistency or being in-memory DBs or supporting fast
> writes or reads or having transactions or ..., but in the end only few
> of these features have any influence on Django's ORM, at all).
>
> Bye,
> Waldemar Kornewald

Could we switch to one issue/feature per thread, please?

I think the overall approach is chosen already, and everyone agreed with it.
And each detail now has to be discussed separately, and overall
discussion continued here.
I.e, I have few words about design of counters and indexes (and my
favorite NoSQL Berkeley DB), but not arrays/lists.

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

Re: [Repost][GSoC] Making django.db usable outside Django

[burc...@gmail.com]

Hi Yuvi Panda,

As far I can remember, Django GSoC goal is to make Django itself stronger.
Not to make just one more external project.

And, actually, I don't see a point of ripping out Django ORM.
I see a point in ripping out templates or forms, so they don't need to
use settings.py...
but ORM is rarely used without other stuff. And ORM needs configuration anyway.

And who's going to support your version of ORM after your branching?

I assume it should be core team's decision if they like to see ORM as
external or internal package.
Now it seems they are pretty happy with internal package.
And I don't see any argument from you why they need to switch.

On Thu, Apr 1, 2010 at 8:40 PM, Yuvi Panda  wrote:
> I'm a CS student from India and am planning to apply for this year's
> GSoC to work on Django. I've worked on several django based websites
> ([1][2] + 1 yet to be released) and flirted around with other Python
> Web Frameworks too (Tornado, web.py, etc)
>
> My project idea is to rip out the Django ORM so it could be used
> outside django. django.db will be isolated (ie. dependencies on other
> parts of django will be cut or folded back into django.db), and
> packaged with a different name (perhaps djangoorm, to avoid conflict
> with django) so it can be used in other web frameworks, application
> servers, desktop apps, etc. I've already done some prelim work[3]
> cutting dependencies, and all the django.db related tests run
> successfully. This will make atleast one part of Django usable by a
> lot more people.
>
> I'm writing up a full proposal, but thought it would be a good idea to
> check with the developers if this kind of project is okay.
>
> Thoughts?
>
> [1]: http://busroutes.in
> [2]: http://novelrace.in
> [3]: http://github.com/yuvipanda/django-standalone-orm
>
> P.S. I posted this a few weeks back, but got no response. Thought I'll
> post this again today with the GSoC folks being more active.

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