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.
Related
I plan on making an advance form system cms for company use. The options I found are WPF, winforms or to render it in HTML on an offline application.
I have varying level of experience with the first 2 but the third one I never came across until recently while researching this topic but (unless I'm poorly searching for it) I can not seem to find much info for it. I also need this system to dynamically create each form via code.
My question is for my situation, which would you choose and also explain a little more about HTML rendering method and how to create this type of system.
We aren't building your system so can't advise what you should do
Winforms
Pros
Classic structure so easy to pick up if you are familiar with classic desktop development
Cons
Rigid structure controls functions and appearance are closely coupled meaning doing anything none standard is difficult
WPF
Pros
Loosely Coupled function and appearance, this means that you can customise pretty much every element of the controls similar to CSS
High automation level, binding is built in as a fundamental function
Cons
very different to Classic structure as MVVM style is almost required, trying to do anything with out it is a very bad idea, meaning it can be hard to pick up
HTML
Pro
Easy to build for anyone familiar with Web development
Con
HTML is designed to be used online this means that any offline html system will require you to reinvent the wheel to circumvent the normal online behaviour (if you go down this route I would highly suggest an online intranet site rather than a offline system)
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.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Recently my company has decided to rebuild an enterprise portal, which will be used by people across the globe to resister there product for extended warranty. They have come up with J2EE ( spring MVC ) and Oracle as technology stack for the Business layer, and have decided to use JSF (java server faces) to design the front-end stuff ( User Interface) I am, being Frontend Engineer, want appose JSF since it will give less control over the generated markup to me, also JSF will inject/generate unnecessary markup in to the page, which will act as unhealthy food for the browser. Also it will become difficult to achieve the Browser Compatibility, since I don’t have any control over the markup generated It is hard to apply correct CSS behavior. Also it not possible to use concept like fluid layout , table less layouts.
All this will result in poor User Experience. My idea is developed UI with hand coded HTML then convert those .html files in to JSP’s and plug those JSP’s in Spring MVC architecture.
Having said all this, I need to present a proposal which will justify the replacement of JSF by HTML for UI layer, your inputs/thoughts and suggestions will valuable, please write back.
Also, I don’t believe XHTML as other option, it has to be HTML? Let me know what do you think and what makes you think that way?
Thanks, for stopping by. I do apologies if reading all this has taken a lot of your time.
What you are stating is true when you're using vintage JSF 1.0/1.1 API with "pure" JSF components. There was no builtin component with which you can represent a HTML <div> element (so that you can accomplish the general page layout on a semantic manner). Also, embedding "plain" HTML in a JSF page was a pain because it got rendered outside and before the JSF component tree. You have to put plain HTML in <f:verbatim> tags over all place. The purists and the unawareness are less or more forced to use <h:panelGrid> (which renders a <table>) to position the elements in the page.
Apart from that, during the early JSF ages, Netbeans shipped with a builtin visual JSF editor which enables you drag'n'drop and bind JSF components visually without the need to write any line of code. This obviously generates a lot of at first sight unnecessary and unmaintainable code and the pixel-precise positioning of the elements were "behind the scenes" achieved with a <h:panelGrid>. Those kind of JSF applications are in view of maintainability and web semanticity a complete disaster.
Most of the negative stories you'll hear about JSF with regard to front end development is related to this. Most of the JSF users/observers/ranters from then are currently still blindly focusing on this because of the bad experience they had and/or they think that JSF is nowadays still the same and/or they see the visual editor as part of JSF while it's "just" another (bad) tool. Also most of the ones who says "JSF sucks" are usually ones who started using it with a visual / drag'n'drop editor without having any solid background knowledge of what's happening under the hoods (especially Servlet API!).
Since JSF 1.2 (which is already over 4 years ago released btw), the <h:panelGroup> component got an extra attribute: layout="block" which will let it (finally) render a fullworthy HTML <div> element so that you can bring a more semantic layout using JSF components only. But it's not only that, JSF 1.2 also comes with an improved view handler which enables embedding plain HTML in line among other JSF components without hassling with <f:verbatim> tags. You could nicely put <div> elements around where you want without adding more verbosity.
Even though this was a major improvement, there were still two other major (however not directly UI related) problems with the standard JSF implementation: 1) state management among requests is hard without grabbing the session scope (think of preserving the same data in tables and dropdowns and the conditions of e.g. rendered attribute); 2) everything goes through POST and you can't nicely invoke JSFish actions through GET.
Since JSF 2.0, which is almost already 1 year old, those problems were covered with a new scope, the view scope, and a new set of components for GET actions. Plus, JSP is replaced by Facelets as default view technology. Facelets greatly eases templating and creating composite components without having to resort with raw Java code and/or custom components/renderers. Even though it's XHTML based, it can perfectly render a HTML5 valid respone with just <!DOCTYPE html>. The XHTML is just there because Facelets is under the hoods using a XML based tool to generate the (X)HTML output. The XHTML based templating does in no way imply that it can only emit XHTML/XML.
All with all, your markup concerns are a non-issue when you're using JSF 1.2 or newer and also XHTML (Facelets) shouldn't be an issue since it can perfectly render HTML5 valid markup.
JSF gives you lot of predefined, rich controls that offer functionality would have to implement manually otherwise. The price for it is giving up control to certain degree in how user interact with the application and about HTML generated. It can also stand in the way of integration with JS libraries.
Debugging and testing is considerably simpler with JSP and specially with Spring.
It really depends on feature set of your web site, skills in the implementation team (and support team), time to deliver constraints, etc.
I personally prefer simpler technologies that give more control to the developer (JSP with Spring MVC) just for the internal elegance of the framework but that is never deciding factor ....
I did a stint as a UI Engineer for Barclays, a global bank. Now, I'll be the first to say that the financial industry has a long way to go when it comes to User Interface anything, and Barclays in particular is behind on their technology. That being said, they do know how to build things that effectively and reliably work, and the UI Lead is one of the most amazing minds I've ever had the opportunity to work with. Also, being a bank they are sticklers for compliance.
We were using exactly the alternative you proposed, and it worked well for us. Sites reliably handled millions of users daily with no negative outcomes. UI work was simple, and as a bonus when the Federal Card act came along, the company could hire basic web folks to come in and do the cutup/html work which engineers could then bolt into the system.
As for your XHTML question, ultimately we chose to go HTML 4.01 strict, and here's why: First, w3 has decided not to advance the XHTML working group...in essence, it's on its way to a slow death. Secondly, 4.01 strict is the closest to the HTML5 standard, and can fairly easily be adapted once 5 support becomes more widespread. A hard requirement for us was full compatibility on IE6, and this allowed us to achieve that goal.
In your negotiations, I would personally argue that it's vital that the final product meet current web standards (W3) because that makes it most possible to achieve a site that is compatible with browsers out there (I say most possible because I'm convinced that Microsoft with find a way, somehow, to break everything that I build eventually...it's how they roll) Secondary for your site might be SEO concerns with non-compliant code, and hindrances to accessibility such as screen reader support. You might also try outputting two similar (simple) sites using either technology and do an analysis of performance. In the case of one website I worked on that was served 1 million times per day, a 5k file size savings translated to 5gb of data daily.
Good luck! This is just one of many reason I got away from big corporate jobs using Java and Oracle....
I think jQuery based components coupled with an action based framework are the way to go. You get complete control over the page, very few surprises, fast development, and ultimately faster page performance.
I've built apps with both JSF, and MS ASPX + DevExpress components. In the end I just want more control over what ends up on my page. jQuery is HUGELY popular, so there is no lack of JS talent in the market. Ajax is almost a no-brainer with jQuery too.
Also, for building database driven wep apps in Java nothing beats the speed of the Tagger Cat framework. It may be old school MVC, but it is seriously database focused, and nice to work with.
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.
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.