|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 24
Messages: 24
Messages: 24
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
JSR-245, JavaServer Pages 2.1 Public Review, approved by JCP
JavaServer Pages 2.1, JSR 245, has been approved by the JCP executive committee with Oracle, Nortel, and Google abstaining without comment.
This release focuses on issues concerning the JSP expression language and integration with JavaServer Faces. As summarized before on TSS, the changes approved for JSP centered around the following elements:
- JspApplicationContext - This class contains context information specific to JSP containers, and allows pluggable expression language resolvers
- Expression Language changes - A new package for expression language classes was created, and the old package was deprecated. Many new features were added to the expression language.
- Tag library changes - New rules and capabilities for the use of tag files and libraries were added.
- trimWhiteSpaces directive - A JSP page can now be directed to remove whitespaces after JSP directives that do not have any other content after them.
- Minor bugfixes to the JSP 2.0 specification.
JSP 2.1 is being targeted for J2EE 1.5.
|
|
|
Message #170978
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EL Method calls
Reading the spec, it seems that you can access a bean property, array index, list index or map entry using the EL syntax. But not make a call onto a bean method like toDate().
This greatly affects many projects (like my own Joda-Time) where various methods that you want to call from EL are named toXxx() or withXxx() instead of getXxx().
However, perhaps it is possible for us to implement ElResolver ourselves to do this? And register this into JSF/JSP?
|
|
|
Message #170983
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EL Method calls
Why just not throw that crappy EL thing out of the window and use OGNL instead?
|
|
|
Message #170988
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EL Method calls
Reading the spec, it seems that you can access a bean property, array index, list index or map entry using the EL syntax. But not make a call onto a bean method like toDate().This greatly affects many projects (like my own Joda-Time) where various methods that you want to call from EL are named toXxx() or withXxx() instead of getXxx().However, perhaps it is possible for us to implement ElResolver ourselves to do this? And register this into JSF/JSP?
Yes, you can provide your own ELResolver within your web app to resolve your own properties/variables.
Jacob Hookom (JSR 252 & EL)
JSF Facelets
|
|
|
Message #170992
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EL Method calls
Why just not throw that crappy EL thing out of the window and use OGNL instead?
EL has a very specific purpose in providing the 'view' the ability to read properties avialable in scope. Lets imagine for a second that all JSP development was done with OGNL. With OGNL, you are opening up a whole subset of functionality that is exposed to the view layer of your application. Most architects don't like this idea.
With the new EL API, ValueExpressions and MethodExpressions are provided to more greatly enhance the request/response lifecycle of the web. An expression can be created on one response to the browser, then invoked later in a subsequent request back to the server. JavaServer Faces uses this functionality for easy page/component development (model 1).
So for those that are looking for OGNL functionality-- go ahead and use it. For the common case, EL is there and provides the features that most developers are looking for. During the JSR process, there was only *one* person that expressed the desire to invoke any method on any object. If that tells you anything...
Jacob Hookom (JSR 252 & EL)
JSF Facelets
|
|
|
Message #170994
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EL Method calls
With OGNL one could do quite innocent, read-only operations like
"blah instanceof my.app.package.Klass"
or
"blah == @my.app.package.Klass@STATIC"
And honestly I don't really care what would so-called "architects" say here. Everything you can access from OGNL are just beans; so if you don't trust those developer guys, expose only View Helper read-only beans available to them. Poor coders are no excuse for use of restricting technology.
|
|
|
Message #171040
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EL Method calls
With OGNL one could do quite innocent, read-only operations like
"blah instanceof my.app.package.Klass"
or
"blah == @my.app.package.Klass@STATIC"
Another person might say that code like that has no reason to be contained in the view. I see the point you are making and have looked at OGNL in the past, but I, like many, believe that putting scripting language in the view isn't the right course of action as a *standard*-- that's the clear emphasis here.
With earlier versions of JSP, the only tool available was scriplets (<% %>). This has quickly fallen out of favor as being hard to maintain, poor practice, whatever. Resultingly, EL has since replaced scriplets as the standard practice in JSP and JSPX.
Truthfully, I wouldn't consider the EL-API a scripting language by any means, but a way of expressing pointers to data you need. The new EL-API really emphasises this point with being able to create and save EL 'pointers' or Expressions for use later. This includes Method invocation with MethodExpressions.
-- Jacob
|
|
|
Message #171129
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Views
Being able to call a method on a Java object is very useful.
Unfortunaley over the 5 years there has been a great amount of "architectural" confusion in the J2EE Web space. People have labelled web frameworks as MVC designs, and have confused application layering in the process.
In most rich GUI components they are both the View and the Control. MVC is design pattern for special cases when you have multiple views onto the same model, being notified in an Observer style pattern. This really has very little to do with the usual web Command pattern, where people call DAOs 'models', JSP 'views' and Actions/Commands/Servlets etc 'controls'.
JSP/Taglibs make it very difficult to encapsulate the control functionality of a GUI component, as they are really write only objects. However people think this is OK because they are the "View" "layer". Please note architectural layering is a different concept.
The end result is that we have J2EE web technologies with very poor encaspulation, making development difficult and reuse even harder.
Also note that MVC is overkill for most rich client GUI work, as a Button is both a Control, a View and a Model. Swing fortuantely hides most of the implementation so you dont need to worry about it. Most other desktop GUI frameworks don't use MVC at all.
|
|
|
Message #171132
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Views
Please note architectural layering is a different concept.The end result is that we have J2EE web technologies with very poor encaspulation, making development difficult and reuse even harder.Also note that MVC is overkill for most rich client GUI work, as a Button is both a Control, a View and a Model. Swing fortuantely hides most of the implementation so you dont need to worry about it. Most other desktop GUI frameworks don't use MVC at all.
You are describing JavaServer Faces... one of the reasons for the new JSP 2.1 specification--- and EL alignment, is so JSF and JSP can work more seemlessly together.
Jacob (JSR 252 EG)
|
|
|
Message #171138
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EL Method calls
Or better yet...just use Java!
Why the hell did they come up with all of these stupid 'expression langauges' to avoid coding in java. This was dumb of Sun.
I have never seen anyone use this crap.
The power of Java in the JSP is something wonderful. No reflection. No need to use 'beans'. No need to use taglibs. Just pure high performance pages.
Life is great without all of this crap.
It's like the designers got together and said 'lets see how many layers of indirection we can provide in the name of simplicity'.
It's dumb I tell you.
|
|
|
Message #171157
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EL could be enhanced
EL should be used to read properties in the view. I agree with that. However, there are two things that I don't like with EL.
First, it's not possible to have access to constants.
For example, I often have to display select boxes with constants as values. Hardcoding the value of the constant in the page doesn't seem good to me. So I often have to add stupid getters to my beans to access the constants:
<code>
public int getNEVER() {
return Constants.NEVER;
}
public int getSOMETIMES() {
return Constants.SOMETIMES;
}
public int getALWAYS() {
return Constants.ALWAYS;
}
</code>
And these getters can't even be static, because the EL can't call them if they are.
The second thing I don't like is that I can't access indexed properties. The only possible way is to put them into a Map, and expose the map to the outside, which breaks encapsulation IMHO.
|
|
|
Message #171185
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Methods are important
During the JSR process, there was only *one* person that expressed the desire to invoke any method on any object. If that tells you anything...
Yes, it tells me that the people writing the spec don't actually use the technology that they are defining (a problem that has come up repeatedly with JSR specs).
Let me explain the exact case where this matters to Joda-Time. We provide a complete set of replacement date and time classes, which are often used as JavaBean properties. However, various jsp tags still expect a Date or Calendar object as input.
Joda-Time provides great interoperability methods called toDate() and toGregorianCalendar() which are designed to be used in cases like this (and which follow the Sun naming conventions for methods of this type). However, EL (and thus JSP/JSF) can't use these methods because of the spec writers 'holier than thou' attitide against method calls.
Thus, instead of:<br />
<fmt:formatDate value="${myBean.startDate.toDate()}"/><br />
I have to do:
<% MyBean bean = (MyBean)pageContext.findAttribute("myBean");
java.util.Date startDate = bean.getStartDate().toDate();
pageContext.setAttribute("startDate", startDate);
%>
<fmt:formatDate value="${startDate}"/>
The good news is that another alternative is to write my own ELResolver. The bad news is that I have to code it, maintain it, make it available from the Joda-Time website, teach people to use it and thats its 'non-standard'. (Code and effort that will probably be dupilcated by many people across many projects)
So, are you still convinced that You're right and all of us developers need to be constrained?
|
|
|
Message #171189
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Any hints why Oracle, Nortel, Google were not there?
Oracle is very active in JSF area. What
message they send by "no vote"? I guess
Nortel and Google also are trying to
communicate something?
Alex V.
|
|
|
Message #171197
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
[OT] Methods are important
During the JSR process, there was only *one* person that expressed the desire to invoke any method on any object. If that tells you anything... Yes, it tells me that the people writing the spec don't actually use the technology that they are defining (a problem that has come up repeatedly with JSR specs).
That couldn't be farther from the truth. There are many developers participating in the spec, and there are many developers out 'in the trenches', like myself that see issues/advantages pop up in development.Let me explain the exact case where this matters to Joda-Time. We provide a complete set of replacement date and time classes, which are often used as JavaBean properties.
As to why Joda Time didn't just extend java.util.Date is beyond me. It would have made Joda Time much more interoptable with every other solution out there-- JSTL for one, ORM solutions, etc.
The good news is that another alternative is to write my own ELResolver. The bad news is that I have to code it, maintain it, make it available from the Joda-Time website, teach people to use it and thats its 'non-standard'. Hey, so is Joda-Time, but we know that's not the point you are trying to prove. Conversions are often times done with the FunctionMapper "jd:toUtil(jodaDate)".
(Code and effort that will probably be dupilcated by many people across many projects)So, are you still convinced that You're right and all of us developers need to be constrained? What it comes down to is while it is easier to simply do dot notation for method invocation-- really it is, we've found ways to be able to provide the same behavior in other ways-- function mappers, method expressions, etc-- without turning EL into a scripting language-- that is *not* EL's intentions.
-- Jacob
|
|
|
Message #171211
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
EL could be enhanced
With suggestions of constants and indexed bean properties, I would recommend that you email the JSR EG at jsr-245-comments@jcp.org, your suggestions are then submitted to the group for voting and discussion.
Otherwise you can get involved in the JCP process in the future by going to jcp.org. Speaking from experience, I don't work for any vendor, just a medical company, and wanted to participate in the design of JSF and JSP. I recommend more people do the same.
-- Jacob
|
|
|
Message #171223
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
[OT] Methods are important
When did it become [OT] to criticise the spec being referenced in the thread?
As to why Joda Time didn't just extend java.util.Date is beyond me. It would have made Joda Time much more interoptable with every other solution out there-- JSTL for one.
We don't subclass it because ther is no 'is-a' relationship. Date has very odd semantics that probably 99% of its users don't really realise. (ie. it is not technically feasible for us to extend Date) Joda-Time gets away from those weird semantics, in fact thats part of its raison d'etre.
Anyway, this is NOT a thread about Joda-Time, but about an entire set of pre-existing Java classes/methods that EL will not work with in a simple manner.
Conversions are often times done with the FunctionMapper "jd:toUtil(jodaDate)".
But why? Why does every EL user need to write a static method function every time they want to convert an object from one type to another? Why can't EL users just call the conversion method already written on the object using Sun's naming conventions? Am I supposed to rename the method to getAsDate() ?!!! Its just exasperating.
What it comes down to is while it is easier to simply do dot notation for method invocation-- really it is, we've found ways to be able to provide the same behavior in other ways-- function mappers, method expressions, etc-- without turning EL into a scripting language-- that is *not* EL's intentions.
At least we are clear that it is an architectural choice. IMHO, the wrong one, as it makes your user's lives harder for little, if any, technical benefit.
|
|
|
Message #171237
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
[OT] Methods are important
When did it become [OT] to criticise the spec being referenced in the thread? ... Anyway, this is NOT a thread about Joda-Time....
... Exactly.
EL is founded on the JavaBean specs, not general naming conventions. I like the idea of incorporating 'toXXX' within JSF or providing a JSP convert tag that is similar to c:set that works off of 'toXXX' in order to provide the functionality you expect.
Again, I recommend that you send comments to the JSR group for consideration. It's kind of like electing a president... if you didn't vote or weren't involved in the first place, then it's hard to complian after the fact.
-- Jacob
|
|
|
Message #171254
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
[OT] Methods are important
And there I was thinking that an example would be a good way to make a general point.
I can understand your fustration at people not getting involved in your JSR, however IMHO it is just impossible to maintain an interest in every single project or JSR going on in the world of Java. Thus we rely on the expert group members making the right choices.
I will try to find time to write to the expert group. However, my previous experience of JSR involvement wasn't terribly positive, so I'm not exactly enthused.
|
|
|
Message #171263
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
[OT] Methods are important
During the JSR process, there was only *one* person that expressed the desire to invoke any method on any object. If that tells you anything... Yes, it tells me that the people writing the spec don't actually use the technology that they are defining (a problem that has come up repeatedly with JSR specs).
That couldn't be farther from the truth. There are many developers participating in the spec, and there are many developers out 'in the trenches', like myself that see issues/advantages pop up in development.
I have to agree with Stephen here. _Every_ single time I've had to write a serious app using JSPs and JSTL, I've cursed the inability in JSTL to call more than basic getter methods and access collection elements, to get at part of my doomain object graph that is being exposed to the view as model data. This is not about the view being able to modify data, but simply about being able to access that data. Consider the simple example of a variant of a 'getter' method that needs to take one or two 'qualifiers' or key values. A typical domain object graph will have a decent number of access mechanism for objects in the graph that are not expressed as simple JavaBean getter methods or collection access.
So over and over again I find myself in the situation where my service layer has passed up what should be a perfectly usable object graph to my view layer, and then I have to morph that to another object hierarchy or or stuff it in some collections, etc., just so my JSTL code can access it.
On the other hand, I've used and seen used OGNL in Tapestry apps, with full access to the methods of objects being exposed to the view, with no ill effects, and a lot less hassles and unneeded code.
To me, this is a sign of a fundamentally bad assumption on the part of the spec team, that people using the expression language can not be trusted, so their access should be limited. The onus of trust should instead be placed on what object graph is exposed to the view template technology (i.e. limit that object graph), and then letting the view template technology fully access that object graph.
Regards,
Colin
--
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com
|
|
|
Message #171304
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
[OT] Methods are important
To me, this is a sign of a fundamentally bad assumption on the part of the spec team, that people using the expression language can not be trusted, so their access should be limited. The onus of trust should instead be placed on what object graph is exposed to the view template technology (i.e. limit that object graph), and then letting the view template technology fully access that object graph.
To be fair, the fact that EL isn't a scripting language and doesn't provide the same features as OGNL, it allows other unique usecases to take place in conjunction within a framework.
A lot of times when you think of EL or OGNL in the 'view', it's being created, evaluated, and rendered at once. With the EL-API, you can create separation such that expressions can be created, serialized, chained, and executed multiple times later.
For example, take the concept of iteration. This proves to be more difficult than one might think in relation to deferred evaluation when you want multiple expressions to work in conjuction with each other at a later time. If we opened up the BNF to 'inlined' method invocation with parameters, we start running into issues that would be a mess for anyone to really grasp on a case by case basis-- given the lifecycle that the EL-API provides to frameworks.
I agree that inlined method invocation would be nice to have, but the proposal has been brought up multiple times in the EG and gets riddled with holes (one of which I touch on above).
-- Jacob
|
|
|
Message #171323
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Who cares....use plain old scriptlets
If you don't know java don't write jsp :)
We can go on with this forever...JSTL, EL, struts-tag, JSF tags....Tags are an overkill. And sometimes with all the diff versions of these tags you could find yrself in jar hell:)
Scriptlets can be easily bugged if you know java
And I don't think anybody would be writing jsp pages without java knowledge -- a fact:^)
And if you use one of the many MVC implementations...things will be fine.
Maintenance? What maintenance?
I have rarely gone into an interface and made changes once it has flown off into production.
Third party maintenance? Put plain old comments in there...will work
|
|
|
Message #175892
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Feedback to the Expert Group
Very interesting thread.
As a JSP co-spec lead, I can say that while wanting to preserve our goal of simplicity, we also acknowledge that the needs of the community evolve, and we're definitely interested in investigating ways to improve the EL. As Jacob mentioned, the JCP process is quite transparent and people can easily voice their opinion directly to the Expert Group.
Please see my blog on the topic.
I also took the liberty to file issues on the constructive comments I could find on this thread. We'll definitely be looking into this. See issues 145-146.
145: Access to constants
146: Access to indexed properties
147: Method invocation
For anyone interested, I'd also encourage you to check the interesting comments we got from Patrick Lightbody. They've been filed under issues 141 to 144.
[Links in my next post. I just can't seem to be able to put them in here].
|
|
|
Message #175893
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Feedback to the Expert Group
Keep getting error:
The message body contains invalid HTML, but I do not have any html... argghhh... One more try...
Blog
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
