There are two solutions for that:

1) Use CDATA for such sections of data, f.e.

or 2) Use escaped HTML sequences

When we create tag library for JSP everything is straightforward: tag library schema support all this information. So we simply create something like that:

Listing 1.

and in page template we include this tag library using taglib directive:

After that IDE does all the magic and when we try to insert new tag it helps us to correctly type it, reveals all its possible attributes, their state, etc.

Problem with facelet code completion.

What happens when we try to do the same thing for facelets? Problem is that facelet taglib DTD does NOT support attributes and their special settings. According to it, it supports only name of component/renderer, converter or validator. These names are then looked up in faces-config.xml and are mapped to appropriate java classes. Then facelet framework invokes getters/setters on these classes using reflection API.

Listing 2.

What’s inconvenient in this approach is the lack of full support of code completion. IDE doesn’t know about tag attributes and their special settings, so it can’t help page author in fullfilling correct data. That leads to lot’s of typos, which can be found only during runtime.

Solution.

How to avoid it? I did it by creating another “dummy” tag library. It’s very similar to the one above with the exception that no tag class is specified. TLD is USED at runtime, it only helps to enable code completion and validation for tag attributes in IDE. Small excerpt from it:

Now it’s time to do final thing: let’s make sure your IDE reads exactly this “dummy” tld and not the one in Listing 2. For that we need to map URI of facelet tag library to the location of dummy tag library. In IDEA it is done like that:

1) File->Settings->Resources
2) Add external resource (<facelet_taglib_uri -> <path_to_dummy_taglibrary>)
3) Enable “Project-related’ checkbox.

That’s it! Now when you edit your xhtml IDE provides you with full code completion support for all your tags and functions.

Problem using JSF with JSPs.

First of all, why does our platform need facelets? Currently we are using JSPs with custom JSF tags inside so what’s the problem with combining JSF and JSP? There are lots of good articles related to this topic, so I won’t be repeating their authors. I’ll just briefly sum up main idea.

• JSP’s goal is to produce static and dynamic content based on HTML/scriptlet mixture; technically speaking JSP produces a servlet. JSP page is processed in one pass from top to bottom, with JSP action elements processed in the order in which they appear in the page.

• JSF maintains component tree where components are created, asked to process their input (if any), and then asked to render themselves. These three actions must be processed separately in a well-defined order.

The root cause of all confusion is that the life cycle of the JSF component model is independent from the life cycle of the JSP-produced servlet. So using JSF components via JSF custom tags lead to the problem that component creation and rendering happens in parallel, causing all kinds of bugs (see “Improving JSF by Dumping JSP”).

Ok…then how do we (still) manage to survive with JSPs in our platform? Apart from God’s help we are relying on custom-made hacks. Hacks are integrated in all parts of JSP-JSF bridge; if some day I have a courage I could possibly write an article describing most interesting ones. All in all, main drawback of these hacks is that view layer in our application became slow, clumsy and what’s even worse – hard to maintain and upgrade. And it’s getting worse with each iteration.

What’s so special with facelets?

Facelets is a view technology for JSF that replaces the standard view handler which deals with JSP pages. It is built from the ground up with the JSF component life cycle in mind. With Facelets, you produce templates that build a component tree, not a servlet. Facelets is a powerful templating system that allows you to define JSF views using HTML-style templates, reduces the amount of code necessary to integrate components into the view  (see “Facelets fits JSF like a glove” for more detailed information).
By using facelets in our platform we’ll become closer to native JSF life cycle. Fast templating and possibility to create reusable composition components will allow us to keep DRY principle while developing new pages. Developing web part of our application should significantly reduce programmer efforts and (who knows?) may become a real joy for him (isn’t it what a Real Developer wants ?)

We revert deletion of legacy code support. Phew, ok – story seems to be done. Let’s measure performance once again… Bingo, results are still very good, no test fails, we can commit our code to trunk!

Resume

Story is done, signed off and committed to trunk. I feel myself satisfied with results we achieved but even more I’m pleased with the way we worked during last 4 days. It seemed to be a bit chaotic and funny in the beginning, but then everything went pretty fast and we were all tuned on the same wave. The difference between in-office and inter-office pair programming was practically invisible after we established environment. Everybody knew what his teammate is doing, everybody could follow his colleague’s ideas and bring his own ones. Everybody discuss them and finally team comes up with certain solution. Nice try!

Ok, let’s continue working in “secretary-boss” style once again.. No it’s a bit quicker, we begin to better understand each other. Christoph joins us, now we are three in the developers chat now! Initial task is quickly done, but now we think if we can improve our implementation even more. I want to take active part in coding not just by typing ideas in skype, but also in IDE. That leads us to establishing alternative VNC server. Christoph uses Windows and RealVNC. I try to connect to his server – bingo! I can even type there. We exchange several good ideas about code refactoring and found new task to implement – automatic generation and validation of persistent classes with ant.

First idea is to establish chat and voice chat as well – skype seems to be the best candidate. Also we should somehow establish desktop sharing. Andrea tells me that she already set up some VNC server on her MAC. I never worked with VNC software before, so a quick search in google gives me several good candidates to start with (RealVNC for Windows and tightvnc for linux). Set up clients on both OS. Trying to use RealVNC – oops, it cannot connect to VNC server on MAC. 

After investigation it appeared that there’s a known problem with connecting to MAC via VNC protocol. Workarounds don’t work. Trying to use tightvnc…works fine! I can see Andrea’s desktop, can even manipulate her mouse, but not keyboard. We decide to establish “secretary-boss” approach for the first try. Andrea types and I watch her typing and correct or propose new ideas. Pretty funny, but a bit slow and non-effective way. Let’s see what will be tomorrow…