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.
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.
(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!
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.
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):
- Facelets Custom Tag
- Specially packaged ui:components or ui:compositions.
- Facelets ui:component
- essentially just a ui:composition with a backing bean.
- Driven by xhtml with more tags.
- JSF Custom UI Components
- Subclasses of javax.faces.component.UIComponent.
- Driven by Java backing beans (rendered as HTML via a renderer)
- backing beans are different from managed beans
- Creates a new tag to be used with xhtml.
- JSF Advanced Composite Components
- They're like a template (in the generic sense, not a ui:template).
- They mean the UIComponents not the ui:components
- JSP Custom Tags
- From Java5, obsolete to a JSF application.
- Mentioned in passing in Java6 docs.
- Also creates a new tag to be used with xhtml.
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 components, strict 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}"/>
</c:if>
<!-- or -->
<c:if test="#{empty newVarName}">
<c:set var="newVarName" scope="page" value="#{oldVarName}"/>
</c:if>
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.
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}"/>
</c:if>
<!-- or -->
<c:if test="#{empty newVarName}">
<c:set var="newVarName" scope="page" value="#{oldVarName}"/>
</c:if>
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:
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.
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"?
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.
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.
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.
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.
Subscribe to:
Posts (Atom)