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.
I don't know if there was an upgrade or something, but it took me until today to notice that java.blogs has an rss feed for recent entries. Very cool. I'm going to be using NetNewsWire for a while to read sites - it's just faster. Another effort to improve my time management skills.
I was invited to attend Basebean's Struts Training today. Vic Cekvenich was nice enough to give me a password to attend, and I agreed that I would blog about it. I also agreed to help out on the MVC Programmers mailing list. I don't know that I'll do the labs, but I am interested in doing them - especially since the examples run on Resin 3.0. So I'm sitting in right now and they're doing some introductions. More to come soon. It's about a 1 and 1/2 hour class this morning - should be fun.
The first 20 minutes have been mostly about open source and it's benefits. I'm thinking - most of the students already know this don't they? Maybe not. I guess my perspective is skewed since I've been involved in open source for so long. Before I started using it, I guess I kinda scoffed at it - so I suppose the intro is good.
The second 20 minutes has been about "why projects fail" and the importantance of requirements. I can definitely understand this - as I've been on a couple projects with a bad requirements-gathering process. So far, this class has been a little disappointing as I haven't learned anything yet. The students seem very interested in the first two topics though - so I guess it's satisfying them. I'm sure I'd be more satisfied if I'd already done the labs (the students have).
Now onto Project Management and CMM. Didja know you can get certified as a Project Manager from PMI.org. IMO, a Project Manager can single handedly make or break a project. I agree with Vic that "the best person to have certified on a project" is the PM. The PM on my current project rocks, and it's made the project soooo much easier. You can track your project's ROI at softwarereality.com.
Don't these student's have mute on their phones? I've heard kids crying and dogs barking so far ;-) No one's heard me sneeze yet - and I've done it 3 times!
Vic recommends the following:
NetLedger.com is a recommended UI for complicated forms. Rumored to have a free login.
Tip: When you have bad requirements, surf the web. Programming on your project will just frustrate you. My advice: contribute to an open source project - then you'll keep your skills up to par. Or, read blogs - you'll learn something there too.
Now we're learning how to setup an IDE (Eclipse) and deploy/test and example app. Looks like the sample app (webPIM) uses JSTL's Fmt tag. Cool, I've never used it, I should probably do the labs. Teaching students how to use an IDE for Struts Development is definitely the easiest way to go, but using Ant is the real-world way - right?
The next lab covers configuring Tiles and developing a sample layout. I noticed it was a big confusing for the students that the tiles definitions file is named layout.xml and the base Tiles template is named layout.jsp. I usually name my tiles definition file tiles-config.xml.
Hmmm, Patrick seems to be doing the same thing I am - generating ActionForms from POJOs with XDoclet. I wonder if he's using my patch or if he's found another way?
Also, he asks if there's a better way to validate:
My ideal way to validate would be to add xdoclet tags right to my domain model to handle validation.
I guess I'm here to brighten your day then - this is exactly what I'm doing with struts-resume. Check it out: User.java contains @struts.validator tags that are pushed into the generated ValidatorForm via a custom struts_form.xdt (xdoclet) template. Enjoy!
If I play my cards right, I'll be either (1) flying back from Florida for this conference, or (2) moving to Florida shortly afterwards.
------------------------------------------------------ Confirmation number: 338104 Name: Matt Raible ------------------------------------------------------ Rocky Mountain Software Symposium 2003: Spring Edition Date: Friday, May 16, 2003 - Sunday, May 18, 2003 Sheraton Denver West 360 Union Blvd Lakewood, CO 80228
After spending the last two nights burning the midnight oil, I have finished struts-resume 0.6. Not much new and exciting, but it definitely a more solid application now. Hopefully, I'll have a demo running in short order. [Project Homepage]
I have a few different side projects I'm working on right now. The first two, struts-resume and security-example are for the Wrox chapters and the third, AppFuse is the kindling I'm using to build these projects. Basically, I'm using AppFuse as a starting point for developing webapps. I think I've got most of what I want done for a baseline, so I'll be removing some struts-resume specific code from appfuse and calling it 1.0. For security-example, I'll be removing even more code.
The slick thing, and the reason for this post, is that I've been doing all my development on one project - appfuse. When I want to update struts-resume or security-example, I simply execute an ant command, and it updates whatever files have changed since I last updated. Ant figures out automagically which files have changed. I love it. I did a few updates and I'll be uploading the struts-resume 0.6 release tonight. Here's what I did to update the app from appfuse.
$ant new -Dapp.name=struts-resume -Ddb.name=resume
Buildfile: build.xml
clean:
[echo] Cleaning build and distribution directories
[delete] Deleting directory D:\source\appfuse\build
[delete] Deleting directory D:\source\appfuse\dist
new:
[echo] Creating new application named 'struts-resume'...
[copy] Copying 17 files to D:\source\struts-resume
[copy] Copied 1 empty directory to D:\source\struts-resume
[copy] Copying 1 file to D:\source\struts-resume
BUILD SUCCESSFUL
Total time: 27 seconds
Now all I have to do is commit it to CVS (BTW, you can get struts-resume from SourceForge CVS) and execute and dist. I could FTP to SF using Ant too I suppose (I have Erik's book sitting right here), but I'll just hope someone sends this task (or page number) to me. ;-)
I've just noticed that a new version (1.0.3) of the JSTL reference implementation has been released containing some minor bug fixes. [Simon Brown]
Hmmm, no release notes eh? Makes you wonder if it's worth the upgrade/headache. I'll be in for it for quite some time with my struts-resume project. I'm using 17 different OSS packages - it'll be a maintenance nightmare to keep up. That is, until I break down and do some Maven integration.
If you're using Oracle 9i and JDK 1.4, you might be interested to know the recommended JDBC Driver is no longer classes12.jar (I just discovered it from the tomcat-user mailing list). The Readme.txt (at least on Win2K) in $ORACLE_HOME/ora92/jdbc states the following:
New classes file name for JDK 1.4 and beyond
Beginning with this release the classes files for JDK 1.4 and
beyond will be named ojdbc<jdk ver>.jar. So, the classes file for
JDK 1.4 is named ojdbc14.jar. The names for the JDK 1.1
and 1.2 classes files will not be changed. We will not provide
.zip versions of the classes files beyond JDK 1.2.
I'm sure most of you Java Developers have a methodology for handling your "constant" values. I've seen a couple of different techniques, and I'd like to see what everyone else is doing. Currently, I use a Constants.java file that has a bunch of public final static String lines in it. I got this technique from the struts-example app when I first started working with Struts. I recently came across (can't remember where) a technique where the Constants.java file was an Interface and it was simply implemented. How are you handling this in your apps?
Secondly - do you ever use these Constants in your JSPs, or do you just use the actual values? I use the actual values - less typing.
In the Struts Validator Guide, there is a section on how to create a pluggable validator that matches two fields. I've been using this server-side validator (as shown in the example) to do password/confirm password validation. This has worked great for me, but I've always wanted the Validator to have the client-side JavaScript method for it too. I wrote my own that just compared the two fields, but it's not the same as having one rendered for you (from validator-rules.xml). So yesterday, I did some tinkering and figured out how to add the JavaScript method to validator-rules.xml. So here's how to configure the whole thing (most of this is contained in the Validator Guide, save the JavaScript).
How To Add a TwoFields Validator
Step 1: Create a class with a validateTwoFields method. In my code, my class is ValidationUtil and has the following method:
public static boolean validateTwoFields(Object bean, ValidatorAction va,
Field field, ActionErrors errors,
HttpServletRequest request) {
String value =
ValidatorUtil.getValueAsString(bean, field.getProperty());
String sProperty2 = field.getVarValue("secondProperty");
String value2 = ValidatorUtil.getValueAsString(bean, sProperty2);
if (!GenericValidator.isBlankOrNull(value)) {
try {
if (!value.equals(value2)) {
errors.add(field.getKey(),
Resources.getActionError(request, va, field));
return false;
}
} catch (Exception e) {
errors.add(field.getKey(),
Resources.getActionError(request, va, field));
return false;
}
}
return true;
}
Step 2: Edit validator-rules.xml to contain the "twofields" rule.
<validator name="twofields"
classname="org.appfuse.webapp.util.ValidationUtil" method="validateTwoFields"
methodParams="java.lang.Object,
org.apache.commons.validator.ValidatorAction,
org.apache.commons.validator.Field,
org.apache.struts.action.ActionErrors,
javax.servlet.http.HttpServletRequest"
depends="required" msg="errors.twofields">
<javascript><![CDATA[
function validateTwoFields(form) {
var bValid = true;
var focusField = null;
var i = 0;
var fields = new Array();
oTwoFields = new twofields();
for (x in oTwoFields) {
var field = form[oTwoFields[x][0]];
var secondField = form[oTwoFields[x][2]("secondProperty")];
if (field.type == 'text' ||
field.type == 'textarea' ||
field.type == 'select-one' ||
field.type == 'radio' ||
field.type == 'password') {
var value;
var secondValue;
// get field's value
if (field.type == "select-one") {
var si = field.selectedIndex;
value = field.options[si].value;
secondValue = secondField.options[si].value;
} else {
value = field.value;
secondValue = secondField.value;
}
if (value != secondValue) {
if (i == 0) {
focusField = field;
}
fields[i++] = oTwoFields[x][1];
bValid = false;
}
}
}
if (fields.length > 0) {
focusField.focus();
alert(fields.join('\n'));
}
return bValid;
}]]></javascript>
</validator>
Step 3: Configure validation for your form in validation.xml:
<field property="password"
depends="required,twofields">
<msg
name="required"
key="errors.required"/>
<msg
name="twofields"
key="errors.twofields"/>
<arg0 key="userForm.password"/>
<arg1
key="userForm.confirmPassword"
/>
<var>
<var-name>secondProperty</var-name>
<var-value>confirmPassword</var-value>
</var>
</field>
Where errors.twofields=The '{0}' field has to have the same value as the '{1}' field. An alternative to Step 3 is to use XDoclet to generate your validation.xml. This requires (1) configuring XDoclet (of course) and (2) adding some @struts tags to your form on the setPassword method.
/**
* Returns the password.
* @return String
*
* @struts.validator type="required" msgkey="errors.required"
* @struts.validator type="twofields" msgkey="errors.twofields"
* @struts.validator-args arg1resource="userForm.password"
* @struts.validator-args arg1resource="userForm.confirmPassword"
* @struts.validator-var name="secondProperty" value="confirmPassword"
*/
public String setPassword() {
return password;
}
I've sent this as a proposal to the struts-dev mailing list yesterday, but haven't heard anything yet. Enjoy!
Update: You'll need to update ValidationUtil.java and validator-rules-custom.xml for Struts 1.2. Full files: ValidationUtil.java and validation-rules-custom.xml.