Re: RequestContext not working?

[Daniel Poelzleithner]

Andreas Neumeier wrote:

> It looks like RequestContext just dies silently, but I couldn't tell
> you for sure.
> 
> I also figured out, there is another installation (rev. 2893 on Ubuntu
> Dapper), which looks that it works perfectly. rev 2917 on Breezy seams
> to fail for some reason i cannot describe. Where could I have a deeper
> look? Does django depend on certain mod_python versions?

Did you overwrite TEMPLATE_CONTEXT_PROCESSORS ?

I made the mistake once, because I didn't knew this variable is filled
by default. You have to write something like:

TEMPLATE_CONTEXT_PROCESSORS = DEFAULT.TEMPLATE_CONTEXT_PROCESSORS +
('my.preprocessor',)

Took me some time to figure out why admin was not working anymore :)

The difference of Context and RequestContext is not a deep one, so I
don't think its a python issue here.

kindly regards
 Daniel

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Proposal: default escaping (and branch request)

[Daniel Poelzleithner]

Simon Willison wrote:
> 
> On 19 Jun 2006, at 21:00, [EMAIL PROTECTED] wrote:
> 
>> anyway, i suppose i will wait for you to elaborate on your  
>> reasoning in
>> the wiki this evening.  :)
> 
> I've written up a proposal for how we can implement auto escaping  
> while hopefully keeping most people happy:
> 
> http://code.djangoproject.com/wiki/AutoEscaping

I like much of this stuff.

Here some further ideas:

I don't like the {% endautoescape %} just to print a unescaped variable.
Maybe the idea of the python string type prefix would help here and
would allow further improvments to be implemented nicely (thinking about
unicode problems...)

