Here's a quick shorthand:
If you want a normal web page, go with def get(self):.
If you want to access form data, go with def post(self):.
On Jan 27, 12:11 pm, Blixt andreasbl...@gmail.com wrote:
Just to clarify,
[...] The other, most common, request is POST, which means [...]
By the above
If you use app-engine-patch to run Django, you should add this at the
bottom of your app.yaml:
- url: /.*
script: common/appenginepatch/main.py
The rest of your app.yaml is for static files. And urls.py is for all
non-static handlers.
On Jan 28, 9:22 pm, arnie parvez...@rediffmail.com wrote:
Hey Niklas,
You can post to whatever path (that is under your control) you want.
But it might be a good idea to post to one that makes sense.
For example: if the user is submitting a login form, a post to /
login makes sense. Then this page can either show a Login
successful message with a link
Hi all,
I'm new to appengine and somewhat new to web development. My question
is regarding proper ways to use sessions.
I'm currently messing around using the gaeutilities sessions module. I
have a basic login page and some content. The question is what is the
standard/best practice way to
I run dev_appserver.py in Windows.
I add time.sleep(10) in one of my scripts and send request to that
script in browser.
During sleep, I send another request to other script in another
browser window.
It's seem that the second request is blocked until the first one has
done.
Hi all,
I have an application that has been up for quite a while, with a lot
of static data that I loaded once after setting up the app. I noticed,
at sporadic instances, that some of my data entities disappear. There
are few thousands of this type of entity, so it's not too easy to
pinpoint all
Yes, the development server can serve only one request at a time:
http://code.google.com/appengine/docs/python/tools/devserver.html#Using_URL_Fetch
On Jan 28, 9:03 pm, 3x3x3 nerd.l...@gmail.com wrote:
I run dev_appserver.py in Windows.
I add time.sleep(10) in one of my scripts and send request
I still do not know how to do paging...I can only get the next link, but I
can not get the page 2,3,4,5,6,7,8 more link. Wish you can give me more
hint. Thanks
On Mon, Jan 26, 2009 at 7:32 AM, Marzia Niccolai ma...@google.com wrote:
Hi,
This may not work for your particular use case, but you
Hi,
I've just noticed that my app is returning random 404 responses for
some requests (such as javascript, images or ajax GET requests).
Hitting refresh seems to return different 404 responses each time -
sometimes the request loads OK, sometimes it doesn't...
I'm using Firebug in Firefox to
Hi,
To further clarify, you must _always_ include an app.yaml file with
your Google App Engine app - this is the way our system knows how to
serve your application, which URLs to map to which scripts, and which
files are static files. This is true for both Django and non-Django
users alike.
Hi Matt,
I believe the issue should now be sorted out with the email with which
you are writing from. You should be able to sign in to App Engine and
create apps here: http://appengine.google.com/a/makeable.co.uk
-Marzia
On Mon, Jan 26, 2009 at 10:36 PM, Makeable m...@makeable.co.uk wrote:
appears to be fixed at the moment...
On Jan 28, 12:54 pm, Fred fred.leef...@gmail.com wrote:
Looks like it might be related to this (I'm based in the
UK):http://groups.google.com/group/google-appengine-downtime-notify/brows...
On Jan 28, 12:50 pm, Fred fred.leef...@gmail.com wrote:
Hi,
If you're familiar with Python:
If you've got separate request handlers for the parts of the site that
require login and the parts that don't, you can make a function
descriptor that checks if the user is logged in before calling the
actual function. If the user is not logged in, it redirects to
Thank you for you reply, that's useful info.
As to the second part of my question, how would I enforce this as the
user leaves my site? Since gaeutilities sessions persist in the
datastore, I would need some way of knowing when the user leaves the
site so that I can either delete the session or
Sessions provide you with a way to store information about the current
site visitor across requests. It's the foundation for an
authentication system, but does not actually provide.
What you would need to do is store within the session that the user is
logged in. In most cases it would work
Hi Andy,
It should always be safe to assume that if fetch returns less than
LIMIT (provided that LIMIT is 1000) the results are the only ones
that match the query.
If the number of results you are trying to fetch takes too long, or
some other limit is reached, fetch will throw an exception,
Hi,
There should not be an issue where the datastore ever looses data, but
what you may have noticed is this bug:
http://code.google.com/p/googleappengine/issues/detail?id=901
Currently, there are certain cases where indexes for a query may not
have been completely updated. If you find such an
Well to answer your question, you'd need to regenerate your index, or
build it in such a way as items can be removed from it.
My approach to paging was this. I determined for my product I didn't
need to offer more than 100 items in a set.
When the system that needs paging is first hit, I pull
I think the problem was that the Django User and ragendja User
were conflicting somehow and causing strange problems with the
runtime.
For my custom backend I'm now creating my own User and ignoring both
of those (neither of which I could get to work properly).
My Users don't persist in the DB
You can also use app.yaml to protect resources. For example:
- url: /.*/admin/.*
script: main.py
login: admin
- url: /.*
script: main.py
That will cause a user to be authenticated as an app administrator
before viewing any URL containing the node 'admin.' You can still
route the
Marzia,
Thanks for your reply.
This could be the cause of the issue. I've been re-inserting some of
these entities that I found missing. Your answer seem to suggest that
maybe I shouldn't do that, since I'll end up with duplicate values, if/
when the old values start coming up in the query
Thanks! Really good info here. Much appreciated.
On Jan 28, 10:34 am, Blixt andreasbl...@gmail.com wrote:
Yup, it certainly is rather straight-forward. I'll give you a short
history of descriptors.
Before descriptors, the equivalent was to do this:
class UserSettings(webapp.RequestHandler):
You forget to put() the created object before you access fields that
probably are set when you store the object, not when you create the
object.
log = Log(key_name=billy,job=write,comment=good work)
log.put()
--~--~-~--~~~---~--~~
You received this message
I don't think it's related to transactions. As Ian mentioned above,
this behaviour is probably caused by in-memory cashing of the entire
datastore by the development server.
This is inconsistent with how the datastore works in production. While
there's a chance it won't be fixed, this behaviour
24 matches
Mail list logo
