Re: Detect SSL/HTTPS

2006-05-05 Thread Steven Armstrong

On 05/05/06 20:06, Jakub Labath wrote:
> Hi Steven,
> 
> Thanks but I don't seem to have the 'wsgi.url_scheme' available in my
> request.META could it be becuase I'm using apache and mod_python?
> 

Hi

Yea, after having another look, it seems that's only available while 
running the dev server. My bad.

In your patch you detect HTTPS by checking the self._req.subprocess_env 
in the modpython handler. I believe the djangonauts already stick that 
information in os.environ.

Maybe try the following from within a view function to see what's 
already there?

def index(request):
   print request
   print '-'*50
   import os
   print os.environ


hth
Steven

--~--~-~--~~~---~--~~
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: Detect SSL/HTTPS

2006-05-05 Thread Steven Armstrong

On 05/05/06 19:33, Jakub Labath wrote:
> Hi,
> 
> I eventually solved my problem by modifying django/core/handlers/modpython.py
> so that request.META would contain a key HTTPS.
> 
> --- core/handlers/modpython.py  (revision 2299)
> +++ core/handlers/modpython.py  (working copy)
> @@ -86,6 +86,8 @@
>  for key, value in self._req.headers_in.items():
>  key = 'HTTP_' + key.upper().replace('-', '_')
>  self._meta[key] = value
> +if hasattr(self._req.subprocess_env,'HTTPS'):
> +self._meta['HTTPS'] = self._req.subprocess_env['HTTPS']
>  return self._meta
> 
>  def _get_raw_post_data(self):
> 
> 
> Is this a good/bad idea? Any thoughts? Let me know if you guys find it
> useful I can add a patch to trac.
> 
> Best Regards

Hi Jakub

I believe you can use something like:

if request.META['wsgi.url_scheme'] == 'https':
   secure stuff
else:
   non-secure stuff


hth
Steven

--~--~-~--~~~---~--~~
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: +1 on part of #1810 (put parse_dsn() in django.conf)

2006-05-11 Thread Steven Armstrong

On 05/11/06 17:02, [EMAIL PROTECTED] wrote:

Regarding the dsn stuff i don't really care. Since the config file 
itself is python I can do in there whatever I like.

So +0 on that.

For putting the dsn in the env I'm -1 as it may cause security problems.
IMHO the only place where such config as a dsn belongs is in a file, 
ideally only readable by the executed program itself.

 > (myself included -- I am not about to put my production db
> password into a subversion repository that everyone in the company can
> read).
> 

settings.py: --
# Django settings for some project.

DEBUG = True
TEMPLATE_DEBUG = DEBUG

ADMINS = (
 ('John Doe', '[EMAIL PROTECTED]'),
)

MANAGERS = ADMINS
...
from settings_local import *



settings_local.py: --
DATABASE_ENGINE = 'someengine'
DATABASE_NAME = 'somedb'
DATABASE_USER = 'someuser'
DATABASE_PASSWORD = 'secret'

MANAGERS = (
 ('Frank Sinatra', '[EMAIL PROTECTED]'),
)
...


Global config and defaults go in settings.py.
Sensitive stuff and server specific settings/overrides go in 
settings_local.py.

settings.py goes in subversion.
settings_local.py does not.

I use this setup for all my projects, be it in Python, Java, PHP, whatever.

just my 2 cents
Steven

--~--~-~--~~~---~--~~
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-auth branch... time to merge?

2006-05-30 Thread Steven Armstrong

On 05/30/06 20:33, Joseph Kocherhans wrote:
> Has anyone tested out the multi-auth branch yet? I haven't heard
> anything, so either people aren't using it, or it's working well and
> the docs are good enough. Personally, I've been using it with both
> external SQL and LDAP backends for over a month now. No issues, but my
> apps are internal and don't get much traffic.
> 

I use it in an email-account administration app to authenticate against 
a custom Mailbox model with email/password credentials.

Works great, zero problems.

cheers
Steven

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



Must app names in django be unique?

2006-06-04 Thread Steven Armstrong

Hi,

It seems that app names in django must be unique or weird things happen. 
Is that correct?

I have a project called 'phc', in which I have an app called 'auth'. In 
this app there is a module named 'UserProfile'.

So my installed apps looks like this:
INSTALLED_APPS = (
 'django.contrib.auth',
 'django.contrib.contenttypes',
 'django.contrib.sessions',
 'django.contrib.sites',
 'django.contrib.admin',
 'phc.common',
 'phc.auth',
)

Django doesn't like that at all.

Part of the problem seems to be that in django.db.models.loading models 
are stored in the dict _app_models, keyed only by the last segment of 
the app-path.

If I comment out my phc.auth app, _app_models looks like this:

_app_models: {
 ...
 'auth': {
 'message': ,
 'group': ,
 'user': ,
 'permission': 
 },
 ...
}


With my own app enabled, it looks like this:

_app_models: {
 ...
 'auth': {
 'message': ,
 'userprofile': ,
 'group': ,
 'user': ,
 'permission': 
 },
 ...
}



When running syncdb, it attempts to create the database tables for all 
models in that 'auth' dict twice, which of course fails with SQL errors.

And when logging into the admin, all models are also listed twice.

