Group items tagged

Authentication with App Engine, regardless of where you're doing it, is a three-stage process: Obtain an authentication token. This can be done with ClientLogin for installed apps, for example, or with AuthSub for a webapp. When logging in directly to an application, this is the part of the login process where your user sees a Google signin screen. Take that authentication token, and use it to obtain an authentication cookie. Use that authentication cookie in all subsequent requests.

Google app engine uses the concept of static files. This is a performance optimization. Using the file appengine-web.xml you can configure the way google handles static files. You can include and exclude certain files using their extension or name. More information can be found here at google. This all works nice in the online version, however there seems to be a problem with the development server. Some solutions try to configure the local version as well, still that did not work for me. I decided to look for a servlet that serves static files.

That is it, now you can test your stuff locally and all your scripts, images, styles are loaded by your application. Of course you have to remove this servlet before uploading your application. Hope it helps people with their local debugging of jquery scripts or other javascript things.

You will only find "unowned relationships" terminology in Google docs. This "unowned relationships" in the GAE/J docs is where you have a field that is a "Key" or a Collection/Map/array of keys. So no *real* relation, just some implicit relation by that "key". You have to manage these keys yourself, and you tie your code to GAE/J by using them.

 * Implements background tasks for * <a href="http://code.google.com/appengine/docs/java/overview.html">Google App * Engine for Java</a>, based on the * <a href="http://code.google.com/appengine/articles/deferred.html">Python 'deferred' * library</a>; simplifies use of the <a href="http://code.google.com/appengine/docs/java/taskqueue/overview.html"> * Task Queue Java API</a> by automatically handling the serialization and * deserializtion of complex task arguments.

Personally, I would recommend using the blobstore API for this since it is officially supported by google and means it won't break in the future. It also has nice bindings into the imageservice. http://code.google.com/appengine/docs/java/blobstore/overview.html

From what I understand, you are "manually" copying the properties from the Entity to the DTO. But this process is automated in GWT 2.1 So, I am not sending my entities directly, but the proxies as per the documentation : http://code.google.com/webtoolkit/doc/latest/DevGuideRequestFactory.html "An entity proxy is a client-side representation of an entity, otherwise known as a DTO (Data Transfer Object). With RequestFactory, entity proxies are interfaces that extend the EntityProxy interface, which is the hook used to indicate that an object can be managed by RequestFactory. RequestFactory automatically populates bean-style properties between entities on the server and the corresponding EntityProxy on the client, which simplifies using the DTO pattern. Furthermore, the EntityProxy interface enables RequestFactory to compute and send only changes ("deltas") to the server." "Entity proxies simply extend the EntityProxy interface and use the @ProxyFor annotation to reference the server-side entity being represented. It is not necessary to represent every property and method from the server-side entity in the EntityProxy, only getters and setters for properties that should be exposed to the client." The entity proxies are merely interfaces that are being populated by the new GWT 2.1 RequestFactory framework. I have no control over this copying process. Per definition, getters/setters of the real entity are injected into the EntityProxy whenever they are present; So my problem still stands : what about complex values like com.google.appengine.api.datastore.Email that are not known by the client side code ? How to transfer these complex values to the client.

When I copy my entities onto my dtos, some entity fields don't even make it into the dto. Others only have getters in the dto because they are read-only to the client. Those that do get into the dto get converted to native Java types. For instance, Text gets converted to String. Key gets encoded to a url friendly string. If I have Set fields on the entities to manager my relations (property lists), I remap those to ArrayList... First, don't serialize interfaces to GWT client, you'll get Javascript bloat. Then, Hashmap is costly to serialize because String.hashCode() is not the same on in Java and in Javascript. Hence, all the items need to be re-inserted into a client side map. Of course, in Web mode, performance is good enough... but in development mode, your data transfers will become really slow for somewhat big transfers.

Yes, you will need to use the federated login (OpenID) stuff. The long-and-short of it is that you pass the federated_identity parameter to users.create_login_url.  You'll need to setup a page for users to tell you what goes in federated_identity somehow, perhaps by clicking a google logo or entering an apps domain. For Google accounts:   users.create_login_url(federated_identity='google.com/accounts/o8/id')   or   users.create_login_url(federated_identity='gmail.com') For an Apps account:   users.create_login_url(federated_identity='google.com/accounts/o8/site-xrds?hd=yourappsdomain.com') There is a little info here:   http://code.google.com/appengine/docs/python/users/overview.html And Wesley has a nice article about it here:   http://code.google.com/appengine/articles/openid.html Some info on Google Apps domains and OpenID:   http://groups.google.com/group/google-federated-login-api/web/openid-...

Basically, all you have to do is create a subclass of bulkloader.Loader and implement (at a minimum) the generate_records method, which should yield lists of strings. This same strategy would work for loading data from XML files or ROT13-encrypted files or whatever. Note that the list of strings yielded by the generate_records method must match up (in length and order) with the "properties" list you provide when you initialize the loader (ie, the second argument to the AlbumLoader.__init__ method in this example). This approach actually provides a lot of flexibility: We're overriding the __init__ method on our JSONLoader implementation and automatically determining the kind of model we're loading and its list of properties to provide to the bulkloader.Loader parent class.

Blobstore crash course It’ll be best if we gave a quick refresher course on the blobstore before we begin. Here’s the standard flow for a blobstore upload: Create a new blobstore session and generate an upload URL for a form to POST to. This is done using the createUploadUrl() method of BlobstoreService. Pass a callback URL to this method. This URL is where the user will be forwarded after the upload has completed. Present an upload form to the user. The action is the URL generated in step 1. Each URL must be unique: you cannot use the same URL for multiple sessions, as this will cause an error. After the URL has uploaded the file, the user is forwarded to the callback URL in your App Engine application specified in step 1. The key of the uploaded blob, a String blob key, is passed as an URL parameter. Save this URL and pass the user to their final destination

allocate_ids(model_key, count)

allocate_id_range(model, start, end, **kwargs)

The most obvious use case is data import. A developer looking to import large amounts of data would take the following steps: Create a CSV file containing the data you want to import. The assumption here is that each line of data corresponds to a datastore entity you want to create Upload the CSV file to the blobstore. You’ll need billing to be enabled for this to work. Create your Mapper, push it live and run your job importing your data. This isn’t meant to be a replacement for the bulk uploader tool; merely an alternative. This method requires a good amount more programmatic changes for custom data transforms. The advantage of this method is that the work is done on the server side, whereas the bulk uploader makes use of the remote API to get work done. Let’s get started on each of the steps.

to build Mappers that map across some large, contiguous piece of data as opposed to Entities in the datastore

-dump --k

import_transform A single-argument function that returns the correct value and type data based on the external_name or import_template strings. Examples include the built-in Python conversion operators (such as float), any of several helper functions provided in transform, such as get_date_time or generate_foreign_key, a function provided in your own library, or an in-line lambda function. Or, a two-argument function with the keyword argument bulkload_state, which on return contains useful information about the entity: bulkload_state.current_entity, which is the current entity being processed; bulkload_state.current_dictionary, the current export dictionary, and bulkload_state.filename, the --filename argument that was passed to appcfg.py.

import_template Specifies multiple dictionary items for a single property, using Python string interpolation.

The data loader feature communicates with your application running on App Engine using remote_api, a request handler included with the App Engine runtime environment that allows remote applications with the proper credentials to access the datastore remotely. To use remote_api, you must map a URL to it.