Re: Allowing custom attributes in Meta classes

2013-09-12 Thread code22 
+1 for this. 

Use case: in one of our projects we had to mark fields allowed for 
publishing. Using additional meta option would be great for that and I've 
regretted that it's impossible.  

W dniu wtorek, 10 września 2013 06:27:29 UTC+2 użytkownik Karan Lyons 
napisał:
>
> Hey all,
>
> I recently opened up a ticket (https://code.djangoproject.com/ticket/21081) 
> that turns out to be a dupe of https://code.djangoproject.com/ticket/5793, 
> both in regards to allowing custom attributes in a model's Meta class.
>
> It was wontfix'd six years ago, the reasoning being that Meta should 
> really only be for setting options related to Django internals. I'm 
> personally of the opinion that at this point Meta is considered the place 
> for *any* options related to a model by developers, and that handling 
> custom options outside of Meta seems against the general Django coding 
> style. Currently you can come up with hacks like 
> https://github.com/karanlyons/django-save-the-change/blob/feature/update-together/save_the_change/mixins.py#L188to
>  take care of the issue, but this isn't very nice for a number of reasons.
>
> Do we think this should still be a wontfix, and are there any other 
> reasons why?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Allowing custom attributes in Meta classes

2013-09-11 Thread Tim Chase 
On 2013-09-10 21:05, Russell Keith-Magee wrote:
> So - I think custom Meta options are something that should be
> *possible*. I don't have any particular ideas for how it should be
> implemented, though.

One of the areas I've considered trying this is annotating "private"
information about models.  The models' Manager class(es) could then
grow methods taking context (such as user information, remote IP,
HTTPS status, etc) and return models that have been sanitized based on
what that context permits ("Joe is a manager on-site, so can see the
full credit-card number and social security number", "Pat is a
non-manager employee visiting from on-site, so can only see the last
4 digits of the credit card number & social", "Ellen is an off-site
user and can only see the last 4 digits of her own credit-card &
social but nobody else's").

For implementation, I'd expect to namespace based on the name of the
app implementing the functionality, so you'd have something like

class MyModel(Model):
  class Meta:
...
class MyApp:
  secure_fields = ["cc_num", "ssn"]

The indentation might get just a little unwieldy, but namespacing
helps prevent clashes and sensibly be accessible just by chaining
properties:

  secure_fields = existing_meta.MyApp.secure_fields

My $0.02

-tkc



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Allowing custom attributes in Meta classes

2013-09-10 Thread Andy McCurdy 

On Sep 10, 2013, at 7:05 PM, Russell Keith-Magee  
wrote:

> I share James' reservations about this as a feature -- attaching flags to 
> Meta is something I can see being abused in all sorts of ways -- but that 
> doesn't mean there's no legitimate uses for extensions to Meta. For example, 
> the USERNAME_FIELD added in support of custom users should, arguably, be a 
> Meta option -- but there was no way we could add that without making a Meta 
> option available to every class.

For what it's worth, I've loosely copied Django's "metaclass w/ Meta options" 
pattern for several projects. In cases where I needed a bit more flexibility, 
the metaclass looked for a well named attribute on the class that would specify 
the options class to use. For example:


class Model(object):
# _meta is a ModelOptions instance
__OPTIONS_CLASS__ = ModelOptions


class Foo(Model):
# _meta is a ModelOptions instance, inheriting Model's __OPTION_CLASS__


class User(Model):
# _meta is a UserModelOptions instance that looks
# for a USERNAME_FIELD option
__OPTIONS_CLASS__ = UserModelOptions

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Allowing custom attributes in Meta classes

2013-09-10 Thread Russell Keith-Magee 
On Tue, Sep 10, 2013 at 7:34 AM, Marc Tamlyn  wrote:

> I'm not sure either way on this one. I don't want people to get carries
> away with Meta, it's not a dumping ground for any old thing you like. That
> said, for a developer of a third party library which extends the ORM, the
> inability to extend Meta is very problematic.
>
> I think a balance could be found where strict validation is retained, but
> third party apps can add to that validation. The difficulty is the API - if
> would be good if it could be done on a per model basis rather than a
> global. This should be explicit on behalf of the end user. I'm not sure how
> this would work though.
>
On the basis that this discussion is happening at all, I've just closed
#21081 as a duplicate of a newly-reopened #5793.

I share James' reservations about this as a feature -- attaching flags to
Meta is something I can see being abused in all sorts of ways -- but that
doesn't mean there's no legitimate uses for extensions to Meta. For
example, the USERNAME_FIELD added in support of custom users should,
arguably, be a Meta option -- but there was no way we could add that
without making a Meta option available to every class.

So - I think custom Meta options are something that should be *possible*. I
don't have any particular ideas for how it should be implemented, though.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Allowing custom attributes in Meta classes

2013-09-10 Thread Marc Tamlyn 
I'm not sure either way on this one. I don't want people to get carries
away with Meta, it's not a dumping ground for any old thing you like. That
said, for a developer of a third party library which extends the ORM, the
inability to extend Meta is very problematic.

I think a balance could be found where strict validation is retained, but
third party apps can add to that validation. The difficulty is the API - if
would be good if it could be done on a per model basis rather than a
global. This should be explicit on behalf of the end user. I'm not sure how
this would work though.

Marc
On 10 Sep 2013 13:04, "Karan Lyons"  wrote:

> Hey all,
>
> I recently opened up a ticket (https://code.djangoproject.com/ticket/21081)
> that turns out to be a dupe of https://code.djangoproject.com/ticket/5793,
> both in regards to allowing custom attributes in a model's Meta class.
>
> It was wontfix'd six years ago, the reasoning being that Meta should
> really only be for setting options related to Django internals. I'm
> personally of the opinion that at this point Meta is considered the place
> for *any* options related to a model by developers, and that handling
> custom options outside of Meta seems against the general Django coding
> style. Currently you can come up with hacks like
> https://github.com/karanlyons/django-save-the-change/blob/feature/update-together/save_the_change/mixins.py#L188to
>  take care of the issue, but this isn't very nice for a number of reasons.
>
> Do we think this should still be a wontfix, and are there any other
> reasons why?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Allowing custom attributes in Meta classes

2013-09-10 Thread Karan Lyons 
Hey all,

I recently opened up a ticket (https://code.djangoproject.com/ticket/21081) 
that turns out to be a dupe of https://code.djangoproject.com/ticket/5793, 
both in regards to allowing custom attributes in a model's Meta class.

It was wontfix'd six years ago, the reasoning being that Meta should really 
only be for setting options related to Django internals. I'm personally of 
the opinion that at this point Meta is considered the place for *any* 
options related to a model by developers, and that handling custom options 
outside of Meta seems against the general Django coding style. Currently 
you can come up with hacks 
like 
https://github.com/karanlyons/django-save-the-change/blob/feature/update-together/save_the_change/mixins.py#L188
 
to take care of the issue, but this isn't very nice for a number of reasons.

Do we think this should still be a wontfix, and are there any other reasons 
why?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.