e.g:

Auth --
Groups  Add Change
UserprofilesAdd Change
Users   Add Change

Sites -
Sites   Add Change

Auth --
Groups  Add Change
UserprofilesAdd Change
Users   Add Change



It looks like some parts of django actually know that those are two 
different apps, while others get really confused.

IMHO that's quite a limitation in regards to app sharing and portability 
and such.

Or am I missing something here?

cheers
Steven


--~--~-~--~~~---~--~~
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: Must app names in django be unique?

2006-06-04 Thread Steven Armstrong

On 06/04/06 14:00, Steven Armstrong wrote:
> Hi,
> 
> It seems that app names in django must be unique or weird things happen. 
> Is that correct?
> 


Just found this [1], so sorry for the noise. I searched through the 
tickets, but forgot to check the mailing list archives.

[1] 
http://groups.google.com/group/django-developers/browse_thread/thread/7197d27127494ee2/df18ee9b91ba383c?q=apps+with+the+same+name&rnum=1#df18ee9b91ba383c

--~--~-~--~~~---~--~~
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: Solving the POST-data-lost-after-redirect problem

2006-06-07 Thread Steven Armstrong

On 06/07/06 05:11, Adrian Holovaty wrote:
> http://code.djangoproject.com/wiki/NewbieMistakes#POSTtoviewslosesPOSTdata
> 
> It's about time to solve this one. Who has a creative, elegant solution? :-)
> 
> Some ideas, just to start discussion --
> 
> * THROW ERROR ON POST: The CommonMiddleware, when adding a slash and
> redirecting, can check for POST data. If it finds any, it somehow logs
> the error or otherwise alerts the developer. Maybe if DEBUG=True it
> can actually display an error, with a custom-built message saying "You
> need to change so-and-so form action to so-and-so URL"? I can't think
> of any case in which a POST to a page that needs to be redirected
> would be intentional, and if we only do it for DEBUG=True I think this
> may be acceptable.
> 
> * THROW ERROR ON FORM DISPLAY: If the APPEND_SLASH setting is set to
> True and the CommonMiddleware is activated, Django could check the
> output of every page for a  whose method is POST and has an
> "action" whose URL doesn't end in a slash. Then it could somehow alter
> the page to display an error on it. This solution is horrific, but I'm
> mentioning it here for diversity.
> 
> Adrian
> 

It probably needs some more thought and may be to 'magical', but how 
about something like this:

--
POST /some/url

- store POST/GET data as /tmp/78fsd8fasdf7ad8asaf7889sdf
- log error message, send email to admin
- redirect to /some/url/?cm_data_id=78fsd8fasdf7ad8asaf7889sdf


--
GET /some/url/?cm_data_id=78fsd8fasdf7ad8asaf7889sdf

- load POST/GET data from /tmp/78fsd8fasdf7ad8asaf7889sdf, populate 
POST/GET dicts with it
- remove cm_data_id from GET variables
- delete /tmp/78fsd8fasdf7ad8asaf7889sdf
- log message that data has been picked up



I believe you do something similar in the admin when a session is 
expired and you redirect to the login form.


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



Any news from the django dojo front?

2006-06-14 Thread Steven Armstrong

Hi all

Have been playing around with dojo lately and started building widgets 
to use in my django apps. Must say - although docs are sparse - dojo is 
one helluva framework :)

While googling for input I came across ticket #13 and now I'm wondering 
how much of those ideas and super sexy mockups are already being worked on.

There's also a ticket (#1613) that brings djangos JS widgets to dojo 
land. It seems to mostly work, just minor issues with date/time widgets.

Could someone involved (Jacob?) give some feedback on what the plans are 
and how/where I/we could help?

cheers
Steven

--~--~-~--~~~---~--~~
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: ManyToManyField looks broken

2006-06-26 Thread Steven Armstrong

On 06/25/06 16:58, Malcolm Tredinnick wrote:
> On Sun, 2006-06-25 at 22:39 +0800, Russell Keith-Magee wrote:
>> On 6/25/06, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
>> >
>> > I'd like to draw some attention to ticket
>> > http://code.djangoproject.com/ticket/2232 (mainly russelm's attention as
>> >   it appeared after his checkin 3195).
>> 
>> Paying attention now :-)
>> 
>> > Basically ManyToMany relations don't work when you try to get related
>> > queryset from a model where ManyToManyField is defined. Or is it just me?
>> 
>> For me, all the regression tests passed at time of checkin. Following
>> the rest of the messages on this thread, it looks like the problems is
>> with model importing. 2 quick observations which might help find the
>> problem:
>> 
>> 1) r3195 did make some changes to the model importing process, so this
>> might have changed the conditions under when any previous __import__
>> related bug revealed itself
>> 
>> 2) I have seen the behaviour from r1796 before - for me, the problem
>> ultimately turned out to be caused by a PYTHONPATH that included the
>> application directory (so "from myapp.models import Foo" and "from
>> myproject.myapp.models import Foo" were both legal). At the time, I
>> chalked it up to the pythonpath, and moved on (sorry - can't give any
>> more specific details as to SVN revision, exact code structure, etc).
>> 
>> I don't know if this helps anyone - however, I thought it might yield
>> a reliably broken test case.
> 
> I've just checked in r3202 which I believe fixes the root cause of #1796
> in a reasonably correct way. I think it also fixes #2232 for the same
> reason. It all seems to come down to the import paths being used as
> dictionary keys and models being registered twice. See the change for
> the way I am working around this.
> 
> Russ: can you see if I've overlooked any problem there, please. It took
> a little while to track everything down and my brain may have gotten
> twisted in the process. Also, I left it alone for now and I realise you
> were just cutting-and-pasting, but __import__ takes dictionaries as the
> second and third arguments (globals() and locals(), basically, although
> the third arg is essentially ignored); why are we passing in strings???
> 
> I can no longer cause #1796 or anything like it to fail -- and I had a
> couple of failing examples there. I believe relative imports
> (appname.models, etc) might now work reliably too (experiments suggest
> they do), which means you no longer are reliant on your project name and
> can create portable apps.
> 
> Feedback welcome/appreciated. I may have screwed up in some subtle way.
> 
> Regards,
> Malcolm
> 

I also had some problems related to this and started writing the mail 
below. But before sending it I noticed that you had checked something 
in, did an svn up, and my problem went away.

I don't know or understand how/where/if my problem and #2232/#1796 are 
really related, but it seems your checkin also solved my problem.

Just posting this here as a FYI.
Thanks for the fix :D

best regards
Steven

--
backward relationships for Many-to-many don't work for optional fields?

Given the following models

class Artist(models.Model):
  first_name = models.CharField(maxlength=30)
  last_name = models.CharField(maxlength=30)

class Event(models.Model):
  name = models.CharField(maxlength=255)
  artists = models.ManyToManyField(Artist, blank=True, null=True)


Forward relationship is ok:
  >>> event = Event.objects.all()[0]
  >>> event.artists



But the backward relationship API is not created/available:
  >>> artist = Artist.objects.all()[0]
  >>> artist.event_set
AttributeError: 'Artist' object has no attribute 'event_set'


If I change the artists field in the Event model to be required,
backward relationship starts working:

class Event(models.Model):
  name = models.CharField(maxlength=255)
  # artists is now a _required_ field
  artists = models.ManyToManyField(Artist)

  >>> artist = Artist.objects.all()[0]
  >>> artist.event_set



--~--~-~--~~~---~--~~
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: Default escaping -- again!

2006-07-28 Thread Steven Armstrong

On 07/28/06 15:34, Ahmad Alhashemi wrote:

> 
> Bill de hÓra wrote:
>> Scope it per template:
>>
>> {% extends "base_generic.html" %}
>> {% escape %}
>>
>> This lets people who want auto-escaping, have it, without typing in
>> "|escape" everywhere or screwing things up site wide with globals.
> 
> This is nearly perfect for my taste. The only thing is to make it just
> a bit more generic like this:
> 
> {% autofilter escape %}
> 
> This will specify that the escape filter will be applied automatically
> to all variables. It is just as easy to use, it is not specific to HTML
> and it can be used in other useful contexts, like for escaping in a
> JavaScript template. It doesn't break backward's compatibility. It
> doesn't force you to do anything you don't want to.
> 
> We can even provide the {! !} tags to mean "do not apply auto filter".
> Then I can immagine some files starting with:
> 
> {% autofilter javascript_escape %}
> 
> Then escaping and the {! !} will work perfecly well in a JavaScript
> template.
> 

nice! +1


--~--~-~--~~~---~--~~
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: modularity of apps

2006-07-29 Thread Steven Armstrong

Assuming that the reverse url mappings is taken care of I see two things 
one may want to define per app. configuration and dependencies

There are usually two kinds of configuration settings an app may need. 
Required ones that the user must set for the app to work, and optional 
ones for which sane defaults are pre-configured or simply none are needed.

In pyblosxom [1] plugins, we do it like this:
Every plugin can define a 'verify_installation' function which is called 
  by the engine when you run it in validation mode.

In this function the author can check if required settings are available 
and inform the user about the used defaults for optional ones.
One can also check for dependencies in this function, or just print out 
messages what's needed for the plugin to work.

I think this is a good approach, as it allows one to give the user hints 
what he needs to do to get it working.

Instead of:
ImportError: No module named foo

you get:
This application requires the 'foo' library to be installed.
You can download it from http://www.foo.com/download/.
Documentation is available at http://www.foo.com/docs/.

or:
You must add 'foo.context_processors.bar' to your 
TEMPLATE_CONTEXT_PROCESSORS for this application to work.


So maybe something like this would be useful:
- myapp/validate.py, which get's run when the user uses 'manage.py 
validate'. From here the user could get a step by step guide what he 
needs to do to get everything working.

- myapp/settings.py, for per app settings.
These could maybe be merged with myproject/settings.py in some clever way.


[1] http://pyblosxom.sf.net/

--~--~-~--~~~---~--~~
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: Strip Whitespace Middleware

2006-08-02 Thread Steven Armstrong

On 08/02/06 09:09, Malcolm Tredinnick wrote:
[...]
> My motivation here was having to debug an email generation template
> yesterday that was like a train wreck with all the template tags jammed
> together to avoid spurious blank lines. It's going to be a few more days
> before I can work on this seriously, I suspect (there are two more
> urgent Django things I need to finish first, for a start), so you might
> like to experiment along those lines too, if you're keen. I'm not sure I
> like my solution a lot, either, since it makes things a little more
> opaque in the code; still having debates with myself about that.
> 

I've written a template tag [1] for just that, more control over 
whitespace when generating config files and emails. Maybe that's useful 
for someone.

[1] http://www.c-area.ch/code/django/templatetags/normalize.py



--~--~-~--~~~---~--~~
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: Saving SECRET_KEY in a seperate file

2006-08-07 Thread Steven Armstrong

On 08/07/06 18:39, limodou wrote:
> On 8/8/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
>>
>> limodou wrote:
>> > On 8/7/06, Kevin Menard <[EMAIL PROTECTED]> wrote:
>> >> On 8/7/06, Joe <[EMAIL PROTECTED]> wrote:
>> >>> Wouldn't you want to put your database settings (Username and password)
>> >>> in another file as well?
>> >> I would be all for this.  I never liked that the settings file
>> >> contains both project-wide and user settings.  Since it's
>> >> project-wide, it gets added to the SCM.  Since it contains user
>> >> settings, users really shouldn't commit it back.  I realize it's
>> >> Python code and all that, but it seems to be a flaky default to me.
>> >>
>> > So I think secure data should be stored separately from project
>> > settings. Maybe usename and password should be stored in separate file
>> > also. But others don't need to do so. And if username and password
>> > also be stored with secure key together, maybe the appoach what
>> > Michael Radziej  suggested need to be considered.
>>
>> In reality, you will have multiple deployments: production,
>> staging, development, demonstration, depending on your company's
>> policy and what your project is about. For each of these you want
>> to use different databases, might have different middlewares
>> (e.g. for different logging levels, or you
>> might want the CSFR middleware not with your development server),
>> etc.
>>
>> I strongly disbelieve that any fixed scheme of storing some
>> settings separately will cover everybody's needs. It's easy
>> enough to code your own thing in your settings.py.
>>
>> Michael
> 
> So I think different things should be considered different. Just like
> before, many people would say settings.py is only a pure python source
> file, no one would stop you to change it, and make it suit for you.
> That's right. And I think many people like me have done like this. But
> I think a good framework must provide the enough flexibility, but also
> a good way about how to do the right thing. If something are proved to
> be the right and wonderful, why not bring it some spec-like things?
> And if someone don't like this and he still can modify the source
> code, and do what he want. I think if we can introduce such the best
> practice principles in django, it's a good thing.
> 
> And just like many people have said, if you should deploy the product,
> you should think about how to deal with securekey, username and
> password, that's right too. But if there is a default good appoach,
> and it's proved to be good, why we don't use it, and let our head take
> a rest. And I think I can learn many thinks from it.
> 
> Just some thought. It maybe not correct.
> 
> Why I bring this proposal, because I just saw thc settings.py in zyons
> project, and I think it a good way, and I should admit that, I don't
> think of it too much before. And I think there maybe many people don't
> think of it carefully also. So I sumbit this proposal. That's all.
> 

Why not just create a second settings file, call it settings_local.py or 
whatever, and at the end of settings.py do something like:

from settings_local import *

That way you can have settings.py under source control with application 
wide defaults configured and override anything you like in 
settings_local.py for per user or per machine configuration.

You can even have a settings_local.template under CVS with instructions 
to copy it to settings_local.py and change as required.

IMHO a simple, flexible solution for the problem.

--~--~-~--~~~---~--~~
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: Saving SECRET_KEY in a seperate file

2006-08-07 Thread Steven Armstrong

On 08/07/06 19:27, limodou wrote:
> On 8/8/06, Steven Armstrong <[EMAIL PROTECTED]> wrote:
>>
>> On 08/07/06 18:39, limodou wrote:
>> > On 8/8/06, Michael Radziej <[EMAIL PROTECTED]> wrote:
>> >>
>> >> limodou wrote:
>> >> > On 8/7/06, Kevin Menard <[EMAIL PROTECTED]> wrote:
>> >> >> On 8/7/06, Joe <[EMAIL PROTECTED]> wrote:
>> >> >>> Wouldn't you want to put your database settings (Username and 
>> >> >>> password)
>> >> >>> in another file as well?
>> >> >> I would be all for this.  I never liked that the settings file
>> >> >> contains both project-wide and user settings.  Since it's
>> >> >> project-wide, it gets added to the SCM.  Since it contains user
>> >> >> settings, users really shouldn't commit it back.  I realize it's
>> >> >> Python code and all that, but it seems to be a flaky default to me.
>> >> >>
>> >> > So I think secure data should be stored separately from project
>> >> > settings. Maybe usename and password should be stored in separate file
>> >> > also. But others don't need to do so. And if username and password
>> >> > also be stored with secure key together, maybe the appoach what
>> >> > Michael Radziej  suggested need to be considered.
>> >>
>> >> In reality, you will have multiple deployments: production,
>> >> staging, development, demonstration, depending on your company's
>> >> policy and what your project is about. For each of these you want
>> >> to use different databases, might have different middlewares
>> >> (e.g. for different logging levels, or you
>> >> might want the CSFR middleware not with your development server),
>> >> etc.
>> >>
>> >> I strongly disbelieve that any fixed scheme of storing some
>> >> settings separately will cover everybody's needs. It's easy
>> >> enough to code your own thing in your settings.py.
>> >>
>> >> Michael
>> >
>> > So I think different things should be considered different. Just like
>> > before, many people would say settings.py is only a pure python source
>> > file, no one would stop you to change it, and make it suit for you.
>> > That's right. And I think many people like me have done like this. But
>> > I think a good framework must provide the enough flexibility, but also
>> > a good way about how to do the right thing. If something are proved to
>> > be the right and wonderful, why not bring it some spec-like things?
>> > And if someone don't like this and he still can modify the source
>> > code, and do what he want. I think if we can introduce such the best
>> > practice principles in django, it's a good thing.
>> >
>> > And just like many people have said, if you should deploy the product,
>> > you should think about how to deal with securekey, username and
>> > password, that's right too. But if there is a default good appoach,
>> > and it's proved to be good, why we don't use it, and let our head take
>> > a rest. And I think I can learn many thinks from it.
>> >
>> > Just some thought. It maybe not correct.
>> >
>> > Why I bring this proposal, because I just saw thc settings.py in zyons
>> > project, and I think it a good way, and I should admit that, I don't
>> > think of it too much before. And I think there maybe many people don't
>> > think of it carefully also. So I sumbit this proposal. That's all.
>> >
>>
>> Why not just create a second settings file, call it settings_local.py or
>> whatever, and at the end of settings.py do something like:
>>
>> from settings_local import *
> 
> So what you do just like what I'v said:
> 
> "Just like
> before, many people would say settings.py is only a pure python source
> file, no one would stop you to change it, and make it suit for you."
> 
> :)
> 

