Appengine Helper, Utilities, Patch, etc

[johnP]

Hello, all -

I was curious if some users might provide some feedback about using
AppEngine Helper, Utilities, and Patch (or nothing at all...:))

Initially, appengine Helper seemed like a safe choice - because it was
sanctioned by the appengine team, and helped bridge the gap between
writing in pure django and writing on appengine. It has over 1500
downloads. It seems to continue being supported at a "moderate" pace
(is it a 20% project for someone at Google)?

Appengine Patch seems very interesting - it promises to allow you to
write in pure Django, excluding models. This makes sense to me. It
seems like it is being developed, and initially - looked like it is
well made. Other positives are the included zip imports, and the
possibility of using my own authentication. My primary concern is
that it is a layer that resides at the core of my application, and is
a potential source of issues (that are not being addressed by a large
community such as Google and Django community).

What I am looking for are the following:
1. Reliability.
2. Ability to write as closely to pure Django 1.0 as possible.
3 Using my own user authentication, rather than Google's
(wonderful) solution.
4. Zip imports.

Can people provide their impressions, positive and negative, with
these different approaches? They all seem very exciting - but an open
discussion would be welcomed. Thanks -

[Alexander Kojevnikov]

About a month ago I migrated www.muspy.com from webapp to Django 1.0
using app-engine-patch. The main reason was to provide a custom
authentication instead of the Google's.

Regarding your questions:

1. The only issue I have is http://code.google.com/p/googleappengine/issues/detail?id=772
but I believe it's not specific to app-engine-patch.

2. I depend on < 200 lines of code provided by app-engine-patch to
ease the implementation of custom authentication. This code could be
easily rewritten or integrated to your app should you decide to
migrate to vanilla Django. Migration from the datastore would take
most time anyway.

3. See above. Very easy and very flexible.

4. After removing unused files from Django, my entire project is about
500 files. I didn't use zip imports and don't plan to.

Hope this helps and let me know if you have other questions.

--
Alex
www.muspy.com

[bowman...@gmail.com]

I'm using appengine-patch to implement Django for a site I'm building,
and it's been very easy. Like Alex, I went to use that instead of
helper because I intend to handle authentication differently than what
comes default with webapp and django helper.

With the inclusion of zip import to appengine-patch it saved me a ton
of time.

Now, not to toot my own horn, but I did integrate appengine-utilities
session and flash into my implementation also. That was extremely
easy. Also, writing an authentication backend to support the google
accounts was a snap as well.

On Oct 21, 12:58 am, Alexander Kojevnikov <alexan...@kojevnikov.com>
wrote:
> About a month ago I migratedwww.muspy.comfrom webapp to Django 1.0

> using app-engine-patch. The main reason was to provide a custom
> authentication instead of the Google's.
>
> Regarding your questions:
>

> 1. The only issue I have ishttp://code.google.com/p/googleappengine/issues/detail?id=772

[johnP]

Thank you both for the responses. Alexander - it is great to hear
that you have had a good experience. Joseph - I'm happy to hear that
you are using the Patch, probably for similar reasons to what I need -
authentication, etc. I didn't quite understand the different niches
for your utilities, and for the Patch. It's good to at least
understand that they are complementary.

If there are other people who have some feedback with their
experiences with the Utilities & Patch vs the Helper - please let us
know. I'm sure there are lots of people trying to make decisions on
what to base their applications upon, and the more data-points, the
better.

johnP


On Oct 21, 6:19 am, "bowman.jos...@gmail.com"

<bowman.jos...@gmail.com> wrote:
> I'm using appengine-patch to implement Django for a site I'm building,
> and it's been very easy. Like Alex, I went to use that instead of
> helper because I intend to handle authentication differently than what
> comes default with webapp and django helper.
>
> With the inclusion of zip import to appengine-patch it saved me a ton
> of time.
>
> Now, not to toot my own horn, but I did integrate appengine-utilities
> session and flash into my implementation also. That was extremely
> easy. Also, writing an authentication backend to support the google
> accounts was a snap as well.
>
> On Oct 21, 12:58 am, Alexander Kojevnikov <alexan...@kojevnikov.com>
> wrote:
>

> > About a month ago I migratedwww.muspy.comfromwebapp to Django 1.0

[bowman...@gmail.com]

Well, I don't want to derail the topic, but the main difference is
both patch and helper are projects to get django more integrated with
appengine so that people can concentrate more on getting their
application working using the Django they know, than figuring out how
to work around the differences appengine introduces.

utilities is just a bunch of, well, utilities, to make working with
appengine easier, and is not django specific at all. It started
because I recognized that there was no session api for appengine at
all. Both helper and patch have gotten Django sessions working, and
I'm not sure what level of support they offer for cache in django. I
created appengine-utilities specifically to handle sessions and cache
the best possible way on appengine, taking advantage of memcache to
provide the best performance.

