Re: How decoupled should forms and models be (was: Re: Move form_for_instance and form_for_model into django.db.models.Model?)
On Fri, 2007-07-13 at 01:31 -0400, Todd O'Bryan wrote: > On Fri, 2007-07-13 at 14:43 +1000, Malcolm Tredinnick wrote: > > > I'm -1 one on this for pretty much the same reasons as Adrian. It's just > > not that big a deal even for people who want to work the way you do. > > I should have re-subjected my second post, since I'm willing to accept > the loss of a possible field named form in the model as sufficient > reason for keeping form_for_instance and form_for_model outside the > model space. > > My question for the rest of the second message was a question of how > much separation between forms and models there should be. For me the > validation issue is key. We currently don't have any standard way to > programmatically validate model fields, but we can validate forms before > we stick them into model fields. Seems like it'd be easy to avoid some > duplication if we just admit the possibility that model fields can > optionally specify something about their form fields. Okay, I understand where you're coming from. I think your concerns are mitigated somewhat by realising you are talking about something we are going to fix prior to 1.0: adding model-aware validation. The rough way this works is that you populate your model's fields, then call the validate() method (however it ends up being spelt) and it will raised ValidationError and provide access to an error dictionary, etc. All similar to forms, but related to the model. Thus, if your validation requirements are mostly related to the data semantics of a particular model, it will rightly belong in the model's validation. Other pieces of validation will belong more naturally to form field validation. So, I think you'll find that each piece of the validation mechanics will end up in only one place. This is actually a piece of work I want to get onto really soon, since it keeps coming up and we keep saying we're going to fix it. It isn't that hard, since Adrian did most of the hard work early last year. I have a couple of other things to do first, but it might be something I can get mostly done before OSCON and then smack it around with some of the people there a bit, too (as well as the no-doubt endless mailing list threads). Regards, Malcolm -- Monday is an awful way to spend 1/7th of your life. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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: How decoupled should forms and models be (was: Re: Move form_for_instance and form_for_model into django.db.models.Model?)
On 7/13/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote: > My question for the rest of the second message was a question of how > much separation between forms and models there should be. For me the > validation issue is key. We currently don't have any standard way to > programmatically validate model fields, but we can validate forms before > we stick them into model fields. Seems like it'd be easy to avoid some > duplication if we just admit the possibility that model fields can > optionally specify something about their form fields. My personal opinion: the less coupling between models and forms, the better. I'd even go so far as to suggest (though I don't think it'll happen) that form_for_model and form_for_instance should go live in django.shortcuts with the other cross-cutting utility functions ;) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
With AGLOCO You can earn money so good.
Hi. We would like to notify to you new affiliate program that name is AGLOCO. Please Read it be carefully With AGLOCO You can earn money, and valuable shares too, when you surf the web like you always do. What is AGLOCO(tm) all about? AGLOCO is the first Internet based economic network, which enables you as a Member to 'Get your share of the internet.' Advertisers, search companies, online merchants and other businesses currently pay lots of companies to deliver people like you to them to get your attention and sell goods. With AGLOCO they will be paying YOU. AGLOCO is a global community of Internet users whose active Members can be paid for all their online activity. By downloading their proprietary Viewbar(tm) technology, members benefit from engaging yet unobtrusive content tailored to their interests. AGLOCO also pays its members to refer their friends to the community (and for those friends to refer more friends through four levels of extended referrals.) The Internet's First Economic Network Today's hottest Internet businesses are all about the power of social networks. Companies like MySpace, Facebook, and YouTube have become worth billions because businesses have realized that these social networks are generating huge advertising and marketing opportunities. As these social networks grow, the economic potential for its owners - and the advertisers who target the site's users - is remarkable. AGLOCO asked one simple question: The users created the community, where's their share of the profit? It was from this question that AGLOCO set out to create the Internet's first Economic Network, harnessing the power of Internet-based social networks to directly benefit the Members who help to create the community. Becoming a member of AGLOCO is as simple as completing a brief sign-up page (name, age, location and email address.). Once you're a Member, you will be asked to then download the Viewbar(tm) software. >From there you can begin referring your friends, and family, and begin earning cash, and shares in the company, by simply using the excellent AGLOCO Viewbar(tm). Do You Realize How Valuable You Are? Advertisers, search providers, and online retailers are paying billions to reach you while you surf. How much of that money are you getting? You Deserve A Piece of the Action AGLOCO gets paid by companies to reach their Members through their Viewbar(tm) software. Then they give that money back to you! Build the Community, Make More Money Through their Referral Program, they reward those who are helping to build this Global Community. The bigger the community, the more money AGLOCO makes for its Members. What's the Catch? No catch. Sign up, refer your friends, download the free Viewbar(tm) software and surf the Internet as you normally would. Privacy Counts. Your information will never be sold, rented,or shared with anyone else. Bulletproof privacy is a core commitment of AGLOCO. AGLOCO takes privacy very seriously and keeps all of your personal information strictly confidential and secure. Some other popular Internet companies take your personal information, use it, profit off it, sell it to others, and then give you nothing. AGLOCO will not share ANY of your Membership information with any unauthorized third party, and YOU share in the profits made from more personalized advertisements. AGLOCO's privacy policy stipulates exactly what information might be collected. It is 100% transparent and spyware-free. Moreover, while you are paid for the time the Viewbar is up, you can turn it off at any time. To ensure that your privacy is kept paramount, AGLOCO has hired a Chief Privacy Officer, Ray Everett-Church. Ray was the Internet's first Chief Privacy Officer, and co-author of 'Internet Privacy for Dummies'. You can trust that your privacy is safe with AGLOCO. AGLOCO makes money for its Members in many ways: * Search: Every time you use the Viewbar(tm) to do an Internet search with yahoo, google, etc, the AGLOCO community earns money from the search engine providers. (For example, Google pays as much as $0.10 on average for each search that is directed to its search engine.) * Advertising: The Viewbar(tm) itself displays ads that are targeted based upon the websites you're visiting. When you click on an ad and make a purchase, the AGLOCO community receives a referral fee, which we pass on to our Members. (Please note: Individual members do not receive any compensation for clicking on ads in the Viewbar(tm), and the Viewbar(tm) can detect if someone is clicking ads in a fraudulent manner.) The Viewbar has space for a text-only ad so you don't have to worry about loud, flashing banners - just unobtrusive text. * Transaction commissions: AGLOCO has affiliate programs with a number of online retailers. The retailers pay commissions when they are referred customers who make a purchase. AGLOCO collects that commission and passes it on to our members. (For example, Amazon pays an
Re: Ticket 3505, Authentication backend
On 7/12/07, Mario Gonzalez <[EMAIL PROTECTED]> wrote:
>
> in my settings file I set AUTHENTICATION_BACKENDS = ('something.that-
> doesnot.exists') so when you use the authenticate() method in some
> view a ValueError is raised. So, my patch catch that exception in
> load_backend() method.
>
> IMO, it's a validation mistake and that I'm trying to fix.
Ah - the error you are catching is a very specific subset of the
problem that I wasn't checking.
AUTHENTICATION_BACKENDS = ('something.that-doesnot.exists')
defines AUTH_BACKENDS to be a string, not a tuple, and that is the
error you are catching (note the missing comma). Note the missing
comma. If you have the comma in the tuple, Django correctly reports
that the backend doesn't exist.
I've modified the patch you submitted to provide a more meaningful
error message, and committed it in [5678].
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: Move form_for_instance and form_for_model into django.db.models.Model?
On Thu, 2007-07-12 at 18:21 -0400, Todd O'Bryan wrote: > form_for_instance and form_for_model are great, but if you have to tweak > the form in any way (say you want to use a non-default widget for one of > the data fields) and want to use it more than once, you're reduced to > defining a new Form class or at least a new callback function to control > the field types. And where do you put that? For me, it's pretty clearly > an attribute of the model in the same way that a utility method would > be, because it just doesn't have any meaning without the model. So you > put it in the model. You're projecting your particular design preferences onto everything else here. Not a horrible thing, since everybody has different preferences. However, you are also making a mountain out of a molehill in the process: you are talking about trying to save one import. The other way to look at the functionality you are doing is that they don't belong anywhere near the models, since one model is not tied to a single form. models and forms may (or may not) intersect. That intersection will often not happen in the model file, since the model is the data representation. It might happen in the view file, if it's small enough. You might decide to create a file (or module) containing a bunch of forms for a partiular presentation format. In any case, the form *processing* is going to happen in the view (or be controlled by the view). It's a presentation-related piece of functionality. To which you will answer, "but I think it should go in the model." Which can already be done. That's the beauty of namespaces, aliases and imports. Forcing it into the model space is a compulsory merging of two not necessarily related pieces of functionality. The argument that we already have the slightly dirty formfield() method in db.models.fields is not really a counter, either. It's not a perfect construct (I would rather have tied model fields to a corresponding form field in the forms namespace, since it's presentation, not semantic), but it shouldn't be used as the top end of a slippery slope to make things worse. I'm -1 one on this for pretty much the same reasons as Adrian. It's just not that big a deal even for people who want to work the way you do. Regards, Malcolm -- Despite the cost of living, have you noticed how popular it remains? http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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: Unicode Keys
On Thu, 2007-07-12 at 20:08 -0500, Jeremy Dunck wrote: > On 7/12/07, Collin Grady <[EMAIL PROTECTED]> wrote: > > For instance, if I have an input with name="語" and request.POST > > doesn't support unicode, how do I then get the value for that? :) > > I believe the issue is that *names* for kwargs can not be unicode. Yes, that's true, but Collin is correct, too, and that's one of the compelling reasons for using Unicode there. Since I've been sucked into responding to this thread, here's the background for the current design (it's not an oversight): The data you get from a form, including the control names is not guaranteed to be ASCII. So the client code either has to get back Unicode or a bytestring and decode it everywhere. After a fair bit of thinking and research (looking at existing uses), I decided that consistency was fairly important and that unless the result is guaranteed to be ASCII in a bytestring, or required to be a bytestring (suitably encoded), Django should always pass back Unicode strings. I was even aware that passing things directly to functions would require some type coercion, but when I sat down and went through everywhere it's likely to be used there were almost no occurrences. Internally, we have to do it in two places (the url template tag and in urlresolvers.py). I also looked through about a bunch of projects on Google code and couldn't find any compelling cases that would be harmed. Almost all the time, passing input args directly to a function is not going to be a good idea. You have to sanitise them anyway, so this inadvertently helps to catch errors. If you truly want to pass in a grab bag of name/value pairs, you can pass them in as a dictionary (i.e. pass in "data", rather than "**data") and you still access it exactly the same way in the function. So, unfortunately, in one or two legitimate cases, people are going to get bitten. I'll update the backwards-compat page and porting guidelines in a moment. The benefits (consistency of data representation) outweigh the disadvantages, though, since this is a rare use-case and can be worked around in one line of code. Regards, Malcolm -- Plan to be spontaneous - tomorrow. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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: Problem using RadioSelect with newforms-admin
On 7/10/07, leif strickland <[EMAIL PROTECTED]> wrote:
>
> As you can see, the template is expecting a unicode object, but the
> RadioSelect widget returns a RadioFieldRenderer object.
>
> I was able to get around this problem by subclassing RadioSelect and
> adding to its render method:
I'm not getting the same problem. Here's my sample Admin class,
controlling a Poll/Choice example that has been augmented with a
'flavour' field (just so I can have something that needs a radio
option):
class PollAdmin(admin.ModelAdmin):
inlines = [admin.TabularInline(Choice, extra=2)]
fields = (
('main', {
'fields': ('question','participants','flavour'),
}),
)
def formfield_for_dbfield(self, db_field, **kwargs):
if db_field.name == 'flavour':
return
forms.ChoiceField(choices=FLAVOURS,widget=forms.RadioSelect,**kwargs)
else:
return
super(PollAdmin,self).formfield_for_dbfield(db_field,**kwargs)
Does this correlate with what your admin class, or have you done
something different?
Regarding your suggested fix: Looking at the code (r5628,
django/newforms/forms.py, line 259), a BoundField already contains a
similar code - when you render a bound field, it passes the rendered
output through unicode, with a comment specifically mentioning
RadioSelect.
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: db2 backend
I have no experience with DB2, but I'm interested in a backend for
Django. Specifically, my interest stems from DB2's spatial database
offering ("Spatial Extender") that is free and feature complete (OGC
compliant). Oracle and ArcSDE have high licensing fees, and MySQL's
spatial support is extremely limited (and will be so for the
foreseeable future) -- thus leaving DB2 as the next closest candidate
for spatial support.
I was, however, turned off by the state of pydb2 -- it looked like the
project hasn't been touched in years. This is not a priority for
GeoDjango at the moment, but it would be cool to play around with a
spatial database other than PostGIS.
-Justin
--~--~-~--~~~---~--~~
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: python.py deserialization and handling foreign key fields ?
On 7/13/07, Etienne Robillard <[EMAIL PROTECTED]> wrote: > Any pointers how to work-around this issue ? On a side note - this message should have been sent to Django-users, not django-developers. Django-developers is for discussing the development of Django itself, not for general user queries. 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: python.py deserialization and handling foreign key fields ?
On 7/13/07, Etienne Robillard <[EMAIL PROTECTED]> wrote: > > How should exceptions caught by FieldDoesNotExist be handled > when trying to deserialize a object mapping to native python data types? ... > Any pointers how to work-around this issue ? I'm unclear what the issue is. Are you building your own CSV deserializer, or using one of Django's serializers? Why are you getting FieldDoesNotExist errors at all? If you are getting these, it suggests to me that your data doesn't match your model. 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: Adding support for ~ to Q objects (negation)
On 7/13/07, Nick <[EMAIL PROTECTED]> wrote: > > On Jul 13, 8:36 am, Collin Grady <[EMAIL PROTECTED]> wrote: > > As such, the following patch was born, allowing ~q instead of > > QNot(q) :) > > > > http://code.djangoproject.com/ticket/4858 > > I've had to use the QNot() myself too, and agree that it would be nice > to have ~. Sounds like a reasonable idea to me. The patch needs tests and docs, though. 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: Unicode Keys
On 7/12/07, Collin Grady <[EMAIL PROTECTED]> wrote:
> For instance, if I have an input with name="語" and request.POST
> doesn't support unicode, how do I then get the value for that? :)
I believe the issue is that *names* for kwargs can not be unicode.
In [1]: u='語'.decode('utf-8')
In [2]: {u:1}
Out[2]: {u'\u8a9e': 1}
In [3]: x={u:1}
In [4]: def y(**kwargs):
...: print kwargs.items()
...:
...:
In [5]: y(**x)
---
Traceback (most recent call last)
/home/jdunck/work/pegasus/b-to-dj5654/ in ()
: y() keywords must be strings
--~--~-~--~~~---~--~~
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: Translated fields
On Jul 12, 7:47 pm, Collin Grady <[EMAIL PROTECTED]> wrote: > Have you seenhttp://code.google.com/p/i18ndynamic/? :) See I thought it would be easy! ;-) Thanks for the link, this is it exactly! -Doug --~--~-~--~~~---~--~~ 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: Adding support for ~ to Q objects (negation)
On Jul 13, 8:36 am, Collin Grady <[EMAIL PROTECTED]> wrote: > Simon requested I bring this up here - I was working through a problem > with a user on IRC, and he noted that Q objects support the bitwise & > and |, but not ~ - if you wanted to negate a Q object, you had to > explicitly import QNot and use that instead. > > As such, the following patch was born, allowing ~q instead of > QNot(q) :) > > http://code.djangoproject.com/ticket/4858 I've had to use the QNot() myself too, and agree that it would be nice to have ~. --~--~-~--~~~---~--~~ 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: Translated fields
Have you seen http://code.google.com/p/i18ndynamic/ ? :) On Jul 11, 3:16 pm, Marc Garcia <[EMAIL PROTECTED]> wrote: > Hi all! > > I've been searching for a way to create a multilingual catalog with > django, and there is just one thing missing, a simple way for > translating information on database, for example having product > description in more than one language. > > I've checked translation module on django-utils, and django- > multilingual, and both solve the problem, but I want a more intuitive > way for end-users (who fill data in admin). > > I've designed an admin page with my > idea:http://vaig.be/2007/07/11/django-database-texts-translated/ > > I haven't seen any post or any ticket that anybody that is working on > something like that. If anybody does, please let me know. > > I'll start soon working on it, but I'm not an expert on hacking > django, is it posible to do that just in contrib? Unless it is, any > core developer think that it could be included in django code? I think > that outside english countries it's very necessary... > > Thanks, > 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 -~--~~~~--~~--~--~---
Re: Unicode Keys
Passing raw GET params into a function seems like a recipe for disaster if you fail to validate something properly. Plus, unicode is allowed to be used as get/post keys, so not supporting it in the dict keys would cause problems. For instance, if I have an input with name="語" and request.POST doesn't support unicode, how do I then get the value for 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: Move form_for_instance and form_for_model into django.db.models.Model?
This doesn't seem a far step from the model fields being able to return appropriate form fields, which they already do, so there's some tie-in already :) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Adding support for ~ to Q objects (negation)
Simon requested I bring this up here - I was working through a problem with a user on IRC, and he noted that Q objects support the bitwise & and |, but not ~ - if you wanted to negate a Q object, you had to explicitly import QNot and use that instead. As such, the following patch was born, allowing ~q instead of QNot(q) :) http://code.djangoproject.com/ticket/4858 --~--~-~--~~~---~--~~ 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: Unicode + memcache = bug
#4845 is probably related here in some way, giving this traceback: PythonHandler django.core.handlers.modpython: MemcachedStringEncodingError: Keys must be str()'s, not unicode. Convert your unicode strings using mystring.encode(charset)! There's a few patches there which force the keys to ASCII, but this may not be the best solution. --Simon [1] http://code.djangoproject.com/ticket/4845 --~--~-~--~~~---~--~~ 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: Move form_for_instance and form_for_model into django.db.models.Model?
On Thu, 2007-07-12 at 15:40 -0500, Adrian Holovaty wrote:
> On 7/12/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> > Is there a good reason not to do something like the following in
> > django.db.models.Model?
> >
> > def form(self):
> > return form_for_instance(self)
> >
> > @classmethod
> > def form(cls):
> > return form_for_model(cls)
>
> Yes -- the good reasons against it are that it ties form logic to the
> model and quashes the field namespace (disallowing you from having a
> field named "form").
How separate do you intend the models and forms to be? As it stands
right now, forms can have validators, but if you actually want to
validate programmatically what you're doing to the database, you have to
repeat any validation code you put in the form somewhere in your model.
For example, I'm storing ISBNs. They have a check digit. I can write a
nice ISBN validator that checks the check digit, but I have to attach it
to the form *and* figure out somewhere to call it in the model to be
sure illegal ISBNs don't get stored to the database. If I ever get
around to trying to check forms client-side, I'll need to supply that
information in a third way. (Ignore briefly the fact that client-side
validation would have to be in JavaScript.)
The thing that's annoying is that this is really an attribute of the
model. It's a fact about the data, not a fact about the form, which is
just a way to view and modify the data.
form_for_instance and form_for_model are great, but if you have to tweak
the form in any way (say you want to use a non-default widget for one of
the data fields) and want to use it more than once, you're reduced to
defining a new Form class or at least a new callback function to control
the field types. And where do you put that? For me, it's pretty clearly
an attribute of the model in the same way that a utility method would
be, because it just doesn't have any meaning without the model. So you
put it in the model.
This may be heresy, but I have to put it out there:
Why not just admit that models are often manipulated by forms and
provide support for things like validators and form fields in the models
themselves. What would be so wrong with:
class Book(models.Model):
isbn = models.CharField(maxlength=13,
form_field=forms.CharField(
widget=forms.TextInput(attrs={'size':'13'})),
validator = isbn_validator)
...
or even better, perhaps,
class Book(models.Model):
isbn = models.CharField(maxlength=13,
widget_attrs={'size':'13'},
validator=isbn_validator)
...
Obviously it would be possible to ignore the form tie-ins completely.
You would still need form validators that aren't tied to models, and
would still have the ability to create forms that were tied to the model
but different from the ones that the model fields specified, but you'd
get to specify all the stuff about your data (including, I'll admit, a
little bit about the data's presentation, but note that that's
completely optional and you're not obligated to do it) in one place.
On the other hand, as has happened several times before, maybe I'm
making this way more complicated than it needs to be because I'm missing
some little piece of code that would make all of this much less
disjointed.
OK...feel free to berate me. :-)
Todd
--~--~-~--~~~---~--~~
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: Move form_for_instance and form_for_model into django.db.models.Model?
On 7/12/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote: > Is there a good reason not to do something like the following in > django.db.models.Model? > > def form(self): > return form_for_instance(self) > > @classmethod > def form(cls): > return form_for_model(cls) Yes -- the good reasons against it are that it ties form logic to the model and quashes the field namespace (disallowing you from having a field named "form"). 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: Unicode + memcache = bug
probably my headache is limiting my ability to rationally
articulate. :)
On Jul 12, 11:24 am, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> On 7/12/07, Bryan <[EMAIL PROTECTED]> wrote:
>
> > trying to do a .set with bytestrings that contain non ascii char
> > values doesn't work. It has to do a .encode('UTF-8') on the string I
> > was attempting to push into memcached. and likewise on pulling it
> > back out I had to do a .decode('UTF-8').
>
> Then you do Unicode.encode('utf-8'), you are creating a bytestring
> with non-ascii char values. I'm not sure how your statements can be
> simultaneously true.
>
> At any rate, I'll get a patch done soon.
--~--~-~--~~~---~--~~
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: Unicode + memcache = bug
On 7/12/07, Bryan <[EMAIL PROTECTED]> wrote:
> trying to do a .set with bytestrings that contain non ascii char
> values doesn't work. It has to do a .encode('UTF-8') on the string I
> was attempting to push into memcached. and likewise on pulling it
> back out I had to do a .decode('UTF-8').
Then you do Unicode.encode('utf-8'), you are creating a bytestring
with non-ascii char values. I'm not sure how your statements can be
simultaneously true.
At any rate, I'll get a patch done soon.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
python.py deserialization and handling foreign key fields ?
Hi all, How should exceptions caught by FieldDoesNotExist be handled when trying to deserialize a object mapping to native python data types? For example, I have a csv row which I would like to deserialize into a model instance, but it breaks when trying to convert any foreign key field, giving the following error message: FieldDoesNotExist: Foo has no field named 'foo_id' Any pointers how to work-around this issue ? Thanks in advance, Etienne --~--~-~--~~~---~--~~ 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: Move form_for_instance and form_for_model into django.db.models.Model?
On 7/12/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote: > As I was writing this, I realized that you can't do this in Python > because you can't overload function names, but surely somebody smarter > than me can figure out a clever way that model_instance.form() and > ModelClass.form() would both do the right thing. I won't comment on whether this is a good idea, because I doubt I'd ever use it either way, but what you're asking for can be done using a descriptor.[1] Just check whether the "instance" argument is None to know if it was called from the class. -Gul [1] http://docs.python.org/ref/descriptors.html --~--~-~--~~~---~--~~ 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: Unicode + memcache = bug
I ran into a similar issue when accessing the memcached python api.
When running django unicode the value returned from the database was
valid. However when running the non unicode version of django it'd
blow up in my face.
trying to do a .set with bytestrings that contain non ascii char
values doesn't work. It has to do a .encode('UTF-8') on the string I
was attempting to push into memcached. and likewise on pulling it
back out I had to do a .decode('UTF-8').
On Jul 12, 7:29 am, "Chad Maine" <[EMAIL PROTECTED]> wrote:
> I did notice this bug, but it went away when I switched to cmemcache (a much
> faster alternative if its availble to you).
>
> On 7/12/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
>
>
> > When using the low-level cache and memcache as the backend, you're
> > likely to run into this stack trace:
>
> > ...
> > File "/pegasus/code/current/django/core/cache/backends/memcached.py" in
> > set
> > 48. self._cache.set(key, value, timeout or self.default_timeout)
> > File "/usr/lib/python2.5/site-packages/memcache.py" in set
> > 305. return self._set("set", key, val, time)
> > File "/usr/lib/python2.5/site-packages/memcache.py" in _set
> > 328. fullcmd = "%s %s %d %d %d\r\n%s" % (cmd, key, flags, time,
> > len(val), val)
>
> > UnicodeDecodeError at /
> > 'ascii' codec can't decode byte 0x80 in position 0: ordinal not in
> > range(128)
>
> > What's going on here is that the memcache.py library does this with
> > the passed parameters:
>
> > fullcmd = "%s %s %d %d %d\r\n%s" % (cmd, key, flags, time, len(val), val)
>
> > Since "key" is often a unicode string, it infects, as it were, the
> > rest of the line, forcing "val" to be encoded, then decoded.
>
> > It may be that only the memcache backend has this problem, but the
> > general solution I'd suggest is to use smart_str on the key given to
> > each low-level cache's backend set method. Works-for-me.
>
> > It may also make sense to run on the value, but I imagine that has a
> > significant overhead, and I haven't had a problem with it yet
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Move form_for_instance and form_for_model into django.db.models.Model?
Is there a good reason not to do something like the following in django.db.models.Model? def form(self): return form_for_instance(self) @classmethod def form(cls): return form_for_model(cls) As I was writing this, I realized that you can't do this in Python because you can't overload function names, but surely somebody smarter than me can figure out a clever way that model_instance.form() and ModelClass.form() would both do the right thing. I mention this because I'm noticing that I want to customize forms and think that the right OO place to do that is probably in the model. Being able to override a standard function would make the right way to do it pretty obvious. I'm also pretty excited about not having another import for form_for_model and form_for_instance in nearly all my views.py files. What's more, this is completely backwards compatible!! :-) Todd --~--~-~--~~~---~--~~ 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: customtags, a higher-level API for template tags
On 7/12/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-07-12 at 01:58 -0500, Tom Tobin wrote: > > Over at the Lawrence Journal-World, we have a bunch of custom template > > tags included in Ellington, our commercial CMS based on Django. One > > day, I finally got fed up with writing the same damned boilerplate > > code for custom tags over and over again (for parsing arguments, > > resolving context variables, etc.); the customtags library was the > > result. My wonderfully cool boss > > Suck up! :-) ::grin:: > (1) When it is ever going to be practical to pass strip_quotes=True to > split_contents()? > > For example, you never use that added functionality in the new code you > have here. Since you have quietly added the change that allows strings > to be delimited by both single- and double-quotes (something I thought > we'd "wontfixed" previously, but I don't care about it too much), it > means that if you want to pass the string "foo" as an arg, you can use > '"foo"' or "\"foo\"". I'm wondering if that argument could be removed > without harm. Oops; the strip_quotes is a leftover from an earlier form of the code that made use of it, so I'll be yanking it. I have no attachment to what quoting form gets used (single vs. double); I was going by what split_contents() did. I'm fine with standardizing on double-quoting only. > (2) Some stylistic note, about customtags.py: I always feel that > phrasing like "a higher-level API" is awkward in core code. Higher level > than what? I'd be tempted to just call it "an API for..." or "a helper > API for...". "Helper API" sounds good to me. > The subsection called "Advantages" is really just "Features", for my > money. I guess I'm a little against the idea of outright advocacy in > comments, but it's a very minor point, so feel free to ignore this > entirely. No, it's a valid point; "Advantages" made it through from when I originally wrote it for internal use here. ;-) > (3) What type of arguments do validators take? It looks like > oldforms-style, strings only and the user has to convert. Since you > already know if something is a string or number earlier (when processing > in convert_arguments(), at least), perhaps you could give them the type > that was determined at parse time? If so, numbers that are not integers > should be Decimal types (not floats), so as not to lose precision. I believe I may have already moved towards passing in the converted type without updating the documentation to match; I'll go over the code soon and check, and set things out that way if they're not already. Good point regarding float vs. Decimal; I'll change that. > For consistency, I'd probably prefer validators that worked like > newforms (and like Adrian has suggested for model validation): methods > called "validate_", rather than the inner class idea. I realise > one advantage of inner classes is avoiding name clashes, but the chance > of a name collision here is essentially zero (you would need args called > foo and validate_foo and somehow have strong technical objections to > calling the latter one validate_foo_ or validate_foo1). I'd like to have the library mirror the syntax of other parts of Django as much as possible, so I'll likely go ahead and do this. > (4) The name of customtags.py feels wrong somehow. Maybe taghelpers.py? I'm definitely not stuck on the name. :-) > (5) Need converting to handle Unicode. Tag and filter arguments need not > be ASCII. Mostly this is easy. A few of the reg-exps should switch to > using \w and being compiled with the re.UNICODE flag. Yeah, that should be straightforward to fix. > (6) The rewrites in defaulttags.py provide interesting reading, as an > example of how to use this. They don't strike me as being particularly > shorter, though. Again, I want to let this sink in over a couple more > reads and I'm not even sure it's a problem. Mostly noting that it's not > an immediately clear win in code complexity, although I realise there > are advantages in consistency of argument parsing. Mostly food for > thought on the layout of TemplateTag subclasses. Unfortunately, the tags in defaulttags.py are probably the worst examples in terms of brevity gains. :-) Most of our converted internal tags are much shorter, since they tend to be fairly simple and all of the boilerplate argument handling code (e.g., " if bit[2] == 'foo' ") gets hidden away. > (7) Is the "resolve" argument on TagArg really necessary? We tend to > always try to resolve at the moment and it works reasonably well. I > guess it might be necessary for the "url" and "for" tags? Now that I've moved toward separating strings and "keywords" out as separate types, you may be right; perhaps the library should always attempt to resolve on a keyword argument. The only issue here becomes what to do if resolution on a keyword fails -- do we set it to None (as ifequal / ifnotequal currently expects), or set it to the string value of the
Re: Proposal: customtags, a higher-level API for template tags
On 7/12/07, Baptiste <[EMAIL PROTECTED]> wrote: > > I have tried to read this patch, but its presentation is really > awful.. But even if I have stopped to read, that seems to be a very > big work! I would like to see it from Trac or I don't know what but > from something that makes him legible ;-) Yeah, I'm sorry about the web view there; hgweb isn't really set up to handle Mercurial Queues patches in a "pretty" way, since it doesn't understand the "diff of a diff" concept. Maybe I'll hack a bit on hgweb when I get a chance and see if I can improve things. ^_^ --~--~-~--~~~---~--~~ 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: Ticket 3505, Authentication backend
On 11 jul, 22:33, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
>
> > if AUTHENTICATION_BACKENDS is empty or something is wrong then
> > nothing is detected, only an ImporError. The patch catch the
> > ValueError.
>
> Where and how is the error revealed? When you import an application?
> When you syncdb? When you try to authenticate? What constitutes "empty
> or something is wrong"?
>
Sorry, my mistake. I'll explain a bit further:
in my settings file I set AUTHENTICATION_BACKENDS = ('something.that-
doesnot.exists') so when you use the authenticate() method in some
view a ValueError is raised. So, my patch catch that exception in
load_backend() method.
IMO, it's a validation mistake and that I'm trying to fix.
>
--~--~-~--~~~---~--~~
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: db parameter impemtation
> By the way, there's one case where we can't always use parameters: IN > value lists. Converting Python tuples to a correctly formatted list > appropriate for IN-clauses isn't a standard part of the DB-API, so we do > that via manual substitution. know off hand where that is? I might be able to improve it. Carl K --~--~-~--~~~---~--~~ 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: db parameter impemtation
Russell Keith-Magee wrote: > On 7/12/07, Carl Karsten <[EMAIL PROTECTED]> wrote: >> Jacob Kaplan-Moss wrote: >>> OK, we're 8 messages deep into this thread, and I've got no idea what >>> the point is. >>> >>> Carl -- what is it you want to know? Is something not working >>> correctly for you, or is this just an academic question? >>> >> When I see SQL parameters being put into the SQL command string, should I >> open a >> ticket? > > No, you should spend a little more time writing messages that explain > the problem that you are having, so that we don't need to spelunk > through 8+ emails of sideways conversation and engage our mind reading > glands to work out what it is that you think needs to be fixed. > > The core developers (and the rest of Django's valuable community) > don't exist on some ethereal plane to serve at your whim and fancy. > Our time is volunteered, and we have _plenty_ of other things on our > respective plates, including the work that pays our bills and feeds > us. Which is why I won't bother wasting my time entering trac tickets and multiple people's time reading them if they are for something that isn't cared about. > > If you have a genuine problem - something that causes a crash, or poor > performance, or a security risk, or a feature that you think should be > added - we're only too happy to help. However, we're not going to play > 20 questions trying to work out the problem that you think you have. > We just don't have that sort of time. > > Read your original question. It didn't report a bug. It didn't report > a performance problem or potential vulnerability. It isn't a feature > request. It was a vague, roundabout way of asking about a general > philosophy of argument passing, without any particular direction as to > why that question was in the least bit interesting. And 8 messages > later, Jacob (quite reasonably, IMHO) asks, "what the hell is this all > about?" > > So - What the hell is this all about? I tried to make my questions easy to answer by those who are in the position to answer them. If you don't understand but are interested, feel free to ask. In this case, if anyone wants a lesson in the value of parameters, I suggest they ask on the support list for their favorite db engine. That would be more appropriate place than here. Once the value is understood, then here is a good place to discuss the pros/cons of django's implementation. Carl K --~--~-~--~~~---~--~~ 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: Unicode + memcache = bug
I did notice this bug, but it went away when I switched to cmemcache (a much
faster alternative if its availble to you).
On 7/12/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
>
> When using the low-level cache and memcache as the backend, you're
> likely to run into this stack trace:
>
> ...
> File "/pegasus/code/current/django/core/cache/backends/memcached.py" in
> set
> 48. self._cache.set(key, value, timeout or self.default_timeout)
> File "/usr/lib/python2.5/site-packages/memcache.py" in set
> 305. return self._set("set", key, val, time)
> File "/usr/lib/python2.5/site-packages/memcache.py" in _set
> 328. fullcmd = "%s %s %d %d %d\r\n%s" % (cmd, key, flags, time,
> len(val), val)
>
> UnicodeDecodeError at /
> 'ascii' codec can't decode byte 0x80 in position 0: ordinal not in
> range(128)
>
> What's going on here is that the memcache.py library does this with
> the passed parameters:
>
> fullcmd = "%s %s %d %d %d\r\n%s" % (cmd, key, flags, time, len(val), val)
>
> Since "key" is often a unicode string, it infects, as it were, the
> rest of the line, forcing "val" to be encoded, then decoded.
>
> It may be that only the memcache backend has this problem, but the
> general solution I'd suggest is to use smart_str on the key given to
> each low-level cache's backend set method. Works-for-me.
>
> It may also make sense to run on the value, but I imagine that has a
> significant overhead, and I haven't had a problem with it yet
>
> >
>
--~--~-~--~~~---~--~~
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: db parameter impemtation
On Thu, 2007-07-12 at 22:27 +1000, Malcolm Tredinnick wrote:
> On Wed, 2007-07-11 at 16:10 -0500, Carl Karsten wrote:
> [...]
> > It is pretty much this simple:
> >
> > import settings
> > import MySQLdb
> >
> > con = MySQLdb.connect(user=settings.DATABASE_USER,
> > passwd=settings.DATABASE_PASSWORD,
> > db=settings.DATABASE_NAME )
> > cur=con.cursor()
> >
> > cur.execute("select * from auth_user where id=1" )
> > print cur.fetchall()
> > cur.execute("select * from auth_user where id=%s" % (1,) )
> > print cur.fetchall()
> >
> > cur.execute("select * from auth_user where id=%s", (1,) )
> > print cur.fetchall()
> >
> > All 3 return the same thing, but only the last one has a chance of the
> > value
> > making it to the server separate from the command, which is a good thing.
>
> Finally the concrete question. Django uses the third form. It's all a
> bit academic as to how much a of a good or better thing this is, but if
> you grep through the code for execute(), you'll be able to see how the
> queries are constructed and passed to the DB-API.
By the way, there's one case where we can't always use parameters: IN
value lists. Converting Python tuples to a correctly formatted list
appropriate for IN-clauses isn't a standard part of the DB-API, so we do
that via manual substitution.
Regards,
Malcolm
--
The cost of feathers has risen; even down is up!
http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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: Decouple simplejson from Django?
On 7/12/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > If you consider the testing framework core, then serialization is, > because the testing framework uses it for fixtures. See? I knew I was missing something obvious. -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://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Unicode + memcache = bug
On 7/12/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-07-12 at 05:34 -0500, Jeremy Dunck wrote: ... > > What's going on here is that the memcache.py library does this with > > the passed parameters: > > > > fullcmd = "%s %s %d %d %d\r\n%s" % (cmd, key, flags, time, len(val), val) > > > > Since "key" is often a unicode string, it infects, as it were, the > > rest of the line, forcing "val" to be encoded, then decoded. > > I thought I understood the problem until I read this sentence. Now my > brain hurts. I fully understand that the whole string is treated as > Unicode as soon as one argument is Unicode. Why is "val" the problem > here then? What sort of object is "val" and why doesn't unicode(val) > work (aah ... is is going via str(val) and val is non-ASCII? That could > do it). Sorry for not giving more context. In that quoted line, cmd is a str (created by the library itself), key is whatever the low-level django API passes in (very likely a Unicode), and val is a pickled object (that is, arbitrary binary). When key is Unicode, it forces val to be decoded into Unicode, which fails, since it's a binary. At least, I'm pretty darn sure. I *think* I understand this bit-pushing. :) > Hasn't actually occurred to me to check previously: can memcache handle > non-ASCII data there, because even converting to UTF-8 is going to give > values that are not always understandable to the ascii codec. > /me checks python-memcache code. python-memcache assumes a str key with no control characters (ord(c) >= 33) and len(key) < 250. The stored value can be any object, but there are a few optimizations. This is how the marshalling is done: if isinstance(val, types.StringTypes): pass elif isinstance(val, int): flags |= Client._FLAG_INTEGER val = "%d" % val elif isinstance(val, long): flags |= Client._FLAG_LONG val = "%d" % val else: flags |= Client._FLAG_PICKLE val = pickle.dumps(val, 2) fullcmd = "%s %s %d %d %d\r\n%s" % (cmd, key, flags, time, len(val), val) The result, fullcmd, is then sent over the wire. So, my assertion is that key is the only possible unicode value, and that it better be coercable to str using sys.getdefaultencoding(), because otherwise the string format will die. cmd, flags, time, len(val), and val must all be str or unicode (it's odd that they have StringTypes there, when they clearly don't handle a Unicode value in the general sense). My understanding is that smart_str forces a unicode value to str using encoding='utf-8', and is a no-op when passed a str. I want to make sure that all parameters there are str; I'm pretty confident "key" is the only non-str object. > The encoding of > str(val) is important, because we have to able to understand it when we > pull it out from the cache again later. I agree, but I don't want to mess with val; I want to force encoding of "key". Clearer? --~--~-~--~~~---~--~~ 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: customtags, a higher-level API for template tags
On Thu, 2007-07-12 at 23:24 +1000, Malcolm Tredinnick wrote: [...] > > A few comments (mostly questions) from an initial reading: One I forgot... (10) On my radar to commit fairly soon is one of Brian Harring's speed-ups for variable resolution -- #3453. It looks like this won't have any real effect on your design or implementation (some changes required, but they're routine). However, if you have 15 minutes to read through the patch on that ticket and think about if there are any collisions of concepts, I'd appreciate a second set of eyes. Regards, Malcolm -- Borrow from a pessimist - they don't expect it back. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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: Unicode + memcache = bug
On Thu, 2007-07-12 at 05:34 -0500, Jeremy Dunck wrote:
> When using the low-level cache and memcache as the backend, you're
> likely to run into this stack trace:
>
> ...
> File "/pegasus/code/current/django/core/cache/backends/memcached.py" in set
> 48. self._cache.set(key, value, timeout or self.default_timeout)
> File "/usr/lib/python2.5/site-packages/memcache.py" in set
> 305. return self._set("set", key, val, time)
> File "/usr/lib/python2.5/site-packages/memcache.py" in _set
> 328. fullcmd = "%s %s %d %d %d\r\n%s" % (cmd, key, flags, time, len(val),
> val)
>
> UnicodeDecodeError at /
> 'ascii' codec can't decode byte 0x80 in position 0: ordinal not in
> range(128)
>
> What's going on here is that the memcache.py library does this with
> the passed parameters:
>
> fullcmd = "%s %s %d %d %d\r\n%s" % (cmd, key, flags, time, len(val), val)
>
> Since "key" is often a unicode string, it infects, as it were, the
> rest of the line, forcing "val" to be encoded, then decoded.
I thought I understood the problem until I read this sentence. Now my
brain hurts. I fully understand that the whole string is treated as
Unicode as soon as one argument is Unicode. Why is "val" the problem
here then? What sort of object is "val" and why doesn't unicode(val)
work (aah ... is is going via str(val) and val is non-ASCII? That could
do it).
The error in the traceback suggests it is trying to treat something
*not* as Unicode. I'm a little fuzzy on what's going on.
> It may be that only the memcache backend has this problem, but the
> general solution I'd suggest is to use smart_str on the key given to
> each low-level cache's backend set method. Works-for-me.
Hasn't actually occurred to me to check previously: can memcache handle
non-ASCII data there, because even converting to UTF-8 is going to give
values that are not always understandable to the ascii codec.
> It may also make sense to run on the value, but I imagine that has a
> significant overhead, and I haven't had a problem with it yet
Assuming the missing key part of this sentence is force_unicode(), it
should be not really worse than running smart_str() (about one extra
function call), from first glance. However, as indicated above, I'll
admit to being sketchy about the real problem still.
If you can guarantee that str(val) will always make sense and be encoded
as UTF-8, then your proposed solution sounds fine. The encoding of
str(val) is important, because we have to able to understand it when we
pull it out from the cache again later.
Regards,
Malcolm
--
Works better when plugged in.
http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
GSoC Update: [Check Constraints] Unicode Compatible, Doctests and a lot more...
Hello Django Developers, This week saw a lot of change in the Check Constraints project. First, most of the SQL generation code has moved from the management.py to the Check class. Initially I was very reluctant to move the code from management.py to the Check Class (because I had the feeling that most of the SQL code ought to be in the management.py along with the other SQL code). After a discussion with my mentor, I realized that it ought to be placed in the class because: 1) Lower number of lines in the main code. 2) Easier to write tests. With the unicode branch being merged into trunk, I had the opportunity to make the project unicode compatible. I also wrote doctests this week. Hope you folks use the project (and love it) and let me know of your suggestions. Cheers Thejaswi Puthraya http://code.google.com/p/django-check-constraints --~--~-~--~~~---~--~~ 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: customtags, a higher-level API for template tags
On Thu, 2007-07-12 at 01:58 -0500, Tom Tobin wrote: > Over at the Lawrence Journal-World, we have a bunch of custom template > tags included in Ellington, our commercial CMS based on Django. One > day, I finally got fed up with writing the same damned boilerplate > code for custom tags over and over again (for parsing arguments, > resolving context variables, etc.); the customtags library was the > result. My wonderfully cool boss Suck up! :-) > agreed to allow me to contribute > this library back to Django. > > customtags is a higher-level API for template tags that borrows much > of its syntax style from the Django model API; it makes writing new > template tags a breeze (if I may say so ^_^). [...] > > I'd appreciate any and all feedback, both positive and critical. :-) I like the idea of having some helper functions. Should make things easier for people. It might take a while for this particular API to grow on me: all these inner classes usually make me wonder if there's another way. That always takes me a couple of days to think about, so not a lot of coherent comments there yet. A few comments (mostly questions) from an initial reading: (1) When it is ever going to be practical to pass strip_quotes=True to split_contents()? For example, you never use that added functionality in the new code you have here. Since you have quietly added the change that allows strings to be delimited by both single- and double-quotes (something I thought we'd "wontfixed" previously, but I don't care about it too much), it means that if you want to pass the string "foo" as an arg, you can use '"foo"' or "\"foo\"". I'm wondering if that argument could be removed without harm. (2) Some stylistic note, about customtags.py: I always feel that phrasing like "a higher-level API" is awkward in core code. Higher level than what? I'd be tempted to just call it "an API for..." or "a helper API for...". The subsection called "Advantages" is really just "Features", for my money. I guess I'm a little against the idea of outright advocacy in comments, but it's a very minor point, so feel free to ignore this entirely. As I mentioned, I haven't fully grokked the example code yet. (3) What type of arguments do validators take? It looks like oldforms-style, strings only and the user has to convert. Since you already know if something is a string or number earlier (when processing in convert_arguments(), at least), perhaps you could give them the type that was determined at parse time? If so, numbers that are not integers should be Decimal types (not floats), so as not to lose precision. For consistency, I'd probably prefer validators that worked like newforms (and like Adrian has suggested for model validation): methods called "validate_", rather than the inner class idea. I realise one advantage of inner classes is avoiding name clashes, but the chance of a name collision here is essentially zero (you would need args called foo and validate_foo and somehow have strong technical objections to calling the latter one validate_foo_ or validate_foo1). (4) The name of customtags.py feels wrong somehow. Maybe taghelpers.py? (5) Need converting to handle Unicode. Tag and filter arguments need not be ASCII. Mostly this is easy. A few of the reg-exps should switch to using \w and being compiled with the re.UNICODE flag. (6) The rewrites in defaulttags.py provide interesting reading, as an example of how to use this. They don't strike me as being particularly shorter, though. Again, I want to let this sink in over a couple more reads and I'm not even sure it's a problem. Mostly noting that it's not an immediately clear win in code complexity, although I realise there are advantages in consistency of argument parsing. Mostly food for thought on the layout of TemplateTag subclasses. (7) Is the "resolve" argument on TagArg really necessary? We tend to always try to resolve at the moment and it works reasonably well. I guess it might be necessary for the "url" and "for" tags? (8) Reading the docs sort of clarifies one of my concerns with all the inner classes: there aren't really any non-inner things on the TemplateTag subclass. (9) If you're going to rewrite a lot of the core tags using this infrastucture (and even if not), it's worth importing the errors and most of the external API into the django.template namespace, as is currently done. I noticed that some of the tests changed, for example, to needing to catching template.customtags.TemplateTagValidationError. Given that custom tags live outside django.template, I would be inclined to make it easier for people on the import front. No real name clashes in the django.template namespace that I can see would prevent this. Regards, Malcolm -- On the other hand, you have different fingers. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers"
Re: Decouple simplejson from Django?
On 7/12/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > I > just wanted to point out that it seemed strange to me to consider it a > core requrement for the serializer, and in fact of Django itself. If you consider the testing framework core, then serialization is, because the testing framework uses it for fixtures. --~--~-~--~~~---~--~~ 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: Decouple simplejson from Django?
Oh, I should also clarify something. I don't actually think simplejson should be removed from Django itself. It's only a few files, and is certainly worth saving people extra trouble for such a common case. I just wanted to point out that it seemed strange to me to consider it a core requrement for the serializer, and in fact of Django itself. -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://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: db parameter impemtation
Hi all,
Not to hijack the thread but I think Django indeed supports prepared
statements if the underlying db-binding supports it.
This is from cx_Oracle's doc (http://www.cxtools.net/default.aspx?
nav=cxorlb):
execute(statement, [parameters], **keywordParameters)
Execute a statement against the database. Parameters may be passed
as a dictionary or sequence or as keyword arguments. If the arguments
are a dictionary, the values will be bound by name and if the
arguments are a sequence the values will be bound by position.
A reference to the statement will be retained by the cursor. If
None or the same string object is passed in again, the cursor will
execute that statement again without performing a prepare or rebinding
and redefining. This is most effective for algorithms where the same
statement is used, but different parameters are bound to it (many
times).
and this:
http://osdir.com/ml/python.db.cx-oracle/2007-01/msg00014.html
Peter
On Jul 12, 8:27 am, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
> On Wed, 2007-07-11 at 16:10 -0500, Carl Karsten wrote:
>
> [...]
>
>
>
> > It is pretty much this simple:
>
> > import settings
> > import MySQLdb
>
> > con = MySQLdb.connect(user=settings.DATABASE_USER,
> > passwd=settings.DATABASE_PASSWORD,
> > db=settings.DATABASE_NAME )
> > cur=con.cursor()
>
> > cur.execute("select * from auth_user where id=1" )
> > print cur.fetchall()
> > cur.execute("select * from auth_user where id=%s" % (1,) )
> > print cur.fetchall()
>
> > cur.execute("select * from auth_user where id=%s", (1,) )
> > print cur.fetchall()
>
> > All 3 return the same thing, but only the last one has a chance of the value
> > making it to the server separate from the command, which is a good thing.
>
> Finally the concrete question. Django uses the third form. It's all a
> bit academic as to how much a of a good or better thing this is, but if
> you grep through the code for execute(), you'll be able to see how the
> queries are constructed and passed to the DB-API.
>
> Regards,
> Malcolm
>
> --
> The early bird may get the worm, but the second mouse gets the
> cheese.http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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: Decouple simplejson from Django?
On 7/12/07, James Bennett <[EMAIL PROTECTED]> wrote: > The other modules you mention are optional to a certain extent (don't > technically need flup to do Django-as-WSGI, can use Django without a > database or with your choice of DB adapter), but simplejson is > absolutely required for the serialization system (and hence test > fixtures and initial data loading) to work. Similarly, Django's > internal dispatch system relies on pydispatcher and will not function > without it, so pydisptatcher is bundled directly in Django. I'm probably missing something stupid here, but this doesn't seem accurate to me. It looks as though the JSON serializer is actually the only one that uses simplejson, not the whole serialization framework. It seems like the JSON serializer could use the same method as it already does for YAML, checking to see if the proper dependency is there, ignoring it if it's not. Admittedly, JSON is quite likely going to be the most common serializer used, but it just doesn't seem like JSON should be considered a minimum requirement for the serialization framework. Of course, on that note, I could also (somewhat feebly) argue that it seems odd to put the serializers in django.core instead of django.contrib. They're a very handy feature, yes, but I don't see anything else in the core that actually relies on it. Keep in mind, though, I don't use the serializers and I don't really know all that much about their history, so I'm probably missing some really obvious things that completely contradict everything I'm saying. -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://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: db parameter impemtation
On Wed, 2007-07-11 at 16:10 -0500, Carl Karsten wrote:
[...]
> It is pretty much this simple:
>
> import settings
> import MySQLdb
>
> con = MySQLdb.connect(user=settings.DATABASE_USER,
> passwd=settings.DATABASE_PASSWORD,
> db=settings.DATABASE_NAME )
> cur=con.cursor()
>
> cur.execute("select * from auth_user where id=1" )
> print cur.fetchall()
> cur.execute("select * from auth_user where id=%s" % (1,) )
> print cur.fetchall()
>
> cur.execute("select * from auth_user where id=%s", (1,) )
> print cur.fetchall()
>
> All 3 return the same thing, but only the last one has a chance of the value
> making it to the server separate from the command, which is a good thing.
Finally the concrete question. Django uses the third form. It's all a
bit academic as to how much a of a good or better thing this is, but if
you grep through the code for execute(), you'll be able to see how the
queries are constructed and passed to the DB-API.
Regards,
Malcolm
--
The early bird may get the worm, but the second mouse gets the cheese.
http://www.pointy-stick.com/blog/
--~--~-~--~~~---~--~~
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: Decouple simplejson from Django?
> Can you use the ORM without a database adapter? Ok, that might sound a bit stupid since you already kind of answered that in the post above. What i meant was that Django has lot of different imports, and without some of them (say a database adapter) Django is crippled. I personally don't see adding simplejson to "requirements" an issue - all we do is moving updates to the user. --~--~-~--~~~---~--~~ 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: (Un)Trac
On 7/12/07, Peter Nixon <[EMAIL PROTECTED]> wrote: > > On Thu 12 Jul 2007, Jeremy Dunck wrote: > > On 7/12/07, Peter Nixon <[EMAIL PROTECTED]> wrote: > > > Am I just being dense, or is there no way in django's trac to monitor a > > > bug for changes (and receive and email when it does) or even to add a > > > bug to a "my bugs" list?! > > > > In the "change properties" section, you want "CC". > > Aha.. Hidden in plain sight. Yeap. You just want to make sure you use a junk email address. Unlike a lot of other account-based systems, your email address is going to be publicly visible. -- Kevin --~--~-~--~~~---~--~~ 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: Unicode + memcache = bug
On 7/12/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: ... > It may be that only the memcache backend has this problem, but the > general solution I'd suggest is to use smart_str on the key given to > each low-level cache's backend set method. Works-for-me. To be clear, if this is accepted as a solution, I'm happy to make a ticket and patch. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Unicode + memcache = bug
When using the low-level cache and memcache as the backend, you're
likely to run into this stack trace:
...
File "/pegasus/code/current/django/core/cache/backends/memcached.py" in set
48. self._cache.set(key, value, timeout or self.default_timeout)
File "/usr/lib/python2.5/site-packages/memcache.py" in set
305. return self._set("set", key, val, time)
File "/usr/lib/python2.5/site-packages/memcache.py" in _set
328. fullcmd = "%s %s %d %d %d\r\n%s" % (cmd, key, flags, time, len(val), val)
UnicodeDecodeError at /
'ascii' codec can't decode byte 0x80 in position 0: ordinal not in range(128)
What's going on here is that the memcache.py library does this with
the passed parameters:
fullcmd = "%s %s %d %d %d\r\n%s" % (cmd, key, flags, time, len(val), val)
Since "key" is often a unicode string, it infects, as it were, the
rest of the line, forcing "val" to be encoded, then decoded.
It may be that only the memcache backend has this problem, but the
general solution I'd suggest is to use smart_str on the key given to
each low-level cache's backend set method. Works-for-me.
It may also make sense to run on the value, but I imagine that has a
significant overhead, and I haven't had a problem with it yet
--~--~-~--~~~---~--~~
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: (Un)Trac
On Thu 12 Jul 2007, Jeremy Dunck wrote: > On 7/12/07, Peter Nixon <[EMAIL PROTECTED]> wrote: > > Am I just being dense, or is there no way in django's trac to monitor a > > bug for changes (and receive and email when it does) or even to add a > > bug to a "my bugs" list?! > > In the "change properties" section, you want "CC". Aha.. Hidden in plain sight. Thanks -- Peter Nixon http://peternixon.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?hl=en -~--~~~~--~~--~--~---
Re: (Un)Trac
On 7/12/07, Peter Nixon <[EMAIL PROTECTED]> wrote: > Am I just being dense, or is there no way in django's trac to monitor a bug > for changes (and receive and email when it does) or even to add a bug to > a "my bugs" list?! In the "change properties" section, you want "CC". --~--~-~--~~~---~--~~ 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: (Un)Trac
You can subscribe to individual issues using RSS. That's the way I tend to keep track of issues which are of particular interest to me. -Phil On 12/07/07, Peter Nixon < [EMAIL PROTECTED]> wrote: > > > Hi Guys > > Am I just being dense, or is there no way in django's trac to monitor a > bug > for changes (and receive and email when it does) or even to add a bug to > a "my bugs" list?! > > A bug tracker without these features is pretty crippled imho, especially > when > some of the bugs I am interested in have been open for 23 months.. > How do others keep track of django bugs? I am, like most IT people I am > sure, > mostly interrupt driven. If something/someone doesn't remind me about a > problem I am likely to forget it after a few days/weeks... > > Regards > > -- > > Peter Nixon > http://peternixon.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?hl=en -~--~~~~--~~--~--~---
(Un)Trac
Hi Guys Am I just being dense, or is there no way in django's trac to monitor a bug for changes (and receive and email when it does) or even to add a bug to a "my bugs" list?! A bug tracker without these features is pretty crippled imho, especially when some of the bugs I am interested in have been open for 23 months.. How do others keep track of django bugs? I am, like most IT people I am sure, mostly interrupt driven. If something/someone doesn't remind me about a problem I am likely to forget it after a few days/weeks... Regards -- Peter Nixon http://peternixon.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?hl=en -~--~~~~--~~--~--~---
Re: Problem inspecting a (django) postgresql table
On Thu 12 Jul 2007, Gary Wilson wrote: > Ben Ford wrote: > > Peter, > > I ran into this problem when I was bringing the multi-db branch up to > > date and was so busy I forgot to tell anyone! (My bad) I fixed it, but > > it was on another machine. It's a pretty simple change, but the exact > > diff escapes me at the moment! Is there a ticket on this, as I think it > > might be a genuine problem in trunk (as well as my branch)? If you raise > > a ticket (if there isn't one already) and email me the number, I will > > attach the diff when I get back onto my other machine. > > http://code.djangoproject.com/ticket/2591 > > Was your fix the same? I can confirm that #2591 fixes the problem. With both #2591 and #399 applied I can fully introspect (and use) my existing table structure. Can someone please apply these patches? I have applied both to the python-django-snapshot rpms I maintain at: http://software.opensuse.org/download/devel:/languages:/python/ Cheers -- Peter Nixon http://peternixon.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?hl=en -~--~~~~--~~--~--~---
Re: Proposal: customtags, a higher-level API for template tags
I have tried to read this patch, but its presentation is really
awful.. But even if I have stopped to read, that seems to be a very
big work! I would like to see it from Trac or I don't know what but
from something that makes him legible ;-)
Anyway, congratulations
Baptiste
On 12 juil, 08:58, "Tom Tobin" <[EMAIL PROTECTED]> wrote:
> Over at the Lawrence Journal-World, we have a bunch of custom template
> tags included in Ellington, our commercial CMS based on Django. One
> day, I finally got fed up with writing the same damned boilerplate
> code for custom tags over and over again (for parsing arguments,
> resolving context variables, etc.); the customtags library was the
> result. My wonderfully cool boss agreed to allow me to contribute
> this library back to Django.
>
> customtags is a higher-level API for template tags that borrows much
> of its syntax style from the Django model API; it makes writing new
> template tags a breeze (if I may say so ^_^). I've been cleaning up
> the code over the past few days, making improvements, and writing
> documentation and tests; I'm not done, but I'd certainly like to get
> some eyeballs on the code ahead of submitting a final patch for
> inclusion into Django trunk. I've been maintaining the patch using
> Mercurial Queues; the most recent version can always be found at:
>
> http://hg.korpios.com/django.korpios.patches/file/tip/customtags.patch
>
> Again, documentation is still quite raw; it should be good enough to
> get a rough feel, though. The best "documentation" at the moment,
> though, might be django.template.defaulttags; I've rewritten every
> default tag as a customtags tag, with the exception of {% cycle %}
> (since cycle is something of an odd case).
>
> I'd appreciate any and all feedback, both positive and critical. :-)
--~--~-~--~~~---~--~~
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: db parameter impemtation
On Thu 12 Jul 2007, [EMAIL PROTECTED] wrote: > Wow, I think I just figured out what this is about. He's asking if > Django creates queries like > 1) "SELECT id, song FROM songs WHERE id = 1" > or > 2) "SELECT id, song FROM songs WHERE id = ?", and the passing in the 1 > as a parameter. > > He says that he saw a query like the first case, and is wondering if > he should open a ticket about it. Yes. That was what I also understood from his questions. 1 is bad from a security and performance point of view. 2 is better... Cheers -- Peter Nixon http://peternixon.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?hl=en -~--~~~~--~~--~--~---
Re: Decouple simplejson from Django?
On Jul 12, 8:55 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > The other modules you mention are optional to a certain extent (don't > technically need flup to do Django-as-WSGI, can use Django without a > database or with your choice of DB adapter), but simplejson is > absolutely required for the serialization system (and hence test > fixtures and initial data loading) to work. Similarly, Django's > internal dispatch system relies on pydispatcher and will not function > without it, so pydisptatcher is bundled directly in Django. > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." Can you use the ORM without a database adapter? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Proposal: customtags, a higher-level API for template tags
Over at the Lawrence Journal-World, we have a bunch of custom template
tags included in Ellington, our commercial CMS based on Django. One
day, I finally got fed up with writing the same damned boilerplate
code for custom tags over and over again (for parsing arguments,
resolving context variables, etc.); the customtags library was the
result. My wonderfully cool boss agreed to allow me to contribute
this library back to Django.
customtags is a higher-level API for template tags that borrows much
of its syntax style from the Django model API; it makes writing new
template tags a breeze (if I may say so ^_^). I've been cleaning up
the code over the past few days, making improvements, and writing
documentation and tests; I'm not done, but I'd certainly like to get
some eyeballs on the code ahead of submitting a final patch for
inclusion into Django trunk. I've been maintaining the patch using
Mercurial Queues; the most recent version can always be found at:
http://hg.korpios.com/django.korpios.patches/file/tip/customtags.patch
Again, documentation is still quite raw; it should be good enough to
get a rough feel, though. The best "documentation" at the moment,
though, might be django.template.defaulttags; I've rewritten every
default tag as a customtags tag, with the exception of {% cycle %}
(since cycle is something of an odd case).
I'd appreciate any and all feedback, both positive and critical. :-)
--~--~-~--~~~---~--~~
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: Decouple simplejson from Django?
On 7/12/07, Johan Bergström <[EMAIL PROTECTED]> wrote: > The way i see it, there are two main reasons to decouple this: > * Concurrency (for instance: flup and all db connectors are > decoupled) > * Less updates to merge into tree (user already handles other > decoupled updates him/herself) The other modules you mention are optional to a certain extent (don't technically need flup to do Django-as-WSGI, can use Django without a database or with your choice of DB adapter), but simplejson is absolutely required for the serialization system (and hence test fixtures and initial data loading) to work. Similarly, Django's internal dispatch system relies on pydispatcher and will not function without it, so pydisptatcher is bundled directly in Django. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Decouple simplejson from Django?
Is there a specific reason simplejson is bundled with Django? The way i see it, there are two main reasons to decouple this: * Concurrency (for instance: flup and all db connectors are decoupled) * Less updates to merge into tree (user already handles other decoupled updates him/herself) cheers, Johan Bergström --~--~-~--~~~---~--~~ 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: Unicode Keys
David Cramer wrote: > Is there any reason why its storing the keys in QueryDict (possibly > others) as unicode? > i think it's for consistency. i mean, when i see mentioned that django is fully unicode, i assume every string i get from django is in unicode, unless there's a very good reason for the opposite. and in this case, it seems to me that unicode strings make sense. for example, what if the keys contain non-ascii data? > This seems like a bug, possibly overlooked, but having unicode keys > prevents certain functionality like **request.GET in a method call. hmmm.. well, you can always convert it, can't you? :) anyway... isn't simply sending in the GET params to functions a little dangerous? 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 -~--~~~~--~~--~--~---
#4418 - Newforms Media again
Hi all,
Newforms media, again. A few small updates this time; the patch is
against newforms-admin.
Adrian - are you OK with this being committed to newforms-admin (along
with some documentation), or do you want me to keep this in patch
form?
Changes in this version:
- Forms and ModelAdmin can now have Media descriptions in the same way
as widgets. This replaces the old 'js' argument on ModelAdmin, but
makes Admin media consistent with the rest of the descriptor scheme.
- Media definitions now have an 'extend' argument, which allows users
to customize which media is inherited
class Widget(Widget):
class Media:
extend = ('css',)
css = ...
js = ...
If extend is undefined, it defaults to True; extend=False means no
media is inherited; extend=(...) means all the media types named in
the tuple will be inherited,
- After a query in the last email, I've checked that the issue
described in #4398 is fixed, and it was. There is a regression test
that covers this case.
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
-~--~~~~--~~--~--~---
