Dealing with application names in a JEE web app

markspace · May 23, 2011

Hi all,

I'm delving more heavily into JSP/Servlets and JSF at the moment. I've
found something that looks like a questionable design issue by the JEE
folks at Sun (now Oracle, of course) and I'd like to pick your brains
about how you might deal with it.

Basically, when developing a JEE web app, the application name gets
inserted into every URL and associated path. If my app is named
TechDarwinia, for example, then all URLS look like this:

http://localhost:8080/TechDarwinia/
http://localhost:8080/TechDarwinia/faces/readPost.xhtml
http://localhost:8080/TechDarwinia/rsrc/css/style.css

The problem is of course that the web app could be renamed anything by
the deployer/sysop, and I've got strings hard coded to that app name
TechDarwinia.

So how do folks write their apps so that they can handle being deployed
under different names?

I can think of a couple of solutions, but they don't seem good.

One solution might be to make the app name an application parameter.
This would mean that everywhere I have to insert some sort of EL
variable, or equivalent, and the app takes extra time replacing the
parameter constantly. Also, the installer has one extra parameter to
configure, and I'd like to avoid that.

The app parameter method fails where URLs are required but it's not
possible to invoke Java. For example, in a static resource like CSS:

body {
background:url(/TechDarwinia/rsrc/img/bbg.jpg) left top repeat;
....

Another solution might be, and I haven't investigated this fully, to use
another agent, like Apache, that has the ability to rewrite URLs before
they are presented to the container, inserting the app name wherever it
is lacking. This also requires extra CPU overhead for each request,
(but only one string swap per request, where the app parameter method
may require many EL substitutions), and also extra work by an installer.
This could be very complicated though, as using more than one app at a
time might make the re-write rules overly complicated.

Both cases run the risk of two application names colliding, as there's
no real convention regarding name we apps.

So, has anyone also encountered issues like this? And how did you fix them?

Thanks all!

Lew · May 23, 2011

Hi all,

I'm delving more heavily into JSP/Servlets and JSF at the moment. I've found
something that looks like a questionable design issue by the JEE folks at Sun
(now Oracle, of course) and I'd like to pick your brains about how you might
deal with it.

Basically, when developing a JEE web app, the application name gets inserted
into every URL and associated path. If my app is named TechDarwinia, for
example, then all URLS look like this:

http://localhost:8080/TechDarwinia/
http://localhost:8080/TechDarwinia/faces/readPost.xhtml
http://localhost:8080/TechDarwinia/rsrc/css/style.css

The problem is of course that the web app could be renamed anything by the
deployer/sysop, and I've got strings hard coded to that app name TechDarwinia.

So how do folks write their apps so that they can handle being deployed under
different names?

Relative URLS.

markspace · May 23, 2011

Relative URLS.

That seems worse. Now my pages are all dependent on their location in
the directory hierarchy. I like to move things around, especially as I
first start development.

I guess I could constantly refactor as I move things, but I'd like to
avoid that also.

markspace · May 23, 2011

Relative URLS.

I found a use-case where this doesn't work.

Templates are used by various other pages in the web app. They have a
static location, but their links are processed as if the template's
"location" in the directory hierarchy was the location of the template
client.

Example: I have a template at /rsrc/priv/lnf-template.xhtml which
includes other resources. Abbreviated example:

<LNF-TEMPLATE.XHTML>

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html">

<h:head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<link href="../css/style.css" rel="stylesheet" type="text/css" />
<title>
<ui:insert name="title">
Facelets Template
</ui:insert>
</title>
</h:head>

<h:body>
...
</LNF-TEMPLATE.XHTML>

That link href to the style sheet is processed by the client, but the
client could be any page in the directory hierarchy.

For example for a client from the root directory (/readPost.xhtml), that
relative link in the template doesn't work.

<READPOST.XHTML>

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:ui="http://java.sun.com/jsf/facelets">

<h:body>
<ui:composition template="/rsrc/priv/lnf-template.xhtml" >
Hello from Facelets
</ui:composition>
</h:body>

</html>

</READPOST.XHTML>

Pretty ugly, if you ask me.

Lew · May 23, 2011

You left out too much context.

I found a use-case [sic] where this doesn't work.

No, you didn't. I meant relative to the app context, not with stupid "../"
prefixes.

Templates are used by various other pages in the web app. They have a static
location, but their links are processed as if the template's "location" in the
directory hierarchy was the location of the template client.

Example: I have a template at /rsrc/priv/lnf-template.xhtml which includes
other resources. Abbreviated example:

<LNF-TEMPLATE.XHTML>

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html">

<h:head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<link href="../css/style.css" rel="stylesheet" type="text/css" />

What? No!

<link href="/css/style.css" rel="stylesheet" type="text/css" />

Here's a line from one of my own personal facelet projects:
<ui:composition template="/WEB-INF/templates/template.xhtml">

Here are a couple of lines from that template file:

....
<h

utputStylesheet name="/css/purrtones.css" />
</h:head>
<h:body>
<t:div>
<ui:insert name="header">
<h:graphicImage id="logo" value="/images/Duncan_and_the_purrtones.png"
alt="#{bundle.bandname} logo" styleClass="logo"
/>
</ui:insert>
....

All those paths are relative to the deployed application name, which is
"/purrtones" by default, but as you say can change. Thus, the image URL
becomes, e.g.,
http://localhost:8080/purrtones/images/Duncan_and_the_purrtones.png
..

<title>
<ui:insert name="title">
Facelets Template
</ui:insert>
</title>
</h:head>

<h:body>
...
</LNF-TEMPLATE.XHTML>

That link href to the style sheet is processed by the client, but the client
could be any page in the directory hierarchy.

For example for a client from the root directory (/readPost.xhtml), that
relative link in the template doesn't work.

<READPOST.XHTML>

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:ui="http://java.sun.com/jsf/facelets">

<h:body>
<ui:composition template="/rsrc/priv/lnf-template.xhtml" >

Hello from Facelets
</ui:composition>
</h:body>

</html>

</READPOST.XHTML>

Pretty ugly, if you ask me.

I use relative links in templates all the time. But you have to start them
from "/", which translates to the application context root, which is the thing
you're trying not to repeat.

Arved Sandstrom · May 23, 2011

Hi all,

I'm delving more heavily into JSP/Servlets and JSF at the moment. I've
found something that looks like a questionable design issue by the JEE
folks at Sun (now Oracle, of course) and I'd like to pick your brains
about how you might deal with it.

Basically, when developing a JEE web app, the application name gets
inserted into every URL and associated path. If my app is named
TechDarwinia, for example, then all URLS look like this:

http://localhost:8080/TechDarwinia/
http://localhost:8080/TechDarwinia/faces/readPost.xhtml
http://localhost:8080/TechDarwinia/rsrc/css/style.css

The problem is of course that the web app could be renamed anything by
the deployer/sysop, and I've got strings hard coded to that app name
TechDarwinia.

So how do folks write their apps so that they can handle being deployed
under different names?

[ SNIP ]

That "application name" is simply the web context root. A J2EE/Java EE
application server can host more than one web application, and that
context root in the request URLs is how the app server knows how to pass
the request to Web App A and not Web App B.

You (anyone in the ops chain) have complete control over what the web
context root is, in the application.xml.

With respect to your complaint about relative URLs, in response to Lew's
suggestion to that effect, I don't think *any* system handles arbitrary
movement of web resources (HTML, JSP, XHTML etc). Regardless of how a
controller parses the resource path described by the URL (URL parts
corresponding to directories in a filesystem hierarchy, or something
different like grabbing resources out of a DB) there still has to be a
definite mapping. This isn't even a J2EE/Java EE thing: it's a web app
thing right across the board.

For your other problem, since the resource locations aren't changing,
and you are using Faces (Facelets), you have access to JSF EL implicit
objects. In a situation like this I use (off the top of my head)

#{facesContext.externalContext.requestContextPath}

so for example

#{facesContext.externalContext.requestContextPath}/rsrc/css/style.css

AHS

Lew · May 24, 2011

purrtones? Is this CSS for the late evenings...

Duncan is a debonair orange tabby cat, and the PurrTones are his Motown-style
singing group. Mrrreow!

Owen Jacobson · May 24, 2011

Hi all,

I'm delving more heavily into JSP/Servlets and JSF at the moment. I've
found something that looks like a questionable design issue by the JEE
folks at Sun (now Oracle, of course) and I'd like to pick your brains
about how you might deal with it.

Basically, when developing a JEE web app, the application name gets
inserted into every URL and associated path. If my app is named
TechDarwinia, for example, then all URLS look like this:

http://localhost:8080/TechDarwinia/
http://localhost:8080/TechDarwinia/faces/readPost.xhtml
http://localhost:8080/TechDarwinia/rsrc/css/style.css

The problem is of course that the web app could be renamed anything by
the deployer/sysop, and I've got strings hard coded to that app name
TechDarwinia.

So how do folks write their apps so that they can handle being deployed
under different names?

<c:url> and equivalent tools that inspect the actual context path (the
"/TechDarwinia/" part of your URL) for the request, largely.

-o

markspace · May 24, 2011

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

Thanks for pointing this out. I was using a regular <link> attribute.
Those don't seem to be translated or affected by the JSF processing at
all, and just emit their HTML literally. The h

utputStylesheet looks
more sophisticated.

I found a website which explains a bit more:

<http://blogs.oracle.com/rlubke/entry/jsf_2_0_new_feature4>

I've got _Java Server Faces 2.0_, by Ed Burns et al, pub. McGraw-Hill.
Ed Burns was apparently the spec co-lead for JSF 2.0, and I have to say
I'm not impressed by his book. His section on templates uses raw HTML
<link> attributes just like I did, and the whole book barely mentions
h

utputStylesheet. It's only touched on once in the listing of the
entire component library, which is a pretty unpedagogical way of
presenting it.

The Burns book also says that h

utputStylesheet looks for its resources
under the /resources directory in the application root. Since you're
plainly specifying a different location, I'm going to have to explore
resource resolution here a bit more to figure out what the full story is.

Thanks again for getting me pointed in the right direction.

Tom Anderson · May 24, 2011

So how do folks write their apps so that they can handle being deployed
under different names?

Just to add to what others have said, the ground truth value for the path
at which your app is located is HttpServletRequest.getContextPath:

http://download.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#getContextPath()

Having access to that lets you programmatically construct URLs of various
kinds (absolute, host-relative, etc). That's how various things, like
c:url, get this right.

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;

A similar approach should be usable in other static resources which
contain links.

tom

markspace · May 25, 2011

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
h

utputStylesheet, it emits HTML that loads the static resource through
the Faces servlet. For example, this:

<h

utputStylesheet 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 h

utputStylesheet, and certainly doesn't discuss its tags or
parameters anywhere that I could find.

markspace · May 26, 2011

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;
}

