HTML5 MVC
A simple, lightweight, DOM Centric MVC framework to build high-end HTML5 applications. Perfect for Bootstrap.
HTML5 Server
A lightweight and powerful Java web framework based on Google Guice. It brings the productivity of PHP/Ruby to the Java world, the Java way (thanks to Google Guice for dependency injections and snow for web bindings to Java).
Building Enterprise HTML5 Application
Choosing the right HTML5 technologies for your Web and Mobile Application. (jQuery, Bootstrap, brite. js, Sencha, jQueryMobile, or Angularjs?)
Given the profusion of HTML5 libraries and frameworks, choosing the right HTML5 technologies for your HTML5 application could be a daunting task. At BriteSnow, we build high-end HTML5 applications for a living, and our two main guidelines to select HTML5 technologies are as follows:
Keep things simple and HTML by using libraries and frameworks that help normalize and modularize HTML, CSS, and JavaScript into well-architected application parts rather than ones that try to provide heavy abstractions. Used the right way, the DOM can be a great foundation to build advanced applications; too many frameworks (especially MVC frameworks) try to bring native/widget patterns to HTML rather than rethinking the way the DOM environment can be extented into a MVC platform. Frameworks that shield the application code too much from HTML tend to make the application much more difficult to customize, enhance, and optimize down the road (i. e. easy to start, difficult to finish). A good understanding of HTML, CSS, and JavaScript is always required to build high-end HTML5 applications; thus, libraries and frameworks that embrace HTML are better than those that try too hard to shield you from HTML coding.
Avoid touch or mobile only frameworks (i. e. avoid device-specific HTML5 frameworks) because having different technology stacks per HTML5 device type removes the core benefits of HTML5. Yes, an application might have a different facade or even behavior depending on form factor and input type (usually a mobile phone on one side, and a tablet/PC Web on the other), but it should not (must not) require two different tech stacks, let alone rewriting the application twice. Writing two applications, one for Touch and one for PC Web, does not make sense, especially when you consider that the appropriate split is often between a smart phone on one side and a tablet/PC on the other. In other words, Touch is just another input mechanism and should not be a factor in splitting the technology stack or application code.
Following these two main principles, here are list of good technologies to use versus riskier ones.
jQuery (core) is a very mature and efficient way to query, access, and modify the DOM. jQuery is not a framework but more of a DOM DSL (domain specific language). Because jQuery is a lower level and well optimized, it works great for mobile, tablets, and PC HTML5.
Bootstrap (formally Twitter/bootstrap) is a very well thought out HTML/CSS structure with default styling that is the perfect basis for starting small or large scale HTML5 applications. It also decouples HTML/CSS from JavaScript well, which allows implementation of completely custom behavior while re-using the bootstrap HTML element structure and style
lesscss or SASS are both efficient and flexible ways to componentize your CSS into reusable “macros.” It does so by extending the CSS language rather than replacing it. Bootstrap uses LESSCSS extensively, and for advanced applications, it is a great way to write advanced and reusable CSS directives while keeping the HTML structure clean and simple. Bootstrap also provides a very useful set of mixins in their “mixins. less,” which could be a great time (and bug) saver for common CSS3 directives. SASS is similar and is a good technology as well, but we are not using it because of its Ruby dependency and the fact that Bootstrap chose LESSCSS. LESSCSS is JavaScript-based, which is great for client-only development as well for Java Server integration (Snow supports. less automatic server side compilation and caching).
brite. js* is a lightweight DOM Centric MVC that turns the DOM environment into a simple and powerful MVC foundation. It has a similar approach to backbone. js, but it is more tailored to high-end applications as it provides a fully asynchronous view life cycle as well as a powerful and asynchronous DAO model.
* Disclaimer: We are the creators of brite. js, which we have been using for the last 3 years to build high-end HTML5 applications. We finally had time to document it. If you have any question, feel free to drop a line below or on any of the brite pages; we always respond within a few hours.
On the other hand, based on our experience, here are the more high-risk HTML5 technology and JavaScript Frameworks:
Sencha Touch or Sencha ExtJS . While both of these frameworks might look fancy and attractive, Sencha breaks both of our guidelines. First, both are mega-frameworks that redefine everything from UI, Layout, and even OO in JavaScript. Consequently, they remove the application code too much from HTML, CSS, and JavaScript. The result is a highly framework-dependent application code that can be very difficult to optimize and maintain overtime, even if it was fun at the beginning. Second, it also breaks the “avoid device-specific HTML5 framework” guideline. This is likely the most important reason why a developer should use caution in selecting this type of framework.
jQuery Mobile and jQuery UI . Like the Sencha frameworks, these also break the “avoid device-specific framework” guidelines. Second, although they both seem more HTML-oriented than Sencha frameworks, their design relies on a heavy post - HTML processing and CSS class manipulation, which significantly impacts application performance as well as styling and customization. We also found that jQuery Mobile has some serious design flaws, such as the page model, which makes writing large-scale responsive applications very difficult.
Ember. js and Angular. js . Both of this frameworks share the same “binding-aware templating” approach, and though we find them interesting, we think they actually promote bad patterns to build HTML5 applications for the following two reasons. First, this type of framework places too much responsibility on the templating side, which ends up commingling the responsibilities (e. g. Model, Data, Binding, and View) into one layer. Good code design is about good partitioning, and moving all the complexity from one side (JavaScript) to another side (templates) does not really solve the code complexity issue and can actually make it worse (templates become very difficult to read and maintain). Second—and this is especially true for Angular. js as it is a bigger framework—they tend to remove the application code far from the DOM, and while it might look attractive at first, we think a good understanding and control of the DOM is the crux of writing good HTML5 applications. It is one thing to have an application declarative UI language such as “Adobe Flex” in a Flash, native, or even Java environment, but bringing it to the DOM is like fitting a round peg into a square hole. You could make it fit, but it is not the most efficient way to go about it.
So this was our brief guide to choosing robust, simple, and future proof HTML5 technology. There is much more information on the subject, and if you have any further questions, issues, or even disagreements, feel free to drop a line below; we always respond within a few hours.
Note: If you liked this article and have a Hacker News account, a +1 on HN would be greatly appreciated.
Step 3) Adding the DAOs
Abstracting the application logic from the data access layer is critical for real HTML5 applications. brite accomplishes this by offering an asynchronous and pluggable DAO (Data Access Object) model. brite DAO model provides an asynchronous (with jQuery. Deferred ) CRUD access layer and a powerful eventing system (jQuery like syntax, and actually jQuery backed as well).
For this step, we will just replace the static data by the brite DAO access layer. We will use the provided InMemory Dao Handler (brite. InMemoryDaoHandler), but this can be easily switched to any custom remote or local storage DAO implementation later without changing the application UI code.
The application will look like the step #2, but with a completely asynchronous and plugable data access model.
Registering the DAO with the brite. InMemoryDaoHandler
For the taskmanager application, we have two DAOs, one for each entity type, Project and Task . Both of these DAOs backed by the provided brite in-memory DAOHandler brite. InMemoryDaoHandler .
The TaskManager DAOs created by registering their DAOHandler instance with brite. registerDAO(new DAOHandler(entityType)) as follow:
Entity DAOs obey to the singleton pattern, meaning they can be reused many times, which is why we can store their reference in main. projectDao and main. taskDao for future access.
Making the ProjectListNav view DAO aware
Now that the data will be accessed asynchronously via the brite dao asynchronous (jQuery. Deferred based) API, we cannot render the HTMLs like this:
So, to render the list of project HTML elements, we will need to do it asynchronously. The code will look something like this:
Here, we are using the previously registered main. projectDao. call the. list CRUD API implemented by the brite. InMemoryDaoHandler. which returns a jQuery. Deferred promise that will resolve with the project List. In the done function, we can then render the HTML.
There are many ways to support asynchronous APIs in brite Views. For ProjectListNav . the strategy is to first display the static part of the view right away, and then, on. postDisplay to get the list of projects and refresh the. list-container element with the sub template ProjectListNav-list .
For this, we just need to change the view HTML template a little, by adding a container HTMLElement (.list-container) and creating a sub-template ProjectListNav-list. add a container HTMLElement in the template that we will refresh.
Note The data-entity="Project" data-entity-id=" >" attributes at the li elements is probably the simplest but most important technic of a DOM centric programming style, which is to embed entity reference (type and id) at the outter most HTML Element of the entity representation. By doing so, any user interface interaction at the DOM level can be easily related to the corresponding entity without any complex and costly binding. For example, any logic for entity selection, deletion, or even modification can be completely generic and implemented in delegated way, and the logic just have to do a $element. closest("[data-entity]") to identify which enitity this particular action applies to.
Then, on the JavaScript side, we will just render the top template first, and refresh the project list on postDisplay .
Note that we could have made the code much shorter by not splitting out the refresh list in its own method, but this will become handy later when integrating with application and data events.
Making the ProjectView DAO aware
Similarly, making the ProjectView DAO aware is trivial. For the sake of this tutorial, we will use another strategy to display the asynchronous content for ProjectView, by using the asynchronous nature of the brite view lifecycle management, which allows the. create method of a view to return a jQuery. Deferred promise (which must resolved with the intended HTMLElement result) rather than the direct HTMLElement result.
So, on create. we will first get the Project from the DAO, and then return a jQuery. Promise using the jQuery. Deferred. pipe method that will resolve in the view HTML. Then, in the postDisplay we will call the refreshTable private method which will call the taskDao to get the list of task and refresh the UI sub elements.
This Deferred code might look a little overwhelming at first, but learning asynchronous JavaScript programming is critical to build simple, scalable, and powerful HTML5 application code. Once mastered, making or using asynchronous APIs become almost as trivial as direct calls but unleash a new level of capabilities.
On the templating side, we also need to do some refactoring to split the task list as a sub template. This will allow, in the later steps to refresh the task list without refreshing the full view.
Step 2 - The Sub Views Step 4 - Adding Events
Step 1) The First View
The first step is to implement the skeleton of the application, meaning setting up the code structure, main components, basic layout, and the minimal dataset sample, and the core views.
Code Structure
bootstrap/ . Twitter/Boostrap is a very well thoughtout HTML/CSS boostrap libraries which is very complementary to brite. We use it in most of our projects. The best practice is to put in its own folder, so that it is easy to update it overtime (without having pick and replace in the common /css and /js folders)
css/ . Here are the common css files for the application. By convention CSS files starting with UpperCase are View css files (as any other view file assets), and other are generic css ones. Here we can main. css as the generic css file for this application that will be included after the boostrap css (see the index. html), and the first view's css file MainView. css.
js/ . Here are the common javascript files for the application and the View javascript files with the same convention as the css ones. jquery is brite only dependency, and we also use Handlerbars. js as templating engine, as it is a well known, performant, extensible, and string based templating engine (but brite. js does not didacte any particular templating engine, and developers can even choose binding aware templating engine).
tmpl/ . Here are the View template files. They are regular HTML templates wrapped in a <script name="tmpl-ViewName" type="text/html"> tag and obviously need to be of the syntax of the templating engine used (in this case Handlebars. js syntax).
index. html . And finally, the index. html file that will start everything and call the first View with brite. display("MainView". )
As shown above, the convention is that all view's asset files (.css. js. tmpl) start with UpperCase. This makes it easier to distinguish view files from other files, and also match the "Object Type" nature of those assets.
Index. html
In brite, applications are mostly single page based, and consequenlty the index. html is just about including the appropriate css and javascript libraries. In this step, it will include, jQuery, brite, bootstrap, and the main. js and main. css which will be the top css and javascript file for the applications. (see the tutorial-01 index. html for full code).
And, the HTML body content code is extremely simple, and just contains the following couple of tags:
And finally, we just display the main view MainView inside the top div #pageBody with the following code.
main. js
Next, we will create the main. js which will have all the necessary logic to intialize and start the application. By convention, we do not put script tags in the HTML files anymore, but rather put them in their own files, as this make the application code more structure and flexible, as well as making it Chrome App ready (Chrome App does not support script tags in html pages).
The first thing we will do is tell brite to load the view. tmpl and. css on demand (as they are first needed) by setting the brite. viewDefaultConfig properties as follow.
This is extremely convenient for developement, especially for large project, as there is no central registry places that keeps conflicting when merging branches. The default of these properties are false, which is usually used in production environment.
brite. js also allow to set this properties at a view level, see the brite. registerView API for more information.
Then, when the document is ready, we just need to call brite. display to display the MainView which will in turn display the sub views.
Additionaly, we will implement an extremely simple wrapper for handlebars which is highly recommended as it will become very handy later if the application have to support pre-compiled templates or even another templating engine. Also, note that this render(. ) will be called from the views create methods and that since we set the. loadTmpl=true the HTML content will be in the DOM and ready to be compiled.
Note As a general practice, application developers should never hesitate twice to write simple framework or library wrappers. While framework people might not recommend it, we actually think it is a very efficient way to build more flexibile application code.
MainView
To define the MainView a brite. regiterView("MainView". in the index. html head tag would suffice, but for this application we want to take advantage of Brite View assets componentization, and therefore, we will create the three typical following view files.
The first file is the JavaScript file that will define the View, and by convention should be at /js/[ViewName].js and will look like this.
The create method just get the HTML template element with the id format as tmpl-[ViewName] and return the content of it.
By convention, the MainView HTML template will be located in the /tmpl/[MainView].tmpl and will start with a first element with a css class name of class="[ViewName]" such as
And finally, the optional but often recommended view css file would be located at /css/[MainView].css and will prefix its css rules with ".MainView-___" or "MainView .___" as:
By convention all View top template id are with the the format id='tmpl-[ViewName]'. and the top HTML element as for css class name class="[ViewName]". If a view as sub templates, then, the id format look like id='tmpl-[ViewName]-[subTemplateName]'. Also the other convention is that main sub-elements css class name can be prefixed with '[ViewName]-' to allow simple selectors in the component css (but this convention is pretty flexible).
Step 0 - The Application Step 2 - The Sub Views
Recommended Reviews
This laundromat has 2 locations, i take my laundry to the one on PCH usually, but last week i was near this place at the Ralphs plaza & decided to drop off some dress shirts that i literally needed within hours - I dropped my shirts off around 9:30am and they were ready by 4pm.
1 check-in First to Review
Convenient to where i live and go to school. I was nervous at first considering the store before had some gnarly reviews. But. they altered my friends dress really nice. I had a 20% discount coupon as well. the hem work was really really nice. I would definitely entrust them for my future cleaning and alterations.
No comments:
Post a Comment