Re: Moving all validation into the model layer.
This answers your question
http://djangoadvent.com/1.2/history-model-validation/
On Feb 19, 7:36 am, orokusaki wrote:
> BTW, I am aware of the ability to create your own custom model field
> class with a custom `validate()` method like my following example. I'm
> also aware of using a model's clean() method to raise logical
> validation errors, like if their email is a gmail address and they
> they specify that they are a Yahoo user, you might raise
> ValidationError("You liar. You use Gmail"), and so on.
>
> My custom field and below an explanation of another pitfall of form
> validation:
>
> class CurrencyField(models.DecimalField):
> """
> Only changes output into a quantized format. Everything else is
> the same.
> Later I will possibly add currency symbol support.
> """
> description = 'A double decimal representing money'
> __metaclass__ = models.SubfieldBase
>
> def __init__(self, *args, **kwargs):
> kwargs['max_digits'] = 8
> kwargs['decimal_places'] = 2
> super(CurrencyField, self).__init__(*args, **kwargs)
>
> def to_python(self, value):
> try:
> return super(CurrencyField,
> self).to_python(value).quantize(Decimal('0.01'))
> except AttributeError:
> return None
>
> def validate(self, value, model_instance):
> """
> Check for anything other than numbers, a decimal, and a dollar
> sign, and
> raise a singular error on success.
> """
> # This allows for a $ symbol as well (but that's not supported
> by forms.fields.DecimalField)
> reo = re.compile(r'^\$?\s*((?=\d*\.|\d)\d*(?:\.\d*)?)$')
> if not reo.search(str(value)):
> raise ValidationError(u'Enter a valid "money value"
> consisting of digits a single decimal place and an optional dollar
> sign.')
> super(CurrencyField, self).validate(value, model_instance)
>
> def get_db_prep_value(self, value):
> """
> Remove dollar signs.
> """
> return re.sub(r'[\d\.]', '', str(value))
>
> The above model does everything necessary but some of it isn't even
> use all of the logic with Django forms. If I'm using forms, the user
> cannot put a "$" symbol because before my code can possibly normalize
> the data and remove the dollar sign, the user is warned about it not
> being a decimal. However, decimal is what makes most sense to use, and
> I don't want to have to create a custom form for this model just so
> that I can strip a dollar sign from one field.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: ANN: Django 1.1.2 and Django 1.2 released
Congratulations to all the developers who worked on 1.2, it's a fabulous release. P.S. It's sad but I'm almost as excited by the dropping of python 2.3 as I am the real features. Almost. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Static media handling - ticket 12323
+1 on Option 2. I have written a basic deployment app (not quite ready for release yet) that deploys a virtualenv for each version of your project, roughly equivalent to Google App Engine. I specifically need to split out the USER_MEDIA so that it isn't versioned. Internally if the developer does not use the setting I will default to the MEDIA_ROOT anyway. I like the limited focus of this proposal. USER_MEDIA nicely describes something that is not specifically meant or available to be deployed by default as part of the app, and is a reasonable convention to encourage developers to split their directories from the start. A more complicated discussion is that around assumed app media directories. I'm inclined to think that admin gives the precedent to declare a default media directory per app, a convention that can be backed up by management command to link/consolidate by app name for production which other apps already do, but this in turn opens the can of worms that is settings when overriding defaults. I think ponies will cry if this proposal gets extended to try and include too much. On May 28, 1:23 am, Luke Plant wrote: > A Django 1.3 proposal. It is a pretty small feature/change in some > ways, but needs some discussion. > > = Motivation = > > This is intended to make it easier to cope with the distinction > between user provided media and developer provided media. This is a > significant pain point when it comes to source > control/deployment/backup. > > For example, it would be much better when uploading my source if I > could do 'rsync --delete', so that the files on the server are exactly > what I expect - extra files can cause all kinds of bugs. But I can't > do that, as it would delete all the user uploaded media (or at least > the symlinks to it). Nor can I simply upload to a fresh directory - I > would still need to mess around with symlinks or moving files to get > user uploaded media where it is expected to be. > > Also, for security it would be good to have the whole source code > directory (including templates, javascript etc) to be write protected > from the point of the webserver. But user uploaded files mess that > up. > > = Options = > > We could: > 1) add 'STATIC_URL' and use it for widgets and all other media. > 2) add 'USER_MEDIA_URL' and 'USER_MEDIA_ROOT' and use them for file > storage. > > (using backwards compatible defaults either way). > > If 1), then, additionally, do we need 'STATIC_ROOT' as well? What > for? It wouldn't be used anywhere in Django. > > I was going to go for 1), like the ticket suggests, but I now think > that 2) is a much better idea. > > I strongly suspect that static media are far more common than user > uploaded files, so doing 2) will require far fewer changes to existing > apps. Also, I suspect that almost all direct use of MEDIA_URL in apps > will be for static media: file fields provide a URL attribute which > automatically includes MEDIA_URL, but it will be common to use > MEDIA_URL for calculating URLs (e.g. in templates). > > Also, use of 'media' for static media is consistent with > ADMIN_MEDIA_PREFIX, which is lost with option 1) > > If we go with 2), there is a good case for not adding USER_MEDIA_URL > to the media context processor - I can't imagine know when it would be > needed in the normal case. If you want to generate a URL to a file > stored in a model, the only sensible way to do it is > instance.somefile.url, which handles it for you. If we go for 1) we > will need both STATIC_URL and MEDIA_URL in the media context processor > for backwards compatibility. > > Are there any common uses cases I have not accounted for? > > Finally, once these things are sorted out, is this a small enough > change that I should go ahead and commit it, or should I wait for > voting on Django 1.3 features? > > Thanks, > > Luke > > -- > "Oh, look. I appear to be lying at the bottom of a very deep, dark > hole. That seems a familiar concept. What does it remind me of? Ah, > I remember. Life." (Marvin the paranoid android) > > Luke Plant ||http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py
-1. The only issue that I have with sites is that the default site should be 127.0.0.1:8000 since that's what runserver defaults to. Putting example.com as SITE_ID 1 only makes novice django developers shout and throw things because like me they 'add 127.0.0.1:8000 and delete example.com' instead of replacing example.com and wonder why runserver isn't serving their first hello world flatpage. I had a blog post which included this tip, and it amazes me how many people commented they had done the same thing, which suggests there is a large number of people who make this simple but avoidable mistake. Since nobody will ever use 'example.com' it should not be there in the first place. On May 24, 12:16 pm, Rolando Espinoza La Fuente wrote: > On Tue, May 18, 2010 at 11:14 AM, Felipe Prenholato > > wrote: > > About idea of use settings.py to set a default site, -1 > > About ask to user what is yours default site, +1 > > This thing only runs at syncdb, so I really don't think that a entry in > > settings.py is needed. > > This seems a controversial topic :) > > +1 to the idea to just ask in syncdb, in the same way that admin user > is created. > Here is my proposal:http://gist.github.com/411456 > > Regards, > > ~Rolando > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group > athttp://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Static media handling - ticket 12323
Ok yes seems like a slam dunk.. hell how about an --install-media for
python setup.py install ;)
On Jun 3, 10:18 pm, Jannis Leidel wrote:
> Am 30.05.2010 um 05:54 schrieb BrettH:
>
> > +1 on Option 2.
>
> > I have written a basic deployment app (not quite ready for release
> > yet) that deploys a virtualenv for each version of your project,
> > roughly equivalent to Google App Engine. I specifically need to split
> > out the USER_MEDIA so that it isn't versioned. Internally if the
> > developer does not use the setting I will default to the MEDIA_ROOT
> > anyway.
>
> Note, my propsal isn't about creating a deployment tool but to make sure
> Django is prepared for the increasing number of apps that ship with media
> files. django-staticfiles is in use today due to Pinax and doesn't make
> assumptions about your custom deployments. (e.g. override the storage backend
> to build the media on S3)
>
> > I like the limited focus of this proposal. USER_MEDIA nicely describes
> > something that is not specifically meant or available to be deployed
> > by default as part of the app, and is a reasonable convention to
> > encourage developers to split their directories from the start.
>
> Agreed, the ambiguity of the MEDIA_ROOT setting is unfortunate but not that
> easy to fix in a backwards incompatible way if we also want to solve the app
> media problem.
>
> > A more complicated discussion is that around assumed app media
> > directories. I'm inclined to think that admin gives the precedent to
> > declare a default media directory per app, a convention that can be
> > backed up by management command to link/consolidate by app name for
> > production which other apps already do, but this in turn opens the can
> > of worms that is settings when overriding defaults. I think ponies
> > will cry if this proposal gets extended to try and include too much.
>
> Honestly, I strongly believe this is a topic in which Django needs to provide
> optional helpers to make it easier to ship non-Python files. Since a vast
> amount of apps out there already ship with media files, nicely wrapped in
> Python packages, ready to be installed with pip, Django only needs to be made
> aware of those conventions.
>
> Speaking of which, the admin is actually a bad example since it uses an own
> legacy WSGI handler ("AdminMediaHandler") from long ago to serve its media
> files. staticfiles abstracts that feature, is backwards compatible and
> follows the simple idea of namespaces -- similar to how app template
> directories are prefixed with the app name, /media//*.
> So say you want to ship media files with your app 'my_blog', it'd look like
> this:
>
> my_blog
> ├── __init__.py
> ├── admin.py
> ├── media
> │ └── my_blog
> │ ├── css
> │ │ ├── base.css
> │ │ └── forms.css
> │ ├── img
> │ │ └── logo.png
> │ └── js
> │ └── ads.js
> ├── models.py
> └── views.py
>
> And you'd be able to use //img/logo.png in your
> templates to point to the right location of your app media files. Either use
> staticfiles' file serving view (for debugging), which knows how to resolve
> the relative path to the file included in the app, or use the build_static
> management command, that can be called from a fabric script during deployment.
>
> FWIW, I've started with an experimental branch
> athttp://github.com/jezdez/django/tree/staticfilesif you want to follow along.
>
> Jannis
>
>
>
> > On May 28, 1:23 am, Luke Plant wrote:
> >> A Django 1.3 proposal. It is a pretty small feature/change in some
> >> ways, but needs some discussion.
>
> >> = Motivation =
>
> >> This is intended to make it easier to cope with the distinction
> >> between user provided media and developer provided media. This is a
> >> significant pain point when it comes to source
> >> control/deployment/backup.
>
> >> For example, it would be much better when uploading my source if I
> >> could do 'rsync --delete', so that the files on the server are exactly
> >> what I expect - extra files can cause all kinds of bugs. But I can't
> >> do that, as it would delete all the user uploaded media (or at least
> >> the symlinks to it). Nor can I simply upload to a fresh directory - I
> >> would still need to mess around with symlinks or moving files to get
> >> user uploaded media where it is expected to be.
>
> >> Also, for security it would be good to have the whole source code
> >> directory (including t
