Re: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)

[Baptiste]

I have found from where was the error coming.
More details on http://code.djangoproject.com/ticket/3973.

Thanks
Baptiste

On 8 avr, 19:07, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
> On 4/7/07, Baptiste <[EMAIL PROTECTED]> wrote:
>
> > I don't know how that was before, but with your commits of today, I
> > can't access the list of some models (some others still work), because
> > of the error : 'NoneType' object has no attribute 'manager' (/django/
> > contrib/admin/filterspecs.py in __init__, line 161). I think it is an
> > issue in my models since they are not all broken, but maybe that would
> > be interesting to display errors messages understandable by humans to
> > help debugging...
>
> Hi Baptiste,
>
> Could you open a ticket for this, with an example of your models? I
> agree that a better error message would be a good thing, but I'd like
> to find the exact problem in your models (or bug in the newforms-admin
> branch) in order to figure out whether to display the message.
>
> Adrian
>
> --
> Adrian Holovaty
> holovaty.com | djangoproject.com


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

Re: contrib proposal: django-values

[Marc Fargas Esteve]

Hi,

On 4/8/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> * The name "values" is a bit too abstract -- it took me a while to
> figure out exactly what this framework *does*. Maybe something like
> "editable constants" or "model-specific options" would be more clear.


Isn't a constant supposed to be **constant** ? ;) As those values are
constant during server lifetime the name could be ok as it's clear. But
maybe "modelsettings" would also sound ok unless it's inside a secondary
namespace under the model in which case I'd go for "settings".


# NEW

> BlogEntry.constants.comment_limit


On this "settings" sound nicer, for me.

Integration with the admin interface would be also a nice thing!

Anyway, it's a nice contrib I think almost everyone here has thought about
something to handle model specific settings sometime and has large
settings.py :)

My 0.02,
Marc

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

#3527 - better debug traceback with code executing...

[jedie]

Why has django not a interactive AJAX traceback debugger?

Using a interactive debugger you can play with objects at any point in
the error traceback.

I known, a web shell is a open security hole. But the interactive
debugger should only running with the development Web server and if
debugging is on.
The development server is not for production use. So there is IMHO no
problem.

Here a example pictures from Pylons:
http://pylonshq.com/img/screenshots/doctraceback.gif


There exist some very nice modules:
http://pylonshq.com/docs/interactive_debugger.html
http://pythonpaste.org/module-paste.evalexception.html
http://trac.pocoo.org/browser/colubrid/trunk/colubrid/debug.py

See also:
http://blog.ianbicking.org/ajaxy-exception-catching.html

Here you can see a screencast, how paste evalexception works:
http://pythonpaste.org/screencasts/evalerror-screencast.html



Existing django ticket: http://code.djangoproject.com/ticket/3527


--~--~-~--~~~---~--~~
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: #3527 - better debug traceback with code executing...

[Malcolm Tredinnick]

Hi,

On Mon, 2007-04-09 at 04:33 -0700, jedie wrote:
> Why has django not a interactive AJAX traceback debugger?
> 
> Using a interactive debugger you can play with objects at any point in
> the error traceback.
> 
> I known, a web shell is a open security hole. But the interactive
> debugger should only running with the development Web server and if
> debugging is on.
> The development server is not for production use. So there is IMHO no
> problem.
[...]
> Existing django ticket: http://code.djangoproject.com/ticket/3527

The reason I originally closed that ticket as "wontfix" -- and I still
think it's the right reasoning -- is because the debug traceback handler
is not associated with whether or not the development server is running.

Instead, it is triggered by whether or not DEBUG is True. Sometimes you
want to have DEBUG=True in production environments, whether for just a
little period of time -- to debug something -- or for longer. So I am
reluctant to put in something that might be a security hole if there's
any chance of it being run on a production site.

Regards,
Malcolm



--~--~-~--~~~---~--~~
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: contrib proposal: django-values

[Honza Král]

On 4/9/07, Marc Fargas Esteve <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On 4/8/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > * The name "values" is a bit too abstract -- it took me a while to
> > figure out exactly what this framework *does*. Maybe something like
> > "editable constants" or "model-specific options" would be more clear.
>
> Isn't a constant supposed to be **constant** ? ;) As those values are
> constant during server lifetime the name could be ok as it's clear. But
> maybe "modelsettings" would also sound ok unless it's inside a secondary
> namespace under the model in which case I'd go for "settings".
>
>  # NEW
> > BlogEntry.constants.comment_limit
>
> On this "settings" sound nicer, for me.