{{r#somevariable}} or {{r:somevariable}}

Even the last one looks strange at first, but is logical under the idea
that r ist just like any other function and generates a escapedstr out
of a string, or escapedunicodestring out of a unicode

2. Currently the autoescape, or better escape in general escapes <>, etc.
But what if you have some different type of output, then you have to do
everything by hand or write other filters, but could be messy.

{% escape_type tex|cvs|something... %}

would set a reference to the escape function of this template instance,
which is default to html. escape and autoescapestring would use this
reference instead of fixed coded escape function. This would allow to
write clean templates, with nearly no bloat in implementation.

kindly regards
  Daniel

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Development Growing Pains: Patch Acceptance

[Daniel Poelzleithner]

Adrian Holovaty wrote:

> Thanks for the comments. I'd like to restructure our Trac installation
> into more useful categories, such as: "Still thinking about it,"
> "Patch is good and should be committed with caveats," "Patch isn't
> good enough," and stuff like that. I think more granular categories
> like that would help us get more on top of the tickets/patches.

Keywords like "request_for_review" etc would help, too. The only thing
which would be required is a wiki page with all keywords listed and
explained.

kindly regards
 Daniel

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: URL confs should take callables as well as strings

[Daniel Poelzleithner]

Simon Willison wrote:

> Allowing callables in urlconfs opens up a whole bunch of other  
> opportunities as well. Setting up generic views could be made much  
> less fiddly:

What i still missing is a possibility to use other values to find the
right view (most likely the http host header).
I suggested http://code.djangoproject.com/ticket/1192 but Adrian doesn't
like it for some reason I can't understand :)

Anyway, maybe there could be some nice and clean way to use callables in
urlconfs to allow such things.

kindly regards
 Daniel

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: The viability of adding ifless and ifgreater to Django Templates

[Daniel Poelzleithner]

[EMAIL PROTECTED] wrote:

> I've been using Django for a project, and one thing I have sorely
> missed is having an ifless and ifgreater template tag. Other internal
> projects have had similar problems, and made at best hacks to work
> around this missing feature. I understand however that there is some
> hesitance to add more tags to the templating system though in an effort
> to separate display and logic.

I think sooner or later you will find all kinds of cases where the
standard tags are not sufficient enough. In FFSomething, I generate a
DOT file out of a network dump of the topology and have to calculate the
color of the lines depending on the link quality. This is surly a layout
not a view code thing. For such cases i just use the expr tag (
http://code.djangoproject.com/wiki/ExprTag ) because it's simply so
flexible for such rare cases where the if and ifequal tags are not
sufficient enough. I don't think ifgreater and ifless are really used
that much that it should result in a additional default tag, maybe the
if tag should simply be more flexible then it is now.

i'm -0 on this.

kindly regards
 Daniel

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Multi-db branch feedback/questions

[Daniel Poelzleithner]

> OK, thoughts, anyone?

When i first heard of multi-db i more thought about support for
clustering then moving some apps/models to other databases, which is
great, too of course.

for example: having one master db and some slave dbs that mirror the
master db. requests should go to slaves in some sort of changeable round
robin style and changes should go directly to the master db.
this scenario popped into my mind the first time i heard of multi-db. is
such a scenario supported somehow. i think it will be useful for very
large sites and should be kept in mind when the db layer is redesigned.

kindly regards
 daniel



--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Auto-escaping patch

[Daniel Poelzleithner]

Malcolm Tredinnick wrote:

> Damn. Your phrasing tipped me off to a case we need this more: RSS feeds
> and Atom content elements with type="html". :-(
> 
> We might need a "mark as unsafe" filter for these cases (so that {{ var|
> escape|unsafe|escape }}) works (or just make "escape" not mark the
> string as safe, but I suspect that will have unintended annoying
> side-effects).

I suggest {{var|escape|escape:force}}

force as an optional argument to escape already escaped strings.

But an unsafe filter may be usefull, too.

kindly regards
 Daniel

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

flat values() in querysets

[Daniel Poelzleithner]

Hi,

Currently it's kinda verbose to get just a list of id's from a query to
put it in a bulk_in or process it further.

example:

>>> NetworkState.objects.all().order_by("-stopdate")[:5].values("id")
[{'id': 2738}, {'id': 2737}, {'id': 2736}, {'id': 2735}, {'id': 2734}]

Then i have to unpack it to get a [2738, 2737,...] list, which is what I
wanted in the first place.

I suggest Object.objects.all().values("id", flat=True). Flat as a
optional argument, which is only allowed when only one field is
requested and returns a list with only the values.

Any better ideas ?

kindly regards
  Daniel

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: flat values() in querysets

[Daniel Poelzleithner]

jrs wrote:

> What would the result be if multiple fields were selected?  or should
> this be valid only when a single field is requested?
> 
> NetworkState.objects.all().order_by("-stopdate")[:5].values("id",
> "name")

I couldn't think of a nice solution at first, so i said for one key only.

What do you think about returning n tupples for n arguments. if n > 1
and a pure list for only one argument ?

.values("id", "name", flat=True) would return
[(id,name),(id,name),...]

.values("id", flat=True) would return
[id,id,...]

?

kindly regards

PS: yes i will provide a patch :)

kindly regards
  Daniel

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: App portability

[Daniel Poelzleithner]

Martin Glueck wrote:

> Be careful ... in one of the next releases of python, support for
> relative import will be dropped! So I would suggest that you don't
> rely on relative import in new written code and change it whenever you
> find it in old code.

It will not be droped in 2.5 but it will be made clear (horray), which
is exactly what we have problems with.

in myapps/views.py:
from .models import Somemodel

which will import from myapps/models.py Somemodel

from ..otherapp.models import Othermodel

imports from myapps/../otherapp/models.py -> otherapps/models.py

This is exactly what we need for our apps to be portable :)

kindly regards
  Daniel

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: Ticket spam

[Daniel Poelzleithner]

Matthew Flanagan wrote:

> In one project I know of that uses trac they just have a single login
> for users to create tickets and submit patches rather than requiring
> every user to register. This eliminated 99% of their trac spam. They
> just documented the login/password in their 'contributing' docs. This
> saves someone having to manage trac users.

Nice idea. I use the trac Admin UsersManagerSomething Plugin, so users
can easily register an account and then change wiki pages, submit
tickets, etc. I don't use any other spam blocking and spam stopped after
that.

kindly regards
  daniel

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: metaapi: Django Meta-API - Invitation to Criticize!

[Daniel Poelzleithner]

Adrian Holovaty wrote:

> Some of these ideas sound really cool! I'd suggest focusing on one or
> two of them rather than attempting to do the whole shebang. In my
> opinion, the Python Imaging Library functions as generic views would
> be a really useful thing to have.

If such a Interface is specified, it should be flexible enough to switch
backends. In my optinion PIL has a total terrible quality when compared
to ImageMagick.

kindly regards
 Daniel


--~--~-~--~~~---~--~~
 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Request params problem

[Daniel Poelzleithner]

plisk wrote:
> Yeah, its OK to have more than one value of the same param and wrap all
> of them in the list. But when you have only one parameter value passed
> making a list for it is at least inconsistent with the value you get
> from request.GET['param'] which is just a scalar and this also breaks
> some parts in admin as was mentioned.

If you have only one parameter simply use [0] to access it. Returning a
list or a string depending on the number of arguments is a bad idea,
because you have to check everytime which type of value it is.
Generating more code and a easy target for mistakes and security flaws.
You can't trust any values comming from the client, somebody could try
to attack your site by altering the urls by hand. I think its the best
solution that way.

request.GET['param'] should also return a list or tuple of values.

kindly regards
  Daniel

Re: Moving auth and core models to contrib -- and dependencies

[Daniel Poelzleithner]

Adrian Holovaty wrote:

> So how is this implemented? The simplest way we could do it is a
> __dependencies__ variable in the __init__.py of the app. For example,
> this would go in django/contrib/admin/__init__.py:
> 
> __dependencies__ = ('django.contrib.auth',)
> 

+1 for dependencies, but not so simple. Imagine what will happen when
django 1.0 is released and apps are starting poping up. On app may
require a specific version of another app, or is incompatible with a
specific app.

Apps sould define a __version__ in __init__.py wich sould be checked on
the dependencies check.

maybe a syntax like:
__dependencies__ = (('django.contrib.auth',
">=0.1,!=0.2"),('my.app.bla', "==0.3"))

would require a version of contrib.auth that is greater as 0.1 but not
0.2 and version 0.3 of bla :)

kindly regards
 daniel

Re: subdomain specific settings file - new idea

[Daniel Poelzleithner]

Amit Upadhyay wrote:
> Hi,
> 
> Wish you all a very happy and fruitful new year!
> 
> Djando URL resolution causes some problem with applications hosted in
> different subdomains. Consider www.example.com 
> and blog.example.com . Both of them are running
> off the same database and share common admin, and so on, but are hosted
> in different subdomain, which causes problem with URL resolution. To
> solve this we can copy the settings file and change ROOT_URLCONF to
> point to different locations. I propose splitting settings.py into
> common_settings.py and www_settings.py. www_settings.py contains
> something equivalent to:
> 
[...]
> 
> What do you think?

I think the right approach would be to make the urlresolver in
handlers.base configurable through a settings variable.
The default value would be something like

URL_RESOLVER = "django.core.urlresolvers.RegexURLResolver"

This would allow to write custom resolvers.
Also a resolver that also checks the hostname would be nice to be
included. it would uses a different ROOT_URLCONF like:

urlpatterns = {
r'www\.bla\.com': patterns('',
...
   (r'^admin/', include('django.contrib.admin.urls.admin')),
)
r'.*\.bla\.com': patterns('',
...
)
}

You could do very nice things with this approach, like using a database
to resolve the url, or even change the other settings depending on the
hostname you resolve...
The speed impact would be minimal and the posibilities enormous.

kindly regards
 Daniel

Re: subdomain specific settings file - new idea

[Daniel Poelzleithner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ivan Fedorov wrote:

>>URL_RESOLVER = "django.core.urlresolvers.RegexURLResolver"
> 
> +1
>
>>You could do very nice things with this approach, like using a database
>>to resolve the url, or even change the other settings depending on the
>>hostname you resolve...
> 
> 
> I'm already have database-driven URL Resolver. It's built over standard
> Django resolver, so anybody can use it with unmodified Django.
> 
> Does anybody interesting in it?..

Maybe something for contrib ?

I'm working on a patch for the URL_RESOLVER. This patch will include a
the default behaviour as django.core.urlresolvers.URLResolver and a
simple HostURLResolver, that allows matching for hostnames, too.
URLResolver is just a small wrapper, because i changed the paramters for
the resolver to be
def __init__(self, request, urlconf_name):
Maybe even remove the urlconf_name and look it up in the resolver class
rather then the http base class. What do you think ?

The HostURLResolver is so small, that i think it doesn't make sense to
put it into contrib.

kindly regards
  Daniel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: GnuPT 2.7.2
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDwWMhy/mkIQp7AD0RAh5zAJ42iWYOgzQ5vMjfLk3lLx3a99lIWACgj6M9
06QNiFOQh5SOUH9+OoIH10g=
=ZgV3
-END PGP SIGNATURE-

Re: subdomain specific settings file

[Daniel Poelzleithner]

Amit Upadhyay wrote:

> This makes clear on what to do incase there are different subdomains, we
> can just add other subdomains specific setting files blog_settings.py
> and so on, which point to different ROOT_URLCONF and so on [we can
> overwrite other things too if required].

Look at http://code.djangoproject.com/ticket/1192 if it fits your needs,
please.

It doesn't have subdomain specific settings, but I think the
HostURLResolver is a very usefull thing. Also you could write a custom
resolver trough the new config setting.

kindly regards
 daniel

Re: magic-removal: "Change subclassing syntax"

[Daniel Poelzleithner]

Jeremy Dunck wrote:

> This makes me think the world needs a wiki whose wikitext syntax is
> restructured text.

In general ?
At least trac has a macro for restructured text I think.

kindly regards
  daniel

using accounts to prevent ticket spam ?

[Daniel Poelzleithner]

Hi,

I think it has become to much spam in django trac. I suggest to use
http://trac-hacks.org/wiki/AccountManagerPlugin so only registered users
can change stuff and comment bugs. I think this would prevent much of
the spam currently comming in, or at least allows to ban those accounts.

Maybe ip may help, but i think they will most likly use a botnet or so.

kindly regards
  daniel

Re: Food for Thought: Yahoo User Interface Library

[Daniel Poelzleithner]

limodou wrote:

> I agree! But dojo seems too large? I also havenot played with it so far.

dojo is large but very modular. it can load stuff on demand if you make
it right, so there is not much blow there. what sense does it make to
use a toolkit that implements only a small subset for widgets that seems
usefull for a wide range, so everybody has to use another toolkit or
bake one for their purposes. such a thing gets only messy when there is
no standard interface.
the guys at dojo are working hard to make it better and better and i
think its the most promising toolkit around.

also there is a question about how the yahoo toolkit will get
development in the future, its not a very open development process as
much as i have seen. something i don't like.

kindly regards
 daniel

Re: [Changeset] r2386 - django/branches/magic-removal/django/core

[Daniel Poelzleithner]

Adrian Holovaty wrote:

> django-admin.py startproject foo
> 
> # generated settings file contains INSTALLED_APPS with the basics,
> # such as sessions, auth, etc.. Advanced users can remove any or all of 
> that
> # if they don't want to use it.
> 
> python foo/manage.py synchdb   # creates tables for all INSTALLED_APPS
> 
> # When you write some new models, just run "manage.py synchdb" again
> # to make sure things are in sync. This can later be expanded to include
> # ALTER TABLE statements.

i was working on a patch that allows to use globs in manage.py install
so you could write "install *" to install all INSTALLED_APPS, but with
the syncdb which later can alter tables this seems even better.

my patch is a extended version of #1371 which allows also simple
depedencies to other apps. in myapp/default_settings.py you could write
DEPENDS_ON=('somethingelse.app',) which would be automaticly appended to
INSTALLED_APPS if it's not there and on "install app" be created before
the myapp is installed.

Thoughts ?

kindly regards
  daniel

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---

Re: urlconf, applications..coupling

[Daniel Poelzleithner]

Adrian Holovaty wrote:

> Yes, I realize __name__ + '.views' will result in something like
> 'myproject.polls.urls.views' -- some extra string mangling would have
> to be done.

how about using the python 2.5 relative import syntax and emulating it
accoringly.

urlpatterns = patterns('.views',

for a views in the current directory

urlpatterns = patterns('..views',

views in the partens directory

etc.

kindly regards
 Daniel

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---