How to create a different set of fields for a model?
Vermus
want in a particular case, request a list with a reduced set of
fields, and in choosing from a list of elements in the UI, to seek a
more complete set of fields to display the object. At the moment, I
understand, I can not create two Handlers for one model (http://
bitbucket.org/jespern/django-piston/wiki/FAQ#why-does-piston-use-
fields-from-previous-handlers). What suggestions?
jespern
We extract the list of fields last minute, and there is a somewhat
undocumented feature that should provide what you're after.
It's called 'list_fields', and will override 'fields', in case you
return a list or a QuerySet.
The feature is here: http://bitbucket.org/jespern/django-piston/src/tip/piston/resource.py#cl-206
Jesper
Thibaud Morel l'Horset
class PlayerHandler(BaseHandler):
allowed_methods = ('GET',)
model = Player
fields = [
'id',
'name',
'level',
'hp',
'max_hp',
]
def read(self, request, id):
player = Player.objects.get(pk=id)
if player.user == request.user:
self.fields += [
'builder_mode',
'items',
'mp',
'max_mp',
'experience',
'next_level',
'equipment',
'inventory',
]
return player
- Teebes
--
You received this message because you are subscribed to the Google Groups "django-piston" group.
To post to this group, send email to django...@googlegroups.com.
To unsubscribe from this group, send email to django-pisto...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-piston?hl=en.
--
Thibaud Morel l'Horset
http://teebes.com
jespern
I don't think that's anywhere *near* thread-safe. Have you run this in
a threaded environment?
Jesper
>
>
>
>
> On Mon, Feb 8, 2010 at 9:11 AM, jespern <jno...@gmail.com> wrote:
> > On Feb 8, 4:08 pm, Vermus <vermus.jab...@gmail.com> wrote:
> > > How to create a different set of fields for a model? For example, I
> > > want in a particular case, request a list with a reduced set of
> > > fields, and in choosing from a list of elements in the UI, to seek a
> > > more complete set of fields to display the object. At the moment, I
> > > understand, I can not create two Handlers for one model (http://
> > > bitbucket.org/jespern/django-piston/wiki/FAQ#why-does-piston-use-
> > > fields-from-previous-handlers). What suggestions?
>
> > We extract the list of fields last minute, and there is a somewhat
> > undocumented feature that should provide what you're after.
>
> > It's called 'list_fields', and will override 'fields', in case you
> > return a list or a QuerySet.
>
> > The feature is here:
> >http://bitbucket.org/jespern/django-piston/src/tip/piston/resource.py...
>
> > Jesper
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "django-piston" group.
> > To post to this group, send email to django...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-pisto...@googlegroups.com<django-piston%2Bunsubscribe@goog legroups.com>
Thibaud Morel l'Horset
To unsubscribe from this group, send email to django-pisto...@googlegroups.com.
jespern
only instantiated once (per interpreter), so the next request being
passed through this handler will likely suffer the side effects.
Jesper
Thibaud Morel l'Horset
To unsubscribe from this group, send email to django-pisto...@googlegroups.com.
Thibaud Morel l'Horset
Sorry about the confusion, I realize now I had misunderstood the original question, as well the proposed solution. I've played with list_fields and I understand its use case and how it answers the question. That is definitely a nice feature.
I still wonder if there is a good way to do what I am trying to do though? adding a set of fields to a resource if it matches a certain criteria. For example, one resource could return a different set of fields when viewed as a regular user vs a staff user. Or, as in my earlier example, a resource showing more details to its owner than to any third party viewer?
I understand that changing the fields after the handler is instanciated is problematic, but then I don't see a clear way to do that would be? any thoughts would be appreciated, and very sorry about all the added noise.
Vermus
> We extract the list of fields last minute, and there is a somewhat
> undocumented feature that should provide what you're after.
>
> It's called 'list_fields', and will override 'fields', in case you
> return a list or a QuerySet.
>
Thank you very much! But my REST frontend takes the answer as:
data=Data.objects.get(pk=id)
response = {"response" :
{"status":0,
"data": data
}
}
Why 'list_fields' overrides fields in response only in a list or a
QuerySet? Simple 'list' works in this case perfectly.
Vermus
> Why 'list_fields' overrides fields in response only in a list or a
> QuerySet? Simple 'list' works in this case perfectly.
Well, I looked at the code and little understood how it works.
I changed the code a bit:
resourse.py
206 fields = handler.fields
if hasattr(handler, 'no_list_fields'):
fields = handler.no_list_fields
emmiters.py
107 elif isinstance(thing, dict):
ret = _dict(thing, fields=fields)
293 def _dict(data, fields=()):
"""
Dictionaries.
"""
return dict([ (k, _any(v, fields)) for k, v in
data.iteritems() ])
class ModelHandler(BaseHandler):
allowed_methods = ('GET',)
model = Model
no_list_fields = ('id', 'title', 'title_original', 'year', 'date',
'length', ('country', ('name',)), )
fields = ('id', 'title', 'title_original',)
def read(self, request):
if 1:
data = list(Model.objects.values_list(*self.fields))
return {"response" :
{"status":0,
"data": data
}
}
else:
data = Model.objects.get(pk=id)
return {"response" :
{"status":0,
"data": data
}
}
Now if pass list() to data, then the response returns the set of
'fields'*, in other cases (also, in future handlers) -
'no_list_fields'.
Criticize code, please.
*elif isinstance(thing, (tuple, list)):
ret = _list(thing)
jespern
It's better if you fork piston on Bitbucket, commit your changes, and
send us a link here.
Jesper