I was recently asked in an interview - In java, how do you compare component based frameworks to request based frameworks? I explained EJB as an example of Component based framework and Struts as a request based framework but was not convinced if I did justice to the question.
Any ideas on what interviewer meant and what should have been compared??
regards,
avajurug
They were most likely looking for examples of web frameworks - for example, JSF is a component-based framework, and Struts is a request-based framework.
Request-based frameworks generally make it clear through their APIs that they're working with parsing an HTML request / generating an HTML response, while Component-based frameworks attempt to abstract this away and treat the application as collections of components with renderers and actions to do things.
In my opinion, component-based web frameworks are more trouble than they're worth - their main purpose is usually to make the development of a web app "easier" for developers unfamiliar with web development, and closer to traditional desktop development. However, in practice, when something goes wrong, you need to develop custom components, you need to customize the framework for something that isn't "out of the box" functionality, etc. you need to understand both underlying "traditional" web development and how the component-based framework abstracts it - and if you're an experienced web developer and have existing solutions, utilities, libraries or snippets that worked in "traditional" web development, you'll waste time re-implementing them to work within the component-based framework.
Request based framework is a web framework that gets user's request then determine what the system should do and give back the response back to the user. So the flow is pretty much linear. You're thinking in actions: what does user want (request) -> what user will get back (response). An example of Request based framework is Struts. The modern Grails is pretty much a Request based framework too.
Component based framework is not like that. There is actually no clear sense of the flow from front to back. An example of it is not JSF, because in some way JSF is pretty much quite the same with Struts (since the creator of Struts and JSF is the same). A good example of Component based framework Tapestry and Wicket. The paradigm in these two framework is different. You don't think in actions or request-response, but components and components. You define a component in your application, and you tell what the component does. But the flow does not have to be linear as in Request based framework.
JSF is component based java API, as said Nate, Struts is an action based framework, the Http requests are parsed, while processing the actions in the end the controler Servlet forwards the request to the JSP that will be responsible to generate the response. While in JSF which became a standard for component based web frameworks, there is actually no need to process the requests and the responses as all we need is to write JSP or XHTML pages, bind the components used in the page or the value they should render to properties in backing beans or managed beans and the FacesServlet (controller) does all the job to care about request parsing and redirecting to the JSP that will render the response based on navigation rules specified in faces-config.xml . So as you can see there is a big difference between Struts and JSF as JSF brings a component-event based approach while Struts is more close to the classic JSP/Servlet model. Another thing jpartogi have said the creator of JSF and struts is the same, I just want to mention that Struts is a framwork owned by Apache community while JSF is an API specified by JCP in the JSR-127 for the version 1.1 and JSR-252 for the version 1.2 and has different implementations (SUN-RI, Apache MyFaces...)
Simply, If the framework has objects in java side for each web element so you can change attributes of it or add some functionality, it is component based framework but If framework does not provide objects and you have to put the response value of web element between its tags it is a request based framework.
Related
For a new project I want to usa a component-based framework (thinking of Wicket or Tapestry). It's an intranet-application, but i have to provide Restful Webservices aswell.
After googling around i havent found any good solution, that describes how to integrate Wicket with any Jax-RS compliant library.
Has anybody done this before?
I already saw, that Wicket CAN provide rest-like URLs, but i would to switch between fully-fledged Wicket-Gui and webservice by accept-header.
Everything i found, suggests, creating a different vhost/url-route.
If you say, tapestry (or any other framework) is much better, for what i wanna do, let me know. But somehow i like wicket.
I'd recommend using Spring "contract first" web services or REST:
http://static.springsource.org/spring-ws/site/
http://www.ibm.com/developerworks/webservices/library/wa-spring3webserv/index.html
Especially if you're interested in frameworks. Spring is much more than a web MVC framework. It gives you:
Dependency injection
Aspect oriented programming
Rock solid modules for web MVC, persistence, remoting, messaging, security, web services, etc.
I'm not sure why you think a component based approach is superior, but it seems to me that it's been left in the dust by HTML, CSS, JavaScript, and jQuery. I'd reconsider the requirement.
The implementation of the web service should not know or care at all about what technology is used to implement the client. That's the beauty of web services: if done properly, they can survive longer. UIs can come and go, but the business logic and fundamentals in the services can remain. They can deal with UIs running on desktops, browsers, mobile, and maybe even Google's heads-up display. We'll see.
Neither Play, nor Spring MVC is component based.
In Wicket 1.5 you can roll your own IRequestMapper that checks the header(s) and decides whether to use the default processing (component-based) or to use your custom IRequestHandler that will deliver JSON, XML, ... See TextRequestHandler for inspiration. Your custom IRequestMapper should be set as 'root' to be able to get the incoming requests first, see the usages of HttpsMapper and CryptoMapper for example.
Feel free to ask for more details in the users# mailing list.
I'm in the "technologies selection" phase of a small, single-page web application that will be heavily-based in AJAX, and which will report to a Java backend.
In a previous question I posted several weeks ago, the SO community at large felt strongly that I would be better off going with a Spring MVC-based web app than with something in JSF. Since Spring is request-oriented, and JSF is component-oriented, it would only make sense to use Spring for something that is going to be getting a lot of asynchronous requests.
If I were going the JSF route, then my next set of decisions would be whether or not to use so-called UI component libraries for the view technology, such as PrimeFaces, IceFaces or MyFaces.
So, I'm wondering: Does Spring MVC have anything similar to, say, PrimeFaces (or its likes) for creating the view component for my page(s)? I know its not component-based, but I'm not all that familiar with Spring MVC's web platform and was wondering what are some de facto standards (if any) or typical technology stacks that Spring web developers use for constructing nice web pages.
And, if Spring just uses run-o-the-mill template engines, would something like Freemarker suffice?
I guess this is a "best practices"-type question for a budding Spring web developer.
Thanks in advance!
Typically, the value so-called UI components lies in how they keep track of user interactions on the server side by integrating with a stateful framework.
Since you have decided to go for a request oriented framework, it would make more sense to use some well-known client-side JavaScript libraries instead. Popular choices include:
Backbone.js – an MVC foundation for user interfaces
jQuery UI for some premade widgets (calendars, etc.)
If you want to go down a more complex route, but with a more desktop-like feel, Sproutcore
Finally, if you wish to avoid JavaScript, you can useGoogle Web Toolkit, which compiles Java to JavaScript and is supposed to have good integration with Spring.
Personally, if I don't need a lot of standard prebuilt widgets, I like Backbone.js + underscore.js + jQuery. I don't like Google Web Toolkit since it feels like writing a pidgin JavaScript, and at that point I prefer to write JavaScript directly.
Yes, JSF is component oriented and Spring MVC is request oriented.
I recommend you to have a look at Thymeleaf Template engine, which is a complete replacement for JSP Engine
....
Thymeleaf Features are:
It allows natural templating.
HTML5 support
Higher performance by utilizing in memory caching
Click here for more
Additionally apart from the things mentioned by Ludovico Fischer, if we consider the same question in now a days tech world than you can use one of the most power full thing of recent world : Angular. There are 2 sample scenario's.
If your architecture is full client side: The integration is very natural for it. Spring MVC expose your service as a REST (JSON / XMl ... ) and your client application with Angular JS consume your JSON. Here the war application (Spring mvc ) must be deployed in a Servlet Container (Tomcat) and your client application can be deployed in the same server or in another server Nginx , Apache etc..
If you want to keep page generation in the server side and only use AngularJS for some nice DOM manipulation so your code must be deployed in the same war (WEB-INF). Mixing the two approachs is not always a good idea. You can try thymeleaf to stay in server side page generation.
Thus in this way you can have simultaneously the cool featuresof angular like templating, testability and clean view code.
Here is another approach (Not JSF) to let Spring MVC to work with ZK UI components - Rich Web Application with Spring MVC CRUD Demo
In that article, it used Spring MVC controller to communicate with ZK UI components. (all in Java code)
Looking to implement a RIA using AJAX with Java on the backend.
I was looking at DWR for an RPC style approach, but the project hasn't been updated since 2008.
I was also looking at DOJO and GWT.
Can anyone recommend a core set of technologies that works best for a Java based back end, that contains a rich set of client side widgets and backend integration with Spring WebFlow/MVC?
thanks
I would recommend Spring 3.0. It's up to date, lightweight, easily configurable, supports dependency injection, annotated classes, and is a great framework.
It supports REST, so it's easy to implement classes that return JSON to your HTML pages. This will help keep your content, behavior, and presentation all separate while still enabling you to build a Rich Internet Application.
Although outside the scope of your question, I'd suggest you use JQuery on the frontend as I've had really good results using it to transfer JSON back and forth from the server.
I would stay away from DWR. They merged with Dojo, which in my opinion is a better choice than DWR. DWR sounded good, but in practice it was buggy and difficult to use. Dojo was much cleaner and more modular. But unless you're using Comet (aka Reverse Ajax) just stick with Spring and JQuery.
Spring 3.0 is also supported on Google App Engine... just worth mentioning as Platform as a Service is in our future.
My recommendation is a RIA framework like SmartClient or ExtJS + a REST-based backend (built on Jersey, for example). I have also found JQuery to be extremely helpful when combined with these frameworks. Together. this allows you to build your GUI right on top of a REST API, which itself could be reusable for programmatic integration.
These kinds of questions are always religious ones, but FWIW I am personally not a massive fan of GWT, for multiple reasons. One of those reasons is because I don't want server side folks constructing GUI-targeted data structures (I'd rather have them stick to pure data and let me GUI folks handle the GUI stuff). So I actually don't appreciate that capability of GWT, but obviously many other people welcome that aspect, so again it's a religious choice.
you can try GWT.That supports Spring well.
http://www.springbyexample.org/examples/simple-gwt-spring-webapp.html
If you use a Spring MVC back end, you can use any AJAX frontend there is.
And if you are going to develop a RIA, I would suggest either Prototype with Script.Aculo.Us (Killer GUI effect library) or MooTools (which is either an extension or a re-write of prototype, that also includes many GUI tools).
The great thing about both ProtoType and Mootools is their Object-Oriented methodology (MooTools Class() docs, Prototype Class.create() docs), but the extension mechanism that gives additional methods and properties to DOM elements (How Prototype extends the DOM, MooTools Element reference). Of course this mechanism is exactly what the JQuery guys loathe about these libraries. But the nice thing is that because of these extensions, you hardly ever have to resort to browser-specific programming, the abstraction handles that for you.
I choose JSF for RIA applications.
It is J2EE 6 standard
it built-in in J2EE application servers (glassfish, jboss),
it has several implementations - if you have problem with one, you can switch to another
I has at least 4 (richfaces, myfaces, icefaces, primefaces) independent, big components libraries.
Spring can work well, but my personal preference is for simplicity, and Spring is bit heavy platform. So I prefer deploying services on JAX-RS containers (like Jersey); Guice for wiring things together, and in case I want to override or change data bindings, Jackson for JSON handling.
Other useful pieces would be jDBI for database access (much simpler than hibernate or other full ORMs), async-httpclient for doing calls to other web services.
Best of all, these all work nicely for many other kinds of uses.
I'm just getting involved with Servlets, Tomcat, JSP etc and was wondering what people typically use for GUI's in their JSP pages (for client-side interactivity). I've used jQuery, YUI, extJS, etc. for JS scripting in simple webpages, but what about for web applications? Do these client-side technologies integrate well with JSP pages? Are there tag libraries out there to help with this sort of thing?
Any suggestions?
As a specific example, would it be a good idea to populate a YUI DataTable using JSP embedded in the JavaScript?
For rich GUI, consider looking at JSF. There are lot of JSF component libraries around which offers GUI awesomeness, for example PrimeFaces. It's basically using jQuery / jQuery UI under the covers. Checkout for example the Mock OS X demo.
If you don't want to bow for a component based MVC framework like JSF, then you can also just go ahead with "plain" jQuery / jQuery UI. It shouldn't be that hard on JSP. All JSP basically does is generating and sending some bunch of HTML/CSS/JS code from webserver to webbrowser. All JavaScript/jQuery basically does is intercepting on the HTML DOM tree as the webbrowser has retrieved (in other words, it has totally no knowledge about the server side JSP code which generated/sent it).
You only need to realize that afterwards bringing a component based MVC framework in an existing JSP/jQuery webapplication isn't that easy. Rather look for a request based MVC framework like Spring MVC then.
Related questions
What is the need of JSF when rich UI can be achieved by plain HTML/CSS/jQuery?
You can use any of those libraries. I personally prefer jQuery. I've also used prototype and Ext JS in the past. Some frameworks integrate proprietary or generic Ajax approaches, but I find the popular ones (such as those you listed) to be a better alternative.
I have been learning ASP.NET MVC in the last few months and I think it is a great improvement over ASP.NET. For me personally, it is a joy to use (as opposed to ASP.NET WebForms :)) I started wondering how the .NET world managed to live so long without any such framework (at least not wide spread and supported by Microsoft as there may be .NET ports of Java MVC frameworks, like Spring.NET).
I know Java folks had such frameworks for a long time and there are many Java MVC frameworks available.
If a web developer was thinking about switching from Java to .NET, which Java framework can be the easiest to switch from, and vice versa, if an ASP.NET MVC developer is thinking about broadening his skillset and learning some Java MVC (web) framework, which would be most similar to ASP.NET MVC architecture- and feature- wise?
Which Java MVC framework is most similar to ASP.NET MVC?
SpringMVC, VRaptor, Grails (Not Java, but somewhat relevant on the Java world)
Play Framework seems to me. It has controllers as classes, actions as methods, Razor-like view engine, object binders and almost everything looks the same.
Even routing seems almost the same.
If I were looking for the simplest framework, I'd dive into Struts. Struts 1.0 was written in a day, and is possibly the most valuable hour-per-hour effort ever spent by a programmer.
If I were looking to broaden my knowledge and/or skills, I might lean towards Spring MVC. If you need some functionality for Java web development, odds are other people wanted it too, and that Spring already has it. (Spring is larger than just Spring MVC; you can simply use Spring MVC, but it integrates nicely with much more, if you choose.)
Wikipedia has a list of a bunch of frameworks here:
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
and of those based on Java technology, about half are component based (that's what you don't want) and the other half MVC. If interested, you could follow the links on some of those to get more information.
In general,
the more mature of them will have more detailed writeups - both in Wikipedia and in the wild. There will also be more documentation, sample code, tutorials,...
The younger ones may be simpler, more fun, more versatile, as they build on the older ones, eliminate known shortcomings and add new features. JSF and Struts, for instance, are "big" in the industry but are considered by many developers (citation needed, I know) to be dated, clumsy, bloated, etc.
You'll probably have trouble getting an answer from people with enough experience to directly compare products on the .Net and Java side; most developers tend to stay on one side of that fence.
While I'm not knowledgeable about similarities with ASP.Net, I submit that Struts and JSF are the workhorses of industry on the Java side, and would be the kind of thing to be useful to have in your CV, even though or perhaps because they're not modern or sexy. Of those two, I think Struts has more of an MVC feel to it.
Apache Struts :
Apache Struts is a free open-source framework for creating Java web applications.
Web applications differ from conventional websites in that web applications can create a dynamic response. Many websites deliver only static pages. A web application can interact with databases and business logic engines to customize a response.
Web applications based on JavaServer Pages sometimes commingle database code, page design code, and control flow code. In practice, we find that unless these concerns are separated, larger applications become difficult to maintain.
One way to separate concerns in a software application is to use a Model-View-Controller (MVC) architecture. The Model represents the business or database code, the View represents the page design code, and the Controller represents the navigational code. The Struts framework is designed to help developers create web applications that utilize a MVC architecture.
The framework provides three key components:
A "request" handler provided by the application developer that is mapped to a standard URI.
A "response" handler that transfers control to another resource which completes the response.
A tag library that helps developers create interactive form-based applications with server pages.
The framework's architecture and tags are buzzword compliant. Struts works well with conventional REST applications and with nouveau technologies like SOAP and AJAX.