I'm a complete noob when it comes to portlet development. I have a task which is to take a fairly small static html site and incorporate it into a portal/portlet environment.
My first thought is to develop one portlet that contains the entire html site within it.
Is this just a terrible idea?
If not, then I know I could make a simple portlet with an iframe to pull in the html for the site, but is there some other way to make a portlet that is a full functional little website?
Any help is greatly appreciated.
That's a pretty vague question, but I don't see why ou can't do what you're trying to do.
The Portlet API is pretty unpleasant, though, and makes the servlet API look fluffy and joyous. I suggest using Spring's Portlet MVC support to make it a bit less painful.
I dont think that you can and want "put" a whole website into a portlet because of the limitations of the api. Even if the website is servlet based that seems not to be a good idea.
From a user perspective you should perhaps focus on your widget idea. Think about a smaller subset that encapsules the functionality of the website that should be embedded or write an aggregator for the information of the site.
Think about why the website should be integrated and which information of the site are the most important ones. Perhaps there are any other information exchange interfaces like rss or atom feeds that you can use.
Another solution would be to use an existing cms-like portlet that can be "filled" with content. Here are some examples: http://www.jboss.org/portletswap/portlets_collab.html
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.
I am quite used to creating user interfaces with HTML/CSS/JS. However, I am working on a JAVA application that utilizes Wicket.
Can anyone point to me anything that shows how to create a ui with Wicket, from a stand point such as mine? If that makes sense. I have been trying to understand how I am going to develop the UI after reading many articles and meeting with our developers. I am just not wrapping my head around how to do it.
Also, from what I know, does it make sense to actually use Wicket when you have a ui designer and developer on staff who can create an MVC UI from scratch?
Please, if this doesn't make sense I hope you feel compelled to ask questions to pull whatever info you need and I am not saying. I am desperately trying to figure a.) does wicket make sense still, b.)how in the heck do I build a UI using it!
I think it can't get better than the examples in wicketstuff. You can just parse through the forminput sample. The sourcecode button is on right top.
There is indeed a small curve related to getting started with wicket as it changes the complete direction of thinking towards web GUI.
Basically, the idea of wicket is to have HTML template pages with some wicket markup placeholders that will be filled by the parallel java class.
The best way is to start looking at wicket tutorials on the official Wicket website. Then there is wicketstuff, which also has a very comprehensive collection as mentioned by Suraj Chandran. Most examples show you both Java and the associated HTML markup.
Even if you are not a Java developer it would be beneficial for you to understand how different Wicket markup tags get interpreted and how a Wicket-based application is built from several HTML pages, borders, panels and other Wicket-related components.
Wicket is very good for separating Java code from HTML (much better than frameworks that use JSP, PHP, and other technologies that mix code with HTML). Because there is no Java source code in the HTML pages it makes it easier for designers to work independently of the developers. Also HTML files can be edited in HTML editor programs like Dreamweaver directly.
If you are a Dreamweaver user and are familiar with Template and Library functions, then in the Wicket world you will find very similar concepts. Dreamweaver Template = Wicket Border, Dreamweaver Library Item = Wicket Panel, for example.
I have a Java-application using Wicket for the frontend. Now I want gradually switch over to WordPress-frontend. First off, the startpage is going to be in WordPress. Is there a good way to use Wicket in conunction with WordPress? Wicket is so tightly coupled with the Java, I was unsure of how to do it.
If anyone can give me some best practices or tips, or links to people who have gone through similar scenarios i'd be very grateful.
To start with, what you are looking to do is likely impossible in the same runtime container. There are ways to run PHP in Java (Quercus comes to mind), but some applications are not well suited for this.
If you want to run in multiple containers, you may be able to fake this out at the browser level with iframes, but you will need Wordpress plugins that can orchestrate setting iframe destinations to your current Tomcat container running Wicket.
It would be helpful to understand why you are doing this. Wordpress has an excellent product, and this isn't to discourage you from going that direction. But if you are just trying to gain CMS functionality, you may want to check out Brix, which is a Java Content Repository backend for Wicket.
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).
Coming from PHP with some Java Struts 2.0 experience any tips/tricks on learning GWT? I have been looking at some tutorials but just wanted to know if anyone has some great gems to pass along?
As someone that has done PHP, Struts2 and GWT, a good tips from me for someone that is coming from web framework like Struts2.0/PHP would be:
Throw away the old mindset, the mindset that a web framework works in request-response way. That's not how GWT works. GWT is a full ajax framework. Get a good understanding of AJAX and throw away those old mindset to get a good grasps of GWT.
Think in application development and not website development. That would affect the way you build navigation in your application with GWT.
You are not building hyperlinks to navigate between html pages, but you are using an event listener to update a partial content in your application. Get a good understanding of this.
With that in mind, always remember that you are not throwing back full html pages, but just updating a partial content in your application
Get a good understanding of Java anonymous class and inner class because you will use this alot in GWT. This is something that is used rarely if you are building with Struts2.0
The last tips would be to learn how to organize your code. If you can do it from beginning, please do so. Because you can write everything in one class if you want to. A good tip would be to take a look at this video on best practice on GWT.
Nothing beats Google's GWT quickstart (IMO):
http://code.google.com/webtoolkit/gettingstarted.html
I agree with karim79. Also add this to your list: http://examples.roughian.com/
GWT developers still need good HTML and CSS skills. It is sometimes useful to build up chunks of HTML on the client or server side (performance, skinning etc.) and not build every part of your GUI using GWT Widget trees in Java code.
Our framework (GWT Portlets) will help you structure your application. It includes a simple demo application in its own directory that you can copy to start a project.