Re: Generic templates

[esatterwh...@wi.rr.com]

I see what you are saying. your template would become somewhat complex
and hard to maintain if you had a lot of permissions. However you can
create whatever permissions you want in the meta class of your model
and use those instead of the ACCESS_CHOICES and number checks

class Meta:
permissions=(
('system_acess','Has System Access'),
('staff_acess','Has Staff Access'),
)

So a user can have both system and staff access or one or the other
and you would only need to check once.

if you are on a django version less than 1.2, there is a smart if tag
on djangosnippets that is the basis of the new if tag in django 1.2.
you can down load that and do {% if user.access <=  100 %}

you have to be careful with booleans. The version I have doesn't treat
zeros as false so you have rewrite some code to check for 1 or 0

{% if user.is_staff = 1 %}

So you have options. You template tag would seem to be the most
concise and DRYest route, at least in the template code

On Feb 1, 12:12 am, Dylan Evans  wrote:
> On Sun, Jan 31, 2010 at 11:46 PM, esatterwh...@wi.rr.com <
>
> esatterwh...@wi.rr.com> wrote:
> > if if you want to change the menu based on the user, you could
> > probably just use the user permissions from the auth context processor
>
> > if the user has the permissions ( access ) to the option - show it
>
> > else - don't show it.
>
> > or if you want to use the model you have listed here, you could use
> > the {% ifequal tag %}
>
> > {% ifequal myuser.access 1000 %}
> >     show some stuff...
> > {% else %}
> >     show something else...
> > {% endifequal %}
>
> The problem with that is if the user has permission 1000 for superuser and
> there is a menu item for staff requiring a permission of 100 the if check
> would fail. My programmers brain says, no problem just use a bit vector, but
> django templates don't allow that either. In the development version it's
> possible to do;
> {% if myuser.access >= 100 %}
> But i'm looking at deploying the site so i don't really want to use it.
>
>
>
> > I personally think using putting users in groups and assigning
> > permissions then checking in the template for who has what would be
> > the easiest solution. Django does most of the work for you
>
> That may be a better option, i'm still learning django and may have cheated
> with access permissions. I'll look into it but i want to avoid a mess of if
> checks. Since the menu is dynamically generated i can't assume a menu item
> with any particular permission is going to arrive.
>
> The solution i did use seems to be working quite well. In the template the
> "access" tag works like this.
>
> {% for item in menu.objects.all %}
>     {% access item %}
>         #Do stuff
>     {% endaccess %}
> {% endfor %}
>
> The "access" tag checks for the existence of user in the context and
> calculates the users access level, or failing that assumes an access of 1
> (Anonymous). Then it checks for an access property on item and renders the
> block only if user.access >= item.access . You see why the formerly
> mentioned if check is way simpler?
>
> > On Jan 30, 9:28 pm, Dylan Evans  wrote:
> > > No i have processors, i have all the data i need in the template, i just
> > > don't know an elegant way to condition out menu items.
>
> > > This is how my model works
>
> > > ACCESS_CHOICES = (
> > >     (1,  "Public"),
> > >     (10, "Private"),
> > >     (100,   "Staff"),
> > >     (1000,  "System")
> > > )
>
> > > class Menu(models.Model):
> > >     name = models.CharField(max_length=16)
>
> > > class MenuItem(models.Model):
> > >     menu = models.ForeignKey(Menu)
> > >     access = models.IntegerField(choices=ACCESS_CHOICES)
>
> > > class MenuSubItem(models.Model):
> > >     item = models.ForeignKey(MenuItem)
> > >     access = models.ForeignKey(MenuSubItem)
>
> > > On Sun, Jan 31, 2010 at 5:31 AM, Shawn Milochik 
> > wrote:
> > > > I think you've missed context processors, which is easy to do. I'm
> > assuming
> > > > that your issue is that you want to have something passed in the
> > context on
> > > > every page load to do something like decide which menu items are
> > available
> > > > based upon whether the user is logged in, their privileges, or
> > whatever.
>
> > > > Context processors allow you to define a dictionary that gets appended
> > to
> > > > the context of every response you send, so you can have that common
> > stuff
> > > > there.
>
> > > > 1. Write code to get the values appropriate for the current user or
> > > > whatever. Put these in a Python file in your app.
> > > > 2. Add that file to the TEMPLATE_CONTEXT_PROCESSORS in your
> > settings.py.
> > > > 3. Replace Context() with RequestContext() in your render_to_response
> > > > calls.
>
> > > > If I've missed your actual point, please give more detail. I think this
> > > > simplifies what you're trying to do.
>
> > > > Shawn
>
> > > > --
> > > > You received this 