I like "parameters", it wouldn't get confused with settings.py and
accurately describes what it does..

but problem is with name clashes... what if I have a field called
parameters (or constants for that matter)? i think this could work a
bit as a Manager class:

class MyParams( params.Parameters ):
  max_items = params.IntegerParam( 'Max ', default=6, )

class MyModel( models.Model ):
  field1 = models
  field2 = models

  params = MyParams()

that way you can choose the name for the pseudo-field and also reuse
your parameters (DRY: I want max_items on many models, I want it to be
simple to reuse these params)

> Integration with the admin interface would be also a nice thing!

definitely

> Anyway, it's a nice contrib I think almost everyone here has thought about
> something to handle model specific settings sometime and has large
> settings.py :)

definetely ;)

>
> My 0.02,

and mine

> Marc
>
>
>  >
>


-- 
Honza Kr�l
E-Mail: [EMAIL PROTECTED]
ICQ#:   107471613
Phone:  +420 606 678585

--~--~-~--~~~---~--~~
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: #3527 - better debug traceback with code executing...

[Armin Ronacher]

Hi,

On Apr 9, 1:48 pm, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> Instead, it is triggered by whether or not DEBUG is True. Sometimes you
> want to have DEBUG=True in production environments, whether for just a
> little period of time -- to debug something -- or for longer. So I am
> reluctant to put in something that might be a security hole if there's
> any chance of it being run on a production site.

The debugger must be additionally of course. Something like
ENABLE_DEBUGGER = True/False in the settings. I would say the debugger
is something that is missing in django. But it should be optional.

Regards,
Armin


--~--~-~--~~~---~--~~
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: #3527 - better debug traceback with code executing...

[Ned Batchelder]

If the only concern here is that debugging is a powerful feature that 
needs to be carefully controlled, then surely a setting to enable it is 
the right way to go?  After all, many security experts will tell you 
that the traceback handler we have now is a security hole, not because 
it lets you execute code, but because it reveals inner workings of the 
server, which can expose vulnerabilities.

Production servers need to have their settings carefully set.  That is 
true now, and it will be true if we add a DEBUGGER=True setting to 
enable this more powerful feature.  I say we add the power and let the 
administrators control where it appears.

--Ned.

Malcolm Tredinnick wrote:
> Hi,
>
> On Mon, 2007-04-09 at 04:33 -0700, jedie wrote:
>   
>> Why has django not a interactive AJAX traceback debugger?
>>
>> Using a interactive debugger you can play with objects at any point in
>> the error traceback.
>>
>> I known, a web shell is a open security hole. But the interactive
>> debugger should only running with the development Web server and if
>> debugging is on.
>> The development server is not for production use. So there is IMHO no
>> problem.
>> 
> [...]
>   
>> Existing django ticket: http://code.djangoproject.com/ticket/3527
>> 
>
> The reason I originally closed that ticket as "wontfix" -- and I still
> think it's the right reasoning -- is because the debug traceback handler
> is not associated with whether or not the development server is running.
>
> Instead, it is triggered by whether or not DEBUG is True. Sometimes you
> want to have DEBUG=True in production environments, whether for just a
> little period of time -- to debug something -- or for longer. So I am
> reluctant to put in something that might be a security hole if there's
> any chance of it being run on a production site.
>
> Regards,
> Malcolm
>
>
>
> >
>
>
>
>   

-- 
Ned Batchelder, http://nedbatchelder.com


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

Re: contrib proposal: django-values

[Gulopine]

On Apr 8, 11:18 pm, "oggie rob" <[EMAIL PROTECTED]> wrote:
> So, my first question is whether this could be designed to work
> without respect to models. For example, there are a lot of cases where
> views might refer to the same data, but not the same models. It would
> seem cleaner if there were a separation (and would avoid complications
> with inner classes vs. overridden fields). In my particular case, it
> would be cleaner to simply have a new class (or classes if it is
> easier to manage) that contains ALL the "constant" data.

Well, it should be fairly simple to put together a base class within
this framework that can then be subclassed in whatever file you like,
where you could then place your placeholder definitions. This way,
you'd have a separate class that's not connected to Django's DB
framework in any way, but is just a place for your settings.

