Win a copy of Beginning Java 17 Fundamentals: Object-Oriented Programming in Java 17 this week in the Java in General forum!

Jim Steinberger

Greenhorn
+ Follow
since Jun 22, 2004
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jim Steinberger

Welcome, Bill! Though I feel strange welcoming you, since this is my first day as a registered member here. I'd like to solely credit you with my registration, but I was especially tech-motivated in general today due to hearing about Eclipse 3.0 finally being released.

(note: I'm terribly sorry for the length of this post -- feel free to pick-and-choose what you read and respond to; I won't be offended =) )

I've actually been using 2.1.3 exclusively -- I tried switching to a 3.0 stream release (M4, I believe) awhile back, but none of my Ant tasks would work because there was a bug in that Eclipse couldn't read in my property files if there was a space in their filepath, and circumstances at my work prevented me from working around that.


My questions to you, then, have to do with new Eclipse 3.0 features, since I have been a bit out of the loop. Specifically, my questions stem from http://www.idevnews.com/TipsTricks.asp?ID=115 . Until I read that article, I was ignorant of plans for "rich client application development" or "opening up Java tools."


For example, my first passes through the "rich client application" stuff got me horribly excited, as I thought this meant built-in GUI support, preferably SWT -- which I love. This appeals to me since I haven't found a decent SWT GUI plug-in that wasn't rather expensive. Hehe, I'm pretty sure now that I completely misunderstood, but the article linked above, nevertheless, stresses "general application development" with regard to this new feature, and I'm having trouble wrapping my brain around the concept. Maybe I'm getting lost in the buzzwords; I'm wondering if you're familiar with this and could possibly try to summarize it


Similarly, the part on "generalized Java tools" says: "Finally, Eclipse 3.0 will provide support for debugging Java like files e.g. JSPs." Does this mean (which is the other reason I was way over-excited about the upcoming release of 3.0) that Eclipse 3.0 will have Lomboz-like functionality built-in, at least with regard to JSPs, and/or that refactoring will now extend to JSPs? Or did they mean that debugging JSPs, etc., is a possible extension of the new functionality? i.e. it's a possibility when someone writes the code for it?


It's just that I hadn't heard these plans yet and I haven't had time to scour the Eclipse site for which plans were implemented, etc. I'm assuming you've used a very recent release and could spare me a lot of research The other reason I worry is that, at a glance, the list of chapters in your book seemed like they could also very well have been the list of chapters for an Eclipse 2.1.* book. Is that because your book covers the requisite Eclipse basics, and is simply updated to the Eclipse 3.0 look-and-feel?

Bonus question: How does one approach the business of tech-book writing? Do authors approach the publishers with their ideas as with traditional books? It'd almost make more sense to me that the publishers would publish a list of books they need written. e.g. I can envision Manning recognizing that Hibernate and JavaServerFaces are growing in popularity and potential usefulness, and soliciting authors. But I have no idea -- I'm certainly interested, though.


You have my guilty gratitude if you've read even half of this At any rate, thanks for being here!

Jim

I have installed JSP plugin in Eclipse. But it doesn't work. We use struts frame work and it is saying JSP Parsing Error: File WEB-INF/struts.tld is not found.

I am sure this tld are available in Eclipse path



I think your plug-in's working fine -- the error message it's giving you is a very good sign actually; it seems to have detected and pointed out a minor user error, which is exactly why it's useful.


I'm going to assume you're using the Lomboz plugin, and I'm going to assume you're getting this error when saving a JSP that has a taglib directive in it, such as: <%@ taglib prefix="bean" uri="/WEB-INF/struts-bean.tld" %>.

The taglib directive instructs Tomcat to load the specified tag library into memory if it isn't already, so that the JSP can make use of the special tags contained in it. Struts 1.1 comes packaged with six tag libraries:
struts-bean.tld
struts-html.tld
struts-logic.tld
struts-nested.tld
struts-template.tld
struts-tiles.tld

If you "intalled" Struts correctly, you put those *.tld files in the WEB-INF folder of your web application.

The uri portion of the <% taglib ... %> directive should point at a *.tld file in the WEB-INF directory. You posted that you're getting the error that "struts.tld" cannot be found -- unless you manually changed the filename of one of the supplied tag libraries, I think your problem is that you accidentally left out part of the filename. That is, "struts.tld" isn't one of the supplied tag libraries.

If that doesn't help you, could you post the <% taglib ... %> lines you have in the JSP that's giving you trouble?

Good luck!
[ June 22, 2004: Message edited by: Jim Steinberger ]
I know you got a solution working -- wanted to put my two cents in for other people that happen by.

--------------
if (param1 == 1 || param2==1) {
// do this
}
--------------

FYI, if for some reason you're dead-set against using jstl core or scriptlets, you *can* achieve OR-logic with logic:equal tags:

<logic:equal name="param1" value="1">
<!-- do this -->
</logic:equal>
<logic:equal name="param2" value="1">
<!-- do this -->
</logic:equal>

Yes, "<!-- do this -->" will be repeated HTML, but it's up to us to weigh the tradeoffs. Certainly, with the massive hard drives in today's servers, JSPs don't have to be as tiny as possible. Also, as long as the values you're comparing aren't calculated -- or, even worse, being queried via a connection to a remote database -- extra comparisons aren't going to substantially affect processing time.

One issue is maintenance, but if you extract "<!-- do this -->" into a template file to be jsp:included, that issue goes away.


Of course, a better solution is to have a JavaBean that returns "(param1 == 1 || param2==1)" as a boolean, so you can merely:
<logic:equal name="bean" property="orCondition" value="true">
<!-- do this -->
</logic:equal>

That way, non-trivial (business?) logic is out of the JSP.
17 years ago