Why would I want to use java portlets above tomcat and gwt?
Would portlets make it less- or un- necessary for me to use jsp and jsf?
Has Jboss been part of the portlet evolution culture? Does Jboss satisfy the portlet jsrs?
What portlet implementation/brand would run on gae java and gae python?
Are portlet specs due to peer pressure from php cms culture?
What are the equivalent of portlet and portlet jsr in .net?
Portlets were a well-meaning but mis-guided attempt at a reusable widget API for web applications. Think of the personalised google home page, with the portlets like weather, news, mail, etc.
Unfortunately, they made a bit of a mess of it. The Portlet API is a bit of a pig, a real barrel of not-fun, and there are very few implementations of it. The only one I've ever used is JBoss Portal, but it's a bit of a brute, and rather buggy. Liferay may also be a portlet server, but the home page is heavy on fluff and light on information, so I can't tell.
Spring provides an MVC framework for the portlet API which tries to reduce the pain, but frankly I wish they hadn't bothered, it just clutters up the documentation.
Essentially, the whole shebang looks like a solution in search of a problem.
If you happen to have a framework that you need to use, and it supports portlets, you may find then that portlets are going to be useful, since the application is built with the idea, but, as others have mentioned, if you are starting on a project, there are many other technologies that will do what you want with less effort, in a more stable environment.
For example, when I worked at the University of South Florida, the learning management system was (and is) Blackboard, and they now support portlets: http://www.ja-sig.org/wiki/display/JSG/Blackboard+Portlet. So, if the application provides an API, and expects people to use portlets, then it may make sense to look at them.
UPDATE:
After looking at the question there were a couple of things I missed.
Portlets were an attempt, it seems, to try to do as Google did on their homepage, where you could have multiple unrelated blocks of information on the webpage, so you could track your stack portfolio and your favorite hockey team, for example. I don't think it was influenced by PHP CMS as it was just an idea that was ready to come about, and if you need the server code to help pull the information, and to tie it into an application, this was one approach.
The closest thing in ASP.NET that I can think of to portlets are controls. I could have a stock portfolio control and when I include it on my page, you can set the options and it will show you your stocks and hockey team scores.
Not everyone uses JSF, for example, so controls would need to be written by hand as JSPs and servlets, with javascript.
Why would I want to use java portlets above tomcat and gwt?
These technologies are not directly comparable. Coming from regular web page development, Portlets seem like a very restrictive technology. But then the value of Portal servers is largely the control they give to administrators and users - the fact that this makes your life more difficult is irrelevant.
Would portlets make it less- or un- necessary for me to use jsp and jsf?
You can write directly to the output, just like you would in a Servlet. You probably still want a view technology (that will have to support portlets).
Related
I'm a newcomer to JSF and am still trying to follow examples to learn the basics of how it works, and that has now lead me to begin exploring ICEFaces.
I love the concept behind GWT that you can just write in pure Java and have it compile down to JS and HTML, but I have also heard that ICEFaces offers a lot of things that GWT doesn't.
That led me to start thinking: is there a way to combine the two in a project, and get the best of both worlds? Is it possible to get the AJAX-centricity, rich UIs and underlying capabilities of JSF, but then use GWT to handle all the client-side code generation?
I looked at something called ICEPush which may very well do just this, but without fully understanding the roles both technologies play in MVC web apps I wanted to take a moment and see what the SO community thought of such a hybrid solution.
Having said that, I was wondering if someone could break down - in quasi laymans terms - the intentional difference between these two frameworks, and to give argumentation as to why they can be - or shouldn't be - combined inside the same project.
Essentially I'm looking for an AJAX-friendly, rich UI Java webapp framework that is open source, has an active dev community, and comes loaded decent/good documentation.
Also, not that beggars can be choosers, but I'd appreciate it if answerers don't solicit other solutions besides ICEFaces or GWT. I'm very well aware that these are not the only two webapp frameworks out there, and this question isn't going to convince me to start using either of them; I'm simply interested if their strengths can be combined, or not.
Thanks in advance.
JSF in general makes heavy usage of javascript. JSF or bette the JSF frameworks provide lots of components. The Javascript is generated on the fly.
GWT compiles the Javascript upfront. It provides some components as well. GWT is doing AJAX calls to its interfaces.
I'm not aware of any bridge that allows you to integrate JSF with GWT. So there is no interface and those technologies don't work together.
Both come with good documentation and have an active community.
ICEpush can be used directly with GWT; you can find out more about the integration here:
http://www.icepush.org/product/icepush-GWT.html
ICEpush provides a simple API to "push" notifications to the browser. Essentially, users (or browser windows) are organized into groups. When something interesting happens (such as a new photo uploaded to a photo sharing application) you can invoke a push on the group users.
In the case of the ICEpush GWT integration, you receive a callback into your "Java" code and can respond to the notification (such as, display the new photo). A GWT application can potentially run offline, but that does introduce the risk of application code being subject to offline attack.
In the case of ICEfaces, the ICEpush integration is abstracted away: rather than a "push" to a group, you "render" a group. With ICEfaces you request that all relevant pages be rendered on the server and any necessary page updates are sent to the browser. This makes it particularly easy to add Ajax Push features to an ICEfaces application.
So, the choice is really whether you want to use JSF or GWT. With JSF you have a standard server-side framework that emphasizes pages built from declarative markup. It is the natural successor to JSP application development. With GWT you have a procedural client/server distributed framework that emphasizes events and pages that are built from "Java" objects. It is the natural successor to AWT/Swing on the web. Both are very popular, so it's more a question of the technique you prefer.
Sorry for asking this question, but I searched all Java-related questions, but I got more confused. I am still not clear what should I start with.
My main thing is building websites in Java, because someone told me that there are some machine learning or AI libraries available in Java which I can use in Java. So I decided to use that as it can reduce my work.
Now I don't know Java at all. Some people say the following are used to build websites, like:
Servlets alone can build a website
JSP alone can also build a website
Struts
Spring Framework with Hibernate
Seam
Java EE also for websites
I am confused. Where should I start from? Where does core Java fits in here?
I was thinking of perhaps learning Python as I know I have to learn Python only, not its variations.
So please guide me to one thing which can solve my basic purpose of using ready-made libraries of AI.
If I can do that with JSP then I will start with that.
But if I need to learn all of them, then it’s better if can start learning Python.
I have five months to finish the website.
I really don't know why there are many branches of Java for doing one thing.
To correct some misconceptions of yours:
servlets and JSP are Java EE
Seam and Struts can be used together with Hibernate as well
Spring MVC is a web framework. Spring as a dependency injection framework can be used together with any other framework.
there are many more options, like JSF, Tapestry, Click, Play, etc.
It depends on what will the site will be doing, but you can choose any.
Experience has shown that building complex HTML forms (especially validation) and Ajax functionality is hard to get right. You will most likely appreciate having a library to assist you with that. The same thing with database access.
Everything builds on servlets. Learn those in order to understand the libraries you will use.
I would suggest learning JavaServer Faces (JSF) with facelets. The easiest, while being powerful, is JSF 2 in Java EE 6. The easiest way to get started is to use NetBeans with GlassFish 3.
For static web pages, HTML alone is enough and if you want to make it more user-friendly and interactive, use JavaScript.
There are lot of frameworks you can use directly in JavaScript, like jQuery. Now if you want to make some more functionalities, like database interaction, then you will need either PHP, Java (JSP and Servlets) or .NET (there exist some more, but I’m aware of three only). Each of them have their library to interact with database.
Since you are interested in Java, go through Servlets, HTML, JavaScript, and JSP. Once this is done, you can look into JSF and EJB beans. So if you have knowledge of Java this will not take too much time, because the syntax is the same; the only difference is the concept.
So you will have a frontend (HTML, JS, and JSP) which will interact with the backend (Servlets and the database) which will be deployed in a Web container. To deploy, you can use an one of the available application servers, like Apache Tomcat, GlassFish, or WebSphere. To develop your application, you can use Eclipse as the IDE, which is one of the best IDEs I have used.
So decide your architecture and design, break it into components and start writing small applications first. Once you are experienced in small application, start writing an application where there are more things you have to care of, like load on database, availability, security, etc. For that, you can refer a very famous question on Stack Overflow, What technical details should a programmer of a web application consider before making the site public?.
The closest to core Java is servlets. No extra syntax, very minimal library, but no included functionality.
For building websites, the main thing is HTML and HTTP.
All technologies (including Enterprise Java or Server side Java) do the same—to understand an HTTP request and respond back with HTML. All that you mentioned do the same thing with a different level of sophistication.
Start with Wikipedia.org to know what technologies do what. If you are completely new to Java, go through the Sun tutorials, do sample programs, and get comfortable with Java packages, JVM and classes. (This might take a week or two).
To build websites using Java, you'll have to learn Java Servlets—everything else (JSP, Struts, JSF, and Spring(!)) are built on it. Get Head First books on Java and Servlets; they will be useful.
You can always build the page in Ruby or something that will give you a website very fast. For the AI stuff that analyzes the bought items for the recommendations, use something unrelated to the page that only takes the database to work with.
I would not mix the whole web page stuff with the AI computing. You can do the AI things that will take a long time and maybe should done on a different machine to have your webpage also responsive with C++ or Java in normal applications.
Choosing your front end technique because of later usage is a very dangerous thing. Using the whole Java EE concept and learning it from scratch will take you much longer than have a quick start with your page if you do it in Ruby or PHP.
You can then build the first version of the page and generate a user base. Start working on the AI stuff once you got some data with other technologies.
If your page has performance problems because your technology does not scale, you can always begin switching parts of the stuff out with a faster technology or maybe simply a bigger machine. Get your page running before you build it bulletproof for the thousand users you are expecting.
If you’re trying to build a website from scratch, with no prior knowledge, your best bet is to go with frameworks that provide a complete stack for web development.
If you aren't dead set on Java, you could probably start learning Ruby on Rails, which would be easier to start with (if so, go buy a Ruby on Rails tutorial which goes through all the necessary things for modern web development, from MVC to version control).
For Java, try:
Play Framework is very similar to Ruby on Rails. It will get you started very quickly, and hopefully (if you follow conventions) handle all of your peripheral needs.
Spring Roo is a very-fast-to-work-with framework, but it might get hard to maintain and extend later on.
These two are full web frameworks, that is, they handle database, MVC (presentation layer), configuration setting, etc... (I'll explain shortly). And could even ease your deployment process.
If you're going to go through any other route (using several frameworks together), you are probably not going to finish what you are doing in five months.
To understand why, and to clear some things you wrote in your question, you need to understand that modern web development (and enterprise development as a whole) is comprised of several different technologies:
Presentation: the term web frameworks has been more or less taken to mean frameworks that deal with this side of web development, i.e., how to create a web page (an HTML page). Most of the frameworks offer an MVC like approach (which you can read about elsewhere), and this is what most of the frameworks/technologies you gave sit in—JSP and Struts (which uses JSP) are examples of web frameworks. Servlets is a lower-level API that standardizes how to answer HTTP requests (which JSP and Struts sit on top of).
Persistence: being able to show a webpage doesn't mean squat these days if you can't save data to a database, and that is what the persistence frameworks do (they ease the way you can save data to the database). Hibernate is a persistence framework.
For Java there are also dependency injection (DI), which is what Spring DI is. It's tough to explain DI to people not familiar with the troubles of Java, so I won't try to explain it, but it's a very important part of modern Java development.
apart from these core technologies, there are also many items that you'll need to learn to actually deploy the application (unless your using services like Heroku or Google App Engine, which should simplify things), and troubleshoot it later (understanding how concurrency and HTTP works).
To address the other technologies you brought up:
I've never really touched Seam, so I'm not sure, but it looks like a collection of other frameworks (mainly EJB 3, which itself is a collection of APIs, and JSF).
Spring denotes a popular open source group (the SpringSource group) that provides various technologies, but most likely when you hear about it they refer to two things Spring's dependency injection (DI) and Spring's MVC (which is a web framework).
Java EE is merely a collection of high level APIs which other technologies implement (Hibernate implements JPA which is part of Java EE for instance).
Can you let me know on the pros and cons of using richfaces and are there any alternatives for it. Its for a proposal submission for a web application. Its for managing documents and it will be intranet. There will be lots of users and main concern is security and ease of use.
Don't do it like that.
I suggest you to ask the same question to your team, after all they are the one, who will be developing it.
You must understand and find out what exactly is JSP, JSF, RichFaces, IceFaces, Facelets, AJAX, etc. are. You must know what all these technologies are meant for, and how and where they can be applied to solve which problem.
You should make a toy application using few viable alternatives, i.e. IceFaces, RichFaces, etc.. Then evaluate considering ease of use, support, strength, etc.
It all depends on what you are creating, what your target audience is, which type of devices are used for accessing your application etc
If you are creating something that has to be really lightweight, for example, something that must be browsable on mobile devices, then you should consider how much of the code is executed in the browser, keep that end light and do the heavy work on the server side.
If you are creating something that has to be access with text based browsers, then you should keep your site as simple as possible and make sure you have full control of the DOM structure.
If you are creating something that has to be indexed by search engines (an application like an eCommerce site), then you have to remember that applications made with AJAX-based frameworks will not be indexed by search engines, as search engines look at the static content of the page (by which I mean that the content hasn't been modified by javascript). If you really want to use a RIA framework to create you frontend, there are workarounds to enable search engine indexing, but that's a whole another topic.
On the other hand, if you are making a web application, something like an accounting system or the management part of an eCommerce site, then you can and should consider full blown RIA solutions, because these kind of application do not need to be indexed by search engines and they are often (if not always) accessed through a modern browser on a PC or Mac. Popular RIA frameworks include Vaadin, GWT, Wicket, IceFaces etc.
http://www.icefaces.org/JForum/posts/list/8347.page and http://forums.sun.com/thread.jspa?threadID=5202018
The company that I work for is using AJAX, PHP & MySQL for Web Applications such as Social Networking, Community Sites, Online Booking Applications, etc. on a Standard Comentum Framework (MVC).
For Ecommerce Applications, we use Zend Framework. I think Zend Framework does a good job preventing programmers from sloppy coding:
http://www.comentum.com/web-application-development.html
Do you know a technology which can provide me a portlet-like interface?
But I do not want to use JSR 168/268 portlet specifications and a portlet container.
The reason is: My web app is a product which can be installed on the client's server (it can be weblogic/websphere/tomcat).
Packing the portlets container along with my application to be installed on clients web server is just too much.
Besides, there are a lot of features this technology offers which I don't need. Actually, all I need is the porlets look and feel (dragable and customizable windows,adding and removing windows and so on).
I know there is also the possibility to do it with client technology (like jquery) and that is cool, but I would like to know if there is any kind of java technology out there which will also give me that.
So, if you know something like a struts or a spring-mvc component library which does this job or maybe a third party product, I would like to know.
If you think my whole approach is wrong I would also like to know that.
Take a look at gwtportlets. From their site;
GWT Portlets is a free open source web
framework for building GWT (Google Web
Toolkit) applications. It defines a
very simple & productive, yet powerful
programming model to build good
looking, modular GWT applications.
The programming model is somewhat
similar to writing JSR168 portlets for
a portal server (Liferay, JBoss Portal
etc.). The "portal" is your
application built using the GWT
Portlets framework as a library.
Application functionality is developed
as loosely coupled Portlets each with
an optional server side DataProvider.
Take a look at the demo here
Another suggestion would be JSF 2.0 which provide AJAX support for updating part of the HTML-page out of the box.
Have a look at this series to get an idea of the possibilities:
http://www.ibm.com/developerworks/java/library/j-jsf2fu1/index.html
There are zillions of Java web application frameworks.
95% were designed before the modern era of AJAX/DHTML-based development, and that means these new methods are grafted on rather than designed in.
Has any framework been built from the ground up with e.g. GWT + Extjs in mind?
If not, which framework has adapted best to the world of forms with dynamic numbers of fields and pages that morph client-side?
Echo2 / Echo3 by Nextapp (www.nextapp.com) is totally awesome.
Advantages over GWT:
1) It is not limited to a sub-set of java like GWT
2) It is easier (in my estimation) to learn
3) Has extremely robust design studio for almost drag and drop designing.
4) It is very fast, and works very well on all platforms browsers
5) You can write your application using either java script or java
6) It has great and straight forward methods for handling events and actions.
Personally I think that for any web-application in which you are trying to integrate java and speedy delivery I wouldn't hesitate to pick Echo3 or Echo2.
If you're starting from scratch. I'd have to say Google Web Toolkit. I have to say it is incredibly powerful. You get keep using most of your Java tools. Plus, you don't have to duplicate code that exists on both the server and the client, it just gets compiled differently for each area.
I'd consider REST-style frameworks as well as the other recommendations here- Restlet or Jersey may be good choices for the backend, while you use something like JQuery or GWT on the front end. Both frameworks can easily produce JSON, and the REST style provides a nice clean line of demarcation between your client application and your server source; I find that JSF can make that demarcation pretty muddy.
I use JSF and IceFaces. Although JSF has a few limitations, IceFaces seems to work pretty well and has ironed out a few of the problems with JSF.
I haven't used a really good AJAX Java framework as yet, although Echo2 looks interesting.
I like the stripes framework. It lets you use whatever javascript toolkit you want.
Here is their documentation on AJAX
GWT is quite powerful and easy to use (all Java, no Javascript/HTML/CSS coding). If Google has their way it will be a dominant framework/tool in web applications development, and for good reason. It already works with Google Gears (which allows offline access to web apps) - and more than likely will be optimized to work within Google Chrome.
DWR
I use this to dynamically populate drop downs, and even filter them on the fly based on user input in other places on the form.
I like the combination of JBoss Seam and Richfaces, especially with the JBoss tools that are extentions to Eclipse - makes building these sort of RIA's incredibly easy.
Wikipedia contains some useful comparisons:
Comparison of JavaScript frameworks
List of AJAX Frameworks
Your choice depends on several different factors including whether you want the "work" done client-side (most javascript frameworks) or server-side (echo2 etc.). Other things worth looking at are tools like OpenLaszlo that provide Flash (I think) out of the box, but drop back to DHTML if there is no Flash player present.
Unfortunately I think the decision comes down to balancing several competing cocerns. Check out the comparisons and try them out - most come with online demo's for you to try.
Aptana has a server side frame work called Jaxer. This is from their site:
Jaxer's core engine is based on the same Mozilla engine that you'll find in the popular Mozilla Firefox browser. This means that the execution environment you use on both the client and the server are the same. It's Ajax all the way through and through. That means you only need one set of languages -- the languages that are native to the browser -- to create entire applications.
This framework is open source and has a very nice IDE based on Eclipse. Aptana is also working on a Javascript implementation for ActiveRecord called ActiveRecordJS. Potentially you could use this both client and server side with their framework.
GWT is one of the best AJAX framework that I used ever. Most important thing about this framework is that its maintained by Google. And Everyone know "Who is Google ?"
GWT is used by many products at Google, including Google AdWords and Google
Wallet. It's open source, completely free, and used by thousands of
enthusiastic developers around the world.
GWT provide rich widgets that can be used to built any application. Almost all the widgets they have.
Another important point is GWT is continuously developing and its also have stable release which is very good thing. Another thing Google has also released GWT-Material which is again a very good thing because everyone is moving toward material.
I hope this will help you!!!