Re: active tickets with patches
Russell Keith-Magee wrote: > On 12/6/06, Lakin Wecker <[EMAIL PROTECTED]> wrote: >> I am also interested in helping with this situation. I've run into quite a >> few patches that are reportedly working for some people.How do we help >> get these triaged? > > A well triaged patch has the following characteristics: > > - A clear, consise description of the problem > > - A clear, concise set of conditions and instructions for consistently > replicating the problem > > - A brief discussion of the merits of any alternatives for fixing the problem > > - A patch that meets Django's coding guidelines > > - If the patch is non-trivial [1], evidence that there has been > discussion on django-developers on the alternatives. > > - A regression test to prevent the problem in the future This is a very useful guideline. Maybe it should be incorporated into the doc on contributing[0]? > So - if you want to help, jump right in. Pick a problem and triage it. How do we avoid duplicating work? I'm not sure if it is necessary, but it could be useful to leave a message on a ticket when people start working on it. [0] http://www.djangoproject.com/documentation/contributing/ -- Matias Hermanrud Fjeld --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Ticket #914: Admin js option does not honor absolute urls
Hello. I've submitted a patch on ticket #914. The patch changes the behavior of the include_admin_script-templatetag. Should this have a regression test as well? If so, in what file should i put the test? -- Matias Hermanrud Fjeld --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
ManyToManyField Join Table Name
Hi, all. Regarding the join table that is created on ManyToMany relationships, there doesn't seem to be a way to override the name given to the table. Am I overlooking this somehow? If not, does anyone else think a join_table option would be as useful as the db_table one? Cheers, deryck -- Deryck Hodge http://www.devurandom.org/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Django Templates and BOM (byte order marks)
Greetings,
While researching strange IE behaviour at some pages of my
Django-powered site I've found that Django does not handle BOM marks
correctly.
For instance I have following templates (!UTF_8_BOM! = EF BB BF):
--- base.html
!UTF_8_BOM!http://www.w3.org/TR/html4/loose.dtd";>
blah-blah-blah
---
and
--- page.html
!UTF_8_BOM!
{% extends "base.html" %}
blah-blah-blah
---
If I will render page.html output will contain TWO byte order marks:
!UTF_8_BOM!!UTF8_BOM!http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Django Templates and BOM (byte order marks)
On 12/8/06, Sergey Kirillov <[EMAIL PROTECTED]> wrote: > For instance I have following templates (!UTF_8_BOM! = EF BB BF): Sort of off-topic, but why are you using a BOM in UTF-8? ;) -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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 feedback
I'm just starting to contsruct a form or two with the newforms package.
It works very nicely. However I have a couple of points so far:
It would be nice for the CharField field to output a "maxlength"
attribute if the max_length parameter is set. Otherwise we have to do
this:
name =
CharField(max_length=64,required=True,widget=TextInput(attrs={'maxlength':64}))
which is a bit unDRY.
Also, how can I pass a validator_list to get similar functionality to
manipulators? Having the ability to supply a validator_list containing
a list of small single purpose validators is quite nice. Have I missed
something?
Thanks,
Gary.
--~--~-~--~~~---~--~~
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: newforms feedback
On 12/8/06, Gary Doades <[EMAIL PROTECTED]> wrote:
>
> I'm just starting to contsruct a form or two with the newforms package.
> It works very nicely. However I have a couple of points so far:
>
> It would be nice for the CharField field to output a "maxlength"
> attribute if the max_length parameter is set. Otherwise we have to do
> this:
>
> name =
> CharField(max_length=64,required=True,widget=TextInput(attrs={'maxlength':64}))
>
> which is a bit unDRY.
>
> Also, how can I pass a validator_list to get similar functionality to
> manipulators? Having the ability to supply a validator_list containing
> a list of small single purpose validators is quite nice. Have I missed
> something?
you can subclass the Field class and add some validation, or you can
use ComboField, which can combine several Field classes' validations.
>
> Thanks,
> Gary.
>
>
> >
>
--
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: django.contrib.formtools: High-level abstractions of common form tasks
> > You could probably have a partial validation, per-page, and a complete > > one on the final page, essentially re-validating all the fields. > > HTML-escaping of these hidden fields values would be mandatory in all > > cases anyway. > > Yes, my thoughts exactly. Per-page validation, plus a final validation > after the last step of the wizard. What I've always done in these cases is carry a MAC along with the hidden data and just validate that the hidden data hasn't changed by re-hashing it after each form submit. You don't really need to re-validate the already-validated data, you just need to ensure that it hasn't changed since you validated it. JP --~--~-~--~~~---~--~~ 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: newforms feedback
On 12/8/06, Gary Doades <[EMAIL PROTECTED]> wrote:
> I'm just starting to contsruct a form or two with the newforms package.
> It works very nicely. However I have a couple of points so far:
>
> It would be nice for the CharField field to output a "maxlength"
> attribute if the max_length parameter is set. Otherwise we have to do
> this:
>
> name =
> CharField(max_length=64,required=True,widget=TextInput(attrs={'maxlength':64}))
>
> which is a bit unDRY.
Hey Gary,
Great suggestion! Based on your idea, I've just checked in an extra
hook, Field.widget_attrs(), which lets a Field specify any HTML
attributes to add to its Widget. I've implemented the maxlength
attribute for CharField, so your example can be rewritten like this:
name = CharField(max_length=64, required=True)
> Also, how can I pass a validator_list to get similar functionality to
> manipulators? Having the ability to supply a validator_list containing
> a list of small single purpose validators is quite nice. Have I missed
> something?
As Honza pointed out, you can use ComboField to combine validators
from multiple fields. Alternatively, you can create your own Field
subclass. I realize this is slightly more work than just specifying a
validator_list -- do you think it's OK?
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: newforms feedback
Honza Král wrote: >> Also, how can I pass a validator_list to get similar functionality to >> manipulators? Having the ability to supply a validator_list containing >> a list of small single purpose validators is quite nice. Have I missed >> something? > > you can subclass the Field class and add some validation, or you can > use ComboField, which can combine several Field classes' validations. Hmm, seems a lot of work to create a subclass for each field that I want to add custom validators to. The (combination of) validators, both custom and Django built-in, is quite large. The ability to simply pass in a list of validators for each field works well with manipulators. --~--~-~--~~~---~--~~ 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: newforms feedback
Adrian Holovaty wrote: > Hey Gary, > > Great suggestion! Based on your idea, I've just checked in an extra > hook, Field.widget_attrs(), which lets a Field specify any HTML > attributes to add to its Widget. I've implemented the maxlength > attribute for CharField, so your example can be rewritten like this: > > name = CharField(max_length=64, required=True) That's better. Thanks. > As Honza pointed out, you can use ComboField to combine validators > from multiple fields. Alternatively, you can create your own Field > subclass. I realize this is slightly more work than just specifying a > validator_list -- do you think it's OK? Well, obviously it works, but ultimately I will have dozens of forms (mostly custom) each with its own validation rules for the most part. We are talking simply passing a parameter to choose from a stock list of validators or writing code to subclass (potentially) lots of filelds or mess about with ComboFields. I would take the simplest option if possible! I'm not usually wanting to combine validators for multiple fields, but more to apply multiple validators to each field. For example I may want to check that a field is an integer and it has a maximum value of 23. On another form I may want to check that it is an integer and has a max value of 42. Trivial examples I know, but all solvable by just supplying a validator list to each field. Your thoughts? Thanks, Gary. --~--~-~--~~~---~--~~ 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: django.contrib.formtools: High-level abstractions of common form tasks
On 8 Dec 2006, at 19:10, JP wrote: > What I've always done in these cases is carry a MAC along with the > hidden data and just validate that the hidden data hasn't changed by > re-hashing it after each form submit. You don't really need to > re-validate the already-validated data, you just need to ensure > that it > hasn't changed since you validated it. MAC? An MD5/SHA1 hash, probably? -- Antonio --~--~-~--~~~---~--~~ 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: django.contrib.formtools: High-level abstractions of common form tasks
Here's a first attempt. As such, this code does per-page validation
only.
import cPickle as pickle
import base64
from django.core.exceptions import ImproperlyConfigured
from django.http import HttpResponse,HttpResponseRedirect
from django.shortcuts import render_to_response
from django.newforms.forms import SortedDictFromList
from django.newforms import *
class FormWizard(object):
'''
Formtools Wizard application
Given a list of django.newforms.Form objects, and a corresponding
list of step names,
it provides the following:
* Displays each form on a separate page in turn
* Marshals data between between pages in a hidden field
* Validates each form as it is submitted
* After the final form is validated, calls the done() hook that you
define
ToDo:
* Checksum marshalled data that's already been validated?
* Look at other ways to save state
* What's the most useful format for final data?
* Get feedback from people smarter than me
* Make this simpler
Usage:
Define your forms somwhere:
class PageOne(Form):
first_name = CharField()
class PageTwo(Form):
middle_name = CharField()
class PageThree(Form):
last_name = CharField()
Subclass FormWizard and define a done() method, overriding
form_template if you like:
class MyFormWizard(FormWizard):
form_template = MyApp/formwizard.html"
def done(self, request):
for clean_form_data in self.data:
...
In your urls.py:
(r"^mywizard/$",
MyFormWizard([PageOne,PageTwo,PageThree],["First","Middle","Last"])),
'''
form_template = "formtools/formwizard.html"
def __init__(self, form_steps, form_step_names):
'''
Store the wizard steps in a SortedDict
'''
form_steps = [(form_step_names[x], form_steps[x]) for x in
range(len(form_steps))]
self.form_steps = SortedDictFromList(form_steps)
self.data = [{} for x in range(len(form_steps))]
def serialize_data(self):
'''
Serialize our previously captured form data in a base64 encoded
pickle
'''
serialized_data =
base64.encodestring(pickle.dumps(self.data)).strip()
return serialized_data
def deserialize_data(self, serialized_data):
'''
Restore our previously captured data
'''
deserialized_data =
pickle.loads(base64.decodestring(serialized_data))
self.data = deserialized_data
def render_step(self, form, form_step_name, first=False,
last=False):
return render_to_response(self.form_template, {
"form": form,
"form_step_name": form_step_name,
"form_prev_state": self.serialize_data(),
"first": first,
"last": last,
})
def __call__(self, request, *args, **kwargs):
'''
Handle a request
'''
if request.method == "POST":
step_name = request.POST.get("form_step_name", "")
if step_name in self.form_steps.keys():
self.current_step_name = step_name
if request.POST.get("form_prev_state", None):
self.deserialize_data(request.POST.get("form_prev_state"))
submit_type = request.POST.get("submit_type", None)
if submit_type == "Prev":
return self.handle_prev(request)
elif submit_type == "Next":
return self.handle_next(request)
elif submit_type == "Finish":
return self.handle_last(request)
## initial request, display first step with no data ##
name,form = self.form_steps.items()[0]
return self.render_step(form(), name, first=True)
def get_prev_step_offset(self):
'''
Determine the previous step
'''
prev_offset = 0
try:
prev_offset =
self.form_steps.keys().index(self.current_step_name)-1
except:
pass
first = False
if prev_offset < 1:
prev_offset = 0
first = True
return first,prev_offset
def handle_prev(self, request):
'''
Go back to the previous step
'''
## add the current step's data, but we don't yet care if its
valid ##
form = self.form_steps[self.current_step_name](request.POST)
form.is_valid()
self.data[self.form_steps.keys().index(self.current_step_name)]
= form.clean()
first,offset = self.get_prev_step_offset()
data = self.data[offset]
name,form = self.form_steps.items()[offset]
return self.render_step(form(data), name, first=first)
def get_next_step_offset(self):
'''
Determine the next step
'''
offset = 0
try:
offset =
self.form_steps.keys().index(self.current_step_name)+1
except:
pass
l
Re: django.contrib.formtools: High-level abstractions of common form tasks
Here's an example template:
{% extends "base.html" %}
{% block content %}
{% if form.errors %}Please correct the following errors{% else
%}{{ form_step_name }}{% endif %}
{{ form }}
{% if not first %}
{% endif %}
{% if not last %}
{% endif %}
{% if last %}
{% endif %}
{% endblock %}
--~--~-~--~~~---~--~~
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: ManyToManyField Join Table Name
On 12/8/06, Deryck Hodge <[EMAIL PROTECTED]> wrote: > > Hi, all. > > Regarding the join table that is created on ManyToMany relationships, > there doesn't seem to be a way to override the name given to the > table. Am I overlooking this somehow? If not, does anyone else think > a join_table option would be as useful as the db_table one? No, there isn't a way to do this at the moment. This suggestion was made last week, and is described in ticket #3098. I'm pretty certain the patch attached to this ticket would work, and I'm happy to commit it as soon as there as there is some documentation and some unit tests. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: ManyToManyField Join Table Name
On 12/8/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On 12/8/06, Deryck Hodge <[EMAIL PROTECTED]> wrote: > > > > Hi, all. > > > > Regarding the join table that is created on ManyToMany relationships, > > there doesn't seem to be a way to override the name given to the > > table. Am I overlooking this somehow? If not, does anyone else think > > a join_table option would be as useful as the db_table one? > > No, there isn't a way to do this at the moment. This suggestion was > made last week, and is described in ticket #3098. > > I'm pretty certain the patch attached to this ticket would work, and > I'm happy to commit it as soon as there as there is some documentation > and some unit tests. Okay, I don't mind helping test the patch and pitch in on the other needed elements. Sorry I somehow overlooked the earlier discussion. I even searched the lists this morning and missed it. :-) Thanks for the info. Cheers, deryck -- Deryck Hodge http://www.devurandom.org/ --~--~-~--~~~---~--~~ 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: django.contrib.formtools: High-level abstractions of common form tasks
Hi,
nice work. I have been trying to come up with a solution of my own,
but I ran into some problems/questions:
1) I think it would be better to allow (but not force) users to add
actions after every step and a final done() - I have NO idea how to do
this, at least no working idea...
2) I don't know what would be the best way to store data from previous steps
individual fields sound the best, but for that they would need to
have some prefix to make them unique accross forms (perhaps modify the
form.fields names in __init__() ?? )
or whole pickled steps
with security hash (as in preview.py) for every step. failing the
hash check would revert the wizard to the step that failed to validate
3) templates - I think some users will want to specify different
templates for each step (if you supply a template_name as a string -
use it throughout the form, if list - use templates[step] for each
step --- but this seems too magical to my liking.. :-/
if all this is done (and I still hope I will find the way to do it, if
only as an excersize), the Preview could be rewritten as a fairly
simple (just override the method responsible for selecting a form to
always return the supplied form, and some other minor tweaks) wrapper
around the Wizard (DRY)
What do you think?
On 12/8/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Here's a first attempt. As such, this code does per-page validation
> only.
>
> import cPickle as pickle
> import base64
>
> from django.core.exceptions import ImproperlyConfigured
> from django.http import HttpResponse,HttpResponseRedirect
> from django.shortcuts import render_to_response
> from django.newforms.forms import SortedDictFromList
> from django.newforms import *
>
> class FormWizard(object):
> '''
> Formtools Wizard application
>
> Given a list of django.newforms.Form objects, and a corresponding
> list of step names,
> it provides the following:
>
> * Displays each form on a separate page in turn
> * Marshals data between between pages in a hidden field
> * Validates each form as it is submitted
> * After the final form is validated, calls the done() hook that you
> define
>
> ToDo:
> * Checksum marshalled data that's already been validated?
> * Look at other ways to save state
> * What's the most useful format for final data?
> * Get feedback from people smarter than me
> * Make this simpler
>
> Usage:
>
> Define your forms somwhere:
>
> class PageOne(Form):
> first_name = CharField()
>
> class PageTwo(Form):
> middle_name = CharField()
>
> class PageThree(Form):
> last_name = CharField()
>
> Subclass FormWizard and define a done() method, overriding
> form_template if you like:
>
> class MyFormWizard(FormWizard):
> form_template = MyApp/formwizard.html"
>
> def done(self, request):
> for clean_form_data in self.data:
> ...
>
> In your urls.py:
>
> (r"^mywizard/$",
> MyFormWizard([PageOne,PageTwo,PageThree],["First","Middle","Last"])),
>
> '''
>
> form_template = "formtools/formwizard.html"
>
> def __init__(self, form_steps, form_step_names):
> '''
> Store the wizard steps in a SortedDict
> '''
> form_steps = [(form_step_names[x], form_steps[x]) for x in
> range(len(form_steps))]
> self.form_steps = SortedDictFromList(form_steps)
> self.data = [{} for x in range(len(form_steps))]
>
> def serialize_data(self):
> '''
> Serialize our previously captured form data in a base64 encoded
> pickle
> '''
> serialized_data =
> base64.encodestring(pickle.dumps(self.data)).strip()
> return serialized_data
>
> def deserialize_data(self, serialized_data):
> '''
> Restore our previously captured data
> '''
> deserialized_data =
> pickle.loads(base64.decodestring(serialized_data))
> self.data = deserialized_data
>
> def render_step(self, form, form_step_name, first=False,
> last=False):
> return render_to_response(self.form_template, {
> "form": form,
> "form_step_name": form_step_name,
> "form_prev_state": self.serialize_data(),
> "first": first,
> "last": last,
> })
>
> def __call__(self, request, *args, **kwargs):
> '''
> Handle a request
> '''
> if request.method == "POST":
> step_name = request.POST.get("form_step_name", "")
> if step_name in self.form_steps.keys():
> self.current_step_name = step_name
> if request.POST.get("form_prev_state", None):
>
> self.deserialize_data(request.POST.get("form_prev_state"))
> submit_type = request.POST.get("submit_type", None)
> if submit_type == "Prev":
> return self.handle_prev(request)
Re: Django Templates and BOM (byte order marks)
Sergey Kirillov wrote:
> Greetings,
>
> While researching strange IE behaviour at some pages of my
> Django-powered site I've found that Django does not handle BOM marks
> correctly.
>
> For instance I have following templates (!UTF_8_BOM! = EF BB BF):
>
> --- base.html
> !UTF_8_BOM! Transitional//EN"
>"http://www.w3.org/TR/html4/loose.dtd";>
> blah-blah-blah
> ---
>
> and
>
> --- page.html
> !UTF_8_BOM!
> {% extends "base.html" %}
> blah-blah-blah
> ---
>
> If I will render page.html output will contain TWO byte order marks:
> !UTF_8_BOM!!UTF8_BOM! Transitional//EN" ...
>
>
>
> Of course I can fix this by introducing custom middleware, but I think
> problem should be handled at template loader level.
>
>
> Any comments?
i experimented a little, and here's what i found:
the basic "problem" is that django simply treats the templates as
byte-strings. for him even the BOM is simply a 3bytes-long text.
so, for example, in the following case:
==base.txt==
bbb
bbb
bbb
==inherit.txt===
xxx{% extends "base.txt" %}
if you render inherit.txt, you get
xxxbbb
bbb
bbb
as you see, the text before the extends-tag is kept.
and, in your case that text is the BOM.
so technically django behaves correctly (well, let's say consistently :)
even if we could change it, what would you propose?
i think the best solution would be to:
- strip the BOM, and remember that there was a BOM
- at the end, when the final rendered template is emitted, add the BOM
if it was used in the input templates
but this would mean that we have to "unicode-interpret" the template,
and i don't think that will happen before django goes completely unicode.
so, imho your best way of action is to strip the BOM from your templates
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
-~--~~~~--~~--~--~---
Re: schema-evolution: postgres introspection bug
> On 01/11/06, Matthew Flanagan <[EMAIL PROTECTED]> wrote: > > # select pg_constraint.conname, pg_constraint.contype, > pg_attribute.attname from pg_constraint, pg_attribute where > pg_constraint.conrelid=pg_attribute.attrelid and > pg_attribute.attnum=any(pg_constraint.conkey) and > pg_constraint.conname ~ '^myapp_foo'; >conname| contype | attname > ++- > myapp_foo_pkey | p | id > myapp_footype_pkey | p | id > myapp_footype_name_key | u | name > (3 rows) > > This is where I reach the boundaries of my postgres knowledge. > > Any help would be appreciated. > What do you want to do? I'm trying to see what you need and I'm not quite shure this is the correct way to do that. When you want to search data in the postgres catalog, there are some VIEWS you can use. so, What do you need? 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: newforms feedback
Adrian Holovaty wrote: > On 12/8/06, Gary Doades <[EMAIL PROTECTED]> wrote: > > Also, how can I pass a validator_list to get similar functionality to > > manipulators? Having the ability to supply a validator_list containing > > a list of small single purpose validators is quite nice. Have I missed > > something? > > As Honza pointed out, you can use ComboField to combine validators > from multiple fields. Alternatively, you can create your own Field > subclass. I realize this is slightly more work than just specifying a > validator_list -- do you think it's OK? I am also a fan of validator_list. As someone mentioned earlier, it is sometimes preferable to have two levels of data validation, at the form level and the model level. I have several cases where I have multiple forms that save to the same model in some way but use different validators. --~--~-~--~~~---~--~~ 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: proposal and patch: original_filename with FileField and ImageField
Ok, I just added a ticket(http://code.djangoproject.com/ticket/3119). Forget this patch at this time. Do you have any idea? 2006/12/4, tsuyuki makoto <[EMAIL PROTECTED]>: > Hello django developers. > > Currently, FIleField and ImageField store file-system-safe file name. > Imagine, if user upload a file named é.txt. > Yes, File-system-safe file name is .txt or _.txt. > It's not special case in Japan. > > I know Django says non dynamic contents should be served via apache-ish > server. > But the other hand. Some client says file must have original name. > > So, I make FileField and ImageField to have their original file name > like ImageField's width_field, height_field. > And if original_filename_field is specified, Field encodes and stores > file name as punycode. > eg. input développement image.jpg: >Field stores it dveloppement-image-kwa33c.jpg >original_filename_field stores it développement image.jpg > > And I make file download generic view that uses original file name > if Field has original file name attribute. > > attention: patch encoding is utf8. > > usage: > class TestModel(models.Model): > afile = > models.FileField(upload_to='afile',original_filename_field='orgname') > orgname = models.CharField(blank=True, maxlength=100) > class Admin: > pass > > (r'^file/(?P.*)/$','django.views.generic.simple.file_download', \ > > dict(queryset=TestModel.objects.all(),file_field='afile')), --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
