miracle occurs here|

JavaScript – Referencing CSS Properties Containing Hyphens or Dashes

November 23rd, 2010 at 1:29 am by Michael Scepaniak

If, in JavaScript, you need to reference/manipulate CSS properties at runtime that contain a hyphen or dash in their names, omit the hyphen and, instead, camelcase the surrounding letters. You need to do this because hyphens in JavaScript variable names are illegal. For example, this won’t work:

div.style.background-color = "red";
div.style.z-index = 3;

Whereas this will:

div.style.backgroundColor = "red";
div.style.zIndex = 3;

Hope this helps.

JSF – You Can’t Submit a Disabled Form Element

November 12th, 2010 at 1:11 am by Michael Scepaniak

I previously discussed the JSF truism that you can’t re-render something you never rendered in the first place. Here’s another one:
You can’t submit a disabled form element.

Here’s the situation. We’ve got a form with a text input element that, by default, we want to be disabled unless the user changes something else, client-side, on the page. The obvious, intuitive way to do this is with the disabled attribute:

<h:inputText id="newId" value="#{thePage.newId}" disabled="true" />

Then, once the user initiates whatever action to enable the text input element, we use some JavaScript to twiddle the disabled attribute, thereby making it editable. However, if the user then fills out that text input element and submits the form, the backing bean won’t receive the user-supplied value. Why? I can only surmise that, according to the JSF viewState, the text input element in question is still disabled. Therefore, JSF sees no point in processing text input element.

One efficient (but hacky and verbose) way around this is to always keep the text input element enabled from JSF’s standpoint and, instead, do it all using JavaScript. The first step is to remove the disabled attribute from the text input element:

<h:inputText id="newId" value="#{thePage.newId}" />

Instead, we use jQuery to disable the text input element at page-load time:

jQuery(document).ready(function(){
    var newIdInput = jQuery("#theForm\\:newId");
    newIdInput.attr({ disabled:true });
});

Some CSS styling completes the job, making the text input element actually “look” disabled in all browsers:

input#theForm\3A newId
{
    background-color: #D6D6D6;
}
span#theForm\3A newIdInputLabel
{
    color: #9C9C9C;
}

Finally, we add a JavaScript event handler function to twiddle the attribute value:

var handleSomeChange = function()
{
    var labelColor = "#9C9C9C";
    var inputColor = "#D6D6D6";
    var disabledSwitch = true;
    if ([test to see if newId should be enabled returns true])
    {
        labelColor = "#000000";
        inputColor = "#FFFFFF";
        disabledSwitch = false;
    }

    var newIdInputLabel =
        jQuery("#theForm\\:newIdInputLabel");
    newIdInputLabel.css("color", labelColor);
    var newIdInput = jQuery("#theForm\\:newId");
    newIdInput.attr({ disabled:disabledSwitch });
    newIdInput.css("backgroundColor", inputColor);
}

The more pure JSF way to get this done (using RichFaces) is to have the event handler function call the server, which would determine the proper disabled/enabled state and then reRender the text input element or containing form. In this way, the server-side viewState and client-side state remain in sync. But, in some instances, this introduces too much latency and negatively impacts usability. The option is available, though.

If you are, for example, disabling/enabling a text input element in a compact form in response to a checkbox being checked in that same form, I’d go with the client-side approach. However, if you are disabling/enabling lots of form elements in response to a button being clicked, going the server-side route might be more appropriate (from both a technical complexity and usability perspective).

I hope this helps.

Finding/Selecting RichFaces Components using jQuery

November 4th, 2010 at 10:33 pm by Michael Scepaniak

If you try to use jQuery to interact with JSF Richfaces components, you might run into difficulty selecting those components using their ID. The match is never made for some reason. That “reason” might very well be that RichFaces tends to put colons in the ID’s of their generated DOM elements. For example:

editForm:requiredOptions:1:listAllOptions:0:colorBox

There’s nothing wrong with this. It’s very well structured and successfully handles nested components and collections. But, if you try to get jQuery to select the component matching this ID, you’ll fail because of the colons. The solution is to properly escape the colons in the ID before passing it to the selector:

var componentId = component.id;
componentId = componentId.replace(/:/g, "\\\:");
var $component = jQuery("#" + componentId);

Hope this helps.

JSF – Render Line Breaks in the outputText Tag

October 27th, 2010 at 8:30 pm by Michael Scepaniak

Like many things having to do with JSF, it can be difficult to figure out how to render a line break (AKA new line) in the content of an outputText tag. This has come up most frequently for me when I want to narrow the width of a table column by breaking the heading content into one or more lines. For example:

<h:column>
    <h:outputText value="Very Wordy Table Column Heading" />
</h:column>

