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.