Re: Generic templates

[Dylan Evans]

On Sun, Jan 31, 2010 at 11:46 PM, esatterwh...@wi.rr.com <
esatterwh...@wi.rr.com> wrote:

> if if you want to change the menu based on the user, you could
> probably just use the user permissions from the auth context processor
>
> if the user has the permissions ( access ) to the option - show it
>
> else - don't show it.
>
>
> or if you want to use the model you have listed here, you could use
> the {% ifequal tag %}
>
> {% ifequal myuser.access 1000 %}
> show some stuff...
> {% else %}
> show something else...
> {% endifequal %}
>

The problem with that is if the user has permission 1000 for superuser and
there is a menu item for staff requiring a permission of 100 the if check
would fail. My programmers brain says, no problem just use a bit vector, but
django templates don't allow that either. In the development version it's
possible to do;
{% if myuser.access >= 100 %}
But i'm looking at deploying the site so i don't really want to use it.


>
> I personally think using putting users in groups and assigning
> permissions then checking in the template for who has what would be
> the easiest solution. Django does most of the work for you
>

That may be a better option, i'm still learning django and may have cheated
with access permissions. I'll look into it but i want to avoid a mess of if
checks. Since the menu is dynamically generated i can't assume a menu item
with any particular permission is going to arrive.

The solution i did use seems to be working quite well. In the template the
"access" tag works like this.

{% for item in menu.objects.all %}
{% access item %}
#Do stuff
{% endaccess %}
{% endfor %}

The "access" tag checks for the existence of user in the context and
calculates the users access level, or failing that assumes an access of 1
(Anonymous). Then it checks for an access property on item and renders the
block only if user.access >= item.access . You see why the formerly
mentioned if check is way simpler?



> On Jan 30, 9:28 pm, Dylan Evans  wrote:
> > No i have processors, i have all the data i need in the template, i just
> > don't know an elegant way to condition out menu items.
> >
> > This is how my model works
> >
> > ACCESS_CHOICES = (
> > (1,  "Public"),
> > (10, "Private"),
> > (100,   "Staff"),
> > (1000,  "System")
> > )
> >
> > class Menu(models.Model):
> > name = models.CharField(max_length=16)
> >
> > class MenuItem(models.Model):
> > menu = models.ForeignKey(Menu)
> > access = models.IntegerField(choices=ACCESS_CHOICES)
> >
> > class MenuSubItem(models.Model):
> > item = models.ForeignKey(MenuItem)
> > access = models.ForeignKey(MenuSubItem)
> >
> >
> >
> >
> >
> > On Sun, Jan 31, 2010 at 5:31 AM, Shawn Milochik 
> wrote:
> > > I think you've missed context processors, which is easy to do. I'm
> assuming
> > > that your issue is that you want to have something passed in the
> context on
> > > every page load to do something like decide which menu items are
> available
> > > based upon whether the user is logged in, their privileges, or
> whatever.
> >
> > > Context processors allow you to define a dictionary that gets appended
> to
> > > the context of every response you send, so you can have that common
> stuff
> > > there.
> >
> > > 1. Write code to get the values appropriate for the current user or
> > > whatever. Put these in a Python file in your app.
> > > 2. Add that file to the TEMPLATE_CONTEXT_PROCESSORS in your
> settings.py.
> > > 3. Replace Context() with RequestContext() in your render_to_response
> > > calls.
> >
> > > If I've missed your actual point, please give more detail. I think this
> > > simplifies what you're trying to do.
> >
> > > Shawn
> >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups
> > > "Django users" group.
> > > To post to this group, send email to django-us...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > django-users+unsubscr...@googlegroups.com
> 
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/django-users?hl=en.
> >
> > --
> > "The UNIX system has a command, nice ... in order to be nice to the other
> > users. Nobody ever uses it." - Andrew S. Tanenbaum
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>


-- 
"The UNIX system has a command, nice ... in order to be nice to the other
users. Nobody ever uses it." - Andrew S. Tanenbaum

-- 
You received this message because 

Re: Generic templates

[esatterwh...@wi.rr.com]

if if you want to change the menu based on the user, you could
probably just use the user permissions from the auth context processor

if the user has the permissions ( access ) to the option - show it

else - don't show it.


or if you want to use the model you have listed here, you could use
the {% ifequal tag %}

{% ifequal myuser.access 1000 %}
 show some stuff...
{% else %}
 show something else...
{% endifequal %}


