PropertyKeys

You know, I'm searching the web and the good ol' Big Moose Saloon for information on PropertyKeys in JavaServer Faces and I find the information to be rather sparse. Maybe it's because all the other JSFer's out there are so much brighter than I am and totally understand them, but truth be told, I'm struggling with them a little bit. Not only that, usage, examples and tutorials that take java enums into any kind of indepth discussion are hard to find as well. It's kinda like, "Well, yeah, java has enums now....so let's discuss generics. "

I'm looking at javax.faces.component.html and viewing a whole section that goes into each individual components' inner PropertyKeys class and I wonder why I can't find more info on it. The java doc says that enum elements of these property keys are CONSTANTS but the documentation doesn't capitalize them like it does most other constants. Also, if you're using the default html renderkit that comes with Mojarra and you call a components getAttributes() method, are you calling into these PropertyKeys elements of whatever base tag you're using? Does anyone want to share their insight on JSF component attributes and state, maybe have or know of a good online tutorial that will help me with this stuff.

I'm just having a hard time finding much information online about it. I mean, if you search this website for the term PropertyKeys, you don't even get one hit returned. I've even bought the "JavaServer Faces 2.0: The Complete Reference" book and it doesn't seem to be covered at all in there either. It's almost like they don't exist or don't matter, but I have sneaking suspicion that they do. Call it a hunch. Especially if you want to write a non-composite component and decorate the default renderkit. Maybe I'm mistaken. I usually am, but I sure could use any help that anyone would be willing to give me on understanding these things.

I haven't the faintest idea of what these so-called PropertyKeys are supposed to be. From the name, I'd expect them to be keys into a properties map of some sort, but there is no particular construct called "PropertyKeys" in Java, J2EE or JSF. However, Google gave me some interesting links to real estate in South Florida as well as a .Net reference.

In other words, nobody says anything about them, because whatever these things are supposed to be, that's not their commonly-used name.

Customer surveys are for companies who didn't pay proper attention to begin with.

If you look at the bottom of the page there is a whole section of PropertyKeys. They are enums that are inner classes in the javax.faces.component.html package. I notice that component authors, most particularly the JSF component library PrimeFaces utilizes them as a properties map that is called through the StateHelper class. I'm trying to determine what their relationship is to the "big picture".

As an example, when you call ResponseWriter you're calling an abstract class without any implementation, so how does it work? Well, the actual implementation is in the "com.sun.faces.renderkit.html_basic" package in the class HtmlResponseWriter. Without that, we'd all be forced to implement ResponseWriter ourselves because ResponseWriter is just an empty class full of method declarations with no implementation... or we'd be limited to what it inherits from Writer.

So, following that convoluted logic, when you create a component that decends from say, UIPanel and you call getAttributes(), where are these attributes coming from? Are they coming from these mysterious PropertyKeys? What is the relationship between UIOutput.getAttibutes() and HtmlBody.getStateHelper().get(PropertyKeys.style)? Am I looking for a relationship that does not exist here?

Incidentally, here's the source code for the PropertyKeys, including their containing class (HtmlBody). Although it's more of academic interest than for practical use, since it's exceedingly dangerous to code-to-implementation as opposed to code-to-specs.

Thanks Tim for your patience and interest in this. I do know that it is an implementation detail and that in general it's outside the bounds of what one needs to know in order to use and code to the JSF api. My problem is, I'm a visual thinker and I need to create a picture in my head in order to feel confident that I understand something.

So, are you basically saying that indeed, this is where the attributes live that are returned to you when you use getAttribute() in your code? This is where the options that are attached to tags such as <h:commandButton> reside and can be accessed by <h:commandButton id=xxx style=xxx etc..> or whatever the proper nomenclature is? Most importantly, if I'm using a component that translates to tag on a faclets page in my code and I call getAttributes() on it, these are the attributes that I have access to at that point? Also, when I call the StateHelper class in my code, is it these properties that are having their state saved and restored? This is what I'm stewing over. I need to be able to draw a line in my head from the UIComponent.getAttibutes() method and the getStateHelper() method to the place where these values are kept, otherwise I can not be confident that I understand what's actually going on when I call these methods.