yup, having python config files is way coool :)

>>
>> That way you can have settings.py under source control with application
>> wide defaults configured and override anything you like in
>> settings_local.py for per user or per machine configuration.
>>
>> You can even have a settings_local.template under CVS with instructions
>> to copy it to settings_local.py and change as required.
>>
&g

Re: Proposal: Saving SECRET_KEY in a seperate file

2006-08-07 Thread Steven Armstrong

On 08/07/06 20:35, Michael Radziej wrote:
> Steven Armstrong wrote:
> 
>> Why not just create a second settings file, call it settings_local.py or 
>> whatever, and at the end of settings.py do something like:
>> 
>> from settings_local import *
> 
> Well (apart from Adrian has put out his word now ...), my problem
> was that I had to build a debian package for my app, and the
> settings file should go somewhere below /etc and will be edited
> by the sysadmins. But your approach is perfectly valid if you
> don't have these constraints.
> 

Had a similar problem lately and ended up doing this:

cat /usr/lib/python2.4/site-packages/phc/settings.py
import sys
import imp

mysettings = imp.load_source('phc_settings', '/etc/phc/config.py')
for k in dir(mysettings):
   if k.isupper():
 #print '%s = %s' % (k, getattr(mysettings, k, None))
 setattr(sys.modules[__name__], k, getattr(mysettings, k, None))

