Hi,
I have a class (Projects), on which i declared a shared property (projects() as project). I now wonder. Is this property now shared across all WebApps that connect to the server, or is a separate shared property (the projects array), instantiated for each WebApp that connects to the server?
I am hoping that its NOT shared across web apps, and each web app has its own “shared” property instance.
thanks,
Dan
hm…good question. I’m not sure I know the answer.
A shared property is shared across all sessions. If you want to store an array of Projects on a per session basis, you should store them in a regular property of your Session object.
Your post confused me at first because I thought you were asking if separate running instances of a web application all shared a class property. The answer to that would be no. If you have 2 or more instances of a web application running for purposes of load balancing, each has its own memory space (like any running app), so nothing is automatically shared between them.
Thank you Taylor for the response.
Now its my turn to be confused.
On one hand: “shared property is shared across all sessions” and on the other “2 or more instances of web applications” each has its own memory space.
I think we need to clarify terminology:
I presume you mean the following:
WebApplication --> that is the application that runs on a server. Apps connect to the server via browsers. If two Web Applications run on two servers for load balancing, then clearly, each would have its own memory space.
Session is associated with one and only App that runs in a web browser and connects to the server based web application.
Is this correct?
I must admit that intuitively, I would have thought that a shared property should only be shared across one session, assuming that a session is alive for as long as an app is actively connected with the “web app” running on the server.
What is the reason that the design decision was to make shared properties, shared across all sessions?
A shared member (property, method, etc.) is a member on the class you define. As there is one class per application (be it a desktop, a console, an iOS, or a web application), there is one and one only member. It is similar to a property in a Module. And also similar to a global variable.
You should maybe look at subclassing WebSession and add your property to this subclass.
[quote=183122:@Daniel Gross]I presume you mean the following:
WebApplication → that is the application that runs on a server. Apps connect to the server via browsers.[/quote]
The second sentence is the source of confusion. At least as far as Xojo is concerned, the Web Application is the Xojo compiled application running on the server. Browsers connect to the web app which is running on the server. There isn’t a separate app running on the client browser.
An instance of Session is created when a browser connects to a Web Application. But whether there’s 1 or 1,000 connecting browsers, there’s only one web app (load balancing not withstanding).
(Technically there is a JavaScript app running on the browser, but it’s entirely behind the scenes and not directly accessible to you. All your code and all the data you create in Xojo exists on the server with no real representation on the browser. The browser JavaScript ‘app’ exists merely to keep the browser display in sync with server state and to notify the server of user actions, events.)
Yes. That’s also true if you have two Web Applications running on one server. (Why do this? To better take advantage of multiple cores.)
With Xojo it gets confusing to think of apps in browsers connecting to the app on the server (even though this is correct for some other web app scenarios/languages/frameworks). All the code you write in Xojo Web, everything you do, basically executes on the server in a single instance/memory space of the server app. (Again, load balancing not withstanding.)
In this respect a Xojo web app is very much like an ASP.NET web app. And the same thing is true there: a shared property on a class is shared across all sessions/connections.
[quote]I must admit that intuitively, I would have thought that a shared property should only be shared across one session, assuming that a session is alive for as long as an app is actively connected with the “web app” running on the server.
What is the reason that the design decision was to make shared properties, shared across all sessions?[/quote]
It’s due to the underlying architecture and where the code is executing.
That was not a design decision, it is the programming language. It has absolutely nothing to do with web applications.
When defining a class, you have to possibilities to add a member: per instance (regular member) or on the class (shared member).
Again: you should maybe look at subclassing WebSession and add your property to this subclass.
A number of web app scenarios work in the manner he described. Your typical AJAX app; downloaded Java applets; any situation where the web server launches a new process to handle a browser session on a 1-to-1 basis. It’s not so much the language as where and how the code is executing. You could in theory load balance a Xojo web app so that there is one app instance on the server for each session, in which case no data is shared outside of a session. It would be wasteful in the case of Xojo, but some stuff works exactly like that.
Agreed. In a new web project Session is a subclass of WebSession, so just put the property there.
All Xojo code is compiled into the executable, none is send to the client the application then sends html, css and JavaScript to the client.
You can’t compare Xojo web applications to PHP/Ajax or Java applets those are completely different architectures.
Yes. But even in some other web app scenarios where that is the case you have data that is not shared between sessions. And you can create the same situation with Xojo. Hence my comment that it’s not the language so much as the architecture.
But he is comparing them. I’m just trying to help him understand what’s different and why.
Hi Daniel, Eli,
Many thanks for the explanations.
Let me first say that the more i work with Xojo, the more excited I am by the technology.
What I am really trying to get at, as a programmer, is the “semantics” of objects in the web development context. I need to know what to think about when I create classes, properties, shared properties, and when I subtype pre-defined classes, such as App or Session. This is crucial to developing code that behaves as expected across concurrently connecting browsers.
BTW, i think it would be useful to have a name for the code running in the browser. WebApp is the compiled code running on the server, so perhaps ClientApp could be the “implicit” App running in a browser that is connecting via a session to the WebApp.
I think what is (dearly) missing in Xojo, and which I hope to now develop (one step at the time), is a framework for making persistence transparent and automatically bound to UI elements – like in WAKANDA or Meteor. This would have many useful properties, for example:
thanks
Dan
You don’t care. You code as if you code a desktop application. The Xojo web framework does the rest. All JS, CSS, HTML meaning the client side is hidden from you. Of course there are exceptions to that, ExecuteJavaScript and WebControlWrapper being probably the most prominent.
If you want to be successful in developing web applications with Xojo you have to take a different approach than the one you know from Wakanda or Meteor (or any other web scripting language or framework). You really are comparing uncomparable things here.
Xojo code runs on the web server. Everything on the client side is hidden from the developer (with the above mentioned exceptions). If you want to compare Xojo web application development it would be with Adobe AIR, Silverlight, JavaFX, maybe Flash, and others but not with scripting languages where you code client-side stuff.
Thanks Eli,
Here is an example where the understanding I am referring to was necessary:
I declared the property “projects() as project”, as a shared property on a module. The list of projects in the array is retrieved from a database, and only those that are “owned” by the logged in user.
I then opened two browser windows and alternatively logged in and out as one or the other user. Apparently, because the projects() array was defined as a shared property, both logged in users saw the same list of projects, the last one that was retrieved.
To remedy this problem, i “demoted” the property to non-shared, and moved the property to the WebMainPage – the main (and single) page in the project. Then the behavior was correct.
Dan
That’s ok if the projects() array is only needed within that web page. If you need to access it from several web pages I would subclass WebSession and declare it there.
Thanks!
Good to know. Currently, I am hoping to only have one page – all UIs are included in container components that I switch in and out via their visible property. But, to be on the safe side, I may as well place it in a subclass.
Why, btw, in a subclass and not directly in Session? Any specific reason?
Dani
Feel free to ask more questions. I’m not sure what areas are still hazy for you.
That makes sense. But unless you’re a web control developer, you pretty much never deal with the Client App. It’s perhaps safer to think as if there is no Client App, just browsers connecting to the Web App and displaying content as instructed.
As a general principle I would love to see automatic binding like what’s available in Cocoa’s MVC framework. But part of Meteor’s persistence is persistence between client and browser, and Xojo already has that 100%. So much so that you can eliminate the client almost entirely from your thinking.
Session is a subclass of WebSession, already setup for you. You should put it there unless you are creating a WebSession subclass with the intent of sharing functionality across projects. If you do that, you generally do that by adding your subclass to a project and then changing the Super of Session to your subclass, i.e. your subclass ends up sitting in between the two:
WebSession → MySharedSessionClass → Session
“As a general principle I would love to see automatic binding like what’s available in Cocoa’s MVC framework. But part of Meteor’s persistence is persistence between client and browser, and Xojo already has that 100%. So much so that you can eliminate the client almost entirely from your thinking.”
Indeed. I would love to see MVC data binding out of the box. It would make Xojo even more productive, and a key goto Tool for Rapid App Dev. Right now most of the code i write is the controller and model code linking the UI to the MySQL DB. With a tool such as OpenXava – (another kind of tool) this is btw done out of the box using attributes on java classes only.