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.
This morning, I found some scripts to do MD4, MD5 and SHA encryption with JavaScript. If I add these to AppFuse and Roller, it means that a user's password will never be sent in plain-text. Very nice - anyone using any of these scripts? Any reason I should use someone else's scripts instead of the ones I found?
Fabrizio (the lead developer on the display tag project), took my hack for supporting JSTL's SQL Tag and turned it into a nice feature. The display tag now supports Maps and you can iterate through JSTL's Results using the regular tag or the EL-enabled version. Download nightly build - now automated!
As an exercise for the NYC conference, I implemented an editable table using the display tag. It's a bit ugly, but it does work. You're more than welcome to use it and improve it. ;-) To see it, checkout the following demo pages in AppFuse:
Any feedback would be great.
A frequent issue that crops up when using Struts is how to transfer data from ActionForms to DTOs or POJOs and vise-versa. In other words, how do you get the data from your true model into Struts' Model? There are a few solutions out there, including the ActionForm-Value Object Mapper and BeanUtils.copyProperties. I've used both and (IMO) the only advantage of using BeanUtils is that Struts uses it internally and it's a bit easier to work with.
The reason I'm writing this post is to show you how to handle Dates and Doubles in your POJOs. The first step is easy - you simply need to register converters for Date and Doubles. The easiest way to do this (that I know of) is to add a static block to one of your classes. I do this in
BaseManager, but it could be easily done in a BaseForm class.
static {
|
When I use Doubles, it tends to be for dollar amounts displayed in a JSP page. Therefore, I call it a CurrencyConverter (source), and I use a DateConverter (source) for dates.
After registering these converters, the next step is to throw a little validation into the mix so that the String values (from the Form) are in an expected format. Since I'm using XDoclet to generate my Forms, it's as easy as adding a couple of tags to my POJO. Here is an example for validation Dates:
/**
|
And one for validating dollar amounts:
/**
|
For the currency validation to work, you have to add a few things to your Struts project. The first is the errors.currency to your ApplicationResources.properties file:
errors.currency=The '{0}' field should be a dollar amount.
The 2nd piece you'll need to add is the currency mask as a constant in your validation.xml file (or metadata/web/validation-global.xml if you're using XDoclet/AppFuse):
<constant>
<constant-name>currency</constant-name>
<constant-value>^\d{1,3}(,?\d{1,3})*\.?(\d{1,2})?$</constant-value>
</constant>
I'm not much of a regular expression expert, but I think this mask is specific to US Dollar amounts. I'd love to see a i18n version, but I haven't had a need for one (yet) - so it's not a big deal for me. The last thing you'll need to do is add a little JSTL lovin' to render your dollar amounts with the proper number of decimal places:
<fmt:formatNumber type="number" minFractionDigits="0"
maxFractionDigits="2" value="${myForm.startingSalary}"/>
It seems that most web frameworks are getting away from a separate web model (ActionForms) and allowing you to use your POJOs in your view. This is likely to be a bit cleaner, but I'm sure they still have to use some sort of converter to get Dates/Doubles from your UI into your POJOs. The nice thing I've seen in other frameworks is that they have Date Converters built in. Why doesn't Struts? Who knows, but IMO it should be a built-in component.
Both of the Converters described in this article can be found in AppFuse.
One of the issues with using XDoclet
to generate your Struts ActionForms (from POJOs) is that out-of-the-box, your Forms will not support indexed properties. This means that if you have a List on an object (this list will likely contain other objects/forms), you have to extend the generated form to add the necessary setters for indexed properties. For example, if you have an addresses List on a PersonForm, you would need the following in order to edit those addresses in Struts.
setAddresses(int index, Object address) {
|
The worst part is that you need to populate the addresses list with a bunch of empty AddressForm objects before Struts' auto-population will succeed. If you were coding the PersonForm by hand, you could code a reset() method such as the following:
public void reset(ActionMapping mapping, HttpServletRequest request) {
|
Now for the best part - I figured out how to generate this code with XDoclet, so any lists on your Forms will be indexed-property ready. By using <nested:iterate> in your JSP, you can easily CRUD you indexed properties. Pretty slick IMHO. The template is a bit much to put on this site, and it's long lines won't fit in a <pre> - so you can temporarily view the template here. I'll add a link to it in AppFuse's CVS once it shows up there. One thing you'll notice in this template is a little Velocity-lovin':
<XDtVelocity:generator>
#set( $method = $currentMethod.name)
## trim off the 'get'
#set( $objectName = $method.substring(3, $method.lastIndexOf('s')))
</XDtVelocity:generator>
Thanks to Erik on Merrick's blog for the quick Velocity/XDoclet howto. It was especially helpful since the XDoclet site has no documentation on this feature.
For all you my framework is better junkies - a clear explanation of how your framework handles indexed properties would be appreciated.
Adding support for JSTL's Expression Language was fairly easy to do in the Display Tag. It was as simple as adding an ExpressionEvaluator and subclassing the ColumnTag and the TableTag. From there, all that was needed was needed a new TLD to reference these new classes.
So the question is - would it be just as easy to support the OGNL Expression Language? Does it have an ExpressionEvaluator I can write with the same simplicity as the JSTL version? If I could figure that out, I think creating OGNL-aware versions of the displaytag and struts-menu would be a piece of cake. All you'd need to do would be to change you're TLD's URI and you'd be off to the races!
Adrian Lanning sent me an interesting e-mail yesterday. He's looking for a better way to extend Struts. I thought I'd post his message here and see if anyone has ideas.
I am a big struts fan and use it for my projects but I think there is something fundamentally wrong with the design. The real crux of the matter may be that Java is a single-inheritance model and Struts is designed more for multiple-inheritance.
Example 1.
Complexity when trying to use "extensions" to struts that have their own RequestProcessors. Such as my extension for roles (mentioned below) used together with Asqdotcom's ActionPlugin which is a plugin but still uses its own RequestProcessor, plus another hypothetical extension which has it's own RequestProcessor. Basically the only way to use them all is to modify the source of one or two to extend the others which doesn't seem like a good design.
Example 2.
Extending LookupDispatchAction to include per-method validation (set in struts-config.xml). Basically same problem. Need to combine functionality of ValidatorAction and LookupDispatchAction but can't extend from both. Have to modify source. Actually Brandon Goodin wrote this already (I find it very useful). It's called ValidatorLookupDispatchAction.
I know this is a common issue with single-inheritence models/languages. It would be really easy to extend Struts in a multiple-inheritance model.
* THE POINT *
I was just wondering if you knew of a better way to design when dealing with single-inheritance models to avoid problems such as these.
Personally, I don't find the need to extend Struts that much, so this is not much of an issue for me. I think Struts 2.0 will solve many of Struts single-inheritance design by declaring interfaces for all core components. I wonder when 2.0 is roadmapped to ship - sometime in 2006? ;-)
Later: The article, Security in Struts: User Delegation Made Possible, by Werner Ramaeker provides a good example of a Struts extension strategy.
At the NYC Conference, I'm going to be talking about The Display Tag and Struts Menu. I figure the best presentations are ones that cover new features or introduce something new. So I'm hoping to add the following features to the two libraries in the next month. Please let me know if there are other's you'd really like to see - or ones that'd make the audience go *wow*.
DisplayTag: I'd like to add this pagination enhancement so you can get easy interaction between the records displayed and the records fetched. I'd also like to see sorting by property, not be contents. Lastly, I hope to add an example that does CRUD on a table using JSTL and simple checkbox and input fields.
Struts Menu: A lot of users are interested in seeing a menu that's created from a database table. This shouldn't be too difficult because examples are out there. I was also thinking of adding support for the Joust Outliner, but it doesn't look like it's still developer or actively used. If there's interest, I'll add it.
If you think I'm blogging a lot today (don't you work Raible?), it's because I'm on babysitting duty. Abbie is sick with a fever and Julie had to go to work - so my work day starts when she gets home. I've got the little one tied up with a little Winnie the Pooh action right now...
Later: The DHTML Kitchen has some nice menus, but they're not free. Anyone know of open source menus like these?
I think it's about time I moved AppFuse from the Struts project on SourceForge to its own project. That way, I'll have more control over controlling spam on mailing lists, adding developers and other such stuff. So the question is - should I stick with SF or move to java.net? I'm fairly happy with SF, except for their recent CVS hiccup and regular CVS outages. It's cool that java.net gives you a wiki, but I doubt I'll convert all my JSPWiki wiki pages to java.net's wiki syntax (whatever it is). So I guess the question is for you folks that have used both (i.e. OpenSymphony developers): Is java.net better than SF?
Dave asked this same question in June of last year - and Roller still lives on SourceForge. I wonder if that's any indication?
I figured out a way to remove any ActionForm references from my Managers yesterday. It was pretty simple, but I thought others might benefit from this knowledge. Basically, you just need to add a couple methods to your BaseManager.java file. Here is the latest one from CVS HEAD. Then you can pretty much eliminate any *Form references in your Manager by using the convert(Object) method. This method will convert POJOs <-> Forms and vise versa. You will likely have to do some tweaks on the package names if you're using anything < v1.4. Looking at this diff of the UserManager before and after this change will show you what's changed.
I started this task thinking I could remove the need for Forms in my classpath when compiling the service layer. However, I soon discovered that my Tests have Forms all over the place - since they replicate what my Actions will pass in. Oh well, at least my code is a bit cleaner now.
Of course, this code will become even simpler when I start using an MVC Framework that allows my POJOs to be my data handlers on the UI. These frameworks make me question if I even need Managers. Then again, it's nice to unit test what your DAOs are returning/receiving from the web layer.
As I'm developing this morning and pulling a drop-down list from the database, it hit me - I'm not internationalizing these drop-down values. Sure, putting them in the database makes it easier for admins to edit the values, but if a user visits the site with a Spanish locale, they're going to get English drop-downs. So how do I fix this?
Is the best solution to put the drop-down choices in Struts' ApplicationResources.properties file so that I can render the values with <bean:message/> or <fmt:message/>? How do you do it in your webapps?
In some cases, I guess it doesn't matter as the values need to be in English. Take for instance, AppFuse's edit user screen (user/pass: mraible/tomcat). The list of roles comes from the database and should always be in English because the form-based authentication depends on having an English role_name value in the user_role.role_name column - since this is the value coded in web.xml.