del mysettings
del sys.modules['phc_settings']


A bit hackisch, but it works :)

Looking at it again a symlink would have also done the job. Oh well ...

> Probably another example that everybody has different needs here.
> 
> Michael
> 
> 
> 
> > 


--~--~-~--~~~---~--~~
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: Saving SECRET_KEY in a seperate file

2006-08-08 Thread Steven Armstrong

On 08/08/06 02:46, Malcolm Tredinnick wrote:
> On Mon, 2006-08-07 at 14:22 -0400, Kevin Menard wrote:
>> On 8/7/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>> 
>> > 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.
>> 
>> With the lack of an endorsed convention, I expect to see this question
>> to continue to come up.  IMHO, this is a common enough scenario to
>> warrant more than a simple write-off.
> 
> Add your favourite ideas to
> http://code.djangoproject.com/wiki/DosAndDontsForApplicationWriters and
> see if they work for other people.
> 
> Adrian's point is quite valid. Setting policy is something you do when
> there are real benefits to it and few or no other options. In this case,
> you have a full Turing-complete language available to do whatever meets
> your needs and (important point) is has zero maintenance cost for the
> developers (my favourite kind of flexibility).
> 

I've created a wiki page [1] with the different ideas from this thread 
and linked to it from the DosAndDonts page [2].

I hope that's ok for everybody who has posted their ideas/solutions 
here. Please add to that page if you have other ideas.

Steven

[1] http://code.djangoproject.com/wiki/SplitSettings
[2] http://code.djangoproject.com/wiki/DosAndDontsForApplicationWriters

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



Thoughts on extensibility of the admin app

2006-08-10 Thread Steven Armstrong

Hi all

I'm just thinking out loud here. Don't know if something like this is 
even wanted in django land.

I've been playing around with trac lately and am rather fond of their 
light weight component architecture [1].

I was wondering if an approach like this may be a good idea for the 
django admin application.

If done right it would make it possible/easy to hook into the admin app 
and extend it or change existing features and behavior.

Anyway, I just wanted to hear what other people think about this.

best wishes
Steven

[1] http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture

--~--~-~--~~~---~--~~
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: Can I respond to table cell mouse clicks without using JavaScript?

2006-10-01 Thread Steven Armstrong

On 10/01/06 16:22, carlwenrich wrote:
> I've done this with JavaScript, but I'd like to stay with Django/Python
> if possible.
> 

No. As this happens on the client JavaScript is your only option.

--~--~-~--~~~---~--~~
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: Potential bug in django.core.handlers.modpython ?

2006-10-16 Thread Steven Armstrong

On 10/16/06 20:13, DavidA wrote:
> Hi,
> 
> I noticed an inconsistency between the request META information in the
> modpython handler versus the base handler.
> 
> I'm opening the URL http://web/data/pos/ which goes through two URL
> conf's:
> 
> The default urls.py for the application:
> (r'^data/', include('pfweb.core.urls')),
> 
> And the urls.py for the 'core' app:
> (r'^pos/$', 'pfweb.core.views.list_positions'),
> 
> But under mod_python, request.META['PATH_INFO'] is '/pos/' while in the
> development server its '/data/pos/' (which I think is right).
> 
> I'm using the PATH_INFO as a base for my next/previous links so they
> aren't working in production (under apache).
> 
> Shouldn't I be able to see the full path of the URL somehow under
> mod_python? (Maybe there is a better way than I'm trying).
> 
> I'm not sure what's right so I thought I'd post a question here before
> submitting a ticket.
> 

Have you got a folder/file named 'data' in your apaches document root?
If so, try nuking or renaming 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-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: Potential bug in django.core.handlers.modpython ?

2006-10-16 Thread Steven Armstrong

On 10/16/06 20:27, DavidA wrote:
> 
> Steven Armstrong wrote:
>> Have you got a folder/file named 'data' in your apaches document root?
>> If so, try nuking or renaming it.
> 
> No. And no virtual directories or aliases named 'data' either, nor a
> file or folder named 'data' in my django project directory.
> 
> Note that the page URL is working (http://web/data/pos/) correctly
> under both Apache and the development server. Its just that I can't
> generate the correct URL for my next/prev links under Apache because
> that path is not correct.
> 
> -Dave
> 

Pitty that didn't work. I've had similar problems with mod_python and in 
my case it was apache being confused because of a folder with the same 
name in document root. After renaming the folder everything was fine.

Anyway it seems like this is a common problem with mod_python [1], [2].

The trac devs have also bumped into this. They solved it by explicitly 
passing the base url with a PythonOption [4]. Same as the MoinMoin devs [3].

Googling for 'mod_python path_info' turns up loads of similiar 
questions/problems/solutions.

Probably a mechanism like that [5] could/should be built into djangos 
mod_python handler.

[1] http://mail.mems-exchange.org/durusmail/quixote-users/3250/
[2] http://www.modpython.org/pipermail/mod_python/2003-July/013948.html
[3] http://moinmoin.wikiwikiweb.de/HelpOnInstalling/ApacheWithModPython
[4] http://trac.edgewall.org/ticket/552
[5] http://trac.edgewall.org/changeset/797


--~--~-~--~~~---~--~~
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: Developer documentation?

2007-02-08 Thread Steven Armstrong

Rob Hudson wrote:
> I'd like to see more inline documentation of the code.  Some .py files
> have this but some don't.  Just an overview of what the file does, how
> things are organized, maybe some concrete examples via doctests.
> Something for the average python programmer to get a toehold into what
> the code is doing.
> 
> Inline in the code seems like a good place for this to me.  It can be
> updated as the code changes.  And those digging around in the code are
> the ones who will benefit the most from it.
> 
> Cheers!
> -Rob
> 

+1

For developers this is IMHO the most useful kind of docs. Most likely to 
be up2date as well.

--~--~-~--~~~---~--~~
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: Getting started in Django development.

2007-02-12 Thread Steven Armstrong

zbelzer wrote:
> Hi all.
> 
> I've been learning about and working with Django for a little while
> now and I have decided that I would like to help contribute to the
> project and community. I'm decent with python, but I still find that
> looking through the entire code base is pretty intimidating and trying
> to follow the execution path of even something simple can become quite
> confusing.
> 

I've found this [1] useful to get an idea of the execution path. Saved 
me allot of grepping and searching.

[1] http://code.djangoproject.com/wiki/CookBookDeveloperTools


hth
Steven

--~--~-~--~~~---~--~~
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: i18n branch has been merged to trunk

2005-11-04 Thread Steven Armstrong


On 11/04/05 06:13, Jacob Kaplan-Moss wrote:

Howdy --

I've merged the i18n branch into the trunk; major thanks are due to  
hugo!  I'm running it live on all the LJW sites and it works fine,  
but there could be some lurking issues, so caveat programmer.  Adrian  
will have a blog post on the matter some time in the next day or two  
(he's got more docs he wants to write) but in the meantime you can  
check out http://www.djangoproject.com/documentation/translation/.


This also means that the i18n branch is defunct.  I'm keeping it  
around for posterity, but it's been marked read-only.


Thanks to hugo and to everyone else who worked on this!

Jacob



Hi everybody

Wouldn't it be better/easier to generally encode the .po files as utf-8?

For example the german translations are encoded as iso-8859-1.
I'm not sure, but guess that this may cause some headaches when serving 
content as utf-8. Or does the gettext library handle this some way?


Thanks a ton for the great work!

Cheers
Steven


Re: i18n for JavaScript

2005-11-28 Thread Steven Armstrong


On 11/28/05 18:25, hugo wrote:

My first instinct in this sort of case is to find out what others are doing,
i.e. Dojo folks, RoR, TG, etc.


That's what I did. Zilch. Nada. Zero. Nothing. Seems nobody ever cared
about a proper solution to JavaScript and i18n. What they do are hacks,
if they do something at all. Some of those hacks sound like the
possible solutions I listed - that's where I got them from ;-)

bye, Georg



Xinha (ex HTMLArea) uses a variant of 4). Altough without pluralization 
and all.


http://xinha.python-hosting.com/file/trunk/htmlarea.js

HTMLArea._loadlang = function(context) ...
HTMLArea._lc = function(string, context, replace) ...

The code is rather ugly and I'm not sure their approach is "the right 
way". But maybe thats a starting point?


cheers
Steven


Re: Django Ajax Redux

2005-12-10 Thread Steven Armstrong


On 12/10/05 21:45, Eugene Lazutkin wrote:

Inline.

"Robert Wittams" <[EMAIL PROTECTED]> wrote in 
message news:[EMAIL PROTECTED]


I had a look at dojo before and these were the questions that popped up
in my mind:

Dojo seems to rely on adding its own unnamespaced attributes to normal
elements. Is this compatible with strict use of XHTML?


No. Yes. And no. And Yes. Let me explain.

1) No. Adding your own attributes is not compatible with XHTML.



When talking about the admin views, that is views only accessible to a 
specific group of authenticated users, I don't realy care if some 
validator barfs on custom attributes or the like.


2) Yes. You can safely add your own attributes to XHTML code providing your 
specified your own namespace for them.


