Re: tastypie - some feedback / comments

[Jani Tiainen]

13.9.2012 11:23, sbrandt kirjoitti:

After evaluating some API creation frameworks, namely tastypie, pistion
and django rest framework, it came out that I would never use the first
two in my projects.

Sorry that I can't provide more detailed information, but it's about a
year ago. Both had issues with their architecture and philosophy not
being clear, straight or smart enough to me. The latter,
django-rest-framework (http://pypi.python.org/pypi/djangorestframework)
was very young at this time and followed the then-new paradigm of class
based views. Since it behaves like other django views (URL config,
mixins, etc.) it is very nice to use and extensible.

--
You received this message because you are subscribed to the Google
Groups "Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-/tXP5LkQDKXQJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.


I'm also fan (and user) of django-rest-framework. Just because it's 
quite easily to be extended with all kind of stuff you need (specially 
since I work with ExtJS 4 which does have support that resembles REST 
from some parts), allows me to define URLs I want and does quite much 
stuff OOTB.


Also in few cases I really work things that do not bound to any models, 
querysets or whatsoever django-rest-framework just works with them as well.


--
Jani Tiainen

- Well planned is half done and a half done has been sufficient before...

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: tastypie - some feedback / comments

[sbrandt]

After evaluating some API creation frameworks, namely tastypie, pistion and 
django rest framework, it came out that I would never use the first two in 
my projects.

Sorry that I can't provide more detailed information, but it's about a year 
ago. Both had issues with their architecture and philosophy not being 
clear, straight or smart enough to me. The latter, django-rest-framework 
(http://pypi.python.org/pypi/djangorestframework) was very young at this 
time and followed the then-new paradigm of class based views. Since it 
behaves like other django views (URL config, mixins, etc.) it is very nice 
to use and extensible.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/tXP5LkQDKXQJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: tastypie - some feedback / comments

[Thomas Orozco]

After giving it a try for a small personal project / curiosity, I couldn't
agree more that it's great for a REST API with querysets, but whenever
something doesn't exactly tie into this structure, things get complicated.

However, I would say that this can also be a good thing.

This forces you to think and build using Tastypie's principles, which I
think are sane.

Eventually, this means that for an existing project, Tastypie can be a bit
disheartening to use.
 On Sep 12, 2012 5:16 PM, "Kurt Pruhs" <kurt.pr...@usu.edu> wrote:

>   I've had the same issues. A previous developer used TastyPy for APIs
> and it's a nightmare trying to modify them beyond the simple,
> out-of-the-box functionality. In its current state, it's more trouble than
> it's worth.
>
>  --
>
>   Kurt Pruhs
> Utah State University
> Information Technology Department
> Programming and Design Team
> office: 435.797.9260
> cell: 435.890.0289
>
>   From: "Cal Leeming [Simplicity Media Ltd]" <
> cal.leem...@simplicitymedialtd.co.uk>
> Reply-To: "django-users@googlegroups.com" <django-users@googlegroups.com>
> Date: Wednesday, September 12, 2012 6:27 AM
> To: "django-users@googlegroups.com" <django-users@googlegroups.com>
> Subject: tastypie - some feedback / comments
>
>   Hi all,
>
>  For the last two years whenever an API has been required for a project,
> we have just used our own API wrapper that consists of about 50 lines, then
> added in the bits we needed as we go along.
>
>  So today, I decided to spread my wings a little and give TastyPie a
> try... here is a bit of feedback for anyone considering TastyPie;
>
>  It works quite nicely out of the box, ties directly into the Django user
> models, has fairly good URL path structures, and within 30 minutes you can
> have it spitting out data from your models with as much control as you
> wish.
>
>  However, like the django-admin system, this is where the fun ends. As
> soon as you want to do anything bespoke or actions that involve not
> fetching data (whether it be ORM or not), things start to get
> touchy. Attempting to get tastypie to work without a queryset/qs is damn
> near impossible, the uglyness of override_urls/prepend_urls() alone was
> enough to make me say "eww", and the general feel was overly complex.
>
>  In theory tastypie is perfect, but in practise it seems to
> overcomplicate things in an attempt to keep everything organized, and to
> quote a colleague "it has a bit too much magic". Sure, it claims to give
> you plenty of control to customize it for your specific use case, but the
> complexity of this makes actual time and sanity saved debatable.
>
>  This isn't to say that tastypie should be avoided, as it will work
> beautifully for simple requirements, but I personally feel that it should
> be kept in the same box as django-admin. It's also worth mentioning that
> (imo) anyone thinking about tastypie should still give it a try and see how
> they feel about it. It'd be interesting to hear other thoughts on it.
>
>  There are obviously some others to compare this against, the most
> notable being piston and Django REST framework. Although there's some bad
> press about piston (and I haven't tried it myself), it would probably be
> next in my list to try. Unlike tastypie, it treats resources as completely
> arbitrary objects and lets you create the magic for yourself.. so although
> it doesn't work out of the box quite as easily, it offers so much more
> benefits in the long run.
>
>  Any thoughts?
>
>  Cal
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>   --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Django-admin (was: tastypie - some feedback / comments)

[Tomas Neme]

The admin templates and views themselves are convoluted enough (the
price of having them work with anything), and full of enough magic
that it's not really feasible to build on top of them to add the
required capabilities. Maybe adding new admin views would be a
posibility, but what happens when you want an admin page that does not
exactly correspond to a given model? You can usually twist things
around to make it so, but the fact stands that the admin is in the end
just a way of managing the database, and that the user must *really*
know what they're doing to avoid screwing up big time. Maybe careful
permission handling and/or different admin site instances are a
(partial) solution to this, but I haven't played with those myself.

-- 
"The whole of Japan is pure invention. There is no such country, there
are no such people" --Oscar Wilde

|_|0|_|
|_|_|0|
|0|0|0|

(\__/)
(='.'=)This is Bunny. Copy and paste bunny
(")_(") to help him gain world domination.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Django-admin (was: tastypie - some feedback / comments)

[Cal Leeming [Simplicity Media Ltd]]

This is just my own opinion but, I can't ever see django-admin going much
further than it is now - for much the same reasons as mentioned on the
tastypie thread, nor have I come across any alternatives (yet) - although
it'd be interesting to hear others thoughts on this.

For me the thing I've found with Django is that the more I've learnt, the
less built in stuff I use.. We've used a whole bunch of different
authentication approaches in the past, and it's really down to use-case and
trial/error. As for the security aspect, spend some time getting your hands
dirty, try different approaches and eventually it'll come naturally :) (be
prepared to make some mistakes!)

Cal

On Wed, Sep 12, 2012 at 4:35 PM, Tomas Neme  wrote:

> Since this came up, are there any more-or-less packaged alternatives
> to django-admin? More than twice I've had to give up in something as
> simple as rendering two-level FK indirections, lest I wanted to
> override most of the ModelAdmin classes.
>
> The thing is that I don't trust myself to be throughout enough with
> security and the such when rolling my own.
>
> --
> "The whole of Japan is pure invention. There is no such country, there
> are no such people" --Oscar Wilde
>
> |_|0|_|
> |_|_|0|
> |0|0|0|
>
> (\__/)
> (='.'=)This is Bunny. Copy and paste bunny
> (")_(") to help him gain world domination.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Django-admin (was: tastypie - some feedback / comments)

[Tomas Neme]

Since this came up, are there any more-or-less packaged alternatives
to django-admin? More than twice I've had to give up in something as
simple as rendering two-level FK indirections, lest I wanted to
override most of the ModelAdmin classes.

The thing is that I don't trust myself to be throughout enough with
security and the such when rolling my own.

-- 
"The whole of Japan is pure invention. There is no such country, there
are no such people" --Oscar Wilde

|_|0|_|
|_|_|0|
|0|0|0|

(\__/)
(='.'=)This is Bunny. Copy and paste bunny
(")_(") to help him gain world domination.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: tastypie - some feedback / comments

[Kurt Pruhs]

I've had the same issues. A previous developer used TastyPy for APIs and it's a 
nightmare trying to modify them beyond the simple, out-of-the-box 
functionality. In its current state, it's more trouble than it's worth.

--

Kurt Pruhs
Utah State University
Information Technology Department
Programming and Design Team
office: 435.797.9260
cell: 435.890.0289

From: "Cal Leeming [Simplicity Media Ltd]" 
<cal.leem...@simplicitymedialtd.co.uk<mailto:cal.leem...@simplicitymedialtd.co.uk>>
Reply-To: "django-users@googlegroups.com<mailto:django-users@googlegroups.com>" 
<django-users@googlegroups.com<mailto:django-users@googlegroups.com>>
Date: Wednesday, September 12, 2012 6:27 AM
To: "django-users@googlegroups.com<mailto:django-users@googlegroups.com>" 
<django-users@googlegroups.com<mailto:django-users@googlegroups.com>>
Subject: tastypie - some feedback / comments

Hi all,

For the last two years whenever an API has been required for a project, we have 
just used our own API wrapper that consists of about 50 lines, then added in 
the bits we needed as we go along.

So today, I decided to spread my wings a little and give TastyPie a try... here 
is a bit of feedback for anyone considering TastyPie;

It works quite nicely out of the box, ties directly into the Django user 
models, has fairly good URL path structures, and within 30 minutes you can have 
it spitting out data from your models with as much control as you wish.

However, like the django-admin system, this is where the fun ends. As soon as 
you want to do anything bespoke or actions that involve not fetching data 
(whether it be ORM or not), things start to get touchy. Attempting to get 
tastypie to work without a queryset/qs is damn near impossible, the uglyness of 
override_urls/prepend_urls() alone was enough to make me say "eww", and the 
general feel was overly complex.

In theory tastypie is perfect, but in practise it seems to overcomplicate 
things in an attempt to keep everything organized, and to quote a colleague "it 
has a bit too much magic". Sure, it claims to give you plenty of control to 
customize it for your specific use case, but the complexity of this makes 
actual time and sanity saved debatable.

This isn't to say that tastypie should be avoided, as it will work beautifully 
for simple requirements, but I personally feel that it should be kept in the 
same box as django-admin. It's also worth mentioning that (imo) anyone thinking 
about tastypie should still give it a try and see how they feel about it. It'd 
be interesting to hear other thoughts on it.

There are obviously some others to compare this against, the most notable being 
piston and Django REST framework. Although there's some bad press about piston 
(and I haven't tried it myself), it would probably be next in my list to try. 
Unlike tastypie, it treats resources as completely arbitrary objects and lets 
you create the magic for yourself.. so although it doesn't work out of the box 
quite as easily, it offers so much more benefits in the long run.

Any thoughts?

Cal

--
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to 
django-users@googlegroups.com<mailto:django-users@googlegroups.com>.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com<mailto:django-users+unsubscr...@googlegroups.com>.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

tastypie - some feedback / comments

[Cal Leeming [Simplicity Media Ltd]]

Hi all,

For the last two years whenever an API has been required for a project, we
have just used our own API wrapper that consists of about 50 lines, then
added in the bits we needed as we go along.

So today, I decided to spread my wings a little and give TastyPie a try...
here is a bit of feedback for anyone considering TastyPie;

It works quite nicely out of the box, ties directly into the Django user
models, has fairly good URL path structures, and within 30 minutes you can
have it spitting out data from your models with as much control as you
wish.

However, like the django-admin system, this is where the fun ends. As soon
as you want to do anything bespoke or actions that involve not fetching
data (whether it be ORM or not), things start to get touchy. Attempting to
get tastypie to work without a queryset/qs is damn near impossible, the
uglyness of override_urls/prepend_urls() alone was enough to make me say
"eww", and the general feel was overly complex.

In theory tastypie is perfect, but in practise it seems to overcomplicate
things in an attempt to keep everything organized, and to quote a colleague
"it has a bit too much magic". Sure, it claims to give you plenty of
control to customize it for your specific use case, but the complexity of
this makes actual time and sanity saved debatable.

This isn't to say that tastypie should be avoided, as it will work
beautifully for simple requirements, but I personally feel that it should
be kept in the same box as django-admin. It's also worth mentioning that
(imo) anyone thinking about tastypie should still give it a try and see how
they feel about it. It'd be interesting to hear other thoughts on it.

There are obviously some others to compare this against, the most notable
being piston and Django REST framework. Although there's some bad press
about piston (and I haven't tried it myself), it would probably be next in
my list to try. Unlike tastypie, it treats resources as completely
arbitrary objects and lets you create the magic for yourself.. so although
it doesn't work out of the box quite as easily, it offers so much more
benefits in the long run.

Any thoughts?

Cal

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.