Matt RaibleMatt Raible is a Java Champion and Developer Advocate at Okta. developer.okta.com

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.

10+ YEARS


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

Don Brown on OGNL

From the Struts Developers Mailing List:

My conclusion is OGNL is like Maven 2 - sometimes it really pisses you off, and you probably generally don't like the thing, but you've invested so much into it that it would be too painful to switch, and really, it does 95% of what you want anyways.

And with that, I'm off to Finland and Norway! See you on the other side of the pond.

Posted in Java at Sep 08 2007, 06:52:20 AM MDT 12 Comments
Comments:

Strange ... I never had a single problem with OGNL in all my years of using it with Tapestry. Drew was always frustrated with people who tried to do weird things with OGNL (he singled out WebWork repeatedly). Maybe it's about Tapestry structure being truly OO. I can't tell you how many times I would show some OGNL list projections and selections (stuff I'm seeing again with Ruby blocks and Haskell list comprehensions) and people would be stunned: "You HAVE to send us that code." My beef with OGNL has been performance, and to a large part, that's been tackled by Jesse.

Posted by Howard Lewis Ship on September 08, 2007 at 08:48 AM MDT #

My main problem with it is how it sticks out like a sore thumb in the template language of your choice. If you are using JSP, you already have an EL you are familiar with, and same with Freemarker and Velocity. Of course, if you have your own template language like Tapestry, this isn't an issue. Yes, it is slow and yes, it consumes a bunch of resources from what I hear, but those are manageable problems. Still, I think Struts 2 will be moving, if nothing else, to a point where OGNL isn't required and is replaceable.

Posted by Don Brown on September 08, 2007 at 09:00 AM MDT #

Don-- the answer is obvious-- the unified EL. Only Seam so far has actually done extension under the API. Go ahead and incorporate a simplified/byte-code implementation, but at least you can retain the single API within the framework.

Posted by Jacob Hookom on September 09, 2007 at 10:09 AM MDT #

Jacob - I agree that Unified EL is the answer (especially if it has extensions like Seam has for passing arguments to methods). However, isn't UEL supposed to be standard in JSP 2.1? If so, is Seam really using it? From the link you mentioned:

29.1.2.1. Incompatibility with JSP 2.1
This extension is not currently compatible with JSP 2.1. So if you want to use this extension with JSF 1.2, you will need to use Facelets. The extension works correctly with JSP 2.0.

Posted by Matt Raible on September 09, 2007 at 11:08 AM MDT #

Yeah, unified EL sounds nice in theory - but it seems like anyone with an -el always tends to get pushed more and more towards the ognl feature set. So, you have a unified "almost good enough" language. I guess being unified is more important than being useful.

Either way it would be really nice if the JSP spec people met with the EL people and fixed the way they are parsing out expressions. I looked in to it briefly when I noticed people talking about it and it doesn't seem very well thought out at all. (on the jsp side)

Posted by Jesse Kuhnert on September 09, 2007 at 05:46 PM MDT #

My argument for the Unified EL isn't the syntax, it's like arguing against the SE 1.6 Script API because it only supports Rhino out of the box. I think the Unified EL API is very flexible, much better than the SE 1.6 Script API, and the only thing I think it lacks is explicit conversion hooks, not to say you couldn't do it yourself with an ELResolver.

So quit arguing against the Unified EL over its default syntax, that's not what everyone's talking about here.

As for the relationship with JSP 2.1, it's unfortunate that the JSP/JSF spec included config entries for ELResolvers, but not for the ExpressionFactory itself. A framework could use their own ExpressionFactory or again, put in dependencies on the Unified EL API, still allowing the end developer to swap in a different ExpressionFactory.

Posted by Jacob Hookom on September 09, 2007 at 08:11 PM MDT #

@Jacob
"So quit arguing against the Unified EL over its default syntax, that's not what everyone's talking about here."

I'm sorry but this doesn't compute. Isn't the "syntax" an EL supports the most important thing that exists in an "expression language"? (ie syntax == supported expressions) I don't really care about what EL is doing but it makes me sad to see it so half assedly crammed in to the JSP spec without any thought towards what it would do to anything / anyone else when there was clearly a standard expression language in place already which this moronic endeavor now seeks to cripple with bad parsing algorithms. I was happy about the unified EL thing at first - but the jsp 2.1 b0rkenness really pisses me off. There's no excuse for crap like that.

You are talking about pie in the sky hooks / factories / other things I don't care about. It either supports what people want or it doesn't. Right? right. As we stand right now jsp 2.1 has crippled many people and caused many problems. I don't know if you were being defensive because you had anything to do with that but it would be nice to get it sorted out in some way. I won't even go in to how Tapestry handles attributes / bindings of course because that would just be mean.

Posted by Jesse Kuhnert on September 09, 2007 at 09:38 PM MDT #

I'm sorry but this doesn't compute. Isn't the "syntax" an EL supports the most important thing that exists in an "expression language"?

Again, from a framework standpoint, you want long term flexibility, including the ability to change the "expression language". That's essentially what the Unified EL-API offers, provide your own ExpressionFactory implementation which does accommodate other language features that you feel you need.

I don't really care about what EL is doing but it makes me... (something about JSP) ....

I don't care either. The Jasper parser which everyone uses is so backwards it requires a near rewrite to support pluggable EL (I tried).

You are talking about pie in the sky hooks / factories / other things I don't care about. It either supports what people want or it doesn't. Right? right.

I don't know what's pie in the sky about it-- both the JBoss and Spring guys are already extending EL.

As we stand right now jsp 2.1 has crippled many people and caused many problems. I don't know if you were being defensive because you had anything to do with that but it would be nice to get it sorted out in some way. I won't even go in to how Tapestry handles attributes / bindings of course because that would just be mean.

I'm sure Tapestry is better than JSP, but that's not what the discussion is about here. At the core, a framework chooses some API for integration with expression languages, so why not pick the standard EL-API, knowing long term, they can provide options for other languages, retaining common java-base artifacts?

Posted by Jacob Hookom on September 09, 2007 at 10:29 PM MDT #

@Jacob Sorry for the random lashing out at u-el (wouldn't it be more convenient to reduce it down to an acronym?) - for some reason I was starting to think you were defending 2.1 in some way.

I guess the framework->el API would be something that ognl could participate in in some way, just so long as no one asks to see its private parts or make it do unholy things to conform to u-el. Was I wrong in thinking that it wasn't quite ready for this "pluggable" approach just yet?

Ping me if you think there is any actual way to make the pluggable aspect of EL something that can be made to work. (i think, still not sure why I should care. maybe tp5 could use it someday)

Posted by Jesse Kuhnert on September 09, 2007 at 10:53 PM MDT #

With all of the discussion on byte-code enhanced ELs, etc-- there's obvious room for improvement in implementation now and in the future. This is good :-)

The only take-away is that all of these options out there today have basically the same API artifacts and it'd be nice to standardize them to an extent to allow a framework or end developer to choose EL(s) and upgrade or swap as needed long term.

There's articles out there now on the unified EL and retro fitting OGNL into the Unified-EL isn't hard from a pure variable resolution standpoint, but leveraging the Unified-EL's ability to chain property resolvers might be-- or something that can be extended later?

Posted by Jacob Hookom on September 10, 2007 at 12:38 AM MDT #

@Jacob Hmm......it sounds sort of do-able? I have not idea what the property resolvers API is or how it works so I'll remain pessimistic until I see more of it.

I'd rather gauge my eyes out than join any spec group or anything, so hopefully if I have suggestions / questions I can just funnel them through you? (I may take a look at some point in the near future just to be able to say "i tried")

Posted by Jesse Kuhnert on September 10, 2007 at 12:56 PM MDT #

Some Links around the API

javax.el package

Quick Example of ELResolver invocation

Posted by Jacob Hookom on September 10, 2007 at 01:02 PM MDT #

Post a Comment:
  • HTML Syntax: Allowed