3) AFAIK, at present there is no standard-conformant XHTML browser. 
Translation: you can define your own namespace for attributes but browsers 
may ignore it and complain about "unknown attributes".


4) Given all that I tend to specify parameters using class names and HTML 
payload and/or JavaScript. Dojo supports specification of widget type using 
class name. It makes it possible to define your custom widgets in following 
manner:



1
Sparky


I believe it is fully compatible with XHTML.



I think using custom attributes, namespaced or not, is a powerfull, 
flexible and clean way to attach behaviours to elements. It also 
degrades nicely for older/non-js browsers.


Personally I prefer something like

to (ab)using classes as in your example.

Using classes it's not clear if it's there to style an element or to 
pass params to some js widget or whatever. When using custom attrs it's 
much clearer what's going on.


regards



Re: Django Ajax Redux

2005-12-12 Thread Steven Armstrong


On 12/12/05 01:15, Lachlan Cannon wrote:
Using classes it's not clear if it's there to style an element or to 
pass params to some js widget or whatever. When using custom attrs it's 
much clearer what's going on.


I couldn't disagree more. :)

class is there to 'subclass' elements. The W3C themselves say 
:


"""The class attribute, on the other hand, assigns one or more class names to an 
element; the element may be said to belong to these classes. A class name may be 
shared by several element instances. The class attribute has several roles in HTML:


 * As a style sheet selector (when an author wishes to assign style 
information to a set of elements).

 * For general purpose processing by user agents."""

This is exactly one of the reasons it's there for! Why go looking at 
(relatively) complicated things like namespaces when class works fine?


Point taken.

We once had to rebuild an existing rather complex site and I spend hours 
scanning through stylesheets fiddling out where which class was defined 
and what it's supposed to do.


After that experience I started using custom attrs for anything 
behaviour related.


Anyway, /me go's and rereads the w3c specs ... :)


Re: GvR prefers Django Template over Cheetah And Modularised Django

2006-01-31 Thread Steven Armstrong


On 01/31/06 22:25, Ian Holsman wrote:

are you proposing a standard interface to templating languages in python
ala WSGI but for templates?




There's currently a discussion about just that on the python web-sig 
mailing list.


http://mail.python.org/pipermail/web-sig/2006-January/thread.html#1912


syncdb inital sql data

2006-03-03 Thread Steven Armstrong

Hi django devs

In a app I'm currently building I rely on the 'sqlinitialdata' feature.
I've recently switched to the magical-removal branch where this is not 
yet implemented.

I've opened a ticket #1438 [1] and sent a patch that implements it.

It currently just fetches .sql files from the app/sql/ folder and 
executes them, which is just what i need. It also gets called from 
syncdb after that has finished its own business. Should sqlinitialdata 
take care of anything else?

If so could someone explain what?

I'ld be happy to implement this.

[1] http://code.djangoproject.com/ticket/1438

cheers
Steven

--~--~-~--~~~---~--~~
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: syncdb inital sql data

2006-03-03 Thread Steven Armstrong