I personally think using putting users in groups and assigning
permissions then checking in the template for who has what would be
the easiest solution. Django does most of the work for you
On Jan 30, 9:28 pm, Dylan Evans  wrote:
> No i have processors, i have all the data i need in the template, i just
> don't know an elegant way to condition out menu items.
>
> This is how my model works
>
> ACCESS_CHOICES = (
>     (1,  "Public"),
>     (10, "Private"),
>     (100,   "Staff"),
>     (1000,  "System")
> )
>
> class Menu(models.Model):
>     name = models.CharField(max_length=16)
>
> class MenuItem(models.Model):
>     menu = models.ForeignKey(Menu)
>     access = models.IntegerField(choices=ACCESS_CHOICES)
>
> class MenuSubItem(models.Model):
>     item = models.ForeignKey(MenuItem)
>     access = models.ForeignKey(MenuSubItem)
>
>
>
>
>
> On Sun, Jan 31, 2010 at 5:31 AM, Shawn Milochik  wrote:
> > I think you've missed context processors, which is easy to do. I'm assuming
> > that your issue is that you want to have something passed in the context on
> > every page load to do something like decide which menu items are available
> > based upon whether the user is logged in, their privileges, or whatever.
>
> > Context processors allow you to define a dictionary that gets appended to
> > the context of every response you send, so you can have that common stuff
> > there.
>
> > 1. Write code to get the values appropriate for the current user or
> > whatever. Put these in a Python file in your app.
> > 2. Add that file to the TEMPLATE_CONTEXT_PROCESSORS in your settings.py.
> > 3. Replace Context() with RequestContext() in your render_to_response
> > calls.
>
> > If I've missed your actual point, please give more detail. I think this
> > simplifies what you're trying to do.
>
> > Shawn
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Django users" group.
> > To post to this group, send email to django-us...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-users+unsubscr...@googlegroups.com > groups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/django-users?hl=en.
>
> --
> "The UNIX system has a command, nice ... in order to be nice to the other
> users. Nobody ever uses it." - Andrew S. Tanenbaum

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Generic templates

[Dylan Evans]

No i have processors, i have all the data i need in the template, i just
don't know an elegant way to condition out menu items.

This is how my model works

ACCESS_CHOICES = (
(1,  "Public"),
(10, "Private"),
(100,   "Staff"),
(1000,  "System")
)

class Menu(models.Model):
name = models.CharField(max_length=16)

class MenuItem(models.Model):
menu = models.ForeignKey(Menu)
access = models.IntegerField(choices=ACCESS_CHOICES)

class MenuSubItem(models.Model):
item = models.ForeignKey(MenuItem)
access = models.ForeignKey(MenuSubItem)


On Sun, Jan 31, 2010 at 5:31 AM, Shawn Milochik  wrote:

> I think you've missed context processors, which is easy to do. I'm assuming
> that your issue is that you want to have something passed in the context on
> every page load to do something like decide which menu items are available
> based upon whether the user is logged in, their privileges, or whatever.
>
> Context processors allow you to define a dictionary that gets appended to
> the context of every response you send, so you can have that common stuff
> there.
>
> 1. Write code to get the values appropriate for the current user or
> whatever. Put these in a Python file in your app.
> 2. Add that file to the TEMPLATE_CONTEXT_PROCESSORS in your settings.py.
> 3. Replace Context() with RequestContext() in your render_to_response
> calls.
>
> If I've missed your actual point, please give more detail. I think this
> simplifies what you're trying to do.
>
> Shawn
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>


-- 
"The UNIX system has a command, nice ... in order to be nice to the other
users. Nobody ever uses it." - Andrew S. Tanenbaum

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Generic templates

[Shawn Milochik]

I think you've missed context processors, which is easy to do. I'm assuming 
that your issue is that you want to have something passed in the context on 
every page load to do something like decide which menu items are available 
based upon whether the user is logged in, their privileges, or whatever.

Context processors allow you to define a dictionary that gets appended to the 
context of every response you send, so you can have that common stuff there.

1. Write code to get the values appropriate for the current user or whatever. 
Put these in a Python file in your app.
2. Add that file to the TEMPLATE_CONTEXT_PROCESSORS in your settings.py.
3. Replace Context() with RequestContext() in your render_to_response calls.

If I've missed your actual point, please give more detail. I think this 
simplifies what you're trying to do.

Shawn

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Generic templates

[Dylan Evans]

I'm new to django and i think it's brilliant except for the weird template
system.

It seems the only way i can write templates which are generic enough to be
reusable is to write complex tags and filters for tasks which could be
handled by a simple argument on a function call, or as a compromise a
workable if check(admittedly in development).

My main problem has been in handling database driven menus which provides
access control depending on the user, showing extra items for staff or
authenticated users. I wanted to avoid the double handling of processing the
model data in the view into lists or querysets, since the menu model is
multi-leveled this would be messy anyway. I think i can do something with
managers, but i'm still not sure how to pass the access data to query sub
menu items.The whole problem is extra weird because i use decorators to send
all the details to the template, but once it's there i can't do much with it
given that i can't make assumptions about user access.

The simplest solution is to hard code the menu generation in python, but of
course that would make me a bad person, so i've been struggling to find a
way to do this very simple thing in templates and my solution was to add
'access'/'endaccess' tags which compare the user in the context with an
access level argument, dropping the block if the user doesn't have access.

It works, but why is it so hard to do something which should be so easy? Am
i missing something?

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Problem with URL naming, generic templates and custom filtering wrappers

[Scott SA]

Hi Karen,

On Oct 10, 5:58 pm, Karen Tracey  wrote:
> On Sat, Oct 10, 2009 at 6:34 PM, Scott SA  wrote:

> > I am trying to use a series of generic views with custom filtering via
> > callbacks as per:


> I cannot figure out how this one differs from the next one, nor can I
> recreate first two errors you are getting (I just get the no reverse match),
> and in making further changes you seem to be moving further away from what
> you want to achieve, so I'm just going to stop here and fix this one.

Sweet, thank you. 8-)

> First, the "P?" should be "?P".  You've got the order of the ?
> and the P reversed.

Finger dyslexia, happens all teh time!

Was, and remains, correct in the urls file. I fabricated the stripped-
down example to try to get to the heart of the matter without
excessive detail.

> Second, since you are specifying this as a bare tuple and not using url(),

I tried using url() and others after reading the 'url' and 'patterns'
source.

> and you want to specify the optional name as 'url-pattern-name', you must
> also include the optional dictionary which comes before the optional name as
> defined here:
>
> http://docs.djangoproject.com/en/dev/topics/http/urls/#patterns

> Given what you have 'url-pattern-name' is being taken to be the optional
> dictionary, not the optional name.  So change it to:
>
>   (r'path/(?P[\w\d-]+)/?$', my_filter_callback, {},
> 'url-pattern-name'),

Hmm, I thought I had done that but maybe something else was also wrong
causing me to follow the wrong path for troubleshooting.

> or use url() (read down further in the doc pointed to), omit the dictionary,
> and specify the name via keyword:
>
>   url(r'path/(?P[\w\d-]+)/?$', my_filter_callback,
> name='url-pattern-name'),

Okay, I know for sure that I tried this, may still have that code
commented out. This is where I received the error that the 'name'
attribute was being passed to 'my_filter_callback', as I recall. I'll
give this another try just to be sure it wasn't a "red herring" that
sucked a few hours out of my day.

