I would like to build a web project, using ExtJS, the famous JavaScript library. The goal is to use only ExtJS (and some CSS and HTML) to build the entire client-side web application. I also would like to apply a Model-View-Controller structure to the code of this project.
First question: is it possible and pertinent to apply such an architecture to an ExtJS project?
Second question: how can I easily apply a MVC architecture to a ExtJS project?
I already read this but it does not answer my questions.
The documentation from the ExtJS community does not provide such tips.
In all given samples, code is contained in one single file, and UI code is not separated from the application logic code. For example, listeners methods and calls to server come along with UI code.
In fact, all tips to separate application logic from user interface code are welcomed.
Edit
Another question: What do you think is the best way to design a ExtJS based web application? I did not found any good designer for ExtJS. The designers I found (this and this) don't seem to be reliable (code generation of the first sometimes fails).
In my experience, you want to think about two separate applications.
On the server side, you want to fashion a pretty typical MVC application that simply provides a web service. You're probably fine just talking JSON. Look into doing things RESTfully.
On the client side, you have a javascript application. If you're really leveraging ExtJS, you should only have an initial request/response that sets up the application. Everything from then on should just be XHR requests to your web service (and, if you're getting fancy, lazy-loading of ExtJS-driven javascript files).
This kind of architecture will pay for itself when all of a sudden you want to open up a public web service, or write some alternative client (iPhone apps, for example). These alternative clients should be able to rely on the already-running web service.
Switching gears to the client-side, ExtJS driven stuff -- MVC can help you here, but you're making a mental context switch from a request-driven system (on the server), to a more open-ended event-driven system in the browser.
Use a lot of the practices the ExtJS community talks about (smart use of factory methods, extending built-in classes, module pattern, ExtJS's template methods, etc).
While organizing your javascript application, try to think in an MVC sort of way. Learn how event bubbling and relayEvents() work. You've got your model stuff (basically, they'll derive from the built-in store classes), view stuff (Grids, Trees, etc), and controller stuff (usually attached to some container. Read Saki's stuff about inter-component communication at extjs.eu.)
There's certainly more than one way to do it when it comes to heavyweight client-side application design. But if you want to seriously leverage ExtJS's potential, it's worth it to take the time to read up on things. Look at articles or books about GUI programming in general -- writing an ExtJS app is more similar to writing a traditional desktop application than writing a web application.
In this domain, the "web" stuff gets very simple -- you're just handling data on the server side. The tricky stuff is figuring out how to organize and optimize the in-browser code.
Use some libraries which makes javascript OOP lang. Then use MVC pattern. Also you can use Ext-GWT for developing web on OOP java.
Related
I've been working with ASP.NET MVC for about a year now. I enjoy the ability to create SPA's especially by using the following tools:
Partial views(via html.action() and renderPartial())
Ajax helpers (Ajax.Actionlink() and Ajax.beginform())
My question is, Is it safe to just continue without a JavaScript frameworks or am i seriously missing out on something by not utilising a Javascript framework like Angular JS.
This depends a lot of the type of application you are building, but in general you don't necessarily have to choose between ASP.NET MVC and Angular, you can use both in a project.
For example, if you have a page with a grid where the user will add rows and you have to calculate sums etc you could use angular on that page (and it will speed up the development process).
But if you have pages with static content you can just serve an html file there using ASP.NET MVC.
And you can even use both of them. For something like a blog post, you can use a static html file for the post content and then implement the comments are with angular.
Since ASP.NET is a server side framework, it can only go that far as AJAX insertions. Angular JS is a client side Framework, designed for SPA in mind. If you are going for a light SPA, ASP.NET will do nicely, but I think you should use the right tools for the right job. Don't hesitate to mix them in order to find the right place between server side rendering and client side dynamism.
You are definitely missing some things.
The purpose of frameworks such as angular is not just to handle your bootstrap tab switches or whatever to display just parts of the UI rather than everything. Sure, you can create small and simple SPAs by utilizing such logic but once you come to create real-world apps that approach will become unusable. The reasons to this are:
Your site will be highly unmaintainable
Frameworks like angular provide much more than just templating (more on that in a moment) but features such as routing, which allows on-demand content loading. That is, instead of sending the whole page to the client, much of which (s)he maybe will not even take a look at, you can load fragments of HTML on-demand, which reduces network usage. Imagine you had to download everything (posts, images, videos, chat messages etc) on Facebook and hide them until you actually want to see them.
Back to templating, this is a very powerful feature. Again, in the case of simple apps you can use custom JS code - that is, concatenate strings to create fragments of HTML and then insert them into the DOM. But even with simple apps this is a smelly thing to do. Imagine you had to write custom JS to concatenate your chat messages in an app like Facebook then insert them into the DOM. With angular2, for example, you can do something like this:
<ul>
<li *ngFor="let msg of messages">{{msg.Sender}} said: {{msg.Content}}</li>
</ul>
This way, Angular2 will do all the parsing and DOM handling for you. That is, you write declarative markup rather than imperative logic for what you want to display.
All in all, they help you to decouple the logic from the UI so you should definitely dig into any of the popular frameworks and get a taste of their capabilities if you want to create rich apps. You will not regret it.
Question background:
Hello everyone, I have been developing windows form application for my employer for about 3 years. Though most of my works are amateurish. I've been using visual studio, c#, enjoying creating re-usable windows form controls by sub-classing and other techniques. Now my boss want me to make website for this company, the first thinking in my mind is to create re-usable WEB controls just like windors form application.
The methods I have tried
Web User Control, At very first, I found visual studio support developer to create Web User Control, with file extension as *.ascx. I was very exciting to find this because I thought I can create Web controls just like I did in windows form application development. BUT, it's a very big "BUT", I then found that it cannot be embed to assembly file (DLL), and either can it be displayed in ToolBox to support drag and drop in web page design time. AFAIK from msdn, the Web User Control is not intended to be re-used across projects. So I give up this method.
Server Control, then I found there is Custom Server Control can be created to support assembly embed and ToolBox. It's a *.cs file that written with a class which sub-classing from System.Web.UI.WebControls.WebControl or System.Web.UI.WebControls.CompositeControl. Good point is that this is exactly what I want: re-usability and design-time support. HOWEVER, the huge disadvantage is that it doesn't support drag-drop when creating the web control itself. The control can only be rendered by html written in c# or be created by code. And I have to embed css/javascript to the control if I want to create more beautiful, complicated or efficient control. Anyway, from MSDN, Server Control is what I need.
Pure HTML, Javascript (jQuery), CSS, actually I've beening working with Server Control method for a while, just in order to make my boss happy. But I still cannot stop thinking about other better solutions. From my understanding, web page is not that complicated, it's simply constructed (please correct me if I'm wrong) by HTML tag, javascript (or other scripting language), CSS to manipulate UI. So I believe if I create web control by pure Html, Javascript and CSS, it will be of course more complicated but more compatible. Because Server Control solution requires the web server support .Net Framework, which is not free and limited to Microsoft scope. If I have a way to get rid of .Net, why NOT? I'm willing to spend double-time to create Re-Usable control if it's worthy to do. For example, if I want to turn to PHP to create web page, I might have to acquire the technique to create my web control simply by HTML, Javascript and CSS.
My question
Speaking all of the above, is it even possible to create my web control library only based on Html, Javascript and CSS?
If so, is there any tutorial about this method?
I really would like to know that how does commercial/professional company create web page.
Thank you everyone, any advice will be very much appreciated!
Speaking all of the above, is it even possible to create my web control library only based on Html, Javascript and CSS?
In strict speak, the controls you have become accustomed to support the aforementioned. This will continue work in future projects created in WebForms.
However, if you foray into MVC then there is a striking difference. Most of the controls that handle input are client side (which can be wrapped in js wigets and user validation classes). On the other hand there is very little server controls, however there are _MasterLayouts and Views that can make use of PartialViews a PartialView is similar to a Web User Control. In your Controller you can return EditTemplates and other types that would be similar to Server Controls
After digging for a few days, I almost give up creating my own javascript library not just only for web widget(UI), neither I would like to use third-part js frameworks because:
Cost too much time: as it says: 'do not reinvent the wheel', well, I accept/disagree with this point half by half. But now, I simply do not have too much time on it. It really really cost time, can hardly complish by an individual person.
A lot javascript frameworks are so great, like dojo, yui, jqui, as #dandavis commented, BUT, the usage of some is difficult, at least for me (as a js beginner), especially dojo. Dojo is very powerful, AFAIK, but it's hard to implement and use. I followed official tutorial to create my own web widget, spend a hour and not get it done. I might give up too fast?
I still want to dig asp.net with ajax, it is much powerful. And can easily manipulate on server side.
Well, I don't know if it's an answer but this is my personal end of my question. Thanks a lot guys.
I've just read about single-page web applications that expose a RESTful interface for retrieving the data - for example in JSON format, and that just provide a single HTML page referencing the Javascript file responsible for invoking the RESTful interface and building the web user interface dynamically in the client's web browser.
To implement this in Play, one should implement the controllers so that they return JSON instead of HTLM and implement some CoffeScript for rendering the user interface on the client side.
So far so good... but I'm wondering whether this design makes sense for large web applications since the amount of javascript code to be run on the client side would increase more and more.
My initial idea was to implement the web application using Play's template engine and then to provide a RESTful interface for Mobile apps.
Any suggestion, idea, or link to documentation that covers this topic would be really appreciated ;-)
The Play for Scala book has a chapter on this topic. They use a single view as an entry point, that's it.
As for large applications, that's a valid concern. For that you might want to use libraries such as RequireJS (which Play 2.1 has built-in support for), among others. You also might want to split your app into sub-modules to manage complexity. On the client side, you probably should use a framework, too, such as AngularJS.
Concerning Play there's not much left to say, it's a very good platform to expose RESTful JSON services. I recommend you take a look at the JSON documentation and also check out ReactiveMongo.
Providing a common REST API should work fine. At the moment I am working with a Play 2.0 server app for browser (Backbone etc) and iOS clients. The browser client is totally separate from the Play app and deployed independently.
I think there is some initial overhead compared to Play template approach but having just one set of controllers to test etc makes life easier.
Couple points to consider:
Client authentication. Preferably you would use the same way for all the clients.
At some point you might want to introduce some specialized REST API for one of the clients in order to save bandwith and number of requests. For example mobile landing screen is a typical candidate.
You need to document your REST APIs more detailed as the web client devs are not sharing the codebase.
We use MVC2 to build up our web app. There are some complicated pages in our project. They have plenty of user interactivities, realtime stock data and charts, requiring no page refresh.
I am new to front end development and ASP.NET MVC2. After using it for a while I think it's a form-based framework for presentation layer(I maybe wrong). If most UI actions are excuted inside one web page, using ajax and javascript to render data and run UI logic seems better.
Then I find there're two way to rendering UI in our app: binding UI model to View using MVC2 and filling the view using javascript. This seems not so elegant or may possibly mess if more and more views are implemented.
It seems MVC2 controller is good at being RESTful UI model data provider. So I think make the solution as Controller(model data)->HTML layouts + javascript(ui logic) could be a good way to implement such a rich client web app. Is it a good practice to do? Or what's your advice on this kind of project? Are there any web resources(articles or sample projects) for reference?
Thanks a lot.
It's not a bad practice to make your actions return just data, you could make your actions return JSon objects since they are lightweight and use JSonP to make ajax request across different domains.
You can try the new template JQuery PlugIn to render your views.
My suggestion would be to build up your application such that it works without JavaScript. Then use JQuery (a JavaScript library) and Ajax to improve the user experience.
Be aware that it is entirely possible that your RIA needs go beyond what one can do with Jquery. In these scenarios one might consider another solution (HTML5, SilverLight, Flash, etc.). Or you could tone down your RIA needs.
I come from the Microsoft world (and I come in peace). I want to rapidly prototype a web app and if it works out, take it live - and I don't want to use ASP.Net.
I am not sure which web application toolkit to use though. Should I use GWT, DOJO...other recommendations? I am open to any server-side language but am looking at RoR, Php or even Java (J2EE to be precise). I am not much of a Javascript/CSS guy so a toolkit that might make it relatively easy on me on those fronts would be preferable.
Also, I am a mac user at home. What IDEs go along with the framework you would recommend?
Any recommendations guys?
If you're open to doing Java, GWT is the way to go. It allows you to have a relatively uniform codebase across client-server, and to only use one language on both.
There are some limitations to doing very off-the-beaten-path AJAXy things (which GWT makes difficult, but not impossible), but it doesn't sound like that's your use case anyway.
GWT will allow you to scale up by using more of its features as your app gets more complex - and your prototype won't be throwaway code.
If you want to write the front and back end in JAVA, and want to do complex ajax type thing, then GWT is a great way to go.
The easiest way to think about it is that building a GWT app is kind of like building a JAVA swing application that hooks into a server. Just like a swing app that uses a server you can make it fat or thin. When you're done it all compiles down into HTML and javascript, and has very good modern browser support (ie6+ ff, opera, safari).
It does abstract all the javascript and HTML away, but if you want it to look good you'll still need to understand CSS.
I think anyone who says that that it ruins MVC or that it's a muddying of client vs server doesn't understand GWT. GWT is a CLIENT side framework. And it is only used on the CLIENT. GWT does provide an RPC mechanism to hook it into JAVA (and other) back ends, but that's just a communication protocol, it doesn't mean that your server code magically becomes your client code. Sure you can write a whole bunch of business rules into your UI if you really wanted to, but you can do this with any framework, so it would be silly to say that GWT is somehow different in that respect.
GWT is a good choice, while if you choose more powerful JavaScript framework based on GWT (e.g. SmartGWT), the compiled stuff is too heavyweight.
Choose direct JavaScript if you need a compact project.
I am a fan of GWT, however I am very familiar with Java. I found it to be intuitive, and surprisingly easy to get good results quickly. If you are to use GWT, then you'll definitely want to use the free, and immensely powerful Eclipse IDE.
One disadvantage of GWT is that it requires Javascript to be supported by the browser, there is no "graceful degradation".
We have evaluate a large list of frameworks and have decide us for Echo2.
You need only to code in Java. Javascript you need only if you want write your own components.
There are no startup performance problems with large projects like GWT.
You can use the full range of Java in your client code because it run on the server. In GWT you can use only very small set of Java classes.
The IDE for Java is Eclipse. This is independent of the used framework.
I'm a fan of jQuery, the chainability of actions, traversals, and commands is really powerful. A good friend of mine is crazy about Mootools, he works at a Java shop FWIW. He mentioned a cool feature of Mootools is that you can specify the functionality you want the framework to include and it will generate the entire library on a single line in a file that you can include on your page to minimize the weight of the framework (pretty cool feature). Really it just depends on what you are most comfortable with. jQuery has great tutorials, is super fast, and can be used along with other javascript frameworks.
Not related to GWT, but have you considered other backends that GWT could work nicely with?
Grails is one backend that ties quite nicely with GWT.
Personally, I would avoid server-side frameworks that try to embed or hide the client-side framework. I'm sure that GWT is great for getting something going quickly, and is probably fine for certain kinds of applications, but you'll probably run into lots of problems "on the edges" for more complex applications. Decoupling the client framework from the server-side framework avoids those problems.