On Apr 8, 11:18 pm, "oggie rob" <[EMAIL PROTECTED]> wrote:
> Was there a
> reason that you went with field-defined values? I can see the
> "context" argument, but seems like a lot of extra complexity if that
> is the only reason.

I'll list the reasons I chose the current approach, but I should note
that I'm not adamantly tied to any of these, they're just the reasons
I used when building it.

* Like any project, I could only plan for what I could anticipate. I
had no way of knowing what other people would want out of it, so I
only designed for the way my own project would best utilize it.
* Defining them directly inside models allows it to be 100% contrib,
with no modifications to Django's core. Given some of the other
suggestions here, however, this doesn't seem like the only way to go
about that, so I'm open to other concepts.
* Defining them within a class allowed me to use descriptors for
accessing their values. However, this only explains why they weren't
defined at the module level; including a separate class on which to
define them on would also satisfy this goal.

On Apr 9, 7:32 am, "Marc Fargas Esteve" <[EMAIL PROTECTED]> wrote:
> Integration with the admin interface would be also a nice thing!

Well, the supplied editor is based on the admin template, so it
visually integrates with the admin interface, but it does still
require a separate urlpattern, and no links are provided from within
the main admin interface. To me, it'd be ideal for the admin app to
have a way to "plug in" contrib apps like this into the admin. This
would work quite well next to the Add and Change links for the models,
or even at the app level if the app has model-neutral options. Or,
worst case, a separate pseudo-app section could be shown, with a list
of all the apps that utilize these options, with each link going to a
per-app editor.

Perhaps, since there's already considerable work being done on the
admin interface for newforms-admin, could something like this be
included? I'd be willing to do some work on it if it would be a
possibility.

On Apr 9, 7:56 am, "Honza Král" <[EMAIL PROTECTED]> wrote:
> but problem is with name clashes... what if I have a field called
> parameters (or constants for that matter)? i think this could work a
> bit as a Manager class:
>
> class MyParams( params.Parameters ):
>   max_items = params.IntegerParam( 'Max ', default=6, )
>
> class MyModel( models.Model ):
>   field1 = models
>   field2 = models
>
>   params = MyParams()

The ability to change the name would have been present in my subclass
idea mentioned above, but you bring up a very interesting idea. I
hadn't considered the possibility of sharing a set of options across
multiple models, and your example does show an excellent way of
representing that. In fact, that would tie in quite well with rob's
request for defining values without regard to any particular model. If
a separate class is used, it could be instiated within a model OR
directly at the module level.

It could also be useful for other contrib apps to supply their own
class, subclassing the base from this framework, but without
instantiating it. Take, for example, a framework that logs edits to
models. The framework could supply a class with options for what
events should be logged, as well as how much verbosity should be used
in the log. Since those could apply to any model, it would be up to
the individual project to simply import the class and instantiate it
on whichever models use it.

All in all, I'm starting to like the idea of a separate class that's
instantiated wherever it's used. I'll set up a branch for it on the
Google Code page and get to work on it.

Thanks again for all the feedback. It's great to hear that there are
others who need this.

-Gul


--~--~-~--~~~---~--~~
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://grou

European VAT registration number validation web service

[Frédéric Roland]

Hi,

I found an official web service from the european union to validate VAT 
registration numbers using SOAP.

I will have to use that for my projects but I'd like to share it with 
Django community.

At this time I just started to play with it but I wanted to discuss how 
to integrate that and what is the best place for such piece of code.

Does it belong to Satchmo (eCommerce Framework based on Django),
Django Contrib, Localflavor/eu , ... ?

Regards,
FR.


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

newforms-admin, newforms is missing FieldsetForm

[Jari Pennanen]

I've made this snippet: http://www.djangosnippets.org/snippets/164/
that I strongly believe should be part of Django (with little
polishing of course).

If newforms admin started to use that, we could give all views an
ability to use fieldsets too. That could be inserted to same file as
BaseForm or in separate, as long as it is part of Django and is used
by newforms admin to follow DRY, at current state I see no easy way to
implement similar as in class Admin: fields = (...) in one's own
views, this snippet is made for that DRY in mind.


--~--~-~--~~~---~--~~
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: European VAT registration number validation web service

[Marc Fargas Esteve]

Hi,
Can you provide an URL for those who haven't found such service? (The
spanish site for checking VAT's is like... s**t)

Maybe the best place to hold this is on it's own project (code.google.com?)
as a standalone application that users can checkout and put in
INSTALLED_APPS. And when it fine and runs smoothly you can start discussion
about including it in contrib.

