This question was originary in my head as "Can I use AWT controls in a Servlet?", which will show all my ignorance on the subject.
I am new to JAVA technologies but after a bit of reading, I seem to understand AWT controls directly hook up the OS GUI elements so there is no way to use or extend JPanels, JButtons and so forth in a Servlet to be injected in a JSP and let the browser render those controls (an alternative could probably be embedding an applet in a JSP but I don't wanna do that).
I am looking for a way of building custom re-usable web controls using JSPs and Servlets.
How is this usually done and can you provide some samples/links?
EDIT: This is part of a test run I am giving to the Google Application Engine - so it would probably make sense for me to explore the Google Web Toolkit - any pointers in that directions would be appreciated as well.
Any help appreciated!
AWT is the OS-specific part of UI rendering on desktop, not on the Web side of things in which JSP, Servlets etc. live. A bit more specifically, things like Swing (which has those JPanels, JButtons and so on you mentioned as UI components) and SWT are currently based on AWT and work on top of it to render the UI and allow it to work as expected.
Unfortunately all this means you can't use AWT based components on Web pages since, well, Web pages are (usually) platform agnostic in the sense that they don't get to decide exactly how parts of the UI are rendered, there's just a pile of markup which is treated as a sort of plea to the Web browser to do things the Web designer hopes for without 100% quarantee that the end result will be what the designer wanted.
There's been a lot of reinventing the wheel to achieve Swing/AWT kind of UI creation on the Java's Web side since it's a clever model, like you seem to already know Google Web Toolkit tries to do its part to make Web seem more like a desktop application while in reality it merely automates the needed JavaScript Ajax underneath to make the web page behave as if it was a desktop application. One another framework for this is Tapestry which I haven't personally used but some think it's a decent choice too.
And then there's of course my personal favorite Apache Wicket which allows you to have a true separation between Java code and markup and it behaves quite similarly to Swing UI code too! In fact there's a whole bunch of name collisions with Swing's UI component classes for the most simple things. Assuming you're any familiar with coding a desktop application UI I strongly recommend Wicket, it abstract away the boring and tedious parts (Servlets, URL resolving, page bookmarkability, security...) and replaces them with an event-driven model similar (but not equal) to Swing's EDT which is where the desktop UI magic would normally happen.
While this is going completely away from what you're looking for, with Wicket you can create such a set of POJO Web components that you can reuse them just about anywhere and thus get what you asked for. A word of warning though, Wicket assumes you really know how to code with Java and some laughably easy things may be tedious at first but in the end you should be quite happy with what you got.
In JSP you are probably looking for Custom Tags. Custom Tags are ways to create re-usable code components to be used in the display of JSP pages. There are some very nice ones out there such as those found in the struts2 framework or the display tags library.
But you can write your own or extend the existing ones with new functionality.
Related
Context:
I have created a 'desktop' (console-based) Java application in Eclipse. I am using several third-party APIs to help me with the logic of my application. There's currently about 1000 lines of Java code.
I would now like to make this application browser-accessible. All I require is a few buttons and a few tables. The buttons (including a file upload button), upon being clicked, would run my 1000-line java code, and then output the text results into a table or two. I might require a few drop down boxes. All that matters, is that the application is accessed through a typical Web browser.
In another project, I have previously used ASP .NET Web forms (C#) to create a browser-accessible Web application and it was extremely straight forward. I simply dragged and dropped the buttons and tables I required. And coded the logic behind each button, and simply pressed "play" for it be usable through the local Web browser. I could do the CSS styling through VS to make it look pretty if need be.
Questions:
Sorry for my simplistic nature, but what is the "Java version" of ASP .NET C# Web Forms? - that is, drag and drop UI components for a web form that I can simply tack code behind, that can be easily deployed to a browser.
What's the "fastest" route I can take to achieve my goal? I simply wish to deploy my console-based Java application into a browser-accessible stand-alone application. It only needs to run on my local machine.
Notes:
From the reading I have done, it appears that I can use JavaFX for my purpose? - that is, create the UI and code the backend. And apparently, I can simply package the desktop-based JavaFX application to be runnable through the browser.
I apologise for any shortcomings of my question/context; I tried to keep it succinct so I may have generalised a bit. Not in the greatest mindset at the moment...
As for question 1, that would probably be JavaFX. It has the UI builder, and can be deployed to the web as well as to the desktop.
As for the general question, there are dozens of solutions, too many of which to cover here. The most straightforward and common solution would be to write a servlet. You would have to do all the mapping from HTTP URLs and request parameters to the appropriate model objects and then convert the model objects to HTML yourself.
Built on top of that are plenty of tools which can help you with the request mapping (JAX-RS, JAX-WS, Spring MVC, ...), and the conversion from model to HTML (JSP, Apache Velocity, ...), and everything in between.
In addition to Servlets and JavaFX, there are probably also several other options such as GWT and Flex. Figuring out which one is the "fastest" would be a broad and subjective question and so the best I can do is list some options.
I want to develop web sites rapidly with good looking easy to use components when needed.
I like python and java both (each with its own strengths).
from my small research it looks to me like i would like to use django for the general web sites framework (models, views, some generic apps like login, registration, comments).
and if i need like cool gadgets/components on my web site like some cool select boxes combo boxes etc i will use SmartGWT (assuming its possible to integrate it seamlessly inside my Django frameworked web apps), also i would like to outsource the templates to good html/javascript/photoshop/gimp ui designers...
does this sounds like a good way to go? :)
PS I want to stress out what i'm looking for: rapid development, large community, ready made open sources created with these frameworks (so i can look for examples), framework on top of these - so i have ready made components, easy development, availability to graphic designers so i can tell them design these htmls they bring it back to me and i have VERY easy integration, not falling behind the massive amount of SmartGWT amount of ready made components if django would be enough for me without feeling i miss all SmartGWT components i might choose only it, but i cant ignore the massive amount of components in SmartGWT.
thanks
I have been developing a Django + GWT site for the last 6 months. The last 6 weeks have been with a designer.
Django and GWT are both excellent ways of working. I'm really impressed with both... but if your key objective is "VERY easy integration", they might not be a good match.
Django's default templating is a bit rubbish compared to Flexy, PHPTal or Smarty. Mainly because the templates themselves end up being too cluttered to use in designer friendly tools like Dreamweaver.
GWT can be made to operate like JQuery where it takes stuff out of the DOM, messes with elements and then puts them back in elsewhere. This way of working would be fine with a designer but really you want a designer to style GWT widgets (as they are one of the most powerful features in GWT). Styling widgets then becomes an iterative process of adding hooks (CSS styles etc.) to various types of GWT panel and then trusting the resulting combination of CSS+JS+HTML fits what the designer was expecting!
The main problem is the overlap of CSS, HTML, Django, AJAX and GWT. There are quite a few things that could be legitimately done in more then one place. A designer will need guiding in a iterative/interactive way. It's not like a few years ago when designers could just come back with a load of templates that a coder just sticks a few for loops and variable into.
I've been working in this iterative way for a while now and am slowly improving the separation of roles (designer, css-monkey, userface coder, sys. backend etc.) but I'm finding this separation much harder then it usually is with web-frameworks.
But ... the results are really good and we've produced an app. that is far ahead of PHP+JQuery type sites and will be much easier to scale, white-label....
Im working on coding a WYSIWYG document designer. The basic intent of this designer is to be capable of both reading(loading) and creating multiple documents written in a variety of templating languages (ZPL, XSL-FO etc).
Now for the sake of building a WYSIWYG designer, i plan to have an elegant UI which the user can play around with to create/edit the document.
The compulsory needs of the UI is that --
The UI should be such that the user must be able to pick or
choose elements and be able to drop them off on the UI. Once
dropped, the position of the elements should be capable of allowing
repositioning.
The UI must associate the spatial postioning of elements to the
element's metadata (say, x coordinate,y coordinate, height ,width
etc).
The UI must be capable of seamlessly passing on the elements and
their spatial positions to a backend module,written in Java, that
would wither edit or create the document in the specified templating
language.
Im having trouble in deciding what to implement the UI in. I tried Swing and found it to be not great(was pretty rigid for my needs). Any suggestions with regard to what can be used to build the UI described above would be of immense help.
Your underpinnings options are pretty much Swing or SWT.
Not sure what you mean by "rigid"; Swing is a pretty good GUI framework architecturally, although some prefer SWT. Not sure how JavaFX will end up, but it has some nice features.
XUI layers on top. Or take the Griffon approach, although I'm not sure it's a great fit for the type of application you're working on. Or use Groovy/JRuby/etc. to make many aspects of working with Swing/etc. less painful.
IIRC there are Java bindings for QT as well, if the QT licensing works for you.
Perhaps you'll be better served by some rich client platform (RCP) like Eclipse or NetBeans. Both are probably best known as IDEs, but the IDEs are actually built on top of the respective platforms. Using an RCP will take a lot of responsibility out of your hands. Existing plugins/modules can be made to interoperate with your code and facilities such as perspectives (Eclipse) or rearranging panels are accounted for.
Like Dave Newton hinted at, JavaFX could also be a candidate. JavaFX 2.0 is now out and no longer requires the scripting language used in 1.0, instead opting for a Java API that'll feel more natural to experienced Java developers. And it can be used within Swing.
I am no artist/designer so usually my GUIs well, you know... I've tinkered a bit with GWT and I was able to get sensible results but I feel I have used contrived ways of getting those results.
If the community feels this question could help: please put one recommendation per answer.
We identified the following high-level best practices for GWT 1.6/1.7 (just after 3 months of research and development):
Use design patterns (MVC/MVP, Command for GWT-RPC, Composite for widget composition, Observer for event bus, etc.);
Isolate application logic with MVP by abstracting out widget classes and views using presenter display interface and GWT characteristic interfaces (such as HasValue, HasText, etc.);
Use dependency injection with gin on a client and Guice on a server (or stick with existing server framework like Spring);
Use GWT Composite in combination with HTMLPanel to drive your views with html, css and MVP;
Use mock testing based on isolation of application logic with MVP;
Implement Event Bus with GWT HandlerManager;
Use GWT modules to effectively optimize code compilation;
Use client, shared, and server packages when organizing GWT modules;
We have developed a large HR portal with GWT. The look and feel of this application can be customized for different deployments. To do this we use fragments of HTML to generate parts of the GUI i.e. bits of HTML are sent to the client in DTOs and then stuffed into HTML widgets. This approach works well for mastheads, logos, menus and so on.
Other things (e.g. capture forms) are generated using normal GWT code.
We use "pages" (different history tokens identifying where you are) as this makes it possible for users to use bookmarks in a meaningful way. We also generate links to different parts of our system in emails and so on.
Our application is composed of a lot of "higher level" widgets we call "Portlets" arranged into "pages" defined in XML. Again this makes it possible to customize the functionality for a given installation.
All this is done using a framework (GWT Portlets) that we have published as open source.
The best practice is to do everything from Java, so your HTML only acts as a placeholder. Yes I hate to say this, but if you're still messing around with the HTML it only makes your life more miserable.
If you still have the only web mindset, which is separating webapps into several html pages, throw that away, get the building the desktop app (that run on the browser) mindset. Think of building swing apps.
If you need to style the GWT components, override the GWT's css classes in your own CSS.
The last best practice is to decouple your application with the MVP pattern. The reason is because you can basically write the whole application in one Java class, which of course can lead you to maintenance hell, and problems if you are working with several peers.
This seems to be a question where the answer is implicit, hence I can't find anything explicit.
Does Google Web Toolkit only support custom layout managers, or a sub-set of the Java layout managers?
For example, is it possible to take a Java Swing application using GroupLayout and get it to work with GWT?
GWT layout support is done through subclasses of 'Panel'. Some of them like 'DockPanel' behave a little bit like Swing layouts (BorderLayout) but there's no way you'll ever be able to take Swing code and compile it into GWT.
This is a common mis-understanding when it comes to GWT. It's written in Java solely because Java is statically type and widely supported with world class editors. The fact that it's written in Java has nothing to do with any desire by the GWT team to allow you to port SWT/AWT/Swing to GWT. The web is a different environment to the desktop, and since your code ends up compiled into javascript it would never make sense to take any kind of Java Desktop application and hit the convert button. That's what Applets tried to do many years back...and we all know how that turned out ;)
No, GWT doesn't support Layout managers from Swing/AWT. These are not compatible.
Source of incompatibility is that those are totally different technologies with different APIs. Swing/AWT is pixel-based, while GWT renders to HTML. GWT layouts simply output different HTML tags (div/table/inline elements, ...), while Swing/AWT layouts do actually compute position of children components. In GWT, position of children is computed by browser, when they are displayed.
Most bottom line issue is that World Wide Web isn't Desktop Application no matter how much you'd want it to be. There's numerous issues involved, these are some which pop into mind:
WWW is stateless, desktop applications aren't. WWW is made stateful usually by cookies, URI parameters and session management and now that we've those for a couple of decades, we've mostly gone over the stateful/stateless issue of WWW.
WWW pages are (nowadays) described with some form of XML and usually CSS, in which the page is described as a tree. Comparing to Desktop Applications, while it's possibly to do nearly the same with XML and just plain component clustering, it just isn't the same. Once again one of the biggest issues is that in DA those components, widgets are stateful by nature on the application level while in WWW you can be truly stateful on the page level at most and even that requires JavaScript/AJAX.
So, direct use of layout managers is a no-go. But, assuming the Web UI Framework you're using allows it, you may create something that behaves quite similarly to layout managers. While I don't know about GWT specifically, I believe that one could do at least a simple layout manager in JSP (or my favorite, Apache Wicket) and make it behave just as the Swing layout managers do.
Note that I really do mean re-creating the whole concept of layout managers here as a set of specialized classes/whatnot, just as Peter Štibraný replied, GWT doesn't support them directly (in fact I haven't heard anything beyond Swing does) and I believe it would be more of an effort to create a wrapped/adapter for Swing Layout Managers instead of just creating your own, properietary ones for WWW.
IF you want a Swing Web application, consider AjaxSwing, but be prepared for network latency and consuming server resources. I think as soon as there's libraries for SVG/VML, we'll see more stuff move to the web. If you want to see a JavaScript IDE, check out Lively Kernel from Sun Labs. Have people tried porting Swing to GWT? It seems evident that there's AjaxSwing that a lot of Swing Could be ported to GWT, just perhaps not the Java2D stuff. Probably some smart company will figure out how to convert Swing to web client technology.