Double the Complexity!

[Fletcher Estes]

I have to take issue with Sun's suggestion that JSTL and EL makes JSPs "scriptless" and "easy". The JSTL is so finely grained, and mirrors straight code so closely, that all it does is double the amount of learning required. Sun would suggest that web-designers find it easier to use tags instead of straight Java code - is there any evidence to support this?

I've been working for a few years as a software engineer, and anybody I've worked with who is writing JSPs also writes Java classes. Application programmers write JSPs, not web designers. They know Java. Java is strongly typed and easily debugged. JSTL tags are arcane and highly dependent on deployment descriptors, library and container versions. Bottom line - they are harder to work with, and ultimately unnecessary.

${myObj.val} is supposed to be some improvement over <%=myObj.getVal()%>?? :roll: At least there's only one way to write <%=myObj.getVal()%>. With EL, multiple expression styles are provided which result in the same thing. This is complexity, not ease of use.

I appreciate the facility to be able to write custom tags, and the tag files introduced with JSP2.0 are definitely a step in the right direction, but with JSTL and EL, I think Sun may have lost sight of their audience...
[ January 19, 2005: Message edited by: Fletcher Estes ]

[James Ellis]

I have to agree with you. I'd like to see some pages where using JSTL or EL drastically reduce the complexity of a JSP page as many claim they do.

[Nicholas Cheung]

Sun would suggest that web-designers find it easier to use tags instead of straight Java code - is there any evidence to support this?

For web designers, do you think that they will find using HTML tags easier, or Java code? If so, in order to extend, they will also find that using JSTL and EL easier than Java coding, isnt it?

Nick

[Fletcher Estes]

The only similarity between HTML and JSTL is that the tags are surrounded by angle brackets, so, no, I don't think it is an easier extension than using Java code.

My main point though is that it is developers, not web designers, who write JSPs...

[Deepa Korecherla]

I agree with Fletcher....I don't think JSTL is the right direction of easier coding ...this is going on extending...Servlets-JSP-Tags-CustomTags-now JSTL...I don't think JSTL is taking into the right direction.
Its comparatively harder..

[Krzysiek Hycnar]

Hi,

Disagree with Fletcher.
It takes up to half an hour to get the concept of EL, and a few days to learn how to use it (including core functionality of JSTL).

With MVC frameworks JSPs are just for data gathering/presentation (database access or business logic code there is considered a really BAD practice) and by adding JSTL/EL to it you can keep Java code away from your JSPs.

You can employ "HTML-only aware guys" and teach them how to use JSTL/EL and then tell sth. like: "in this jsp you've got itemsAvail that contains item elements. An item in turn consist of itemID, name, price etc... and your job is to display it as a table where name should be active and linked to say displayDetails.do action which takes one parameter named itemID...".

This way you can gain clear role separation in your project (guys who for example write Struts actions needn't have an idea of JSTL and vice versa) and your staff doesn't have to be really highly qualified - if someone decides to quit it will be easier to find replacement.

To be honest, EL does not come without some minor lacks (and that's where scriptlets still can save your a..). For example I don't know how to get to the servlet init parameters using EL - $(pageContext.servletConfig)... and what then ??

Anyway IMHO JSTL/EL rocks!!

Cheers
Krzysiek

(Excuse me my English :ashamed: )
[ January 25, 2005: Message edited by: Krzysiek Hycnar ]

[Krzysiek Hycnar]

By saying "your staff doesn't have to be really highly qualified" I mean they do not have to be experts on everything (so... no offence, you highly qualified guys)

K

[Krzysiek Hycnar]

Laszlo,

${initParam.myParamName} is (despite its name) for context parameters declared directly under <web-app> in <context-param> element, and I mean servlet init parameters declared inside <servlet> in <init-param> element, so the construct you propose will not work for them

Cheers,
Krzysiek

[Laszlo Kiraly]

Krzysiek,

you are right

sorry for deleting my post, i did it before i saw your answer

greetings,
laszlo