Bear Bibeault

Randy Maddocks wrote:They couldn't have picked a better actor than Jack Nicholson to play Jack Torrance in The Shining...about as insane as they come!

Actually, I thought that was the problem. The character was supposed to start off sane and go increasingly insane as the story went on. Nicholson's character was clearly insane from the outset -- Nicholson can't play anything other than insane. So I actually thought he was a poor choice for the role.

The selector identifies the input element, not the label. The label plays no part in your script.

The jQuery selector $('img') matches any element of type img, so you're getting a matched set of all images. Since attr() only operates on a single element, it's giving you the value of the first image. Always.

Your post contains little context. Is getInfo() called from a click handler? If so, inside a click hander, the clicked element is found via this.

So, something like:$(this).attr('alt') would be more likely what you are looking for. But you need to be careful, the value of this is per function, so why do you have a separate getInfo() function in the first place? Why not just do this work in the click handler?

P.S. This is a misuse of alt which has its own distinct purpose. If you are going to use an attribute for your own purposes, I suggest you use a custom attribute. In HTML5, custom attributes start with "data-", so you can create any that you like, data-fred, for example, where "fred" can be anything that you want (and makes sense for what you are using it for).

P.P.S. If you are just looking for a distinct id for each image, you already have that in the id attribute. Why add another?

Harry Kar wrote:Disneyland is not in Orlando?

No. That's DisneyWorld.

Junilu Lacar wrote:Andy Hunt's Rule #1: Always consider context.

Quoted for emphasis.

Daniel Demesmaecker wrote:that seems to unnecessesarily [sic] slow down the program

Please post how you tested this, and the data that supports this assertion.

The JSP-ness is irrelevant once things get to the browser, so it all ends up being one page. So, yes, it should work.

Reasons it might not work:

Do you have more than one element with that id? id values must be unique on a page. It's best to avoid them and use class names rather than ids unless you know they are clearly intended to be, and will be, unique.

Are you sure that the element exists before this code executes? You could have a race condition.

Check the code for pcdaohist.getHistoryPaciente(). That's where the value is coming from.

Swastik Dey wrote:If it contains only static contents, html/css/js are good enough.  But if it's a dynamic kind of web site you need support of servlet/jsp etc at the back end.

I'll disagree with this classification. "Dynamic" to me, means that the site has behavior. So a dynamic site uses JavaScript for client-side behavior, and backend code (perhaps Servlets with JSP, but there are many choices) for back-end behavior.

A static site -- one with no behavior -- needs only HTML for structure, and CSS for styling.

Is there actually a problem at run-time? IDE errors and warnings are notoriously unreliable.

A past implementation:

A POST is used to create a re-usable search query resource. A GET is used to fetch the results of running a parameterized search using the query resource.

Pure REST.

Java and JavaScript have very few similarities other than some common syntax, and even that is rapidly diverging as each language evolves.

And the pro-active answer in case the question was "Why aren't JavaScript classes identical to Java classes?" is that the classes of any language other than Java are not identical to Java classes; why would JavaScript be any different?

JavaScript does have classes. You need to get up to date with the latest versions of JavaScript (EcmaScript 6 and beyond).

That said, the classes aren't identical to Java classes, but I'm pretty sure that's not what you meant. (In which case the question would have been "Why aren't JavaScript classes identical to Java classes?")