But if it's a SOAP service you'll most likely have external dependencies
like a SOAP library and Django has a strict policy on not having external
dependencies which would block that from getting in contrib :)

Cheers,
Marc.

On 4/9/07, Frédéric Roland <[EMAIL PROTECTED]> wrote:
>
>
> Hi,
>
> I found an official web service from the european union to validate VAT
> registration numbers using SOAP.
>
> I will have to use that for my projects but I'd like to share it with
> Django community.
>
> At this time I just started to play with it but I wanted to discuss how
> to integrate that and what is the best place for such piece of code.
>
> Does it belong to Satchmo (eCommerce Framework based on Django),
> Django Contrib, Localflavor/eu , ... ?
>
> Regards,
> FR.
>
>
> >
>

--~--~-~--~~~---~--~~
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: European VAT registration number validation web service

[Frédéric Roland]

Hi,

 > Can you provide an URL for those who haven't found such service? (The
 > spanish site for checking VAT's is like... s**t)

Question 16 in VIES faq has a link to WSDL file:
http://ec.europa.eu/taxation_customs/vies/en/faqvies.htm#item16

There is also a form that can be used for manuel queries:
http://ec.europa.eu/taxation_customs/vies/en/vieshome.htm

There is nothing fancy but it just work.


> Maybe the best place to hold this is on it's own project ( 
> code.google.com? ) as a standalone application 
> that users can checkout and put in INSTALLED_APPS. And when it fine and 
> runs smoothly you can start discussion about including it in contrib.

Ok, I'll try to get some working code first.

> But if it's a SOAP service you'll most likely have external dependencies 
> like a SOAP library and Django has a strict policy on not having 
> external dependencies which would block that from getting in contrib :)

Ok, I understand.


FR.


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

DATABASE_CHARSET

[Ivan Sagalaev]

Hello everyone!

Malcolm has introduced DATABASE_CHARSET in changeset 4971[1] in a 
unicode branch. If I remember correctly this setting was needed if we 
have out internals in byte strings. But if internals are in unicode we 
(theoretically) can feed them as utf-8 or even in pure unicode to a 
database driver and let the driver do the encoding into a database's 
internal charset. All is needed from Django side is to declare client 
encoding to be always unicode (or utf-8, depending on backend). Now it's 
done differently: we try to declare the client encoding equal to the 
database encoding and decode to unicode upon receiving.

Malcom was it done because of some backend specific things? If not I 
could try the utf-8 approach I described on my machine.


[1]: http://code.djangoproject.com/changeset/4971

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

TEMPLATE_CHARSET

[Ivan Sagalaev]

As implemented now in unicode branch templates are loaded from files 
stored only in utf-8 (as far as I can read the code). However there's a 
problem with legacy template files that are stored in one-byte 
encodings. This is unfortunately not a rare thing and happen to raise 
offenses from developers who we are forcing effectively recode all their 
template files (and may be change text editors etc.)

May be a TEMPLATE_CHARSET setting will be useful?

-- 
Ivan Sagalaev, trading charset settings for food

--~--~-~--~~~---~--~~
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: contrib proposal: django-values

[Brian Beck]

On Apr 9, 9:02 am, "Gulopine" <[EMAIL PROTECTED]> wrote:
> > So, my first question is whether this could be designed to work
> > without respect to models. For example, there are a lot of cases where
> > views might refer to the same data, but not the same models. It would
> > seem cleaner if there were a separation (and would avoid complications
> > with inner classes vs. overridden fields). In my particular case, it
> > would be cleaner to simply have a new class (or classes if it is
> > easier to manage) that contains ALL the "constant" data.

This does sound useful, and I agree with the above -- the most
immediate use cases for my personal projects have little to do with
models and more to do with templates. For example, the number of
entries to display from my blog feed on my home page. It would be nice
to use this project to not have to restart the site just to change
that...


--~--~-~--~~~---~--~~
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: editable attribute limitation

[[EMAIL PROTECTED]]

There is a problem with:
http://code.djangoproject.com/ticket/3247
http://groups.google.com/group/django-developers/browse_thread/thread/50150b61aca46a7e

I've made a first working version but my implementation reverses the
changes described in the above ticket/discussion. Here's a summary of
what I did:

- cancel filtering of editable=False fields when creating forms for
instances and models (ie the fields are in the form, hence the above
remark)
- added an editable (default value True) field in newforms.Field
- added a DisplayWidget, and made Field use it when editable = False

Please tell if that is acceptable. Again, there seem to be an issue
with naming. Maybe there should be a name for fields that can be
created by the user but only seen afterwards, and purely internal
fields which are not even displayed.
Maybe those options could be spread out between the model and the
admin class ? The current semantics of editable make sense for models,
but what I'm doing would be relevant only for the admin.

Adrian: I've cc'd you so because you seem to be working on newforms-
admin. The context of this message is at
http://groups.google.com/group/django-developers/browse_thread/thread/1d7d8cb0662181c6

Regards,
Philippe


--~--~-~--~~~---~--~~
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: Status of SQLAlchemy branch

[Norjee]

I've uploaded the code to my website. 
http://jeroen.concept-q.com/projects/djangoalchemy/
(I'm sorry to admit that the website is plain unworkable in IE6, and
slow in other browsers. My use of transparency proves a tad ambitious)


--~--~-~--~~~---~--~~
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: #3527 - better debug traceback with code executing...

[Armin Ronacher]

Hoi,

Alright. Patch here: http://pocoo.org/~mitsuhiko/django_debugger.patch
Screenshot here: http://pocoo.org/~mitsuhiko/djangodebug.png

(Note, I edited those files in the same checkout I did the patches for
the __loader__ hook. So the patch is a bit bigger. Sorry for that)

Enable by adding ENABLE_DEBUGGER = True into the settings.py file

Also note: I had to modify the CommonMiddleware. That's not the best
way to hook the traceback AJAX call in, maybe there are better ways.

Regards,
Armin


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

wrong names in variables. startapp rutine

[Mario Gonzalez]

  I found a variable in django/core/management.py file named
project_name, its content should be the project name but it's not. It
saves the parent directory name instead, so I wrote a patch that fix
it.

Please, see
http://code.djangoproject.com/ticket/3846

Regards!
-- 
http://www.advogato.org/person/mgonzalez/

--~--~-~--~~~---~--~~
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: wrong names in variables. startapp rutine

[Adrian Holovaty]

On 4/9/07, Mario Gonzalez <[EMAIL PROTECTED]> wrote:
>   I found a variable in django/core/management.py file named
> project_name, its content should be the project name but it's not. It
> saves the parent directory name instead, so I wrote a patch that fix
> it.
>
> Please, see
> http://code.djangoproject.com/ticket/3846

Thanks, Mario. I've checked in the patch.

Adrian

-- 
Adrian Holovaty
holovaty.com | djangoproject.com

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

Re: wrong names in variables. startapp rutine

[mario__]

On Apr 9, 4:58 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> wrote:
>
> Thanks, Mario. I've checked in the patch.
>

 ok, I hope it help. Thanks for your time, regards!

>


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

[Malcolm Tredinnick]

Ivan,

On Mon, 2007-04-09 at 18:35 +0400, Ivan Sagalaev wrote:
> Hello everyone!
> 
> Malcolm has introduced DATABASE_CHARSET in changeset 4971[1] in a 
> unicode branch. If I remember correctly this setting was needed if we 
> have out internals in byte strings. But if internals are in unicode we 
> (theoretically) can feed them as utf-8 or even in pure unicode to a 
> database driver and let the driver do the encoding into a database's 
> internal charset. All is needed from Django side is to declare client 
> encoding to be always unicode (or utf-8, depending on backend). Now it's 
> done differently: we try to declare the client encoding equal to the 
> database encoding and decode to unicode upon receiving.
> 
> Malcom was it done because of some backend specific things? If not I 
> could try the utf-8 approach I described on my machine.

Look closer, my friend. There is no DATABASE_CHARSET setting. :-)

There was one for a while in my sandbox (and in my planning), but it
turned out not to be needed: every currently supported backend has a way
to either detect the client encoding or set it. So it works exactly as
you propose.

The only reference to DATABASE_CHARSET in that changeset was an
accidental leftover in the postgresql (psycopg1) backend. That was an
error. I removed it in r4972. :-)

Regards,
Malcolm



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

[Malcolm Tredinnick]