Tom Anderson · May 26, 2011

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;

Click to expand...

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

Lew · May 26, 2011

Tom said:
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/tutorial/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.

markspace · May 26, 2011

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.

markspace · May 26, 2011

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

Lew · May 27, 2011

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.

Arved Sandstrom · May 27, 2011

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

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.

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

Lew · May 27, 2011

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.

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

Click to expand...

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.

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!

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!

How to effectively develop a web application from scratch?	0	Jul 2, 2023
How to go about building a crud app when you are a noob	1	Jan 2, 2023
Not connecting with Java Application Server in JEE 5	0	Apr 15, 2007
Web app on the desktop	11	Jun 3, 2008
Problem with JEE 5 Sun Java System Application Server	1	Apr 14, 2007
running a web app using NetBeans &tomcat	1	Nov 10, 2008
Root application in Tomcat6 and servlet-mapping	0	Oct 19, 2007
I need help in understanding these files on my phone, Could someone help me understand these files? Urgent help needed. Please help.	3	Jun 4, 2023

Dealing with application names in a JEE web app

markspace

Lew

markspace

markspace

Lew

Arved Sandstrom

Lew

Owen Jacobson

markspace

Tom Anderson

markspace

markspace

Tom Anderson

Lew

markspace

markspace

Lew

Arved Sandstrom

Lew

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads