«

On 5/24/2011 10:16 AM, Tom Anderson wrote:
>
> It doesn't help you deal with this in resources which are not
> programmatic, like static CSS, so here you have to depend on relative
> references. This doesn't strike me as difficult - you decide early on to
> keep all your css under /contextpath/css, and your site furniture images
> under /contextpath/images, and then because CSS image paths are relative
> to the stylesheet, in your CSS you can write:
>
> background:url(../images/bbg.jpg) left top repeat;


Thanks for replying Tom, but this doesn't appear to be quite correct.
According to some sources on the 'net, you CAN put EL expressions in
static CSS resources:

background:url("#{resource['sunny:images/header.png']}")

<http://primefaces.prime.com.tr/forum/viewtopic.php?f=3&t=3774&start=0>

<link type="text/css" rel="stylesheet"
href="#{request.contextPath}/css/theme/login.css" />

<http://forums.oracle.com/forums/thread.jspa?threadID=1717161&tstart=-2&messageID=7177962>

This works because apparently when you load with a Faces tag like
hutputStylesheet, it emits HTML that loads the static resource through
the Faces servlet. For example, this:

<hutputStylesheet name="css/login.css" />

renders as this:

<link type="text/css" rel="stylesheet"
href="/solicitacoes/javax.faces.resource/css/login.css.xhtml" />

where "solicitacoes" is apparently the web context root.

<http://forums.oracle.com/forums/thread.jspa?threadID=1717161&tstart=-2&messageID=7177962>


I really appreciated you guys trying to help me out, but I'm really
frustrated at the lack of a single, authoritative source where all this
is spelled out. I looked in the JSF 2.1 spec and it barely even
mentions hutputStylesheet, and certainly doesn't discuss its tags or
parameters anywhere that I could find.

On 5/25/2011 12:16 PM, markspace wrote:

> Thanks for replying Tom, but this doesn't appear to be quite correct.
> According to some sources on the 'net, you CAN put EL expressions in
> static CSS resources:
>
> background:url("#{resource['sunny:images/header.png']}")


And what's more is those resources from the CSS file will themselves be
fetched through the Faces servlet. This:

body {
background:url("#{resource['img/bbg.jpg']}") left top repeat;
color:#555555;
font-size:11px;
font-family:Tahoma, Arial;
padding:0px 0px 0px 0px;
margin:0px 0px 0px 0px;
}


gets transmorgified to this:


body {
background:url("/TechDarwinia/faces/javax.faces.resource/img/bbg.jpg")
left top repeat;
color:#555555;
font-size:11px;
font-family:Tahoma, Arial;
padding:0px 0px 0px 0px;
margin:0px 0px 0px 0px;
}

On Wed, 25 May 2011, markspace wrote:

> On 5/24/2011 10:16 AM, Tom Anderson wrote:
>>
>> It doesn't help you deal with this in resources which are not
>> programmatic, like static CSS, so here you have to depend on relative
>> references. This doesn't strike me as difficult - you decide early on
>> to keep all your css under /contextpath/css, and your site furniture
>> images under /contextpath/images, and then because CSS image paths are
>> relative to the stylesheet, in your CSS you can write:
>>
>> background:url(../images/bbg.jpg) left top repeat;
>
> Thanks for replying Tom, but this doesn't appear to be quite correct.
> According to some sources on the 'net, you CAN put EL expressions in
> static CSS resources: [...] This works because apparently when you load
> with a Faces tag like hutputStylesheet, it emits HTML that loads the
> static resource through the Faces servlet.

In which case it's not static CSS! Anything that gets mangled by code
before being served is dynamic, and is able to evade this problem.

> I really appreciated you guys trying to help me out, but I'm really
> frustrated at the lack of a single, authoritative source where all this
> is spelled out. I looked in the JSF 2.1 spec and it barely even mentions
> hutputStylesheet, and certainly doesn't discuss its tags or parameters
> anywhere that I could find.

So the "all this" you'd like to see spelled out is JSF? I can't comment -
i have never used JSF, and have absolutely no desire to. I'm surprised and
disappointed to hear that JSF is poorly documented, since it's a flagship
J2EE technology. I think the servlet and JSP specs (i'm thinking of
javadocs, actually) do explain their parts of this reasonably well, FWIW.

tom

--
.... which may end up with the women in your office cornering you at the
office xmas party and taking turns at jamming their bootclad feet into
your genitals. This is what is known as the Wrong Kind of Footsie. --
Lord Foom

Tom Anderson wrote:
> So the "all this" you'd like to see spelled out is JSF? I can't comment - i
> have never used JSF, and have absolutely no desire to. I'm surprised and
> disappointed to hear that JSF is poorly documented, since it's a flagship J2EE
> technology. I think the servlet and JSP specs (i'm thinking of javadocs,
> actually) do explain their parts of this reasonably well, FWIW.

I've been able to work out "all this" pretty much from
http://download.oracle.com/javaee/6/...doc/bnadp.html
the MyFaces docs and the articles in IBM DeveloperWorks.

I don't know of any technology, Javas, C#, SQL or what-have-you, that is fully
documented in a perfect way for every practitioner in a single source.

JSF is simply a wonderful framework.

--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedi.../c/cf/Friz.jpg

On 5/26/2011 10:07 AM, Tom Anderson wrote:
>
> In which case it's not static CSS! Anything that gets mangled by code
> before being served is dynamic, and is able to evade this problem.


Well, true, I was just surprised that JSF was capable of taking a
resource that looked like it should be static and treating it dynamically.

On 5/26/2011 10:25 AM, Lew wrote:

> I've been able to work out "all this" pretty much from
> http://download.oracle.com/javaee/6/...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 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 typical grumpy when I'm trying to plow my way
through new concepts.

markspace wrote:
> Lew wrote:
>> I've been able to work out "all this" pretty much from
>> http://download.oracle.com/javaee/6/...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 went nuts until I learned that every
backing bean is a controller, unlike the front-controller pattern familiar to
Model 2 and Struts mavens. I still don't use "immediate='true'".

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.

> 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.

--
Lew

On 11-05-26 08:39 PM, Lew wrote:
> markspace wrote:
>> Lew wrote:
>>> I've been able to work out "all this" pretty much from
>>> http://download.oracle.com/javaee/6/...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?"

> 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.

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.

For my own amusement I dissected the JSF controller behaviour some years
ago. With reference to Fowler's P of EAA stuff, there are aspects of
both front and page controllers in JSF. To be pedantic, I'd argue that
it's still more Front controller than Page controller: the FacesServlet
actually handles the requests. The getters/setters in a JSF backing bean
that are associated with UI components only process a request meant for
them in a rather anemic, last-mile way. And the actions in a backing
bean are akin to the command objects inherent in Front Controller.
FacesServlet handles the navigation also.

If someone makes a Page Controller argument for JSF, and that's been
done more than once, I won't get bent out of shape because of it. One
one level of abstraction the JSF beans look like page controllers. As
long as one understands the mechanics that's fine. But I personally
really think it's still Front Controller.

> 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_T...ttribute_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.

> 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.

>> 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.

AHS

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/...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_T...ttribute_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/wikipedi.../c/cf/Friz.jpg