Simply put, MVC is the pattern for separating contents (model) from presentation (view), and having a mechanism in place (controller) defining how to gather both.
If you already see where I am going at, I am very interested to hear your opinion on the matter. Of course, MVC applies to serverside mechanics and all, but think out of the box here with me for a second.
"Visitors" of the web, both human and robot/Google will be likely to see HTML and what comes with it. Writing structured and meaningful HTML, together with separating it from presentation using CSS has become more important over the years, and future technology such as HTML5 only contributes to this separation by offering a more content-focused set of elements, and mechanisms for working with the pure visual representation.
Considering all this, I was wondering if it would be correct in some way to say that the MVC paradigm applies to the front-end as well, where:
The model would be HTML, as in the pure httpwise contents that it has become
The view being CSS; it makes your content be presented a certain way
The controller being the webserver and all that lies underneath, it is what gathers and separates the model and view, and does all the decision making
Makes sense? Not?
VonC pointed me to an article that definitely changed my thoughts on the controller part. The browser takes up a major part of the controller too, as it handles a great deal of user interaction and how the model and view work together.
You can generally find MVC in anything if you look hard enough.
I would agree, although one can argue about the controller.
Jeff illustrates that point in his post, with ZenGarden
With:
Model = HTML
View = CSS
Controller = Browser (which is more 'front-end' than the web-server)
Actually, this is a valid perspective from the client-side.
From the server side (a server more complex than a simple html-page server), MVC would be different.
With ASP.Net for instance;
Model = all of your application logic that is not contained in a view or a controller. The model should contain all of your application business logic and database access logic. For example, if you are using LINQ to SQL to access your database, then you would create your LINQ to SQL classes (your dbml file) in the Models folder
View = HTML markup and content that is sent to the browser, plus scripts
Controller = responsible for controlling the way that a user interacts with an MVC application. A controller determines what response to send back to a user when a user makes a browser request.A controller is just a class (for example, a Visual Basic or C# class).
That is a services-ide perspective of MVC
No, sort of...
Your HTML is also at your presentation layer (View), although your CSS should contain the presentational specifics like fonts, colors etc.
Your Model must contain your data + business logic, and I really don't hope that you'll want to store these in HTML - that's for real programming languages, stored procedures and a DBMS to handle. And these should be at server side.
But to follow your line of thinking, I would suggest:
Model: Server side programs + DBMS
View: HTML+CSS
Controller: Webserver
I can see your point, but I think I would describe HTML-CSS-Server/Browser more as Document-Viewer rather than MVC. If all of the content is static then it is an expression of the model, true, but the model is embedded in mark up. Even though I can override it with CSS, CSS is really just a filter on the underlying presentation described in HTML. The HTML describes a view of the data as well as the data itself. To wit, I can turn off CSS and I still have a view of the data. In MVC, this is not possible.
There is also a close coupling between your HTML and your CSS -- both need to be very aware of the other. This violates a key paradigm of MVC where the components are loosely coupled. In particular the view enforces no constraints on the model (other than the restriction that the data be viewable). HTML designers are constrained to operate within the domain of the CSS or to modify the CSS to make it applicable to the domain of the HTML.
Further, HTML has no way of operating on the data to make persistent changes. A key aspect of the model is the ability to enforce business rules. HTML does not do this with static content -- the web designer does by the choice of the HTML encoding.
This doesn't make it bad, or not useful. Not everything has to be MVC. MVC simply describes one particular way of organizing your data and code. It has some particular advantages with respect to decoupled architecture and testability, but that doesn't mean that it is the only valid architectural pattern available.
Static HTML content, in my opinion, isn't MVC and doesn't need to be.
[EDIT] I am not arguing that you can't use MVC in the design of a browser, or that MVC isn't applicable to the the display of static content in a browser. I'm really looking at this from the perspective of the content provider, not the browser programmer. MVC could be a perfectly logical choice for browser design.
CSS is definietely not the view. Rather the rendering by the browser (which combines HTML/DOM and CSS input into a 2d layout) is the view. The HTML/DOM is the model. The controller is halfway built into the browser UI, but can be extended with javascript.
It is true that CSS is considered the presentation layer when talking about the content/presentation seperation - however that is a different (orthogonal) model.
In MVC, CSS is part of the model along with HTML/DOM because it is the underlying data which can be rendered in different views. For example, a print layout is a seperate view based on the same model.
Related
First, a short disclaimer. I have next to no knowledge about web applications. I come from an iOS background where I exclusively wrote native code, so if you write your answers like I know nothing outside the shallow parts, that would be great.
I'm interested in learning a stack to develop web applications, but I'm not sure what the right way to build the GUI is. I know that a web front end consists of html and CSS to create the display and javascript as the bridge between the back end and the GUI, but I don't know the best way to put something together.
I know in iOS, you can use the Interface Builder (part of xcode that lets you graphically create the xml that describes the display) to create GUI's without any knowledge of how iOS translates the xml to some rendering, or even what is written in your xml files. Is there any analog to the web front end?
I'm mainly just looking for a list of the accepted ways to develop the GUI for a web application. If I have to learn HTML and CSS, so be it, but I'd like to know what my options are and the tradeoffs between each of them.
I can answer shortly stating that (technically) you can design web pages without coding in HTML or CSS, or even Javascript - although, you would be somewhat limited in your creative abilities and applications.
You can read about WYSIWYG html editors on this link, or try out ckeditor (someone said it's good)...
...I think a bit of background will help you reach a correct decision...
so here goes:
The Long Answer
I would start by trying to put the world of web programming and design into concepts that correlate with iOS coding.
If we look at the whole of a web app from an MVC perspective, then the browser is the view, the server is the controller and the database is the model... although this is very simplified.
Just like in iOS, each of these can be (but doesn't have to be) broken down into sub-MVC systems.
Just like any model in MVC, the view (the browser) can talk to the model (the database), but really it shouldn't. that's just bad practice.
If we break down the main-view (the browser) to a sub-MVC system, I would consider the HTML as the model, the CSS as the view and the browser (through links and javascript) as the controller.
It's not all that clear cut, but thinking like this helps me practice better and cleaner coding.
The HTML is the view's model for the web-app - it contains the data to be displayed or used.
HTML is a variation on the XML format and it contains data organized in a similar way to an XML file.
The basic HTML file will contain:
<html>
<head>
</head>
<body>
</body>
</html>
this should look familiar to you if you read any XML.
The CSS (cascading style sheets) is the view - it states HOW the html DATA should be displayed.
if your web app does't have any CSS, it will use the browser's default CSS/styling to be applied on the data in the HTML.
This "language" makes me think more about dictionaries in iOS (I think that's what they're called in Objective C). They have properties and values (like key-value pairs) that determine how the HTML data is displayed (if it's displayed).
They could look something like this:
body
{
color: white;
background-color: black
}
The browser is the web-app's view's controller - it makes it all work together and serves it up to the screen.
Javascript and links help us tell the controller what we want it to do, but it is the browser that acts (and willfully at times).
You can have a whole web app that acts without javascript, using only the default actions offered by links - in which case the browser will usually ask the server (the main controller) what to do.
Javascript helps us move some of the legwork from the server to the client, by allowing us to have a "smarter" controller for our view - just like in iOS.
The issue of the errant main-view / browser
Not all views are created equal, and not all browsers are the same.
Because the browser is used as the controller for the web-app's view, and because some browsers act differently then others, we web coders have the problem of working around someone else's idea of how our view's controller should behave.
You might see us complaining about it quite a lot (especially complaining about Internet Explorer).
These days, this issue is not as big of a problem as it used to be... it's just that some people don't update their computers...
WYSIWYG web editors
There are website builders and editors that try to work like X-Code does, by allowing us to build the website much like we would write word documents.
But, unlike X-Code which codes only the graphical interface of the view, these website builders write the model as well and usually add javascript into the mix.
When we use these tools (which I avoid), the whole MVC model breaks apart.
We can use them as a starting point for dirty work, but then we take their code apart and adjust it to our needs - usually by taking the code we need for the view (CSS) and applying it where we need it (and discarding much of the nonsense they add to the code and the HTML).
To summarize
As you can tell, HTML and CSS (and Javascript) are only a small part of a web app - as they all relate to the main view of the web app.
To write the controller and models for web apps, we use other tools (such as Ruby, PHP, js.node, MySQL and the like).
Coding the HTML and CSS isn't as hard as you might think, although it might be harder then I present it to be.
You can avoid writing code for web apps and use applications that offer WYSIWYG (What You See Is What You Get), but that would limit your abilities and will take away from your control over what you want to create.
I would like to development a set of HTML components that can be reused across a set of applications developed by many of our business partners (both internal and external do our domain). For example, I would like to develop a 'graph' widget that takes care of all the details around retrieving data, plotting on a chart and so on. Then a business partner can 'reference' this component and embed it within their web application. I logically visualize this as the partner being able to link to the component and the component returns with all the details in between. Traditional ways of doing this leveraged IFrames but we do not want to utilize this approach for internal reason.
Are there existing frameworks that allow that allow this?
I'm aware of all the XSS and it seems it's possible to do if I leverage CORS. Are there other security (or other aspects) I need to be aware of?
To simply the question, is there a way a client can make an http call out to my service, and my service returns HTML fragment (including whatever required css/js needed to render the html).
Thanks in advance.
With pure HTML, this is not possible; HTML is simply a markup language, and is not extensible.
However, XHTML is extensible (see: Developing DTDs with defined and extended modules).
You could also utilize CSS and/or JavaScript files (which your business partner could reference with <link> and <script> elements, respectively), which could modify the appearance (CSS) and behavior (JS) of normal HTML. There are a number of libraries using these techniques already which you could potentially use. For example, Kendo can transform your "normal" HTML elements into something feature-rich.
I'm currently evaluating the use of Backbone.js along with Aura.js for building an enterprise scale SPA.
I have a nice Javascript architecture mapped out that provides abstraction, consistency, flexibility and no dependencies on any base libraries.
As I see it, in using any MV* pattern (and in particular Backbone), markup generation could be scattered throughout views via a combination of direct dom manipulation and external html templates.
I would like to apply the same principles to the html markup in my views as I have with my Javascript architecture.
Abstraction - Ideally I would like to provide developers with a simplified API for producing markup, potentially shielding them away from the css classes/markup structure being used.
Consistency - I would like to promote and control consistency in the markup produced within a team of developers.
Flexibility - I would like to avoid having to find and completely rewrite all instances of certain markup if there comes a need to change either the css classes/markup structure being used. Ideally I'd like any changes to be made in one place, that will propagate throughout all uses within the system.
As a practical example of how this can be achieved server-side, we currently use a suite of custom HtmlHelpers within ASP.NET MVC (similar in design to KendoUI). These helpers provide a nice fluent API for developers to use and centralise control of the markup that is generated.
However as we're moving towards client-side UI generation I'm not sure how to gain the same benefits that are available in server-side markup generation.
I appreciate templates can provide re-usable widgets throughout the UI, however that does not completely address the issues outlined above, which apply when creating those templates and the layout to contain them.
So to summarise my question...
What practices can be employed to achieve control and consistency in markup generation within a team when developing enterprise scale SPAs?
Since your question is limited to Backbone.js and Aura, I'm not sure this qualifies as an answer, but I would definitely check 3 things
AngularJS and AngularUI - the concept of directives, resembles the notion of Web Components (a work in progress W3C standard for web controls)
If you like typed coding, and likes to live on the bleeding edge, check Dart Web UI it also uses a pretty much similar concept
If you have to stay in Backbone land, then I would check Backbone UI of course
I believe the first 2 have a better chance of answering your 3 requirements.
We are about to break our controllers up: actions that return semi-static HTML pages, actions that return JSON ViewModels and finally actions that post changes. We plan on using JSON.NET to do the JSON serialization since it supports a spiffy LINQ-like syntax for creating complex JSON objects. We will use jQuery+AJAX to call the JSON actions and use the results to replace elements in the HTML.
Before, we were passing ViewModels to the View() method and using it with Razor to fill in the screens. So the real big difference is that our view models will be JSON objects and JavaScript will be building the pages. The problem with the Razor syntax was that it was acting as a crutch. A lot of times we were mangling Razor and JavaScript (Frankenstein). Plus, a few pages take long enough to load that some sort of up-front feedback is needed anyway (loading...).
To the question: I have been looking at my code and have noticed that many ViewModels share common properties. Furthermore, the same logic is appearing across multiple controllers. I have been wondering what patterns/tools are out there for putting this logic into one place. Also, should I be trying to create a "master" ViewModel with child ViewModels (with other child ViewModels and so on)? The idea being that some elements are shared across all pages (such as header and footer content) and so it would seem to make sense to have a common ViewModel structure for each page. That way I can reuse the some JavaScript for finding data and setting it in the HTML. I figure if a page doesn't use a child ViewModel, I would just pass null, so it wouldn't take up too much space.
I want to make sure that I get things right before I start going down this new path. I have seen applications that use the hierarchy of ViewModels before and have seen problems because of it. I also want to keep the number of AJAX calls down, so I want to return as much data as possible in as few calls as possible. They are kind of contradicting requirements. I was hoping someone had experience with building lots of ViewModels and and with converting these to JSON objects for consumption on the client side. I was also curious if anyone found any tools for JavaScript for building pages from ViewModels. We are looking at backbone.js right now, but it seems oriented towards forms rather than generic content generation.
The idea being that some elements are shared across all pages (such as header and footer content) and so it would seem to make sense to have a common ViewModel structure for each page.
You should consider using partial views and master pages to accomplish this if you aren't already. Both are very useful and powerful tools.
I was also curious if anyone found any tools for JavaScript for building pages from ViewModels.
An extremely powerful JavaScript library that uses the MVVM pattern is Knockout.js. The twenty minute introduction video on the home page explains it very clearly.
Summary for the impatient:
What I want to know is what you want to have in a new gui language. About the short answers mentioning $your_favorite_one; I assume you mean that, such a language should look like $your_favorite_one. These are not helpful. Resist the temptation.
I'm thinking on the user friendliness of XML based languages such as XHTML (or HTML, although not XML they are very similar), XUL, MXML and others ("others" in this context means that, I am aware of the existence of other languages and their implementations alternative to their original ones, and the purpose of the mentioning only these languages by name is, to give an idea of what I am talking about and I don't feel like mentioning any others and also, I see no point in trying to make a comprehensive list anyway.). I have some opinions about what features should such a language have;
The language should be "human writable" such that, an average developer should be able to code a good amount without constantly referring which tags have which properties, what is allowed inside what. XHTML/HTML is the best one in this regard.
There should be good collection of controls built-in for common tasks. XHTML/HTML just sucks here.
It should be able to be styled with css-like language (with respect to functionality). It should be easy to separate concerns about the structure and eye-candy. Layout algorithm of this combined whole should be simple and intuitive. Why the hell float removes the element from the layout? Why there is not a layout:not-included or something similar instead?
I know that I don't even mention very important design considerations like interaction with rendering engine and other general purpose languages, data binding, strict XML compliance (ability to define new tags? without namespaces?) but these are the points that I would like to ask what you consider important for such a language?
There will always be a tradeoff between ability and simplicity.
Personally I'm happy with the features of WPF (which uses XAML) for MS development. I dont find its complexity to be a barrier to developement at all.
However if your going to target your toolkit/language to a demographic that requires a higher degree of simplicity, you could possibly get away with leveraging an existing framework and provide the end user with a DSL specific to their needs.
Writing a new framework for the dev community as a whole is a mammoth undertaking though, and I suspect you will find that due to the wide range of features required that you will have to deal with a large degree of complexity at some point. Best of luck.
Most recent XML GUI language (not only for GUI actually) is called XAML. It has all that candies: styles, layout definition, objects initialization, etc. But it's a pain to write more or less large XAML files. Auto-completion helps but the core problem - forest of angle brackets - is not solved. Another problem with advanced XML-based GUI langs - they try to serve to several purposes at once, but XML syntax is not suitable for all situations. For example XAML supports data-binding, but why the hell I should write it in attribute string? It's first class feature and should have proper support.
IMO all modern XML-based langs suck terribly. Language intended for humans must not force it's users to write tons of brackets or do deep tags nesting. It must be user friendly, not computer friendly. My dream it to have GUI language with Python-like syntax.
In conclusion I want to say:
Dear XML-based langs authors, please be humane, don't create another language based on XML. Read some good book on Domain Specific Languages and please, don't make me type < and > symbols ever again.
You should have specified whether you mean web or rich client, but either way take a look at XAML/WPF. If you're anti-MS, then look at Moonlight, the Mono implementation of SilverLight.
I would like it to be easy to connect to any database, perform queries that return a recordset, and be able to parse and iterate easily said recordset to display its data in graphic controls, for example pie-charts, bar-charts, timeline charts (stock options like), node graphs with animation effects, all this at run time.
Easy mouse events catching, to implement any action on rollovers, mouseins, mouseouts, clicks, drag and drops, clipboard management, etc. A good infinite zooming capability would be great too.
I don't want to set a "datasource" that establishes a fixed connection between some column in my SQL query and some displayable element at design time, I want to perform any query that I want and show elements tied to any query field, anytime, in run time. I don't want to be only able to bind a datasource and displayable elements at design time.
css style capability for everything. Or something as simple and easy.
resize and layout taken care of automatically. Easy access to local files, to parse, play, display. Easy classes for image management, supporting transparency, resizing, etc. Basic and advanced classes for drawing in the screen: lineTo, rectangle, circle, animations. Even 3D.
Embedded fonts functionality. I don't want to worry about "will the user have this font installed?" Also I don't want to worry about DPI or screen resolutions.
Basic widgets: treeviews, etc.
A good designer. I don't want to add widgets writing the code. I want to place them visually in the screen.
Also, it would be good if it could connect to dlls made in C++ or COM objects in general.