After having gone back and adding the empty dictionary in the patterns
(prefix, tuple...) call, I now get resolution and reverse for that
URL. The second part of my prev. statement re. the url call seems the
likely culprit, and a quick double-check on the url() call just proved
it. The problem is another reverse url call later in the page
template, similar name, different regex, etc. 8-(

Thanks for the quick and very informative reply, greatly appreciated.
Sorry for the 'red herring' issue!

Scott

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Problem with URL naming, generic templates and custom filtering wrappers

[Karen Tracey]

On Sat, Oct 10, 2009 at 6:34 PM, Scott SA  wrote:

>
> Hi,
>
> I am trying to use a series of generic views with custom filtering via
> callbacks as per:
>
>
> http://docs.djangoproject.com/en/dev/topics/generic-views/#extending-generic-views
>
> Unfortunately, when I try to name the URL in urls.py, I get various
> errors depending upon how I try to write the pattern call.
>
> I'll write a skeleton of what the code really is:
> ___
>
> in views.py:
> - - - - - - - - - - - - - -
> def my_filter_callback(request, name):
>   ...
>   return list_detail.object_list( request, queryset... )
> ___
>
> in my_template.html:
> - - - - - - - - - - - - - -
> {% for object in obects_list %}
>
> {{ object.name }}
> {% endfor %}
> ___
>
> in urls.py:
> - - - - - - - - - - - - - -
> from views import my_filter_callback
>
> urlpatterns += patterns( '',
>( r'path/(P?[\w\d-]+)/?$', my_filter_callback, 'url-pattern-
> name'),
>   )
>
>
I cannot figure out how this one differs from the next one, nor can I
recreate first two errors you are getting (I just get the no reverse match),
and in making further changes you seem to be moving further away from what
you want to achieve, so I'm just going to stop here and fix this one.

First, the "P?" should be "?P".  You've got the order of the ?
and the P reversed.

Second, since you are specifying this as a bare tuple and not using url(),
and you want to specify the optional name as 'url-pattern-name', you must
also include the optional dictionary which comes before the optional name as
defined here:

http://docs.djangoproject.com/en/dev/topics/http/urls/#patterns

Given what you have 'url-pattern-name' is being taken to be the optional
dictionary, not the optional name.  So change it to:

  (r'path/(?P[\w\d-]+)/?$', my_filter_callback, {},
'url-pattern-name'),

or use url() (read down further in the doc pointed to), omit the dictionary,
and specify the name via keyword:

  url(r'path/(?P[\w\d-]+)/?$', my_filter_callback,
name='url-pattern-name'),

Karen

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Problem with URL naming, generic templates and custom filtering wrappers

[Scott SA]

Hi,

I am trying to use a series of generic views with custom filtering via
callbacks as per:

http://docs.djangoproject.com/en/dev/topics/generic-views/#extending-generic-views

Unfortunately, when I try to name the URL in urls.py, I get various
errors depending upon how I try to write the pattern call.

I'll write a skeleton of what the code really is:
___

in views.py:
- - - - - - - - - - - - - -
def my_filter_callback(request, name):
   ...
   return list_detail.object_list( request, queryset... )
___

in my_template.html:
- - - - - - - - - - - - - -
{% for object in obects_list %}

{{ object.name }}
{% endfor %}
___

in urls.py:
- - - - - - - - - - - - - -
from views import my_filter_callback

urlpatterns += patterns( '',
( r'path/(P?[\w\d-]+)/?$', my_filter_callback, 'url-pattern-
name'),
   )

- - - - - - - - - - - - - -
AttributeErrror:
'str' object has no attribute 'resolve'

/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/site-packages/django/core/urlresolvers.py in resolve

 211. def resolve(self, path):
 212. tried = []
 213. match = self.regex.search(path)
 214. if match:
 215. new_path = path[match.end():]
 216. for pattern in self.url_patterns:
 217. try:

 218. sub_match = pattern.resolve(new_path)
___

in urls.py:
- - - - - - - - - - - - - -
from views import my_filter_callback

urlpatterns += patterns( '',
( r'path/(P?[\w\d-]+)/?$', my_filter_callback, 'url-pattern-
name'),
   )

- - - - - - - - - - - - - -
ValueError at /path/
dictionary update sequence element #0 has length 1; 2 is required

/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/site-packages/django/core/urlresolvers.py in resolve
 116. # positional arguments.
 117. kwargs = match.groupdict()
 118. if kwargs:
 119. args = ()
 120. else:
 121. args = match.groups()
 122. # In both cases, pass any extra_kwargs as **kwargs.

 123. kwargs.update(self.default_args)
___

Alternate version of urls.py

urlpatterns += patterns( '',
( r'path/(P?[\w\d-]+)/?$', my_filter_callback ),
   )

# note: after reading the code, I also passed the prefix
"myapp.views",
# then called my callback as "my_filter_callback", trying to get
# the  'url' method of /django/conf/urls/defaults.py to compose
# the callback path as a string.
- - - - - - - - - - - - - -
TemplateSyntaxError at /path/

Caught an exception while rendering: Reverse for 'url-pattern-name'
with arguments '()' and keyword arguments '{'name': u'some-name'}' not
found.
___

So, I followed the source and tried a few different things. For
example, I have tried to call RegexURLPattern adding a 'name'
parameter, but that then gets passed to my callback, which in turn
gets passed to django's generic list architecture. That subsequently
generates an "unexpected attribute" error named "name", instead of it
being used by RegexURLPattern to name the url pattern for reverse.

Am I going to have to sub-class RegexURLPattern and force it to stick
the name 'somewhere' appropriate, because at this point I don't think
things are working as they should and I think I've dug deep enough to
see that I've been making the correct calls.

So, in a word: Help!

Thanks in advance to any and all that can help me decode this mystery.

Scott

PS. My other alternative is to not reverse the URL, but calculate it
m'self, which is less flexible. It may, in the short term be
substantially quicker than some of my other alternatives.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---