On Mon, 2007-04-09 at 18:56 +0400, Ivan Sagalaev wrote:
> As implemented now in unicode branch templates are loaded from files 
> stored only in utf-8 (as far as I can read the code). However there's a 
> problem with legacy template files that are stored in one-byte 
> encodings. This is unfortunately not a rare thing and happen to raise 
> offenses from developers who we are forcing effectively recode all their 
> template files (and may be change text editors etc.)
> 
> May be a TEMPLATE_CHARSET setting will be useful?

Yeah, I wondered about this. I was kind of hoping it wouldn't be an
issue, but people will insist on using non-portable encodings in their
files even in the 21st century. :-(

I'm not so much worried about the one-off conversion (after all, it's
for those peoples' benefit that we're doing this) as much as filesystems
that store in a particular encoding by default. There's no reliable,
non-expensive way to automatically detect the file encoding, so it
probably has to be done with a setting.

TEMPLATE_CHARSET is not the right name, though. Templates aren't the
problem: the filesystem encoding is. So maybe FILESYSTEM_ENCODING or
something explicit like that. We'll need to graft it into each
filesystem-based template loader and it defaults to utf-8.

Unless anybody can think of a really good technical reason not to have
this setting, I'm inclined to put it in.

Regards,
Malcolm


--~--~-~--~~~---~--~~
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: editable attribute limitation

[Malcolm Tredinnick]

On Mon, 2007-04-09 at 18:28 +, [EMAIL PROTECTED] wrote:
> 
> There is a problem with:
> http://code.djangoproject.com/ticket/3247
> http://groups.google.com/group/django-developers/browse_thread/thread/50150b61aca46a7e
> 
> I've made a first working version but my implementation reverses the
> changes described in the above ticket/discussion. Here's a summary of
> what I did:
> 
> - cancel filtering of editable=False fields when creating forms for
> instances and models (ie the fields are in the form, hence the above
> remark)
> - added an editable (default value True) field in newforms.Field
> - added a DisplayWidget, and made Field use it when editable = False

Without seeing the patch, it's hard to comment on specifics, but this
feels like more machinery than I would have expected. Why isn't this
just a matter of inserting a single static string when they reference
{{ field_name }} in the form? You might need a dummy widget to give it
the right method, but I'm not sure why the editable attribute is needed
in Field. A non-editable field shouldn't ever participate in the form
submission process, for example.

The main argument *against* having any support at all for non-editable
fields in normal forms is that you can just insert their value directly
yourself. This argument breaks down a little in the case of the admin
app, since there is a benefit in being able to read the values of
non-editable fields when editing other fields. I would still have
thought it was close to a one-method class, though (okay, maybe a little
more than one method, but not a lot).

> Please tell if that is acceptable. Again, there seem to be an issue
> with naming. Maybe there should be a name for fields that can be
> created by the user but only seen afterwards, and purely internal
> fields which are not even displayed.

No. For a form created by a person, if you don't want the field
displayed, don't put it in the form. That's up to the template designer.

For the admin, there is the list of fields to display (presumably
there's something similar in newforms-admin).

If you want that sort of control, you may not be able to use
form_for_instance() and form_for_model(). Not a big deal. They're  aids
for common cases. Uncommon cases, like treating different non-editable
fields differently might require the developer to write a helper
function.

> Maybe those options could be spread out between the model and the
> admin class ? The current semantics of editable make sense for models,
> but what I'm doing would be relevant only for the admin.

I don't understand this. Open a ticket and attach the patch might be
easiest. I can't see why this is admin specific.
[...]

Regards,
Malcolm


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

incorrect sql generated for sort in admin changelist

[Tai Lee]

http://code.djangoproject.com/ticket/2884

this ticket was opened 6 months ago with a patch, fixing a bug where a
ProgrammingError is raised when sorting by a foreign key field which
has an ordering clause that contains further foreign key fields.

i ran into this bug when specifying a foreign key in the Meta class'
ordering property, but it seems it would apply when clicking on and
attempting to sort by a foreign key field within the changelist even
if no ordering is specified.

could somebody with commit or triage access take a look at this
ticket, and if it's still valid against the current trunk, think about
committing the patch?

cheers.
tai.


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

Re: DATABASE_CHARSET

[Ivan Sagalaev]

Malcolm Tredinnick wrote:
> The only reference to DATABASE_CHARSET in that changeset was an
> accidental leftover in the postgresql (psycopg1) backend. That was an
> error. I removed it in r4972. :-)

Great!

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

[Ivan Sagalaev]

Malcolm Tredinnick wrote:
  > I'm not so much worried about the one-off conversion (after all, it's