Actually, it sounds like you know too much for your own good! JSF was designed to be as simple as possible (and no simpler). I'd say the #1 mistake that most people make in getting used to JSF is that instead of using basic Java POJO techniques, they start latching onto every javax.faces class and method in sight, when in fact, in most cases, the only javax.faces stuff that you should be coding is datamodels and rare references to the FacesContext for things like HTTP information (which I normally confine to a common utility class).

Well, actually, that's the #2 mistake. The #1 mistake they make is in thinking that they can design and implement reliable do-it-yourself security systems, This has been a bad week for computer security, as you can see from the news.

I don't think it helps that a lot of old and out-of-date stuff on JSF seems to come up ahead of newer and more appropriate info when one does a web search on JSF. JSF went through more than a normal amount of mutations as it was developed, and a lot of the original stuff was really cumbersome. Much of it lives on, since it's still useful, but there are better, cleaner ways.

It sounds like you're trying to pick apart the JSF controls and that's something that after about 5 years or so now, I still rarely (if ever) do. Mostly I stick to the KISS approach where I code a control, bind it with a "value=" attribute and let it be. Cascading dropdown lists and stuff like that I use valueChangeListeners for in order to get the cascade effect. And in a few extreme cases, I'll define an anchor node and dynamically add items underneath it. But only if I can't do it any simpler way.

Do not use internal definitions to figure out what attributes a JSF tag can use. That's playing with fire. The tag javadocs are authoritative. Anything you find that aren't in the javadoc list of available attributes isn't "real" and may disappear or change radically in future JSF versions. As I said, code "to spec", not "to implementation". Implementations are supposed to be "black boxes", so they can change radically internally as needed. For example, you can't be assured that what's an enum in JSF 1 didn't turn into a Map in JSF 2. It's there for the internal support, not as a definitive resource for applications work. If it were otherwise, it would have been listed in the public JavaDocs (and in the actual JEE spec document itself).

When you dynamically modify the JSF View structure, you instantiate elements such as the HtmlOutputText object. You set its properties using set/get methods, not the enums. In fact, if you did attempt to use the enums or the setAttribute method directly, you might end up with a defective object, depending on what side effects the object's mutator methods might have. So once again, Keep It Simple:

Donald Jackson
Greenhorn

Joined: Mar 09, 2009
Posts: 19

posted Apr 21, 2010 14:36:28

0

"Actually, it sounds like you know too much for your own good!"

> Well, if that's true, you can blame it partly on Ed Burns and Chris Schalk since I'm pulling through their book: "JavaServer Faces 2.0: The Complete Reference", as well as digging through Mojarra source and various component librarys' source.

My objective is to be able to create a JSF non-composite component. Using the classes and resources that Mojarra provides along with my own selection of javascript, html, xml, css or whatever as my browser resources, I want to have the chops to be able to do it if I need or want to. Plus, whenever I don't particularly understand something I often start digging in until I get to the bottom of things and I'm satisfied that I do understand. Kinda like pulling a thread on a sweater, I can't stop until it's totally undone.

Now, back to PropertyKeys. See, I ran into this section in the book on pages 316 and 317 that discuss state management in custom components. The authors are basically saying that prior to jsf2.0 it was common practice to save and restore the state of a custom component using JavaBeans style property getter and setters to explicitly handle state within the component. Now, and I quote: "JSF2.0 introduces the StateHelper interface to make this sort of activity easier and less error prone." I don't know since my horn is pretty green, but to me it looks more complex than using getters and setters.

It goes on to say that the getter and setter method on UIInput now looks like this:

enum PropertyKeys {

/**
*<p>Flag indicating whether or not this component is valid.</p>
*/

Soooo... what do I do? Are these the same attibutes that are being handled by the getAttributes() call that all components that subclass UIComponent inherits? Or does getAttributes call into some other map hidden off yonder somewhere. The reason that I'm digging into this so tenaciously is because I keep trying to write these cool java web apps and everything I try to do becomes a rats nest and even the simplest of endeavors turns into a complex unworkable pile of disappointment. Yeah, I can follow these basic tutorials I find laying around and as long as I obey every detail and don't stray in any way, most of the time it works. HelloWorld can only take you so far though, right? The minute I try to do something the least bit interesting it hits the fan, and no one short of an expert can usually figure out why. Maybe I'm just unlucky?

Well, you don't lack for ambition. The rules are different, of course, if you plan to subclass one of the existing components.

I'm not familiar with the details of the internal changes for creating your own JSF tag in JSF2, but in JSF 1, a tag implementation would use "getAttribute" to capture the value that was supplied via the source XML tag. In other words, if I coded

I'd use the "getAttribute" method to read "angle" and "attribute" in the bean's controller and render logic. If "myTag" subclassed HTMLInputText, however, I wouldn't attempt to read and process all the inherited attributes in my own tag class, just the attributes I was overriding, if any. I'd let the superclass handle the rest of them.

The StateHelper, I can confidently predict, is going to provide a way to automate the state save/restore process, and I'm sure that to do that it is going to need some sort of context that replaces the brute-force code that JSF1 required. Other than that, I'd have to RTFM.

Incidentally, Kito Mann's "JSF in Action" book has some useful info on creating custom JSF tags. It's now dated (JSF1), and it does require a little head-scratching, but it did help me last time I needed to do a custom JSF tag. The process is a bit more involved than a custom JSP tag, and I did run into some confusion in that I was actually doing more of a Facelets tag, which means the rules were a bit different. I mention that because Facelets functionality is supposed to be integrated into JSF2, so the same confusion might apply when attempting to use this older book as a reference.

Donald Jackson
Greenhorn

Joined: Mar 09, 2009
Posts: 19

posted Apr 21, 2010 17:39:19

0

Thank you Tim. My guess is that they wouldn't change the properties that getAttributes accesses although they may have changed the method of accessing them.

"... I wouldn't attempt to read and process all the inherited attributes in my own tag class, just the attributes I was overriding, if any. I'd let the superclass handle the rest of them."

Bingo. That's pretty much how I was figuring to approach it if I used the html components. BUT-> You suggest that I don't? You see, I wasn't sure about that part and I was wondering why people were subclassing UIComponents pretty much exclusively for non-composite components. So I gather that basically the UIComponent classes are designed for subclassing with component developers in mind and the Html classes are the html_basic renderkit implementation and I would be better served by leaving it alone. It's beginning to make sense to me now. I think I can safely move on to the next head scratcher now.

One thing people tend to forget is that JSF wasn't designed just to manage views on web pages in HTML. That's why they split the renderers off from the core tag stuff.

However, the "h:" tags are designed with HTML-style output in mind, so that's why they're favorites as a basis for subclassing. Especially in polymorphic inherited associations.

Any tag is fair game as a superclass, as long as it makes sense to subclass it. Or, for that matter, you can start from first principles where it makes sense.

Donald Jackson
Greenhorn

Joined: Mar 09, 2009
Posts: 19

posted Apr 21, 2010 19:37:54

0

"One thing people tend to forget is that JSF wasn't designed just to manage views on web pages in HTML. That's why they split the renderers off from the core tag stuff."

Exactly. That's pretty much why I've had so much interest in the composition of components and the painful details about how they go together and what properties maps they're accessing and what not. I've been puzzling over the usefulness of having visual components that would work on a number of different platforms, say, where ever you could host a JVM and 2 inch LCD screen, ease of development on mobile or specialty devices with the ability to interface with the whole Java Enterprise infrastucture. Sounds like big fun to me.