Formatting data in jspf fragment

[Pranava Sheoran]

Hi,
I am a complete beginner to jsp and jspf. I have a jspf fragment which is inserted in a jsp file. The fields in this jspf file read values from a managed bean like <h:inputText id="TtlInptBx" value="#{beanName.fieldName}" size="21">. I want to sanitize the value returned by #{beanName.fieldName} and escape all the javascript tags in this string. IHow can the TtlInptBx read its value from a string defined in a jsp section in the same file. The string in this jsp section will read its value from the managed bean somehow. I don't have the option of sanitizing the data in the java code for the managed bean. Any help or guidance on how to do this is really appreciated.

Thanks
Pranava

[Tim Holloway]

Welcome to the JavaRanch, Pranava!

I think you need to get some basic concepts straight.

In JSF version 2, there is no support for JSP/JSPF. JSF2 uses a View Template Language (also known as View Definition Language), which is an xhtml-format resource. And the concept of "JavaScript tags" doesn't exist on any J2EE platform I know of.

JSF is based on Model/View/Controller where you define the Model (backing beans) and the View (xhtml) and the Controllers are pre-defined parts of JSF itself. Views don't "read" or "write" and neither do the Models. Instead the Controllers automatically transfer values to/from the Models as part of the submit and render phases of the JSF lifecycle.

The JSF models are UI model objects, and any shop that forbids modifying them is not using JSF properly - they are probably trying to force Domain Model objects to universally serve as UI model objects. Since JSF is POJO-based, you can sometimes present a Domain Model Object as a UI model, but for advanced usage, it may be better to use a UI model as a façade object in front of the domain model. For example, when dealing with Domain models that don't support boolean properties (a lot of databases don't), but you want to use a checkbox on the View. Or in cases where you need to convert data in some way that the ordinary JSF converters cannot support - JSF converters are intended to convert from binary to character form and back again, and cannot handle character-to-character or boolean-to-character.

[Pranava Sheoran]

Thanks for your reply Tim.But I am dealing with a huge codebase using JSF 1.1 and my only option is to change the jspf file provided to me. So it not possible at all?

[Tim Holloway]

It is possible, but the same rules apply to JSF 1.x as do to JSF2. Other than the deprecation of JSPs in favor of XHTML (which was an add-on in JSF1), there's no significant code or architecture difference. Mainly I wanted to point out that JSP isn't part of the current JSF architecture. Not that even JSF1 "JSPs" really acted like traditional JSPs.

Too often there is an assumption in IT that "If it ain't broke, don't fix it" applies. In IT, your code doesn't have to break to get broken. The world moves on, and software that doesn't keep up will first lose support and then eventually stop executing reliably because the world in which it lives has changed. At least unless it's 1960's COBOL code. So I hope someone has budgeted funds and time to migrate to JSF2 before too long. Otherwise, like the dinosaurs, you may receive a rude shock someday. And Murphy's Law predicts that that someday will be a very inconvenient day.

[Pranava Sheoran]

Hi Tim,
There is a plan to revamp the whole application next year but for now I have no choice. Is something like <%String myVariable= beanName.fieldName; EscapeHtml(myVariable);%><h:inputText id="TtlInptBx" value=myVariable size="21"> where EscapeHtml() is just a method that returns string. Is something like that possible. And if yes, then can you give a hint as to how to do it.

[Tim Holloway]

Well, to work my way backwards, JSF requires a Value REFERENCE expression on an input control. That's why they have EL constructs like value="#{myBean.myProperty}" instead of "${myBean.myProperty}". Because the JSP "$" notation is strictly read-only, and JSF needs read/write. Nor does JSF support free-floating variables for value expressions. They have to be references to properties of Java objects in Request, Session, or Application scopes. Page scope is not supported by JSF. And, for that matter, scriptlets aren't likely to function well, either. Scriptlets are designed to function in conjunction with JSPs that compile into Java Servlets, and JSF View Definitions actually compile into data structures, not executable Java code.

For output-only controls, the h:outputText control has an "escape=" attribute that determines whether the value it displays will output as pure HTML or with escapes so that the actual raw HTML tags can be seen. Very simple and it works with JSF1.

But HTML itself cannot support input controls done that way, so neither can JSF, since JSF is built on top of HTML. About the only way you could alter inbound text would be to buffer the current backing beans that need that sort of functionality with a façade backing bean that does the translation before passing it on to the legacy bean.

[john lazeraski]

Ouch.. tough decision.. this reminds me of not too long ago..well about 10 or so years ago when we were using shtml files, trying to use a template engine to process the shtml file to replace $$tokens$$ for dynamic content. Mean while, JSP 0.7 came along, and soon JSP 1.0 with the MVC model 1 architecture, which was "better" (sort of) than the shtml way we were doing things. The problem was, shtml and jsp were not the same thing.. the cool thing was, we could do one page at a time.

I would first take what Tim is saying to heart.. even though you say there is budget for a move next year, are you in any position at all to suggest moving to say Tomcat 6 or 7 (not sure what container you deploy in). Tomcat 6 I believe supports JSF 1.x apps, but ALSO supports JSF 2. The same would be for GlassFish 3 or JBoss 5 or something. My point is.. if you can move to a container version with minimal effort that supports both versions, you may open up a case for you to slowly work on a JSF 2 page, converting an existing page to JSF 2 in the process, one step at a time. This would allow you to use the now standard JSF 2 right way of doing things, while keeping the existing app in place. I was surprised when JEE 1 came out how easy it was to quickly built a WAR and EAR file, modify our code a slight bit, and deploy and have things working. I would imagine it wouldn't take too long if you spend a few hours each day extra (if you can and if it will pay off) to move to a better supported platform, even if it's on your own accord on your own computer to see it work. This may give you a good learning experience as well and then perhaps you can show your peers or boss and show them how easy it is, why it is better, etc.

Anyway, just some thoughts.. I know in many cases we developers are just pawns on a board and have no say in anything. That is why I prefer smaller teams, where everybody has a say and is important to the project.