> > > About a month ago I migratedwww.muspy.comfromwebappto Django 1.0

[Waldemar Kornewald]

On Oct 22, 3:32 am, "bowman.jos...@gmail.com"

<bowman.jos...@gmail.com> wrote:
> utilities is just a bunch of, well, utilities, to make working with
> appengine easier, and is not django specific at all. It started
> because I recognized that there was no session api for appengine at
> all. Both helper and patch have gotten Django sessions working, and
> I'm not sure what level of support they offer for cache in django. I
> created appengine-utilities specifically to handle sessions and cache
> the best possible way on appengine, taking advantage of memcache to
> provide the best performance.

Appenginepatch allows to use Django's memcache backend, so everything
should just work.

Apart from the goal of making Django work seamlessly, appenginepatch
also provides a library of utility functions/extras. For example, our
most recent addition is a prefetcher for reference properties which
could help speed up your code.

Just take a look at the (uhm, minimalistic :) documentation:
http://code.google.com/p/app-engine-patch/wiki/Documentation

Bye,
Waldemar Kornewald

[johnP]

OK - Thanks, Joseph for helping understand the role of the Utilities
project.

A final question is the difference / compatibility between the Helper
project, and the Patch project. Currently, I have completed some work
on a project which was started in an environment with django .97 and
the Helper. Now, I'd like to establish a foundation for the longer
term. There is a bunch of rearranging I need to do to my code; I want
to move to django 1.0; and I want to have non-Google login/
authentication.

After research, I get the impression that the Patch serves my needs
better than the Helper. It has zipped Django 1.0 implemented. It
seems to have better support for authentication than the Helper. And
in general, it appears that it is more substantial in terms of active
development, than Helper is. Helper seems like it has slowed down a
bit. It's last release was in early August.

So my understanding is:

1. I should choose *either* Helper or Patch - not both.
2. It appears that Patch has better support for implementing
authentication.
3. It appears that Patch is reliable.

Is my analysis correct?

Sorry to belabor the point. Maybe someone else will get value from
this thread, too. :)

[bowman...@gmail.com]

All I can offer on that is that I chose patch over helper, because it
appeared helper was more oriented with getting the google
authentication system working. I have had 0 problems using patch and
will personally continue to use it in the future.

[Waldemar Kornewald]

Hi John,

On Oct 22, 7:12 pm, johnP <j...@thinkwave.com> wrote:
>  1.  I should choose *either* Helper or Patch - not both.

Yes.

>  2.  It appears that Patch has better support for implementing
> authentication.

Yes, you can even use Django's auth backends API to support
alternative authentication methods (e.g., OpenID, Google Accounts,
etc.).

>  3.  It appears that Patch is reliable.

Release 0.8 should be pretty stable and we depend on appenginepatch
for our own website, so we try to get bugs fixed as quickly as
possible.

Bye,
Waldemar Kornewald

[Mike]

> >  2.  It appears that Patch has better support for implementing
> > authentication.
>
> Yes, you can even use Django's auth backends API to support
> alternative authentication methods (e.g., OpenID, Google Accounts,
> etc.).

I am interested in using Google Accounts for authentication with the
rest of the django auth package to handle permission, additional user
data and the decorators to restrict access to views. Do you have any
hints how to do this? Basically I am thinking to authenticate a user
by simply checking if the email property from users.get_current_user()
matches with the username/email field of any objects in the User Table
I setup. The request.user attribute seems to be required for the
permission decorators to work, so I presume I would need to find some
way to have request.user retrieve the User object based on
users.get_current_user(). Any ideas would be appreciated.

[Waldemar Kornewald]

Hi Mike,

On 24 Okt., 03:57, Mike <michael.sor...@gmail.com> wrote:
> I am interested in using Google Accounts for authentication with the
> rest of the django auth package to handle permission, additional user
> data and the decorators to restrict access to views. Do you have any
> hints how to do this? Basically I am thinking to authenticate a user
> by simply checking if the email property from users.get_current_user()
> matches with the username/email field of any objects in the User Table
> I setup. The request.user attribute seems to be required for the
> permission decorators to work, so I presume I would need to find some
> way to have request.user retrieve the User object based on
> users.get_current_user(). Any ideas would be appreciated.

Joe Bowman published his implementation on our Google Group:
http://groups.google.com/group/app-engine-patch/msg/9f0d2e6928896381

I'd also suggest looking at the appengine-helper code (the middleware,
in particular):
http://code.google.com/p/google-app-engine-django/source/browse/trunk/appengine_django/auth/

BTW, it's better to use a UserProperty instead of identifying users by
email address. Otherwise someone could change his email without you
taking notice.

Bye,
Waldemar Kornewald

[Waldemar Kornewald]

Well, since it was pretty easy and you weren't the only one requesting
this feature I've just added support for Google authentication:
http://code.google.com/p/app-engine-patch/wiki/GoogleAccounts

Bye,
Waldemar Kornewald