Your first (and last) thought might be to insert a line break tag (escaped, of course, so as not to break the XML formatting) in the content, like so:

<h:column>
    <h:outputText value="Very Wordy&lt;br /&gt;Table Column&lt;br /&gt;Heading" />
</h:column>

But, this don’t work:

Very Wordy<br
/>Table Column<br
/>Heading

Actually, this isn’t far off. The key is to disable output escaping using the escape attribute of the outputText tag, like so:

<h:column>
    <h:outputText value="Very Wordy&lt;br /&gt;Table Column&lt;br /&gt;Heading" escape="false" />
</h:column>

This works:

Very Wordy
Table Column
Heading

What’s going on here? By default, the outputText tag escapes HTML tags, which is great because it helps prevent injection attacks. What we’re telling the outputText tag to do is not do that. So, it follows that you shouldn’t do this when dynamic, possibly unsafe content is being passed to the outputText tag.

Hope this helps.

JSF RichFaces – Combine ReRender With CSS Display, Not Rendered

October 8th, 2010 at 3:25 pm by Michael Scepaniak

RichFaces reRender attribute is very convenient and powerful. Basically, it allows you to dictate that one or more components on a page re-render when something else happens – like when a button is pressed, link is clicked, or JavaScript function is called. But, one frustration that many developers run into sooner or later is when the reRender doesn’t seem to work. There’s one very important thing to remember about reRender

You can’t re-render something you never rendered in the first place.

Here’s an example. You’ve got a page with a submit button. When the button is submitted (in this case, via AJAX using a JavaScript function), you’d like to display a confirmation message to the user. See below:

<h:outputText
    id="submitConfirmMsg"
    value="Got it!"
    rendered="false" />

<a4j:jsFunction
    name="submitSomething"
    action="#{thePage.submitSomethingAjax}"
    reRender="submitConfirmMsg" />

<a4j:commandButton
    id="submitButton"
    onclick="submitSomething(); return false;"
    value="Submit" />

The intention is that, when the JavaScript function finishes the AJAX call, the outputText component should appear. But, because we don’t want the message to appear until after the submission is made, we want to hide it when the page is first loaded. As such, we set the outputText’s rendered attribute to false. That makes perfect sense, but it don’t work. What it does is make it impossible to re-render the outputText – because it was never rendered in the first place. The “correct” way to accomplish this is to use the the very non-JSF-ish CSS display attribute, like so:

<h:outputText
    id="submitConfirmMsg"
    value="Got it!"
    style="display: #{thePage.submissionSuccess ? 'block' : 'none'}" />

Twiddle the display attribute based on a property of the backing page/bean. This way, the component is rendered when the page is first loaded, making it eligible for re-rendering.

These examples were coded using JSF v1.2.x and RichFaces v3.3.x

Hope this helps.

Hibernate – argument type mismatch converting a char to a String

September 16th, 2010 at 9:46 am by Michael Scepaniak

I ran into a problem with Hibernate not converting a char column to a Java String object. In this instance, I was using the createSQLQuery() method on the Session object, like so:

session.createSQLQuery("select char_column from some_table");

I had “char_column” mapped to a String property in my model object (bean). However, at runtime, I was receiving the following nastiness:

Caused by: java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.hibernate.property.BasicPropertyAccessor$BasicSetter.set(BasicPropertyAccessor.java:66)

I also saw this once:

Caused by: java.lang.IllegalArgumentException: java.lang.ClassCastException@95d068
at sun.reflect.GeneratedMethodAccessor59.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.hibernate.property.BasicPropertyAccessor$BasicSetter.set(BasicPropertyAccessor.java:66)

I tried changing the property from a String to an Object and saw that Hibernate was trying to set the char column value as a java.lang.Character object. Not cool – because going that way would result in my 4-character-long database value being truncated to 1 character.

I did some Googling and eventually found this (unaddressed) bug report – “Wrong type detection for sql type char(x) columns”.

The simple fix is to cast the column, like so:

session.createSQLQuery("select cast(char_column as varchar) from some_table");

The (supposedly) cleaner fix is to twiddle with a custom dialect, as explained in the above-referenced page by Julien Kronegg. I declined to go this route because I was wary of breaking the application, at large.

Hope this helps.

Jetty – Auto-reload JavaScript and CSS Files

September 4th, 2010 at 2:27 pm by Michael Scepaniak

If you are developing a web application using Jetty via Eclipse, by default, changes made to static resources such as external JavaScript and CSS files are not picked-up on the fly by the running Jetty server. Out of the box, picking up such changes requires that Jetty be stopped and restarted, possibly with the webapp being redeployed in between. In order to enable hot deployment of such resources, modify the [JETTY_ROOT]/etc/webdefault.xml file like so:

<init-param>
<param-name>maxCachedFiles</param-name>
<param-value>0</param-value>
</init-param>

By way of colleague and friend, Justin Alpino.

Migrating Your WordPress Permalinks

August 26th, 2010 at 6:53 pm by Michael Scepaniak

When I first set-up my WordPress blog, I used the default permalink structure. For example:

http://milestoneinc.com/blogs/tech_blog/?p=79

I liked it because it kept the URL’s short. But, I came to understand the SEO benefits of readable URL’s. And the default structure made interpreting my Google Analytics reports a chore. So, I decided to change the structure to one that just used the name of the post:

/%postname%

And this works fine. You go into your Permalink Settings screen, specify the Custom Structure, save the .htaccess file, and the above URL changes:

http://milestoneinc.com/blogs/tech_blog/migrating-your-wordpress-permalinks

But, I could still access the old URL directly. This wasn’t cool to me, because the search engines would still drive visitors to the old link structure, Google Analytics would still show the obtuse links, and my URL’s would remain search-engine hostile. What I wanted to do was migrate the old URL’s to the new URL’s. It turns out that there are lots of WordPress plugins offering to do this for you. After much investigation and reading, the one I finally settled on was the Permalink Redirect WordPress Plugin by Scott Yang. Why? Primarily because of this thorough blog post about the Permalink Redirect Plugin by Michael Bubbo.

I followed the instructions and everything worked as expected. And when I look in my Apache access logs, I see the 301 redirect goodness that I expected:

12.345.678.999 - - [26/Aug/2010:02:37:58 -0500] "GET /blogs/tech_blog/?p=76 HTTP/1.1" 301 4224 "-"
"Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8"
12.345.678.999 - - [26/Aug/2010:02:37:58 -0500] "GET /blogs/tech_blog/migrating-your-wordpress-permalinks HTTP/1.1" 200 3798 "-"
"Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8"

I hope this helps.

A/Bingo Installation Tips

October 1st, 2009 at 5:48 pm by Michael Scepaniak

I wanted to incorporate A/B testing into a Rails project of mine. Being that I’m a fan of Patrick McKenzie and his micropreneurial pursuits, I decided to go with A/Bingo, his Ruby on Rails A/B testing framework. However, since I’m still pretty much a rookie when it comes to Ruby and Rails, I had some issues with the installation. Here are my tips…

In step #1, Patrick gives the installation options. I tried the script/plugin install command first, which seemed to execute fine. But I couldn’t figure out where the download got placed. So, I tried the git clone command, but, well, turns out I didn’t have git installed. (Remember, I is a rookie.) I quickly figured out that git can be easily installed (on OS X) using the Git OS X Installer. It worked great. I tried the git clone command again and an abingo directory got created in my local directory. Lovely.

In step #2, Patrick says to execute the ruby script/generate abingo_migration command. I tried, but I kept getting “Couldn't find 'abingo_migration' generator“. I figured that something was in the wrong place, but, me being a Rails novice, it took me a while to figure out. Do the following:

  1. Copy the contents of the abingo/lib directory to your Rails project’s lib directory.
  2. Copy the abingo/generators directory to your Rails project’s lib directory, too. (I figured this out by reading the usage/help for the script/generate command.

With regard to step #3, I must be using a different version of Rails (v2.3.3), because the names of the applicable files for me were application_controller.rb and application_helper.rb.

In the “Usage” -> “Statistical Significance” section, the command you want is experiment.describe_result_in_words, not experiment.describe_results_in_words.

Hope this helps anyone having similar issues.

Maven – Install a POM-less JAR

January 11th, 2009 at 8:05 pm by Michael Scepaniak

At some point while using Maven, you’ll most likely come to a point where you need to install a POM-less artifact (probably a JAR) into your local Maven repository. This could happen for a number of reasons:

  • The JAR has never been published to a public Maven repository. This could be the case with a small, niche library.
  • You need to compile against JAR’s included in your runtime environment, which might be closed-source (e.g., WebSphere).
  • You might have some third-party JAR’s which you know work and are Maven-accessible, but you’re having difficulty determining their versions.

To install, run the following command (I think against any arbitrary pom.xml file):

mvn install:install-file -Dfile=[path/to/jar] -DgroupId=[group.id] \n
 -DartifactId=[package-id] -Dpackaging=jar -Dversion=[version] \n
 -DgeneratePom=true

So, for example, at one point in recent history, I needed to compile against some internal JBoss JAR’s. This is the command I used to install one of the JAR’s into my local Maven repository:

mvn install:install-file -Dfile=jboss-api-lib.jar \n
 -DgroupId=jboss.jboss-api -DartifactId=jboss-api-lib -Dpackaging=jar \n
 -Dversion=2.6.4 -DgeneratePom=true