I am developing a site using App Engine and Webapp2.
I understand the concepts of OO and more or less how they are applied in Python. However I am confused about how App Engine uses OO. When an instance of my app is created, is one instance of each class created and re-used for each user? Or are separate instances created for each user? This will decide whether I should use instance or class variables.
So to be even more specific, when should I use self. variables (instance variables) and when should I leave out self. (class variables)?
Thanks for your help. :)
I would separate the concepts of object-orientation (OO) and request handling. First and foremost, App Engine is based on a request-driven model. A request is the base for most actions triggered on App Engine.
Second of all, be aware of the differences between an App Engine instance[0], which is like a container for you application and provided by the App Engine infrastructure, and an webapp2.WSGIApplication[1], which is an object instance of a class you defined.
To simplify things, I assume your app only has 1 webapp2.WSGIApplication . Now let's start with the first request your application gets. Before that, nothing of your app exists, except the code and configuration available on App Engine machines. Once the request reaches App Engine, a new App Engine instance[0] is created. Once the App Engine instance is in place and set up, it will instantiate a webapp2.WSGIApplication instance[1]. Now you have both relevant "instances" in place, the object being a part of the container. Next, the incoming request is routed to your webapp2.WSGIApplication instance which will handle the request according to the implementation you have done.
The App Engine system will create new App Engine instances for you dependening on the load. If a single instance is not able to handle all the requests that come in, it will create a new instance(first [0], then [1] within the former) and spread the load. If that's still not enough, a third instance is created and so on. The same is true if load decreases. If you application is currently running on 3 instances, but 2 would be enough to handle the load, 1 instance will be killed. In addition, you don't know which particular instance will handle which request.
And this leads us to your second question, should you depend on instance variables. Because App Engine creates and kills instances as it seems appropriate and you don't know which instance handles a request, you should always assume instances to be stateless. While it is not always the case, potentially every request can be handled by a completely new instance.
If you need to have state, use memcache (volatile) or datastore (persistent) or some other data backend (blobstore, files API, and so on).
[0] https://developers.google.com/appengine/docs/adminconsole/instances
[1] http://webapp-improved.appspot.com/guide/app.html
PS: people do use instance memory to optimize requests, but beginners who start to learn about App Engine should consider this an advanced technique.
Related
I'm looking for an easy way to integrate Vue.js with AutobahnJS.
I've already checked this repo for guidance/template, but my main problem is that Autobahn has two layers of "wait":
First you create a Connection/Session instance
You wait for it to connect (maybe even retry N times)
Only after this can you access the session methods (subscribe/call/etc..)
With my limited JS knowledge (i'm a backend dev), i have two ideas:
Create a global variable which will be assigned to the autobahn session after connection. This will surely cause cases where the var is not yet set, so I'd have to check it's existence every time I want to subscribe from a vue instance.
Place the Vue init code into the Session connected callback, but then that would delay the whole application, which is obviously bad too.
I'm looking for a simple and efficient solution, not necessarily a full-fledged plugin (which I haven't found anywhere).
Any help/advice is appreciated!
I've been looking for a plugin like this: https://github.com/lajosbencz/vue-wamp
Plugin calls are deferred until autobahn Session is ready, unsubscribe and unregister are automatically called component-wise.
We have a Seaside Application in place that creates a session and handles user login etc. So we're happy with that.
But we'd like to have the ability to serve a few pages using a fixed url. This is not a problem using #initialRequest: and delegating to a certain component depending on the url. What I'd like to avoid, however, is that some of these pages create a new session and start up all the machinery that's coming with it.
Any ideas?
Seaside 2
You could create a WASession (or WAMain) subclass which will be used if the request was static. Then in that session (or main) you could override those methods that do too much for your liking.
Seaside 3
You could use the new filter mechanism. If I recall correctly you can take control of the request pretty much at any time. That should give you enough leverage to do what you want.
Or if you don't need session state, just subclass WARequestHandler and register an instance somewhere in your handler tree (presumably in a WADispatcher).
There's some messiness currently if you want to use a Canvas for rendering but there should be some examples in the image.
So I'm building a document-based application in Cocoa and trying to understand NSManagedObjectContext. I've read Apple's "Core Data Basics" but can't wrap my head around it. In my application I created a custom CoreDataUtility class so that all of my classes can get the context via the following lines of code:
MyCoreDataUtility *coreData = [MyCoreDataUtility sharedCoreDataUtility];
NSManagedObjectContext *context = [coreData context];
I got this idea from the site "Cocoa is my girlfriend". Where I get confused is when I run my application and I create a new window (my file owner class is a subclass of NSPersistentDocument) if I make changes to the context on the new window, the view reflects the changes on the old window and as well as the new one. Based on this I'm assuming that both windows are referring to the same context or at least the same data in some way.
So my questions are:
I have the assumption that each time I create a new window a new
context is created, is this correct?
If a new context is created and they are different (I actually
printed out the memory address of the two contexts and they
addresses are different) does this have something to do with the
persistent store coordinator or persistent object store (both of
these concepts are also nebulous in my mind)?
If all documents refer to the same context is it my responsibility to
create a new context every time a document is created?
Thanks all!
I have the assumption that each time I create a new window a new
context is created, is this correct?
No and yes. Creating a new window does not create a new context, but I suppose that what you see as "a new window" is actually your action of "creating a new document". In a document based app with CoreDate you are likely to have a persistent store which creates a new context for every document by itself.
That is also the answer to your second question. The store coordinator is just the central point that manages all documents of your application. It takes care of some menu related actions, such as opening, saving and all side effects.
If all documents refer to the same context is it my responsibility to
create a new context every time a document is created?
That is not possible. One context can be related with only one file (or "store"), hence every document must have "at its minimum" one context. If you are using the template for a CoreData and Multi-document based app, you do not have to worry about creating a new context. As I said before, the store coordinator will take care of that. However as you learn more about CoreData, and specially if you do multithreading, you will have to create more than one context because because a context cannot cross threads.
Could you provide the link from Cocoa is my girlfriend where you took that code? It seems you want a singleton to store your context and usually that is a bad idea in a document based app because it is extremely easy to mess up things giving one function the context of a different document. Your application should have a good flow where the context is passed. However I always use a singleton if my application is not document based.
I am developing a Cocoa Mac app which dynamically generates and registers itself for URL schemes. However, when the application registers itself to handle a newly generated URL scheme (e.g. myscheme1423://), I would like to prevent the application from responding to any previously registered URL schemes.
I am using LSSetDefaultHandlerForURLScheme() for the purpose of registering a URL scheme; in conjunction, the application automatically overwrites it's Info.plist to contain the new scheme. As you may know, the LSSetDefaultHandlerForURLScheme() function adds the given bundleID/scheme to a Launch Services database. However, I couldn't find an equivalent Launch Services function to remove the same bundleID/scheme pair from the database.
I know that I could simply ignore any external events which originated from a URL scheme other than the one for which the app is actively registered, but it feels to me that there should be a simple way to completely wipe out the system's knowledge of the previous scheme. If my application goes through the process of registering for a new scheme more than a few hundred times, a point will come where a significant amount of space (for a Plist, at least) is being taken up on disk by a plethora of pointless pieces of data (i.e. the old Launch Services entries).
I just fired up a playground and began playing. This is utterly undocumented but it appears to work.
Try passing ("None" as CFString) for the second parameter of
LSSetDefaultHandlerForURLScheme()
I want to store values in variables to access form another page (a.k.a State management).
Now I cannot use sessions since I have multiple Zope instances & if one fails the user need to be redirected to another Zope instance and one session is valid only for one Zope instance.
Now my remaining options are
submit a Hidden input tag using POST method
Passing through URL with GET method
Using cookies
Using Database (which I think is 'making simple things complex'.)
I am not even considering the first 2 methods and I think using cookies is not secure.
So is there a commercial or open source module that can securely (encryption etc.) do cookie management.
If not I will have to use a database.
Please inform me, if I am missing something.
Version - Zope 2.11.1
The SESSION support built-in to Zope 2 actually keeps the session in a temporary partition of the ZODB so I think it actually is valid for multiple Zope clients connecting to the same ZEO server. The cost of this is that all session changes invoke the transaction machinery and result in a commit, so just make sure you're not using the SESSION in something very low-level like PAS auth or you'll have commits hitting your ZODB for every image, CSS file, and JS file.