> for those peoples' benefit that we're doing this) as much as filesystems
> that store in a particular encoding by default. There's no reliable,
> non-expensive way to automatically detect the file encoding, so it
> probably has to be done with a setting.
> 
> TEMPLATE_CHARSET is not the right name, though. Templates aren't the
> problem: the filesystem encoding is. So maybe FILESYSTEM_ENCODING or
> something explicit like that. We'll need to graft it into each
> filesystem-based template loader and it defaults to utf-8.

But filesystem doesn't control the encoding of file's content. It may do 
some things to file names but it's another story. The default encoding 
in which a file is saved depends on locale and on a text editor's 
abilities and settings (Notepad.exe saves in Windows' system single-byte 
encoding by default but may easily save in utf-8 if told so).

So if we're talking about file's content then it's only templates we 
should worry about since Python sources have their own way to deal with 
it that must be used to correctly deal with u'...' things.

So I'm still +1 on TEMPLATE_CHARSET.

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

Removing auto_now and auto_now_add

[Russell Keith-Magee]

Hi all,

I'm trying to tie up the loose ends of the auto_now/auto_now_add
discussion so that I can bang together a patch.

auto_now_add can be pretty much replaced with default=datetime.now.
Honza raised the issue that the two aren't completely identical
because if you supply a value for the field, it will override the
default. However, for my money, the default approach is acutally
better, because the current behaviour of auto_now_add messes with the
serializers.

However, auto_now is a reasonable use case, and doesn't have an
obvious replacement. A few options have been suggested:

1) Leave it completely up to the user to define their own auto_now equivalent.

2) (Jacob) Add a child class of DateTimeField that defines the
required pre_save behaviour.

3) (Brian Beck) Add a 'default_condition' parameter - a function that
is evaluated to determine if the default value should be applied.

4) (Sean Perry) Add a factory method that can produce an
implementation of save that updates the values of named fields.

However, I haven't been able to find the original discussion leading
to this decision in the archives (other than a reference in the early
discussions about model validation [1]), so I haven't been able to
establish the source of the original objection to auto_now - and as a
result, I can't really evaluate if any of these proposals overcome the
perceived problems of auto_now.

Anyone care to comment on the underlying reason for removing auto_now?
Are there any other solutions I have missed? Any preferred solutions?

Yours,
Russ Magee %-)

[1] 
http://groups.google.com/group/django-developers/browse_thread/thread/b0bd008c85cf8fa0/341df9d41f5ad491

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

[Gabor Farkas]

Malcolm Tredinnick wrote:
> On Mon, 2007-04-09 at 18:56 +0400, Ivan Sagalaev wrote:
>> As implemented now in unicode branch templates are loaded from files 
>> stored only in utf-8 (as far as I can read the code). However there's a 
>> problem with legacy template files that are stored in one-byte 
>> encodings. This is unfortunately not a rare thing and happen to raise 
>> offenses from developers who we are forcing effectively recode all their 
>> template files (and may be change text editors etc.)
>>
>> May be a TEMPLATE_CHARSET setting will be useful?
> 
> Yeah, I wondered about this. I was kind of hoping it wouldn't be an
> issue, but people will insist on using non-portable encodings in their
> files even in the 21st century. :-(
> 
> I'm not so much worried about the one-off conversion (after all, it's
> for those peoples' benefit that we're doing this) as much as filesystems
> that store in a particular encoding by default. There's no reliable,
> non-expensive way to automatically detect the file encoding, so it
> probably has to be done with a setting.
> 
> TEMPLATE_CHARSET is not the right name, though. Templates aren't the
> problem: the filesystem encoding is. So maybe FILESYSTEM_ENCODING or
> something explicit like that. We'll need to graft it into each
> filesystem-based template loader and it defaults to utf-8.
> 

python uses sys.getfilesystemencoding to detect the filesystem's 
encoding, but it's not perfect, because for example on linux, there 
isn't any guarantee that this encoding (as far as i know python is 
guessing it based on your locale) is used in your template file.


but what i don't understand, is: why is this an issue? can't we assume 
that the developer knows the encoding of his own files? and if he knows 
them, he should be able to easily recode them to utf-8, for example.

i'm personally for the one-encoding-to-rule-them-all solution btw :)
the only issue i have with it is that if we make utf-8 mandatory,
will it be still easy/possible to generate html files in non-utf-8?

gabor

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