> If you are with me so far, then Thadeus's question sounds like "where > do I put the client-code, to keep it MVC-like in organization, to help > me keep my sanity during development and revision"
You hit the nail on the head. In the simplest form of the issue. To take an idea from gaming. There are two parts, the gaming client, and game server. The server handles all data storage/retrieval, it handles all logic (damage calculations, position movement, unit spawns, chat logs). The client takes data from the server (a list of all sprites) and renders them, and allows you an interface to send the server input. However the client has special logic to make sure your input matches only that which makes sense to the games logic. In this case, javascript is the game client, and web2py is the game server. Javascripts job is to take data, format it in a pretty way, and provide interfaces to allow for input that still adhears to the business logic. web2py handles the data storage/retrieval, and all logic (calculations, accounts, appointments, contact history). So here, what is returned as a "web2py view" is not really a view at all, but a client side application that happens to be in javascript. Now client side applications of any type (javascript, java swing, tkinter, pygame) follow their own MVC conventions. Where your "model" is the interface to communicate with the server, your "view" is the presentation and input handling layer, and your "controller" handles the transition from presentation to engineering layer. Now we get into the grit of the issue. If web2py can only return one view/.html file, how do I separate my javascript in such a way that makes sense, so that it can all be streamed in one request by web2py, but still communicate via ajax with web2py without refreshing the page completely. So you end up with your view files actually being the cilent application, and your server exposing services, where your controllers response is now the "view" -Thadeus On Tue, Mar 30, 2010 at 4:16 PM, Yarko Tymciurak <resultsinsoftw...@gmail.com> wrote: > On Mar 30, 1:01 pm, Thadeus Burgess <thade...@thadeusb.com> wrote: >> How do you MVC a javascript client application? > > Here's the "simple" of it: > > An application is ... an application. > > Layered applications are partitioned into layers for (among other > things) a clean interface between layers. > This is important for a couple of reasons, one of them being the > ability to move where the network boundary is. > > In typical, plain web2py applications, the network boundary is placed > at the junction between the controller and the view (the controller > being server-side). > > Now - more generally, layered applications are a way of structuring > your solution. > > I like the 4 layer model, as it is descriptive and usually brings home > another point: > > Presentation: > > How you display things to the end users; the problem is presented in > a "language" describing the problem (and results) familiar to the end > user, i.e. in the language of the problem domain. Typically, this > is NOT in terms of "classes" or function calls (that is the "language" > of the presentation), but rather (for example) in terms of account > status, or amount due, or things registered for. > > Corresponds closely to "V" from MVC terminology. > > Business Rules: > This is the solution, in the language of the problem-domain, i.e. in a > way the end-user would be able to understand. Accounts are > represented as accounts, names as names, etc. This is devoid of > implementation logic (that is, there is nothing that says "but you > have to hold it this way for it to work in a python dict" --- because > a python dict has nothing to do with the end-user's problem domain). > > Engineering Rules: > This is whatever logic you need to implement the Business rules, in > the language needed to accomplish this in the technology in use. For > example, > account_in_good_standing() - lets say this will be business-rule-like > - would list things like: account_exists(), > account_positive_balance(), etc. The engineering rules would > implement account_exists() logic as DAL validator statements > (depends on table definitions - even if they are "close" to the > business language), perhaps queries. Since another implementation > might use sqalchemy rather than DAL, the Engineering rules (the way > you would implement) would differ for that system, BUT NOT the > Business Rules. > > Together, Business Rule and Engineering Rule layers correspond to "C" > from MVC. > > Data Persistence Layer: > This is where sqalchemy, DAL, data manipulation and storage code (and > device and network layer drivers) would go. db.define_table() (and > all it's contents) are here. Even as you might be accustomed to > seeing "requires" - standard statements in something like db.py, by > this definition, those would only be standard validators required to > ensure data consistency -- validators that belong in the Engineering > Rule layer would appear elsewhere, strictly speaking. > > This corresponds closely to "M" from MVC. > > So much for background definitions - we have MVC > > Now - client-server is nothing special: it is just communicating > programs. When you want responsiveness, or other forms of > partitioning your solution, you simply put more out on the client- > side. > > BEFORE you parrition parts of your solution between client and server, > they are all part of the solution stack. By writing pieces in > javascript, you are just choosing another language (you _could_ write > your entire application - using something like jsshell - on the server > if you wanted). This is even clearer if you consider Java (and the > same goes for actionscript, or 'processsing' language). > > Now - architecturally, you have a solution, and it potentially is a > networked solution. So it will have a network boundary. In the > simplest form, contollers all reside on the server, and business > ruiles (BR) may be the direct connection the the view, and in turn > call engineering-rule (ER) entities by simple function calls (lets > say). > > If some of the view logic (pre-processing - i.e. selecting menu > elements) is done on the server (web2py views), the rest is computed > at the client (i.e. css rendering, javascript). > > This "traditional" or simple web app architecture is MVC (or PL, ER/ > BR, DL), and looks something like this: > > [client]---> PRESENTATION > ---<network boundary>---- > [servr]--> CONTROLLER > [servr]--> MODEL > > or simply: > > V > -- > C > > M > > WHen you split this functionality, hand part off to javascript, you > might have something like this: > > V V V V > ------ > C C C C > -- > M M M M (client) > --- > M (server) > > You now have to decide: does the client data store (say, for a full > editor, such as Aviary.com) communicate directly with a counterpart on > the server (i.e. little more than a storage service), or will the > client-M need to talk through a server-C to further validate > consistency at the server. > > If you are with me so far, then Thadeus's question sounds like "where > do I put the client-code, to keep it MVC-like in organization, to help > me keep my sanity during development and revision" > > This is a good question - and even more, gets to the original question > of plugins.... do you now do what with did for plugins, and have file > spaces that look like: > > controllers/client_somefunction.js ??? > > I think this doesn't make sense, as client and server are "two > programs" which will communicate. > > It still leaves the question of where the best place to put this is. > > I like to think of an app-level js directory, i.e. applications/ > myapp/js that contains the application-specific js files for > development. When completed, the minified package would be linked / > placed in application/myapp/static - excpet for the one thing > remaining: the python-ish jquery toolset, such as Nathan has created > --- which taps into a "live" web2py application, and thus is part of > the client/model/view directory spaces (i.e., no longer "static"). > > Good question, Thadeus! > > Discussion? > > - Yarko >> >> So I have web2py acting as the server, and I write a Javascript GUI (based >> off extjs or similar library). >> >> So of course this goes in the View files... The interesting question is that >> these client side js have their own MCV on top of that (models are your >> JSONRPC, controllers to format data/communicate with server, and then view >> code to generate/populate the html). >> >> -Thadeus > > -- > You received this message because you are subscribed to the Google Groups > "web2py-users" group. > To post to this group, send email to web...@googlegroups.com. > To unsubscribe from this group, send email to > web2py+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/web2py?hl=en. > > -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
