<!DOCTYPE faces-config PUBLICI think the DTD version might have changed (to 1.2?) since I last used the reference implementation from Sun. This is a surprisingly common problem for people just starting out with JSF. A few books I have reviewed don't mention that configuration files (including web.xml) are validated by the container during deployment.
"-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN"
"http://java.sun.com/dtd/web-facesconfig_1_1.dtd">
Monday, April 30, 2007
cvc-elt.1: Cannot find the declaration of element 'faces-config'
If you get this error while trying to deploy JavaServer Faces (JSF)-based applications, just make sure your faces-config.xml configuration file has the reference:
Sunday, April 29, 2007
Creating Custom Tag Actions For JSPs
Custom tags are used to extend the JSTL, and are especially important when you decide to go scriptless in JSPs like I recently did. The process involves three actions: creating the tag handler class, creating the tag library descriptor (TLD), and updating the deployment descriptor (web.xml). This example creates a custom action that can be used in JSP pages to format dates for display in the resulting HTML.
The example is done in the NetBeans 5.5 IDE (with Sun Java System Application Server 9u1). NetBeans makes this process a no-brainer. I still encourage you to learn to write these tags by hand - for debugging and troubleshooting. Almost all Java web-oriented IDEs have similar features.
Create the Tag Library Descriptor (TLD):
- This is where your application looks up references to tags used in JSPs. It can refer to individual tag files or other libraries.
Creating the Tag Handler Class:
- This is where what the tag does is defined. It follows JavaBean conventions and implements tag extension interfaces (such as SimpleTag in JSP 2.0).
- Unfortunately, the IDE does not update web.xml (and you need to if you are not using JSP 2.x).
- You have to manually add the tag-lib node under jsp-config.
- With Java EE 5, you do not need to do this step.
Use the Custom Action in a JSP:
The example is done in the NetBeans 5.5 IDE (with Sun Java System Application Server 9u1). NetBeans makes this process a no-brainer. I still encourage you to learn to write these tags by hand - for debugging and troubleshooting. Almost all Java web-oriented IDEs have similar features.
Create the Tag Library Descriptor (TLD):
- This is where your application looks up references to tags used in JSPs. It can refer to individual tag files or other libraries.
- Open the web application you want to add custom tags to in NetBeans IDE.
- Right-click web module | New - File/Folder - Web - Tag Library Descriptor, click Next | provide a name and prefix. Click Finish.
- A basic TLD is created. I normally remove the uri tag and commented text from the generated TLD file - keep things tidy.
Creating the Tag Handler Class:
- This is where what the tag does is defined. It follows JavaBean conventions and implements tag extension interfaces (such as SimpleTag in JSP 2.0).
- Open the web application you want to add custom tags to in NetBeans.
- Right-click web module | New - File/Folder - Web - Tag Handler, click Next | provide a name and package. Click Next. Provide the path to the TLD file we just made above to have its information added automatically. Provide attributes on the same page.
- The TLD is updated and the handler class created, complete with setters for all the attributes you specify. Only thing you need to do is modify the doTag() method with what you want the tag to do.
- Unfortunately, the IDE does not update web.xml (and you need to if you are not using JSP 2.x).
- You have to manually add the tag-lib node under jsp-config.
- With Java EE 5, you do not need to do this step.
Use the Custom Action in a JSP:
- Reference the TLD using the taglib page directive. Remember you can use Ctrl+Space in NetBeans to have the some of the directive's fields autocompleted for you.
- Use the tag to format some dates.
Monday, April 23, 2007
Move To Scriptless JSP A Pain
If you plan to use 'scriptless JSP' in your Java web applications, it is much easier to start out with the idea than hope to convert existing JavaServer Pages (JSP) after building your application. Scriptless JSP (s-JSP) involves moving all Java code, scriptlets, declarations, and "set operations" away from JSPs to servlets, leavings the JSPs display-oriented. Dynamic content in the JSPs is then provided by a combination of the JSP Expression Language (EL), JavaBeans, JSTL/custom actions, and objects in mainly the session and application scopes.
Scriptless JSP is great for enforcing the MVC design model, allowing non-Java programmers to take control of designing the presentation/view a lot easier. It also conforms to XML specifications by using characters that XML engines won't freak about. For example, the '>' sign is known simply as 'gt' in EL - the day you wish to XML-ize your JSPs, the transition will be much easier from s-JSP than from regular JSP.
In my opinion, you better make the decision to use s-JSP before you start writing web applications. In fact, it is always smarter to use EL from the start - conversion to regular JSP is as easy as setting the el-gnored switch to false and scripting-invalid switch to false in web.xml.
Also, you should be very familiar with the Java Standard Template Library (JSTL) and know how to build your own custom actions. Because I could have Java code in JSPs, I neglected these topics only to discover they are important for s-JSP.
Also make sure your IDE supports EL fully. In NetBeans 5.5 (which does fully), I kept on seeing what seems like a discrepancy: when I use a statement like: <c:if test="${empty sessionScope["title"]}"> I get an error. But outside the test, I can obtain the title attribute from the session map by using ${sessionScope["title"]}. I must not be understanding something here. Why do I need to omit quotes (as in <c:if test="${empty sessionScope[title]}">) in the test to make the syntax right? With correct syntax, I can never find my object in the session. It'd seem as if the "title" attribute is a page-scoped object?
As a matter of caution, endeavors like this should be done on test systems first before moving them into production. I'll take this a step further - do changes like this move on test code before integrating them into production code. If I didn't use CVS, I'd be screwed just about now; fortunately, I was able to return to my original code from CVS. Save for the wasted hours, you must plan the move very carefully.
Scriptless JSP is great for enforcing the MVC design model, allowing non-Java programmers to take control of designing the presentation/view a lot easier. It also conforms to XML specifications by using characters that XML engines won't freak about. For example, the '>' sign is known simply as 'gt' in EL - the day you wish to XML-ize your JSPs, the transition will be much easier from s-JSP than from regular JSP.
In my opinion, you better make the decision to use s-JSP before you start writing web applications. In fact, it is always smarter to use EL from the start - conversion to regular JSP is as easy as setting the el-gnored switch to false and scripting-invalid switch to false in web.xml.
Also, you should be very familiar with the Java Standard Template Library (JSTL) and know how to build your own custom actions. Because I could have Java code in JSPs, I neglected these topics only to discover they are important for s-JSP.
Also make sure your IDE supports EL fully. In NetBeans 5.5 (which does fully), I kept on seeing what seems like a discrepancy: when I use a statement like: <c:if test="${empty sessionScope["title"]}"> I get an error. But outside the test, I can obtain the title attribute from the session map by using ${sessionScope["title"]}. I must not be understanding something here. Why do I need to omit quotes (as in <c:if test="${empty sessionScope[title]}">) in the test to make the syntax right? With correct syntax, I can never find my object in the session. It'd seem as if the "title" attribute is a page-scoped object?
As a matter of caution, endeavors like this should be done on test systems first before moving them into production. I'll take this a step further - do changes like this move on test code before integrating them into production code. If I didn't use CVS, I'd be screwed just about now; fortunately, I was able to return to my original code from CVS. Save for the wasted hours, you must plan the move very carefully.
Friday, April 20, 2007
Freedom of Fonts in Web Browsers
I really do not think it should be up to web page designers to dictate what font you view a web page with. There are websites you visit and you can hardly read content because someone specified some insane font style and size for the page, which works well if the viewer's web browser is left in defaults. If you in fact have the fonts and can do the sizes specified, trouble happens. I wish I could just avail a few fonts to a browser and force every website I visit to be displayed in just those few fonts as desired.
Also, don't developers ever test their sites across browsers any more? I've come across a few websites that work well only in IE or Firefox and suck in other browsers. Even if you develop for IIS only, it's imperative you test on other browsers ... unless you don't care about visitors that exercise freedom of browsers. At least have a disclaimer if you have to go that way.
For the rest of us that customize our browsers to the tee, including specifying a font and style, it becomes an annoyance. Preferences change often, but I like "Californian" and "Courier New" at 10pt for my pages - small font. If I were to visit a site that attempts to reduce the font size by 3 points (relative), for example, the text would be unreadable. This is where Firefox excels at giving control to the user - you can specify a minimum font and the browser ensures that all font sizes are always above that size. I don't know anywhere in IE where this can be done. In Firefox, you also have to unselect the option that allows pages to choose their own fonts.
I always recommend that when you design web pages, the bulk of your content shouldn't have restrictions on what font styles and sizes users should use. Most users customize these two things, and you'd be abusing your authority as an author to restrict that freedom. It's understandable for fonts that must fit on images or certain fixed spaces such as menus and ads. Developers that use templates that calculate font sizes based on available space, etc, are prone to this problem. I discourage using relative font sizing (e.g. <font size="-3">) for text that can be manipulated by browsers. User preferences with fonts and styles can also mess up your menus and such that depend on fixed spaces. For such, images are the way to go - to promote consistency.
Also, don't developers ever test their sites across browsers any more? I've come across a few websites that work well only in IE or Firefox and suck in other browsers. Even if you develop for IIS only, it's imperative you test on other browsers ... unless you don't care about visitors that exercise freedom of browsers. At least have a disclaimer if you have to go that way.
For the rest of us that customize our browsers to the tee, including specifying a font and style, it becomes an annoyance. Preferences change often, but I like "Californian" and "Courier New" at 10pt for my pages - small font. If I were to visit a site that attempts to reduce the font size by 3 points (relative), for example, the text would be unreadable. This is where Firefox excels at giving control to the user - you can specify a minimum font and the browser ensures that all font sizes are always above that size. I don't know anywhere in IE where this can be done. In Firefox, you also have to unselect the option that allows pages to choose their own fonts.
I always recommend that when you design web pages, the bulk of your content shouldn't have restrictions on what font styles and sizes users should use. Most users customize these two things, and you'd be abusing your authority as an author to restrict that freedom. It's understandable for fonts that must fit on images or certain fixed spaces such as menus and ads. Developers that use templates that calculate font sizes based on available space, etc, are prone to this problem. I discourage using relative font sizing (e.g. <font size="-3">) for text that can be manipulated by browsers. User preferences with fonts and styles can also mess up your menus and such that depend on fixed spaces. For such, images are the way to go - to promote consistency.
Subscribe to:
Posts (Atom)