On 03/04/06 01:34, Russell Keith-Magee wrote:
> On 3/4/06, Steven Armstrong <[EMAIL PROTECTED]> wrote:
>>
>> Hi django devs
>>
>> In a app I'm currently building I rely on the 'sqlinitialdata' feature.
>> I've recently switched to the magical-removal branch where this is not
>> yet implemented.
> 
> sqlinitialdata _was_ implemented, but it's been removed in favour of
> the new syncdb command. syncdb has been under development this week -
> it looks like Jacob put initdata stuff back in with r2482.
> 
> Thanks for the report, though. Does Jacob's patch restore all the
> behaviour you need? Can we close out your ticket?
> 
> Russ Magee %-)
> 

r2482 looks good and puts the bits and peaces I need back in place. I've 
closed the ticket myself.

Thank you.

cheers
Steven

--~--~-~--~~~---~--~~
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: Solved: DNS for *.djangoproject.com broken

2008-07-22 Thread Steven Armstrong

Ludvig Ericson wrote on 07/22/08 22:45:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Jul 22, 2008, at 16:40, Jeremy Dunck wrote:
>> In general, expect DNS hiccups for a while; the whole world is
>> patching right now.
> 
> Off-topic, yes, but I have to ask, what do you mean?

Guess he's referring to the recently discovered weakness in the DNS 
protocol [1].

[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447

--~--~-~--~~~---~--~~
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: MEDIA_URL template tag/context processor/etc again

2007-05-29 Thread Steven Armstrong

Simon G. wrote on 04/25/07 13:33:
> Evening all,
> 
> There's been a long history of people asking for some way of easily
> using the MEDIA_URL setting in templates. At a quick glance, I get
> #1278, #3818, #2532, and #4105.
> 
> These have all been marked wontfix, and I closed this last one to
> match. The reasoning for the wontfix is that this leads to a slippery
> slope of adding everything to the context and it's also quite easy to
> implement this on your own.
> 
> However, given the frequency of this request (I've seen it raised a
> few times in django-users too), I figured I'd ask if core's still
> against this, or whether we want to accept one of these.
> 
> --Simon
> 

+1 for #3818

I've been using a similar context processor for a while.

I prefer such an approach over something like #1278 as the 
developer/administrator chooses which settings to expose instead of the 
template designer.

Also it's more generic and can be reused for your own apps/settings.

Just my 0.02

cheers
Steven

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



validators as Meta attribute in ModelForms

2008-04-13 Thread Steven Armstrong

Hi

I've made a small change to the ModelForm framework to allow declarative 
definition of validators. This allows for quick and easy reuse of 
validators and means I have to write less clean_foo methods. This works 
both in the admin as in custom views.


What used to be written like this:

class Domain(models.Model):
 name = models.CharField(_('Name'), max_length=255, unique=True,
 validator_list=[validators.isValidHostName])
 active = models.BooleanField(_('Active'), default=True)


Could then be written like this:

class Domain(models.Model):
 name = models.CharField(_('Name'), max_length=255, unique=True)
 active = models.BooleanField(_('Active'), default=True)

class DomainModelForm(forms.ModelForm):
 class Meta:
 model = Domain
 validators = {
 'name': [validators.isValidHostName],
 }


And can be used in the admin like this:

from foo.forms import DomainModelForm
from foo.models import Domain
class DomainAdmin(admin.ModelAdmin):
 list_display = ('name', 'active')
 list_filter = ('active',)
 search_fields = ('name',)
 form = DomainModelForm
admin.site.register(Domain, DomainAdmin)


Anybody interested in this?
Is it worth opening a ticket with a patch?

Cheers
Steven

--~--~-~--~~~---~--~~
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: validators as Meta attribute in ModelForms

2008-04-15 Thread Steven Armstrong

Honza Král wrote on 04/16/08 00:13:
> Hi,
> check out ticket #6845 ( http://code.djangoproject.com/ticket/6845 ).
> It enables you to define validators on both DB Fields and FormFields
> and should make your work much easier.
> 

Hi Honza

Found your ticket just after posting this :)
Will keep an eye on it.

Thanks for the pointer.



--~--~-~--~~~---~--~~
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: Rethinking silent failures in templates

2008-05-18 Thread Steven Armstrong

James Bennett wrote on 05/18/08 06:30:
> On Wed, May 14, 2008 at 8:58 AM, Simon Willison <[EMAIL PROTECTED]> wrote:
>> Silent errors are bad. If we were to remove them, how much of a
>> negative impact would it have on the existing user base?
> 
> The impression I get is that a lot of people rely on silent *variable*
> failure, but very few rely on silent *tag* failure. In fact, most
> real-world custom template tags I've seen are wired up to raise errors
> quite loudly, and the few times I've tried to write tags which fail
> silently it's been a laborious process that results in much more
> brittle code.
> 
> And, really, variables are the big thing that the current behavior
> helps: it's really really nice to be able to do boolean tests on
> things that might not exist, and trust that the test evaluates False
> instead of, say, raising a KeyError because you asked about something
> that isn't in the context dictionary.
> 
> So, personally, I'd vote for keeping the current behavior with respect
> to variables, and rewriting any built-in tags to raise exceptions when
> you do something wrong.
> 

+1

What I personally would like to see is that such errors where logged 
somewhere. I know this came up before, and that the django devs, for 
whatever reasons, think it's not necessary.

But something like:

try:
whatever
except SomeTemplateError, e:
logger.debug('Template Error: %s', e)

Would IMHO be the most elegant solution.


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