I'm refactoring a large web app with another developer's help. In my mind, the backend is organized like so:
Symfony PHP: controller
PostgreSQL DB: model
As I understand it, the client-side browser is the 'view' of the server.
The frontend is additionally organized like this:
Redux.js: model + controller // this is all mildly simplified
React.js: view
Is it, therefore, conceptually correct to consider the client-side browser as the view of the server's state, and further, that the browser maintains its own state, controller, and view of the server-side data?
I'm a server-side "expert" (emphasize the quotes), while my helper is a front-end pro. We're deliberately trying to separate frontend and backend and restrict interaction to JSON payloads beyond the initial page load. If I'm looking at the global organization of the project right, it'll really help me organize our master codebase.
I don't think it's particularly helpful to think of the client-side app as just a view of the server-side state anymore.
The client-side is its own MVC application. Strictly, I don't think react-redux is actually MVC. It's considered an alternative to MVC. React is the View in MVC, but also a little bit of the Controller, and redux is an opinionated way of using the Model. You should read more here: http://redux.js.org/docs/introduction/Motivation.html
Relationship of the client-side M to the server-side M
Maybe another way of thinking about this is that the server has a 'model' and a part of the redux state-tree is actually kind of a view of that 'model' (like a list of todos derived from and kept in sync with a todo table on the server-side).
Parts of the redux state-tree could also have nothing to do with the server-side 'models' and could just be useful for storing client-side state (like the current url/route).
My firm belief is to not worry too much about the terminologies too much and stick to first principles. The server has state, the client-app has state. A part of the client-app's state is derived from and/or synced to the server-side state. The rest of the client-app's state helps generate the UI that the user sees. As the user interacts with the app, code is triggered that manipulates the state. Once you write a simple react-redux app, you'll see where all these pieces go!
Sounds about right.
The state of the application
React components maintain internal state. The state is updated via this.setState upon an event (e.g. click, mouse move, keyboard input, timeout, AJAX response, etc.). When this.setState is called, en entire re-render of the component is scheduled, after which, the component is then redrawn.
The cycle pretty much continues. You can think of React's state to work just like a traditional LAMP web app, that is, in an example web app, user submits a form, the page is updated with new content. Only that instead of you setting up the listeners, and imperatively telling react what data to pass in to this.setState, with a traditional LAMP app, you do so declaratively in the HTML declaration of the <form>, in the inputs that you define.
Albeit, the above React vs LAMP example is probably a bad analogy, because React does not directly work with the server. It's your responsibility on how to design your code to work with the server.
Communication with server
So, with LAMP, trivially, if you want user input to persist on the server, you simply record the input from a form POST request.
With react, there's an extra step on your end.
When a user triggers an event (click, mouse move, keyboard input, etc.), you first need to issue an AJAX request, which, of course, the server will act on the request (e.g. store form input).
In the (successful) response callback, you would then call this.setState to update what the server responded with. With a traditional LAMP app, you would get an entirely new web page rendered with the user's persisted data. With React, instead, you get back some piece of data (perhaps JSON or XML) which isn't the web page, but is used by your front-end application to determine what the page should look like.
Is it, therefore, conceptually correct to consider the client-side
browser as the view of the server's state, and further, that the
browser maintains its own state, controller, and view of the
server-side data?
Yes, it is completely correct.
In fact, you can think about your web app as an MVC that lives inside another MVC (the browser) that is then executed inside another MVC (the OS windowing system). Which communicates with another MVC across the wire (your backend app).
Now, swap MVC for "the implementation of a software design pattern", because there is no canonical definition of what MVC is. There are many variations, for example, MVC in the server is quite different from MVC in a client machine.
The server side approach is based on what is known as Java Model 2. This design shares the same philosophy as MVC and most of its components resemble it, so we all call it MVC. Which is not incorrect, although inexact too.
http://givan.se/mvc-past-present-and-future/#server-mvc
You can compare all of the documented patterns that belong to the MVC collection here:
http://mvc.givan.se/
Overview:
I am trying to create a PoC application that mimics WebIntents-like feature.
So, in my Qt application, I create two QWebviews launching two different webApps. Now let's call them apps A and B.
Scenario:
Main Application creates two QWebViews each launching an App i.e. AppA, AppB.
App A is programmed to fetch some data via AJAX, automatically.
App B also needs part of that data. AppB simply displays a button (HTML) called .
Note: Since, AppA already has that info, I would like the AppB to invoke a JavaScript API which was injected into it's(appB) DOM by means of addToJavaScriptWindowObject() method call when the QWebView was launched.
App-A completed the Ajax Call and indicates the completion in its WebView.
User clicks the button in AppB,
App B invokes that JavaScript API i.e. fetcData({source: "AppA");
Now the control is in the QT-world:
Question: the Control is in the context of AppB, How should I communicate with the WebView in AppA -- i.e. AppB asks AppA: hey AppA, please give me that data that you have fetched?
Can Signals and Slots help me here? Or should I use some other form of IPC.
I read this page: http://qt-project.org/doc/qt-4.8/qtwebkit-bridge.html, but I still didn't get a hint for a solution for my problem.
Another related question: Are QWebViews created in their own threads ?
Can't you just emit some sort of signal from AppB that basically says, "Hey, I finished fetching my data if anyone wants it" or am I missing something? It would happen at the end of AppB::fetchData().
All you have to do after that is connect any interested objects to that signal.
I have a GWT project A and another project B on another computer. Now I want to call the business logic in project B whenever a user presses a button in project A. Project B cannot be a GWT project because of other restrictions.
How can I do that?
I tried to use sockets, but that is not possible with GWT: java.net.Socket is not supported by Google App Engine's Java runtime environment. If a uncheck the usage of GWT App Engine in the project properties, my application does not start anymore (java.lang.NoSuchMethodError's).
So what I need is a behaviour like the following:
Fire an event in project A
Notice that the event was fired and call method x
After getting notification from the client, about the event, you can use HttpURLConnection to contact the project B. Project B must have HTTP interface to handle the request from the A.
You can read more details about HttpURLConnection here: http://code.google.com/appengine/docs/java/urlfetch/
Calling certain method on the B project is matter of good contract between the request parameters and the mechanism for calling methods(I guess some kind of mapping).
I found at this Adobe tutorial a nice "RemoteService" class that creates a RemoteObject and contains the functions for handling the result and fault events. If I wanted to use this approach, how could I pass the data from the result handler to interfaces that modules from the main application could use?
I could put the RemoteService/RemoteObject in the modules, but (in my opinion- and I could be wrong) the best design seems to be using the remote calls in the main app and passing the data along to the modules.
I think you're correct -- have the remote calls in the main app if other parts of the app will need the data.
To get data into the module, just set a property of the module to the data. So a result handler in the main app sets myModule.someObject = event.result.someObject.
To get data from the module back to the app, dispatch an event. This way the module is loosely coupled to whoever its host is.
I'm making a .net component, resulting in a dll assembly, that will be referenced by an asp.net site, and in another project by an asmx webservice. All code is version 2.0.
The component has a few functions that call an external webservice, which returns an object. One of these functions is for example Login(username, password), which generates amongst others a unique session id for this user. The resulting information and session id are stored in variables in the component.
The issue in the website is:
When the user logs in in the frontend, and my component gets called and checks the login and generates the session id, I want that information in my component to persist when the user browses to another page in the site.
The issue in the web service using my component is:
I don't really care much about session state, but I want the component to just work. If per call a new session id is generated, that's okay.
The combination of the two environments causes the following problem for me:
I can't use the asp.net Session() variable in my component without referencing system.web, which is kinda silly and might not be available in the web service project that includes my component
I can't program my component as a singleton, because then in the website application, it's shared amongst all visitors, overwriting sessions and whatnot
making an array of "session information" in my component and maintaining that is hard to program (when does it get invalidated?) and might not work in a web farm environment
Is there a solution to this situation? Or should I make two instances of my component, one for use in websites, and one for use in web services?
Perhaps I'm not understanding what your asking but why can't you do something like:
Component.Login(user,pass);
Session["Component"] = Component.SessionID
I've created an extra class "Factory" which has a .Create(byref Session as HttpSessionState), that looks if the passed in session object is Nothing, if not, it checks if there is a Component object in it, if so, it uses it, if not, it creates it and adds it to the session.
In the case of the webservice call, the factory gets the Nothing-parameter, so it doesn't check in the session object. It seems to work.
Thanks for your answers!