Binding data to a HtmlInputHidden in a Custom JSF Component

So I had this problem with a JSF Custom Component for which it took me 3 days to find the answer.

The problem: Inside a custom component, modify the value of a bound piece of data in a hidden input.

Ok, so in a normal JSF page you'd simply place the tag in page and bind it to data on your bean. It'd look something like this:

<h:inputHidden value="#{myBean.data}"/>

Using that on your page, you could modify the value with javascript and it would save back to your bean just fine. But putting it in a custom component made things weird.

There are other articles on how to create a whole JSF Custom component. I'm not going to repeat them here because they all show you the basics quite well. I will recommend anything you see from the author BalusC. Moving on.

In this example, I'll create an entirely unnecessary tag <myCompany:hidden>. It will simply render a hidden input on the page using the HtmlInputHidden object.

A quick reminder, I'm only going to address the rendering portion of this tag.

When you create your component rendering class, whether it's a separate one or not, there are a few JSF methods that you will use to get everything on the page. These are encodeBegin, encodeChildren, & encodeEnd.

encodeBegin renders what should appear in your page where the opening tag is. encodeChildren handles what is rendered between the opening and closing tags. Finally, encodeEnd renders what should appear with the closing tag.

A more concrete example of that:

JSF Code		When it gets rendered
<h:panelGrid columns="2" styleClass="prettyStyle">		encodeBegin
<h:outputText value="Hello">		encodeChildren
<h:outputText value="World!">		encodeChildren
</h:panelGrid>		encodeEnd

Here's where things get weird. For our tag, all we really want to do is have it render a single hidden input, right at the start and be done with it. But that won't work. Sure, you can get the value set on the page, but it won't be bound to your bean. Instead, create the HtmlInputHidden object, bind its value, and add it as a child to your component by calling: this.getChildren().add(myHtmlInputHidden);.

This will be encoded during the encodeChildren call and be properly bound, assuming you've done everything else right.

As with all JSF Custom Component creation, it's a little obtuse until you try it. Then it's still obtuse, and hard, but it works.

Zaephod's Philosophy on Tanking

I got into tanking with the release of the Burning Crusade. Actually, slightly before that but that doesn't really count b/c Baron Ghedon still wasn't actually tankable by me then. I levelled 60-70 as prot. Once I hit 70 and went into Kara, I found out I had a lot to learn about tanking. So I started reading. Maintankadin became my staple for tanking knowledge. I learned the terms of tanking, and the gear of the tankadin. Then, for the first time in my WoW career, I felt like I contributed in a meaningful way to the group. I would like to say, before going much further, that I consider each role in WoW and similar games, equally important. Tanks can't do their job if healers don't keep them up. Healers can't keep healing if the fight never ends. No one can survive if the boss enrages. Tanking to me is a job and mostly how I define myself within the game. I consider it part of my job to know the all the strategic details of the fights. Continuing, I believe that knowing how to organize each pull is also part of the job. Finally, I need to know my strengths and weaknesses, as well as those of my fellow tanks so that the right tank can do the job, even if that means that I'm not tanking at all for some encounter. A secondary goal for each encounter, is to be able to describe and possibly do the other jobs in the raid. I want, when main tanking an encounter, to provide consistent and predicable situations for the group. They should expect that the damage I take will be the same/similar each time and same for the threat I generate. Given this goal and the expectation on me, I use a threat rotation based on the incoming damage. Hammer of Righteousness, Judgement, Shield of the Righteous, Holy Shield, (Consecration if incoming damage will support it). This provides a consistent threat output and consistent incoming damage since Holy Shield is up nearly on the cooldown. The way is gear also helps with threat generation and damage taken. 689 defense rating on gear brings me to uncrittable. Avoidance stats applied until unhittable (102.4% total avoidance wih Holy Shield active). Stamina in the remaining sockets, with extra armor applied where I can.

Why Zaephod's Window?

Forgive me for not explaining this in the first post, nor simply editing it in. Who am I? In life, I answer to Jonathan. I'm closing in on 28, a software developer by trade, a wannabe guitar and trumpet virtuoso (meaning it sounds great to me only), a next-to-high-end raider in World of Warcraft; great at stringing a sentence out far too far. I'm married to April, a soon-to-be-professional rocket scientist, and also a next-to-high-end raider. I go by Zaephod in WoW with the occasional sojourn on Tubafore. Zaephod is my Paladin, normally protection, and is, by far, my main. I don't play alts hardly ever because there's always something else that Zae needs for task X. Zaephod is a tank and normally quite philanthropic. It's not uncommon for "Sure" to appear in the chat log after someone says, "Hey Zae, can you tank ___?" In keeping with such endeavors, my main trade skill is Jewelcrafting, in which I spend a hefty amount of time obtaining patterns for jewels guidies may need. So to this point, we've covered who I am, who April is, and who Zaephod is. That leaves the point of the blog. My plan for this blog is to do a few things. It will do a few things for me. I'll use it to teach things I'm good at, or bad at, and occasionally give you a glimpse into my head. It will be the window into my world, and unfortunately for you, subject to my strange sentence structure. Please pardon the grime on the window, English is my first and best language, but that doesn't mean I'm good at it.

Welcome!

Greetings! And welcome to my blog. Thanks for stopping by. I have one question before we get started: why in the world are you here? I know why I'm here, but why you? Why now? I'm not harassing or anything, I'm just baffled someone found this. Moving on... I created this blog initially to explore the way it behaves in Opera (v. 9.62 and 10.00 alpha). The issue I'm trying to address is the browser event onbeforeunload that fires in IE 6+ (as far as I've tested) and Firefox (latest and greatest version because it will annoy me otherwise). Here's the problem: we have a page with some various inputs, buttons, links, select boxes, and even some check boxes. When the user submits the form, we don't want them to be able to submit again before the page loads anew. Our previous effort was to place on every, single, clickable element in every, single page something to the effect of:     onclick="suppressInput();" Aside from being elegant and efficient, of which it was neither, it was a headache. Some quick search lead us to the browser event onbeforeunload. Yay! It was perfect. Before the page unloaded, it would call our little event. Except for one problem...it doesn't work in Opera. More accurately, it's never called by Opera. More web searching lead me here. Somewhere out there, it was mentioned that blogger.com handled this type of situation with Opera very well. So I hopped on and hoped for the best. It doesn't work with Opera 10. Back/forward/navigation to another page are all working, unfortunately, perfectly but never am I being caught for an "Are you sure you want to destroy all that hard work?"