Tuesday, November 22, 2011

Views, Documents and Trinidad

So I got Apache Trinidad's partial page rendering (PPR, basically AJAX) to work, and learned about Trinidad in the process.

I was highly confused by <f:view>, <tr:document> and <trh:html> (and <trh:head> and <trh:body>).  As it turns out, you don't need f:view if you're using Facelets, so no need to worry about that.  The documentation about tr:document makes me think that it's a replacement for the top-level <html> tag, but it's really the top tag in a Trindad Component.  So, if you need to use Trinidad's PPR you want use the <trh:html>, <trh:header> and <trh:body> tags with a <tr:form> and THEN you are good to go.

Monday, November 21, 2011

The Eclipse .ini File

Quick post about the Eclipse's eclipse.ini file.

This one is usually used to either explicitly specify the JVM to use (so you won't have to worry about changes to JAVA_HOME breaking your Eclipse) or to pass arguments to the JVM being used (i.e. memory arguments usually).

The full list is pretty large.  The -noSplash option looks interesting, as well as an option to give your own image file for the splash screen.

Friday, November 18, 2011

Not as Easy as it Looks: h:form to tr:form

So, I'm trying to implement Trinidad's AJAX (Partial Page Rendering) to decouple my ui:components (see prior post, Components and Confusion in Facelets) from Spring Web Flow.

In essence, you have a trigger (like a button) and a receiver (like a tr:form that needs to be refreshed).  These both need to be Trinidad components.  My first attempt was to upgrade the page's current h:form to a tr:form but this caused a bizarre seeming error at runtime.  Then I read the docs more thoroughly (for this blog post) and found that a tr:form seems to require that the entire page is Trinidad-ified either with a tr:document or a trh:html, trh:head and trh:body instead of the base HTML equivalents.  Also note that the f:view tag is only needed for using JSF with JSP (i.e. NOT Facelets).

(Note: image from Google image cache of http://www.caribbean-tour.com)

Fortunately, changing the template for the entire project like this worked out fine.

Thursday, November 17, 2011

Not as Easy as it Looks, Part 2

I also tried upgrading from OGNL to SpEL on a Spring project recently and was surprised.

At first I thought that SpEL wasn't really a drop-in solution when I got some initial errors after switching, but SpEL (in depth intro at JavaBeat) actually caught a bug at compile time that OGNL (wiki) would only notice at runtime (and thus wasn't found before).

At least configuring Spring Web Flow for this is easy!

Wednesday, November 16, 2011

Not as Easy as it Looks

After trying to migrate from JSF 1.2 to 2.0 with these StackOverflow questions I found that if you're upgrading to Facelets 2.0 you also need to upgrade to Apache Trinidad 2.0.

Maven info can be found at this post at Thoean.  It's supposed to have more content, but I couldn't figure out how to get to it.

It appears that that is the best upgrade guide that I could find, and this Andy Schwartz blog post is great for what features you get when it's all over.

Part 2 is about moving from OGNL to SpEL.

Thursday, November 10, 2011

Components and Confusion in Facelets

The word component is used a lot in Facelets (and supporting technologies):

In general if you're talking about facelets, a component is a ui:component and a custom tag is a facelets custom tag.  If you're talking about JSF, a component is a UIComponent and a custom tag is a JSP custom tag.

Further more, this shouldn't be confused with general purpose software componentsstrict components, or modules.

Tuesday, November 8, 2011

Default / Legacy variables in JSTL

So I've been working with JSTL, JSF and Facelets for a while now and didn't come across a decent post on how to default values or work with legacy varibles (i.e. you had renamed your f:param to a component).

The solution is to use a combination of c:if and c:set tags, like the following:

<c:if test="#{empty optionalVar}">
  <c:set var="optionalVar" scope="page" value="#{defaultValue}"/>
<!-- or -->
<c:if test="#{empty newVarName}">
  <c:set var="newVarName" scope="page" value="#{oldVarName}"/>

This has been working great for me.  I've been digging around for decent articles on how else f:param and f:attributes are used and found a great one called Communication in JSF.

Sunday, November 6, 2011

Fun Times: Happy Daylight Savings (US)

Here in the US we're ending daylight savings time ("spring ahead, fall back") and to honor this, this post will be about all of those tricky things about time that affect programming.

There are already some good posts about this issue, but here are some fun facts:

  • In the US west coast, the two time zones uses (yes, there are two) are Pacific Daylight Time (PDT, during the summer) and Pacific Standard Time (PST, during the winter).  When it changes time zones in the fall 1:59 AM PDT is followed by 1:00 AM PST.  This also causes the day to have 25 hours.
  • The US state of Arizona does not observe daylight savings time.
  • Some time zones are not on even hour increments from GMT (i.e. -8 or +3), but can involve minutes as well (GMT +5:30 for Mumbai and GMT +5:45 for Kathmandu).
  • In Java, Calendars are important (but the standard one is the Gregorian Calendar, as far as I know).
  • Time zones are decided by the nation's government, as when Venezuela changed it's time zone in 2007.
  • Usage of GMT is depreciated in technical contexts, and can refer to UTC or UTC1.
  • Windows XP references GMT, but Windows 7 references UTC.
  • UTC and UTC1 are different, but always by less than a second (when it's more there is a leap second).
  • Leap seconds can cause some minutes to have 59 or 61 seconds in them.
  • java.util.Date is really a time stamp from the Epoch, and I find it useful to subclass a "TimeStamp" object for clarity.
  • XKCD has a hilarious comic related to all of this.
  • Birthdays should not be related to the java.util.Date object.  If someone is born on at 11:30 PM and later goes east to another time zone their birthday does not change.
  • When mankind starts doing serious space travel relativity is going to make all of this much worse.
  • I'm sure that there are more things that escape my memory right now, so do not consider this list complete.
All in all, time is one of those "tricky" things.

There are also some libraries that aim to replace the core java.util.Date classes: Date4j and Joda Time.

Friday, November 4, 2011

Annoying Habits of Developers on Spark Minute

I just came across an interesting article on the Spark Minute about Annoying Habits of Developers.

I've come across more "annoying" managers than developers, but I had a coworker who had a coworker who would dress in drag with combat boots, and put an army surplus parachute over his cube to keep it dark.

Is there a stronger word for "eccentric"?

Thursday, November 3, 2011

GRASP in Spring

TheServerSide has a very interesting link to an article on JavaDepend about how Spring is designed internally (go open source!)

The gist of it is the Spring is designed well internally, the JavaDepend tool looks really useful and that if you're a developer and don't know what GRASP is, you should read the Wikipedia on it.

Wednesday, November 2, 2011

Documenting Facelet Components

Right now I've been trying to figure out how to properly document Facelet includes, Spring Web Flow directories and Facelet components.  It seems that for Facelet components you're to use the JSF Tag Library Descriptors (TLDs).  I've been having a rough time finding how to do TLDs on the web, and could only find the (somewhat dry) entries for the Java EE 5 Tutorial and Java EE 6 Tutorial.

I read all of these docs a few months ago, before "getting my hands dirty" by actually using these technologies on a project.  It looks like time for a re-read.

Tuesday, November 1, 2011

Scopes vs Strict Components

So I've been working a lot with JSF, Spring Web Flow and Facelets lately.  I never thought that I'd say this, but I miss something about the AribaWeb framework.

In AribaWeb there were strict components.  Strict in the sense that ONLY attributes of the component (i.e. <my:component data="test"> were accessible as data.  In Facelets everything in the SCOPE is visible so it is very easy to get your "reusable" components mixed up with application specific logic.

Even if you have discipline and only use component attributes you still have a namespacing problem similar to early BASH or C without the namespace keyword (i.e. your "data" variable may clobber another one accidentally).

Maybe there is a solution to this that I haven't discovered yet.  Until then I may go with the old convention of prefixing names with the component name (i.e. <my:component myComponent_data="test">) and only using local attribute data.  The naming convention would make that easier to check for too!

Happy Hacking all.