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.
My flight leaves Denver around 3:00 and is supposed to arrive at SFO at 7:15. If I'm good, I can grab a taxi and make it to Moscone before registration closes at 8. I doubt it, but it's worth a try. If it's closed, I'll head to my hotel and try to hook up with Bruce, Bill or Simon. Leave a comment or shoot me an e-mail if you are around and want to hook up tonight.
One of Maven's best features is its ability to generate websites with project documentation. In most cases, it'll motivate developers to improve the documentation for their project. At least it has for me with Struts Menu. However, Maven makes the worst mistake in the history of web development - it doesn't set a default background color. A lot of idiots do this these days, so do me a favor folks - change the default background color on your browser to something obnoxious. Mine is set to bright orange right now. Try changing yours to orange and then visiting the Maven site - its fugly.
This issue isn't as bad as it used to be. Most people don't notice it, but "back in the day" when browser's used gray as their default - it was an issue. Maybe I'm just old fashioned.
Anyway, back to Maven. Yesterday, I was responsible for upgrading some Maven sample apps to the latest RC3, which makes the mistake mentioned above (RC1 did not). Usually when you encounter these issues in Mavenland, you click 5 times (Google with Firefox makes it 1 click) to find the plugins site and then look for its properties. In this case it's xdoc, which has a horrendous number of UI Color Settings.
These settings have two major problems. First of all, they don't work with RC3, and secondly - it's an awful way to define the colors and such for your site. Especially since its mostly related to colors. A better way that I've found is to put a maven-theme.css file in your xdocs/stylesheets directory. This will override Maven's default stylesheet and you get a lot more control over the look and feel of your Mavenized project site. The easiest way to get a template to start with is to generate your site and then copy target/docs/style/maven-theme.css into this directory. Hope this helps make Maven a little bit easier. 
SiteMesh is a kick-ass tool. It's much easier to use and configure than Tiles, although I don't know if its as powerful. Tiles has Controllers that you can assign to a definition and it supports easy i18n. I've been using Tiles for over 3 years and I've only used SiteMesh for a few months. However, SiteMesh already seems to suite all my needs. I'm guessing that most people use Tiles over SiteMesh because they haven't given SiteMesh the 10 minute test.
Anyway, back to the point of this post. Rick Reumann has put together a nice tutorial titled Use SiteMesh instead of Tiles.
I think you will quickly see the benefits after going through this brief example. In summary, the main reason I like SiteMesh more than Tiles is that SiteMesh is much easier to configure and use (less typing and easier to understand).
Good stuff - thanks Rick! As part of the WebWork integration into AppFuse, I was planning on using SiteMesh. I'm already using it in Spring Live sample app and it's pretty slick. I haven't had to touch it since I integrate it. Compare this with Tiles where you have to add a new definition (or JSP) everytime you want a new page. If nothing else, I think Tiles needs to learn from SiteMesh and add a Filter that can be used to decorate pages.
The last two nights I gave talks at the Denver JUG and Boulder JUG meetings. On Wednesday night, I presented AppFuse in the basic concepts meeting and Thursday I was the main speaker at BJUG. Both meetings were great and my presentations went pretty well. Denver had about 50 attendees and Sue Spielman gave a very informative talk on J2ME. To me, J2ME seems like the equivalent of Swing for the Desktop. Building mobile-friendly websites seems like an easier route - then you don't have to worry about how the phones differ. Maybe I don't know enough about J2ME - why should I write a J2ME app when I can write a webapp? To me, it seems that I should stick with what I'm familiar with - and if I do choose to get into the mobile space, websites would be the way to go. My phone (a T68i) was very helpful last week in San Deigo. I used it's internet access and go2.com to find directions to several locations in San Diego. I just told the website to "auto-locate" me, then I'd type in an address and voila - it spit out a list of directions. Bruce and James also wrote about the Denver meeting.
Last night was the Boulder meeting, where Scott Davis kicked it off with a talk on Struts. My AppFuse presentation could've been much better if I based mine off of Scott's. I do some live coding of a DAOTest and a DAO in my presentation - and I think the audience would've gotten a lot more out of it if I'd showed them how to develop Actions and JSPs with AppFuse. Oh well, that's what the tutorials are for. I also like showing the DAO stuff because it shows the power and simplicity of the Hibernate+XDoclet+Spring combination. It's pretty cool to mention that integrating Spring into AppFuse only took a few hours. During integration, I remember deleting 5 or 6 classes/files and reducing my LOC count by about 75%.
After the meeting, I talked to one guy who was interested in adding a Swing front-end to AppFuse. I told him it shouldn't be too hard since the dao and service layers are already packaged as JARs. From a Swing app, you could easily reuse the business delegates and DAOs to talk to a database. The hard part would probably be mimicing authentication and authorization. I'm guessing that JAAS could probably provide a nice standards-compliant solution for this. I'm sure Spring's RCP project could make developing this front-end even simpler. I also talked to Kris about helping with the WebWork version of AppFuse. Hopefully he can help me out and make that happen sooner than later. I'm still targeting the end of July for a WebWork/Sitemesh-enabled release, as well as lots of enhancements to IDE friendliness.
Both meetings where followed by beers and good conversation. Last night, the tavern we were at lost power after about an hour. That didn't stop us from spending another hour in the dark telling old war stories. Good times - thanks to all who participated!
It's too bad I've already signed a contract for the next couple of months. Today, on the appfuse user mailing list, a 2 month contract came across the wire.
Hello everyone,
My name is Mark Janveaux, I'm Chief Technology Officer at Mobile Design Technologies (http://www.mobiledesigntech.com) a
software firm specializing in mobile applications for the healthcare
industry.
We are developing our next generation project right now which is based off
of AppFuse 1.5,
and have an open position for a developer experienced
in the relevant technologies (Java,JSP,Struts,Hibernate).
It's an simple but interesting project. Project length will be
about 2 months with definate possibility of extension.
Position may be part time or full time depending upon your
availability, skills, experience and salary expectations.
If any of you are interested, please contact me at:
Email: mjanveaux-AT-mobiledesigntech.com
Ph: 250.483.3430
This position can be 100% telecommute if necessary.
Kind regards
Mark
Of course, you probably don't need to know AppFuse. If you've worked with Hibernate, Spring, Struts, JUnit and Ant - you've probably got a good chance.
I've never had a problem getting builds and unit tests to work with Ant. However, unit tests run faster in an IDE, so I'm trying to refactor some code to allow for testing in the IDE. My current directory structure looks like this:
-- project
- web
- WEB-INF
- classes
I need both "WEB-INF" and "WEB-INF/classes" in my classpath. There's XML files under WEB-INF for Spring and Commons Validator, and there's a log4j.xml under WEB-INF/classes for log4j. These files are all in their natural locations as far as all the projects I've seen. However, Eclipse won't allow me to nest classpaths - so it's virtually impossible (as far as I know) to add both directories to my classpath. Any ideas how to workaround this Eclipse "feature" are appreciated.
For those "IDEA is better" folks - I agree. IDEA allows me to add web, web/WEB-INF and web/WEB-INF/classes to my classpath with no issues.
Charles responds (in a comment) to Ted's accusation that .NET's community is better than Java's.
Actually, the strength of the Java community lies in its disunity. Unity is a false strength: it's safety in numbers, but it's also a herd mentality. I suspect the drive for "strength in unity" is a reflection of Microsoft's philosophy of dominance: that the best thing for the world is if everyone just Does Things Our Way: A computer on every desk running Microsoft software. The Java community has competing infrastructure vendors. We have a raft of competing web frameworks, competing AOP frameworks, competing persistence frameworks, competing IDEs, competing heavyweight and lightweight containers. And it's this competition that makes Java such a vibrant community. Nobody's quite satisfied with what the other guy's doing: everyone wants to do better. It's also what makes us, at times, a bunch of bickering children. That does us quite a bit of harm, but I think in the long run things work out for the best.
Well said.
There's a good that was published today on JavaWorld.com: End-to-end internationalization of Web applications. I stumbled upon it via TheServerSide.com. I especially like the tip about using a hidden "dateFormat" field in conjunction with Commons Validator to validate locale-specific date formats. AppFuse could certainly use this. Did you know that AppFuse supports 4 languages out-of-the-box and has full i18n support (save for the date format thingy). Supported languages include: English, Dutch, Brazilian Portuguese and Chinese. I opted to use JSTL's i18n support in most areas rather than Struts. It's simply more portable when moving to other MVC frameworks like Spring and WebWork.
David is going to cover some JSF advanced topics: data table, tiles integration, custom components and validators. I was talking
with Rick Hightower last night. He mentioned that he's been doing a fair amount of work with JSF lately and really likes it. He
actually said he thinks he can develop a webapp faster with JSF than he can with Struts. He also said that JSF ships with a lot
of what you need - and a lot of the JSF books seem to cover how to add new stuff (custom components and validators) you don't need. This is to
say that the books tend to cover the features of JSF, rather than how to develop successful projects with JSF. I said I thought
it'd be nice if there were some JSF books by folks who'd used it to deliver applications. More of a "here's what you need to
know" kindof manual. I think that's what JSF needs.
The <h:dataTable> in JSF is pretty much the same as the <c:forEach> tag in JSTL. An interesting note on the JSF
expression language - it starts with a # instead of a $. For example:
<h:dataTable value='#{tableData.names}' var='name'>
...
</h:dataTable>
The major difference between JSF and JSTL's expression language is that JSF EL can access managed beans. The JSP 2.0, JSTL and
JSF expert groups are going to work together to try and synch up their expression languages. Personally, I don't see why the JSF
folks didn't just use JSTL and simply include managed beans in the lookup logic. Here's a wierd one - if you use any "template text",
i.e. in a dataTable - you have to wrap the text with <f:verbatim>text</f:verbatim>. David says this is one of the embarrasing
things about JSF. He hopes it'll be fixed in the next version.
The <h:dataTable> looks very similar to the
DisplayTag. Sweet - that's one less thing I'll have to worry about when creating a JSF app.
I've said it before and I'll say it again - my two favorite tag libraries are the DisplayTag and
Struts Menu. As I'm learning new frameworks, one of my major goals is to reproduce the same functionality I enjoy in my Struts+JSP
apps. It's been pretty simple so far with Spring and WebWork, since both support JSP. However, it might get a bit tricky with Tapestry
and JSF. I'm sure it'll be possible (and hopefully easier) to reproduce this functionality, it's just a big unknown
at this time.
"Form" beans in JSF are not like form beans in Struts. It's really just a class that doesn't extend anything and has action handler methods.
An interesting point - the actionListener's value (which is really a class.methodName) can be any class in any scope OR it can be a
managed bean. How about some code:
public class Form { public void changeLocale(ActionEvent e) { FacesContext context = FacesContext.getCurrentInstance(); Map requestParams = context.getExternalContext(). getRequestParameterMap(); String locale = (String) requestParams.get("locale"); if ("english".equals(locale)) { context.getViewRoot().setLocale(Locale.UK); } else if ("german".equals(locale)) { context.getViewRoot().setLocale(Locale.GERMANY); } } }
The major reason behind the FacesContext is to support Portlets. So rather than using a ServletContext or PortletContext, the FacesContext
provides a level of abstraction. The underlying theme of JSF: To be as flexible as possible. This is to say that there are many ways
to do things with JSF. I often think it's better to have less choices when learning a technology, but once you're versed in it - choices
are great. I guess I just wanna know the best way to do things, not all the options. Actions are for business logic, ActionListeners are for UI logic. ActionListeners are always fired before Actions - in the event
that you have an actionListener and an action defined for the same component. Listeners and Actions are really just methods on a class and they
can actually both be in the same class. JSF is starting to appeal to me. This session has been one of the fastest so far - there's only 20
minutes left and it feels like it's flown by.
JSF ships with converters for dates and currencies out-of-the-box - cool! Now David is explaining about a custom
CreditCard converter. This is what Rick was talking about last night. Why do we need to know this stuff? Would a normal talk on another MVC
Framework talk about converters and validation? I bet not. I think it's a good topic - maybe something that other frameworks should cover
more visibly. The Converter interface has two methods: Object getAsObject() and String getAsString(). The Validator interface has one method:
void validate(FacesContext context, UIComponent c). I just asked David about using Commons Validator instead of JSF's core validator. He said, "Yes,
it's possible." Sweet! You can use Commons Validator with Struts, JSF and Spring! Now if we could only get support for it in WebWork
and Tapestry - then I'd eliminate my need to learn another validation engine.
Now David is talking about using Tiles with JSF. It looks as simple as using the <tiles:insert> tag to insert dynamic content into an <f:subview>.
Any time you insert a tiles component, you need to wrap it in an <f:subview> tag. That was short - we're done talking about Tiles. I had some
questions - i.e. can you refer to a definition directly from an action or in the action's navigation definition? Oh well, onto custom components and renderers.
Custom components and renderers seems to me to be something that should be left out of these types of presentations. Sure, it's cool they're possible - but
who's using them? Have you needed them in a real-world JSF application? I only want to know the things I need to know to develop a real-world JSF webapp.
Sorry, I forgot - there aren't any real-world webapps written with JSF. If I'm wrong - send me a link. ;-)
This presentation was good - it inspires me to learn some more about JSF. Maybe there'll be some projects in my next gig that require JSF - that would
be wicked cool. After all, the best way to learn this stuff is to get paid to do it. If nothing else, I'll get to learn it later this year when I write
AppFuse's web layer in JSF.
I decided to stay in the same room after Dave Thomas's talk and attend Bruce Tate's talk on Intro to Spring. After looking through the slides, I realized that its possible I won't learn anything new - but I think I'll stick around for a 1/2 hour or so - just to hear Bruce talk. At the beginning of his presentation, he asked if anyone has downloaded Spring. Hmmm - I'm the only one in a room of about 35. Bruce then mentioned Spring books coming out in the next few months. Damn, he didn't mention Spring Live - I guess I have some more marketing to do! Bruce calls Spring's ApplicationContext a "container", but it's not really a container, but a "dictionary of instantiated objects." That sounds like a good definition to me. Spring's mission statements, or basic beliefs:
I've been working with Spring for long enough that I've actually forgot about how much easier my J2EE development life is. This session is a good reminder of how cool Spring is. Poor suckers in this room - no one is even using it. Bruce is a good speaker - and looks quite a bit younger in real life (than in his pictures).
OK, I'm outta here - time to go learn some more about CVS. Note to self - talk to Bruce and figure out how he modified JUnit's excluded.properties file. He had to do this a few weeks back in order to get Hibernate's EHCache working with Spring in JUnit tests. I was able to replicate his issue, but never solved it myself.