The Angular Mini-Book is a
guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and
deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.
Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.
For book updates, follow @angular_book on Twitter.
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.
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 by Howard Lewis Ship on September 08, 2007 at 08:48 AM MDT #
Posted by Don Brown on September 08, 2007 at 09:00 AM MDT #
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:
Posted by Matt Raible on September 09, 2007 at 11:08 AM MDT #
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 #
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 #
"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 #
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 care either. The Jasper parser which everyone uses is so backwards it requires a near rewrite to support pluggable EL (I tried).
I don't know what's pie in the sky about it-- both the JBoss and Spring guys are already extending EL.
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 #
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 #
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 #