I am working on a Swing application and would really love to declare my views in an XML format in fashion similar to GWT's UiBinder, JSP, JSF, ZK, IceFaces, etc.
I found JFCML but it doesn't appear to be an active project; in terms of development as well as use/reference.
Have my Google skills failed me or does something like this not exist? If it doesn't exist, is it because such methods of separating view and controller are better done another way in Swing?
The "built-in" solution is the XMLEncoder - XMLDecoder pair, but they are not widely used, I am not sure that they can cope with real-world scenarios.
A lot of open-source libraries have been suggested already on SO, I recommend these questions:
suggestions for declarative GUI programming in Java
Java: Create a GUI with XML?
Is XML or XUL the future of Java GUI building?
Java form from xml
Related
I've recently started playing with Play Framework and I was wondering: is there a way to write my templates using not Scala but Java?
E.g. this link http://www.playframework.com/documentation/2.1.0/JavaGuide3 provieds great tutorial to start with, but some Scala code makes it really hard for me to understand almost anything...
I mean, I could learn that much but it would be amazing if it's possible to write all in Java
Sure, you can use Freemarker as a template language.
https://github.com/guillaumebort/play2-freemarker-demo
You can effectively use Freemarker and you can also don't use server side compiled template :
Create Rest API
Put html template in public directory
Use javascript for populate view (html)
For structure your application, Angular could be a good solution.
I've downloaded primefaces sources to see if I can learn from them. The jar contains a bunch of java classes that use writers to handle the rendering etc. I was expecting to find some .xhtml files with
<ui:composition> ... </ui:composition> and <cc:interface> etc etc
Anyway this got me thinking, is there another way to write facelets and composite components or they wrote everything in xhtml files then compiled them to java classes? Sorry if my question is absurd I am new to JSF.
Template files and composite components are just for enduser's convenience because it's easy to write and use them. The basic JSF implementation (the f: and h: components) and component libraries like PrimeFaces use fullworthy UI components. That are classes which extend JSF UIComponent class.
Development of UIComponent classes is relatively complex and clumsy. You've got to take a lot of things into account when developing them, such as writing tag files (you've to define every attribute in a XML file), configuration files (link component and renderer with each other), etc, but you end up with a more modular and reuseable model and better efficiency. They are even useable on plain old JSP files.
Facelets templates are unlike JSP files not compiled to Java classes. They're just loaded and executed by a SAX (XML) parser which is by itself already written in Java.
Update as per the comment: it will in general perform a tad better if there is relatively a lot of business/conditional logic involved which is in no way related to the view, such as a heap of <c:if>, <c:choose> etc tags based on non-user-controlled input.
The book JSF 2.0 The Complete Reference also covers custom UIComponent development in chapter 10 "Noncomposite components". The Java EE 5 tutorial covers it as well, but it's targeted on JSF 1.2. It's unfortunately not in Java EE 6 tutorial for JSF 2, although the technique has not changed, but there are several new annotations which you need to know about.
One more advice in case you want to patch around in the sources of primefaces2. It uses a org.primefaces.maven-jsf-plugin which generates many of the .java files. I once tried to patch one of them and I was surprised that the change always was lost after a mvn package
Apache Tiles framework is great. But one thing I hate about it is the large xml configuration file that I have to maintain, even if partitioned, I just hate placing programmatic and presentation information inside configuration files.
I just don't get it? How did struts/tiles authors reach this obsessive tendency to place so much presentation logic inside configuration files?
I'm searching for a framework like Tiles but without the bloody XML configuration. Anyone can help in listing layout frameworks based on the Composite View model that compete with Tiles.
Sitemesh. Sitemesh is a similar system for templating pages but can be done without xml. This is especially nice if you have one or two main templates that you keep using over and over, no need to create an xml entry for each and every one. It's currently the default templating system in Grails. Sitemesh 3 has some nice additions but as of the time of this writing is stuck in beta with almost zero documentation. It uses the decorator pattern as seen in all of the comparison of tiles vs sitemesh.
Alternatively if you are willing to give up on jsp, you can give a go at JSF 2.0 which has very impressive templating capabilities with no xml needed. That along with the JSF component model for server side code will certainly assist in cutting down repetitive code. (As a bonus the Primefaces component library for JSF 2.0 is one of the most impressive component/widget sets around.)
Have you considered Apache Wicket?
With proper mark-up/logic separation, a POJO data model, and a refreshing lack of XML, Apache Wicket makes developing web-apps simple and enjoyable again. Swap the boilerplate, complex debugging and brittle code for powerful, reusable components written with plain Java and HTML.
Apache Tiles can be configured without using XML.
The layout tags provided by stripes are excellent. Require no configuration at all and easy to comprehend and start using. They are so great to an extent that I think they should be extracted from stripes and maintained as a separate project on there own github project space.
You can see a Tiles example with Java config (no XML) in this SO post.
The idea is to implement the DefinitionsFactory with a TilesDefinitionsConfig of your own and call tilesConfigurer.setDefinitionsFactoryClass(TilesDefinitionsConfig.class);. Your new config contains the layout definitions.
(WARNING: this is my first java application, coming from .NET, so don't bash me if I write too much garbage)
I'm developing a simple JSF 1.2 web application which should support Russian, Chinese, and other languages outside ISO 8859-1, which is automatically used in Properties.load().
Is there a way to use the Properties loaded from XML files, with Properties.loadFromXml(), inside JSF, without writing too much code?
I know there are alternative ways to do so (writing my own loader, escaping the characters...), but I'd really love to find a simple solution, and I don't see it in all the forums I checked.
Thanks in advance for any help
I think the most widely used approach is to encode your .properties files with unicode escape sequences. This can easily be done with the AnyEdit plugin for Eclipse.
The problem is that ResourceBundle uses the Properties(inputStream) constructor, rather than Properties(reader).
You can use your own LoadBundle component instead of f:loadBundle to overcome this, but you'll have to:
extend the original one
define it as custom component (facelets and/or jsp)
define a new ResourceBundle implementation
instantiate it, using new InputStreamReader(classloader.getResourceAsStream(..))
I am a beginner in accessing backend XML files (which act like a database) in JSP code. Can anyone please provide me the links and references that provide good understanding for beginners like me? Please help.
Some tips when working with JSP: Keep as much code as possible outside of the JSP. I've had very good results with creating a helper object at the top of the JSP. In the HTML of the JSP, I can then call the methods of the helper object to get at my data.
This way, I have a normal object (which doesn't depend on the JSP cra....framework) which I can test and use just like any other object.
So my suggestion is to create a couple of objects which allow you to access the database. In the JSP, have as little actual Java code as possible.
You may want to take a look how to implement typical webapp design patterns in J2EE (see e.g. Sun's blueprint describing the webapp designs). Depending on complexity of your application, make a decision which pattern to use. You may also choose to use some of existing MVC frameworks build on J2EE (although I'd not advise that to a beginner).
Building a model classes around your XMLs would be a good start (there is a variety of ways to process XML in Java, check e.g. JAXP). Once a model is ready, you can start using it in your JSPs (implementing the view and controller per the pattern you will choose).