Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #4486 > unrolled thread

Dealing with application names in a JEE web app

Back to article view | Back to comp.lang.java.programmer

Contents

  Dealing with application names in a JEE web app markspace <-@.> - 2011-05-23 12:11 -0700
    Re: Dealing with application names in a JEE web app Lew <noone@lewscanon.com> - 2011-05-23 15:30 -0400
      Re: Dealing with application names in a JEE web app markspace <-@.> - 2011-05-23 12:41 -0700
      Re: Dealing with application names in a JEE web app markspace <-@.> - 2011-05-23 13:10 -0700
        Re: Dealing with application names in a JEE web app Lew <noone@lewscanon.com> - 2011-05-23 17:02 -0400
          Re: Dealing with application names in a JEE web app jebblue <n@n.nnn> - 2011-05-23 19:30 -0500
            Re: Dealing with application names in a JEE web app Lew <noone@lewscanon.com> - 2011-05-23 21:13 -0400
          Re: Dealing with application names in a JEE web app markspace <-@.> - 2011-05-24 09:32 -0700
    Re: Dealing with application names in a JEE web app Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-23 19:01 -0300
    Re: Dealing with application names in a JEE web app Owen Jacobson <angrybaldguy@gmail.com> - 2011-05-23 23:20 -0400
    Re: Dealing with application names in a JEE web app Tom Anderson <twic@urchin.earth.li> - 2011-05-24 18:16 +0100
      Re: Dealing with application names in a JEE web app markspace <-@.> - 2011-05-25 12:16 -0700
        Re: Dealing with application names in a JEE web app markspace <-@.> - 2011-05-25 16:40 -0700
        Re: Dealing with application names in a JEE web app Tom Anderson <twic@urchin.earth.li> - 2011-05-26 18:07 +0100
          Re: Dealing with application names in a JEE web app Lew <noone@lewscanon.com> - 2011-05-26 13:25 -0400
            Re: Dealing with application names in a JEE web app markspace <-@.> - 2011-05-26 12:57 -0700
              Re: Dealing with application names in a JEE web app Lew <noone@lewscanon.com> - 2011-05-26 19:39 -0400
                Re: Dealing with application names in a JEE web app Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-27 07:31 -0300
                  Re: Dealing with application names in a JEE web app Lew <noone@lewscanon.com> - 2011-05-27 10:14 -0400
          Re: Dealing with application names in a JEE web app markspace <-@.> - 2011-05-26 12:51 -0700
          Re: Dealing with application names in a JEE web app Steve Sobol <sjsobol@JustThe.net> - 2011-05-26 14:51 -0700

Page 1 of 2  [1] 2  Next page →

#4486 — Dealing with application names in a JEE web app

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!

[toc] | [next] | [standalone]

#4487

On 05/23/2011 03:11 PM, markspace wrote:
> 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.

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

[toc] | [prev] | [next] | [standalone]

#4489

On 5/23/2011 12:30 PM, Lew wrote:

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

[toc] | [prev] | [next] | [standalone]

#4491

On 5/23/2011 12:30 PM, Lew wrote:
> On 05/23/2011 03:11 PM, markspace wrote:
>> So how do folks write their apps so that they can handle being
>> deployed under
>> different names?

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

[toc] | [prev] | [next] | [standalone]

#4494

You left out too much context.

markspace wrote:
> Lew wrote:
>> markspace wrote:
>>> So how do folks write their apps so that they can handle being
>>> deployed under different names?

>> Relative URLS.

> 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:outputStylesheet 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" >

That would translate to "<application-context>/rsrc/priv/lnf-template.xhtml", 
and I am having a hard time correlating that to the CSS example above.

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

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

[toc] | [prev] | [next] | [standalone]

#4505

On Mon, 23 May 2011 17:02:51 -0400, Lew wrote:

> You left out too much context.
> 
> markspace wrote:
>> <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:outputStylesheet name="/css/purrtones.css" />

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

-- 
// This is my opinion.

[toc] | [prev] | [next] | [standalone]

#4507

jebblue wrote:
> Lew wrote:
>>     <h:outputStylesheet name="/css/purrtones.css" />

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

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

[toc] | [prev] | [next] | [standalone]

#4540

On 5/23/2011 2:02 PM, Lew wrote:

> <h:outputStylesheet 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:outputStylesheet 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:outputStylesheet.  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:outputStylesheet 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.

[toc] | [prev] | [next] | [standalone]

#4498

On 11-05-23 04:11 PM, markspace wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#4512

On 2011-05-23 15:11:32 -0400, markspace said:

> 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

[toc] | [prev] | [next] | [standalone]

#4543

On Mon, 23 May 2011, markspace wrote:

> 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%28%29

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

-- 
Just because Congresspeople do it, doesn't mean it's right. -- Ian York

[toc] | [prev] | [next] | [standalone]

#4580

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 
h:outputStylesheet, it emits HTML that loads the static resource through 
the Faces servlet.  For example, this:

<h:outputStylesheet 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:outputStylesheet, and certainly doesn't discuss its tags or 
parameters anywhere that I could find.

[toc] | [prev] | [next] | [standalone]

#4586

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

[toc] | [prev] | [next] | [standalone]

#4606

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 h:outputStylesheet, 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 
> h:outputStylesheet, 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

[toc] | [prev] | [next] | [standalone]

#4607

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

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

[toc] | [prev] | [next] | [standalone]

#4610

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

[toc] | [prev] | [next] | [standalone]

#4618

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

[toc] | [prev] | [next] | [standalone]

#4644

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/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?"

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

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

[toc] | [prev] | [next] | [standalone]

#4648

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

[toc] | [prev] | [next] | [standalone]

#4609

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.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web