I am writing a software for a website where people can manage the website content. The interface is similar to Windows with all those windows floating around, click-able components, type-able text fields, etc. The admin interface is written in JavaScript, HTML and CSS. I'm wondering what kind of architecture should I apply to my admin system before it's too late (I've written some minor code so far).
For example, for the PHP back-end I'm using MVC, but what should I use for the client-side JavaScript admin system?
If you were developing an GWT application, you would automatically have an architecture. For custom JS, with AJAX calls a two-tier architecture would be more than sufficient. However, I prefer going the event-driven way, where I have a layer full of listeners and another layer of handlers. I use closures for the most part and use custom page-ids. Works like a charm. I rarely separate the AJAX calls out, owing to the single-threaded aspect of JS.
P.S: I had to use the term layers for lack of better alternative.
You can use an MVC on the browser too.
But it may be overkill.
The minimum you can do is to separate the HTML(view) and the JS(logic) code.
We use a javascript templating engine (PURE) for our JS app, but there are plenty of other available on the web.
jQuery and jQuery UI are a good start.
Have a look at JavaScriptMVC. It's an MVC framework for front end JavaScript applications. Version 2 is jQuery based so you'll get the power of that fantastic library into the bargain
Related
On one of my ongoing web development projects, we need to create a page (really a mini-application of its own) which will have an interactive, "Web 2.0" interface, more like a graphical desktop application than a typical web page.
I'm hoping to use a higher-level language which can compile down to JS for the client-side logic, rather than programming directly in JS, and ClojureScript is my first choice.
I'm looking for a JS GUI library which can be used from within ClojureScript, and which supports a style of programming similar to "desktop" GUI libraries like Swing, QT, wxWidgets, and so on. It should allow me to create popup <div> "windows", put widgets such as buttons/labels/etc. in them, attach event handlers to the widgets, and so on. Do you know of one which would work?
Clojurescript is still young - I don't think there are mature frameworks of that caliber (yet?). Having said that, I'm building a UI using the following components:
Twitter Bootstrap + JQuery for visuals and UI elements
Chas Emerick's Friend for server-side authentication
Compojure + Ring + Jetty for the server
Crate (Clojurescript Hiccup) for html/dom generating
Jayq for JQuery wrapping
Fetch and/or Shoreleave's remotes for client-server RPC
Shoreleave's pubsub mechanism or Clojure's add-watch for data binding
A good feature of Clojure and Clojurescript are that they favour simple functions on generic data structures. That's why you tend to see several smaller libraries that do one specific job, but work really well together, as opposed to giant monolithic frameworks with an object model that requires you to adopt one way of thinking completely.
You should consider Google Closure Library. It has all features you ask and is definitely usable from ClojuresScript, I've played around with it. See http://closure-library.googlecode.com/svn-history/r1430/docs/index.html
I think ExtJS would fit the best in your case, even though this is pure JS. This is the most advanced web GUI library at the moment and it makes possible to create web applications the way similar the one using the desktop languages and IDEs. Just check out their demos. I don't think there will be something similar for the ClojureScript in the foreseen future.
I am planning to rewrite an existing Silverlight application using HTML, JavaScript and CSS. This will be a rich internet application connecting to a server only for data (JSON based web services) - so there will be no server-side presentation framework such as JSP or ASP.NET. The application consists of about 8 screens, most of them in a tabbed layout. The question is...
What is the best way to write such an application in a modular fashion? I would like to write the individual screens as standalone modules communicating with each other only via events. I would also like to use some sort of an MVC framework to decouple the presentation layer from the model.
Any thoughts on which frameworks I should look at? Have you had a good experience using them? I am starting to look at Backbone.js, JavaScriptMVC and SproutCore. Am I missing anything that is worth considering?
Thanks in advance for your time.
P.S. If you'd like to see the application that I am trying to rewrite, an online demo is available here - it is a realistic trading application built for learning and comparing technologies.
I haven't yet had a chance to try SproutCore, but I hear good things about it and want to look into it at some point. I would recommend trying out at least Backbone and Sproutcore to see which of the two fits your needs and your programming style better.
I do a lot of work with Backbone, and what your suggesting sounds like it would be a very easy fit with backbone. I follow an event-driven architecture with my backbone apps and I find it works very well. it keeps code clean and separated, and allows me to add functionality easily by binding to events that my objects raise.
there are a lot of great tutorials and screencasts for backbone out there, too. here a few of them that should hopefully give you some of the information you need (including my own blog posts):
http://lostechies.com/derickbailey/category/backbone/
http://lostechies.com/derickbailey/2011/07/19/references-routing-and-the-event-aggregator-coordinating-views-in-backbone-js/ (introduce event-driven apps in backbone)
http://joeybeninghove.com/2011/08/16/backbone-screencast-introduction-views/
http://peepcode.com/products/backbone-js ($)
http://tekpub.com/view/mvc3/6 ($ and specific to ASP.NET MVC integration)
again, don't just pick one and never look back. it's worth your time to at least do some simple trial applications in backbone and sproutcore, if not additional frameworks.
hope that helps.
With Sproutcore, you can create so-called frameworks so separate your application. Every SC project has a frameworks directory, you just add a directory for your custom frameworks, and include the frameworks in your buildfile.
It's not a bad idea with SC to at least separate your Model layer into its own framework, for loose coupling and testing purposes (SC is heavily MVC). It might make sense to separate your screens into their own frameworks, depending on how beefy they are. One of the benefits of this approach is you can reuse your frameworks in other projects if needed.
SC also includes a robust Statechart mechanism, so using custom events is quite natural, and because of the statecharts its relatively easy to insure that the events are handled only when the app is in the right state.
Have you tried the Relay framework? Your write your individual screens as standalone modules and use relay's event system to link them together.
http://relay.github.com
I'm working on a Java EE project right now, using lots of javascript function, but only using jQuery library.
I would like to know if anybody has some experience with this, used a Javascript framework with Java before, and tell me what would be the best way to do it, and best tool to do it.
Also, part of requirements are that I want to use the Framework to make it easy to handle the events, and to define a state machine for the website. I was looking a sproutcore, but couldn't find any information on how to use it inside a Java EE project.
For pure frontend compilation, there are several options, darioo mentioned Google Web Toolkit, though this is all very low level and thus harder to roll into out of the box. There are several GUI frameworks out there based on GWT.
Ext GWT
Smart GWT
Vaadin
Out of those three I hear our Java devs are most happy with Vaadin, though it's quite hard to create really customized (your average funky website with never before seen features...) frontend apps with these frameworks and you will long back for the expressive freedom JS toolkits like jQuery have to offer in a lot less code.
Then there are hybrids (JSP based), allowing more freedom in you frontend files (aka. frontend developers can tinker with it without knowing Java). Java code doesn't compile JS, but offers out of the box solutions you can tinker with in the JSPs.
JSF2 (uses YUI)
Spring Roo (uses Dojo JS framework)
Spring Roo scaffolds an entire frontend provides/uses the Dojo framework. JSF2 was/is looking nice as well according to our Java devs, though wwhen looking at the website, the angst of Oracle seeps in.
Both Dojo and YUI are quite expansive and mature JS frameworks specialised for large JS projects. Whereas jQuery is nicer for smaller JS projects with a rather flat architecture.
Ignoring Java based solutions, you can always fall back to YUI, Dojo or even MooTools for more architecture options.
You can also stick with jQuery, but imo. you need to be happily insane and masochistic (aka. frontend/JS developer) to maintain large scale JS/Html/CSS projects. jQuery is a nice toolkit, but as a framework, it offers meager architectural/structural solutions, you will have to devise them yourself by mixing and matching it with other small toolkits like RequireJS.
My best advice would be, build your app without JS first, using page refreshes and whatnot. Then apply a JS layer and build Ajax services for that layer. That way, your views and JS solution are losely coupled and theoretically, you can always switch frameworks without touching your JSP's too much.
If you already know Java, Google Web Toolkit is the most Javascript centric framework out there that I'm aware of.
Note: it's not just another Javascript library like jQuery, but a full blown framework with set rules you must adhere to. By writing Java code, it will generate Javascript for you that's highly optimized for speed, size and multiple browser compatibility.
I would like to know, how powerful/viable are JavaScript only clients based on say, GWT/gxt/vaadin, when compared to DHTML clients such as those made with wicket, tapestry, click etc?
My boss has insisted on using GXT (due to its nice colors and theme) on a project that will most likely become very big with lots of screens. I am against the idea of a javascript only client, especially when the javascript is generated from Java code. I have tried to advice him that we use something like wicket whereby we construct the screens with html but put in ajax where and when neccessary.
How viable is such a JavaScript client? I understand that JavaScript was intended for minor web page enhancements, and not all browsers, especially mobile devices have complete support for JavaScript.
Yes, it is viable for certain applications. Consider Gmail, Google Docs and Google Maps as typical applications where this works, and is probably the most feasible approach.
Some rich UI JavaScript frameworks, such as Ext JS also rely on this technique.
I've built javascript only web apps for ages.
First in SAP projects for big multinationals. And now on a new project:https://beebole-apps.com?demo
So yes it is powerful and viable.
Javascript-only webapp can be extremely powerful, and it's viable for certain applications, say, an Instant-Messenger webapp?
You mentioned that there are lots of screens in your web-app. One of the advantages from GWT/GXT is the fact that you can unit test your UI-layer with JUnit. This is an extra testing you can do on top of, say, Selenium. This is essential if you'd like to make UI testing a part of the continuous integration process, and, as the team grows, you'll definitely want to have tests around to make sure everything works (At least in theory.)
However, if what your boss meant to do is to build an in-house, custom Javascript engine using GWT's JavaScript Native Interface (Link), then I'm not sure...
Another advantage with GWT-like-engine over Wicket is that you can rely on HTML-code-gen to generate standard-compliant (In theory) HTML code. With framework like Wicket, it is hard to ensure every single developer on the team to author good HTML code - Especially when the team gets bigger.
Disclaimer: I'm a member of the Vaadin team.
Our Timeline demo is a good example of what can be achieved with Vaadin and GWT in client side, but I think all of the options presented in this discussions are viable given enough time.
Since you are going to start a big project you should build a simple proof-of-concept app with each of the relevant frameworks. If your PoC includes at least some of the more complex use cases you'll probably can make a pretty informed choice based on the experiences you get while building them.
I urge you to at least evaluate Vaadin. With it you write only server-side Java code and Vaadin will create a slick and professional browser UI for you. Client side can be easily extended using standard GWT (also pure Java), and there are no HTML templates, tag libraries or XML configuration involved at all. A Vaadin UI is fully Ajax'ed and lazy loading out of the box, and it easily integrates with any server side technologies, eg. Spring.
In addition to the development model advantages you get top-notch documentation, a bi-weekly update schedule, a very lively community filled with helpful experts, 100+ useful open source add-ons, and a 10 year old backing company with help on hand should you need it.
I would like to create a database backed interactive AJAX webapp which has a custom (specific kind of events, editing) calendaring system. This would involve quite a lot of JavaScript and AJAX, and I thought about Google Web Toolkit for the interface and Ruby on Rails for server side.
Is Google Web Toolkit reliable and good? What hidden risks might be if I choose Google Web Toolkit? Can one easily combine it with Ruby on Rails on server side? Or should I try to use directly a JavaScript library like jQuery?
I have no experience in web development except some HTML, but I am an experienced programmer (c++, java, c#), and I would like to use only free tools for this project.
RoR is actually one of the things the GWT is made to work well with, as long as you're using REST properly. It's in the Google Web Toolkit Applications book, and you can see a demo from the book using this kind of idea here. That's not to say that you won't have any problems, but I think the support is definitely out there for it.
There's a neat project for making RoR/GWT easy that you can find here (MIT license). I haven't had a chance to try it out yet, but it looks like a good amount of thought has been put into it. One catch is that it looks like it hasn't been fully tested with 2.1 Rails yet, just 2.0, so you may run into a few (probably minor and fixable) errors.
If you are looking to integrate GWT with non-Java backends such as ROR, PHP etc., you should bear in mind that GWT 1.5 now supports JavaScript Overlay types. This feature lets you write classes that can be mapped over the top of native JavaScript objects to easily provide accessor methods for properties of those objects and other extended functionality.
See this link for more details:
JavaScript Overlay Types
So you could return JSON encoded data from your backend via AJAX calls, parse it into a JavaScript Object and then access the data through your GWT Java code using the overlay classes you've created. Or when you render your page you can render static config data as JavaScript Objects and read it in via this mechanism, rather than having to do an AJAX call to grab the data.
If you know JAVA, and have somewhere you can host it (like a tomcat or glassfish container) I would recommend that much more than using Ruby for the back end. The main reason is that then you can share all of your objects, and use the built in RPC mechanism. I've done this for quite a lot of our projects and it's a huge timesaver, not to mention that the code is less error prone, because you don't convert your java objects to anything and then back again.
I have linked my GWT with Rails before, using the to_json function in Rails and then reading the JSON in GWT. It's all supported, but it is far more annoying than just doing the back end in JAVA.
Of course if you have cheap hosting, then Java containers are pretty much out of the question, in which case I would think Rails would be the next best thing.
GWT is very high quality with a great community. However you do need to know CSS if you want to adjust the look of things (you will) - CSS can do a lot of the layout, just like regular web if you want it to. Libraries like GWT-ext or ExtGWT can help a bit as they have stunning "out of the box" looks but for a price (extra size to your app).
You can code everything in Java using GWT, and you can integrate existing 3rd party javascript libraries with it. It's very good. I've never used RoR much though, so can't say anything about that.
If you're experienced in Java but not in Javascript/CSS, then GWT is going to be a lifesaver (unless you want to learn them, of course). CSS has so many little fiddly details. It is not uncommon to spend half a day fixing a 2 pixel misalignment that only occurs in IE6.
I am not sure about how easy it would be to use ROR for the back end... It is possible, I am sure, since GWT ajax communication is just servlets. But they provide some really nice functionality for passing Java objects back and forth which you won't be able to utilize if your server isn't also using Java.
I wrote about some of the disadvantages of GWT recently. Mainly, the disadvantages are: long deployment cycle for changes to some parts of the application and a rather steep learning curve. As a seasoned Java programmer, the second should be less of a problem and if you use a seperate backend, the first is also mitigated (as a complete redeploy is primarily required when you change the 'server' part of the application).
GWT is a wonderful framework with lots of potential. Keep in mind that it's still quite new, though. There are some unresolved bugs that can really annoy you, and they usually require ugly workarounds to get past. The community is great but you'll probably end up with a few problems sooner or later that Google can't answer yet.
But hey, I say go for it. The potential for GWT is awesome, and I bet it's future will be bright.
You should definitely use GWT for a new project (it's pretty easy to use in an old project too).
I my experience it's very fast to learn and use. The compiled javascript code is much better than anything you could ever write by hand and it works fast too.
Another benefit is the ability to debug you're code (which is hell with javascript alone)
This blog has inputs from many experienced users of GWT and have some great discussion points. I personally have huge experience with varied UI Frameworks. I will add my two cents. Lets look at fundamental advantages and disadvantages of GWT
Fundamental Advantage
GWT takes the web layer programming to JAVA. So, the obvious advantages of Java start getting into play. It will provide Object Oriented programming. It will also provide great debugging and compile time checks. Since it generates HTML and Javascript, it will also have ability to hide some complexity within its generator.
Fundamental Disadvantage
The disadvantage starts from the same statement. GWT takes the web layer programming to JAVA. If you know JAVA, probably you will never look out for an alternative language to write your business logic. It's self sufficient and great. But when it comes to writing configurations for a JAVA application. We use property files, database, XML etc. We never store configurations in a JAVA class file. Think hard, why is that?
This is because configuration is a static data. It often require hierarchy. It is supposed to be readable. It never requires compilation. It doesn't require knowledge of JAVA programming language. In short, it is a different ball game. Now the question is, how it relates to our discussion?
Now, lets think about a web page. Do you think when we write a web page we write a business logic? Absolutely not. Web page is just a configuration. It is a configuration of hierarchical containers and fields. We need to write business logic for the data that will be captured from and displayed on the web page and not to create the web page itself.
Previous paragraph makes a very very strong statement. This will explain why HTML and XML based web pages are still the most popular ones. XML is the best in business to write configurations. A framework must allow a clear separation of web page from business logic (the goal of MVC framework). By doing this a web designer will be able to apply his skills of visualization and artistry to create brilliant looking web pages just by configuring XMLs and without being bothered about the intricacies of a programming language. Developers will be able to use their best in business JAVA for writing business logic.
Finally, lets talk about the repercussions in direct terms. GWT breaks this principal so it is bound to fail. The cost for developing GWT application will be very high because you will need multiskill programmers to write web pages. The required look and feel will be very hard to achieve. The turn around time of modifying the web page will be very high because of unnecessary compilation. And lastly, since you are writing web pages in JAVA it is very easy to corrupt it with business logic. Unknowingly you will introduce complexities that must be avoided.
You could also consider Grails ("Groovy on Rails") which gives you the benefits of a Rails framework and the use of the Java VM.
Our team recently asked the same question, and we chose to go with GWT, especially since the designer plugin made working with GWT more accessible to non-java experts on the team. Whoever makes this choice, just beware you DON'T use the GWT Designer plugin !! It has not been updated (in at least a year, apparently) to create a GWT application that is compatible with IE8.
Our team had almost completed our application layouts, which were working perfectly in Chrome, FF and Safari. Then they blew up in IE. IE 7 would load partial pages (but not composite includes), and IE8 was not even able to load up the application. It just hung.
The designer plugin has buttons that allow the user to add CellTable widgets that are not IE compatible (CellTable, DeckPanel, Horizontal Panel, Vertical Panel, among others). These will cause intense pain when the layouts have to be re-done in java without assistance from the designer.
Experienced GWT users love it, but the designer plugin will kill you.