Re: Dealing with application names in a JEE web app
Arved Sandstrom wrote:
Lew wrote:
markspace wrote:
Lew wrote:
I've been able to work out "all this" pretty much from
http://download.oracle.com/javaee/6/tutorial/doc/bnadp.html
the MyFaces docs and the articles in IBM DeveloperWorks.
Thanks for pointing out those additional resources. I think right now I'm
I forgot to mention the most important one: lots of example apps that I
created in my (copious) spare time. I went nuts in JSF 1.something when
"rendered='false'" on first page call would prevent a component from
being in the tree, never to be reinserted in postback when the value
flipped to 'true'. They fixed that later. I went nuts overall until I
began to grok the six-stage component lifecycle of JSF.
I similarly went nuts in my early exposure to JSF until I learnt that
lifecycle. I lived by Rick Hightower and BalusC. These days I go nuts
because I work with people who have had to use JSF for the same length
of time as me, but who haven't bothered to learn the lifecycle, and
screw coding up because of it.
Typical problem - people not realizing how often getters get called in
first view or postback, and jamming all sorts of unguarded persistence
operations into getters as a result. "Duhhhhh...why did that table get
updated twice?"
Boy, that was a surprise the first time I encountered it AT HOME WHILE I WAS
PRACTICING!
Then I studied up and found out about the lifecycle.
All before I accepted a paycheck to do JSF programming. Not that I needed to
be a master first, but I sure needed to do SOME practice first.
I went nuts
until I learned that every backing bean is a controller, unlike the
front-controller pattern familiar to Model 2 and Struts mavens.
One other thing to learn early on is the distinction between JSF managed
beans and JSF backing beans. Many of the same aforementioned people use
the terms indistinguishably, and I wish they wouldn't. No excuse for
this confusion: the Java EE tutorial explains the difference clearly in
2 sentences.
This one I had not encountered, maybe because backing beans were first in the
managed-bean universe and managed beans were generalized therefrom:
<http://download.oracle.com/javaee/6/tutorial/doc/bnacj.html#indexterm-85>
"Managed Beans represent a generalization of the managed beans specified by
JavaServer Faces technology and can be used anywhere in a Java EE application,
not just in web modules."
I see from
<http://download.oracle.com/javaee/6/tutorial/doc/gjaam.html#gjacb>
"As mentioned earlier in this chapter, a backing bean, a type of managed bean,
is a JavaBeans component that is managed by JavaServer Faces technology.
Components in a page are associated with backing beans that provide
application logic."
However, managed beans are actually not defined earlier in that chapter.
<http://download.oracle.com/javaee/6/tutorial/doc/bnaqm.html>
"A typical JavaServer Faces application includes one or more backing beans,
each of which is a type of JavaServer Faces managed bean that can be
associated with the components used in a particular page."
In any case, I couldn't find the "two sentences" to which you refer, so I
suggest you lighten up a little on that particular rigidity.
I like the (newish) CDI annotations that allow the "managing" bit -
naming and scoping, for starters - not to be a JSF thing. I use them
when I can.
... [snip ...
I still
don't use "immediate='true'".
I almost never use it either now. The reason I don't is because it takes
some quality reading to understand what "immediate" does (see the
excellent description at
http://wiki.apache.org/myfaces/How_The_Immediate_Attribute_Works), and
you have to re-read and refresh yourself on that every few months when
your use of "immediate" has caused a bug (or more likely, some other
developer never read up on it and uses "immediate" incorrectly, and
you've got to fix the defect).
It's just not worth it.
You echo my reasoning. Hard to understand, limited usefulness - screw it.
I must've tried every variation of URL in JSF, JSTL, jsp:useBean and
such structures as I've learned my J{2,ava }EE skills in order to learn
where things need to be for the app server to find them. I still am not
fully aware of the nuances.
Other takeaways: thank God for Facelets. I haven't used JSPs in 3 years.
And even though it's got better support in JSF 1.2 and 2.0 than it did
in 1.1, _don't_ mix JSTL and JSF. If you're writing JSF JSPs or
Facelets, and you think you need JSTL, think again - you don't.
I've seen this mistake in practice, and people (so-called "programmers", no
less!) look at me blankly when I give that advice. And yet they're never the
ones to get fired!
mostly concerned that the JSF 2.1 spec seems a lot less complete than
the JSP
and Servlet one, and that the book I purchased by the spec co-lead seems
equally abbreviated. You'd think Sun (and now Oracle) would be most
interested in making sure that accurate and complete documentation is available.
"Google for it and read some blogs" seems like the opposite of that idea.
Don't mind me though, I'm typically grumpy when I'm trying to plow my way
through new concepts.
Curmudgeons of the world, uni- - - ah, screw it!
If programming was easy, anyone could do it. Sometimes you just have to
bang your (metaphorical) head against the (metaphorical) brick walls
until something (hopefully the wall) crumbles (metaphorically). And I
truly found that GIMF through all that with JSF.
I am reasonably fond of both JSF (especially JSF 2.0) and ASP.NET MVC.
As far as I am concerned both teams got It.
Yay, facelets!
Boo, ignorance!
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg