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.
Related
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).
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
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.
Just wanted to ask if anyone knows of a reliable & easy way to expose a webservice (wsdl) as a webform to end-users.
Our team develops a lot of software for external contacts, which often involve creating a web service and exposing it as both a wsdl and a website. We'd like to automate this last step as much as possible (especially for the mindless data-pumping projects) so we can concentrate on developing web services instead of websites.
I recently came across Enunciate, but have not found the time yet to play with it in detail. I was wondering if anyone has any experience with it (or with any similar projects) what your findings are, and what direction you would advice us to take with this.
Best regards,
Tim
Update2:
Turns out what I need is perfectly described in this Enunciate module: http://jira.codehaus.org/browse/ENUNCIATE-23. The only problem is that it's not implemented... (yet?)
Anyone have any experience in creating your own modules, or knows of an existing solution that provides the same functionality?
I'm not sure how much weight my response carries (since I'm the lead developer of Enunciate) but I'd like to encourage you to try it out. I know a lot of happy Enunciate users.
Even if you decide not to use it, I'd like to hear about your experience and why you decided against it.
I've found that using the Metro libraries to provide the web service engine, a web page is produced when accessing the end point with a GET which allows you to easily get the WSDL if you need it.
I do not know if that is what you mean with a "web site" but it is a nice default way to work.
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!!!