Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book 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 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.

RECENT ENTRIES


Tag Cloud


abbie appfuse birthday denver family grails gwt jack java javascript jhipster jsf linkedin maven roller skiing softwaresummit spring springmvc struts2 travel trish vacation webframeworks wicket
« WebWork Books | Main | Should I change... »
Wednesday September 14, 2005

Biled Again, this time because my design sucks

Looks like I've been biled again. Unlike the last time, this time Hani doesn't offer any specifics, he merely says that my OSS efforts don't do anything other than the "very very basics".

Java, specifically, goes a long way towards ramming down a set of design principles. Said principles are followed fairly blindly by most practitioners. The OSS world is awash with examples of people who have read the right books, but have absolutely no skill or talent at conceptualising or grokking the underlying principles behind the books. To them, the design pattern is an end goal, not a tool. To pick one example (out of thousands), look at Matt Raible's OSS efforts. It has inheritance! It uses PATTERNS! It is LIGHTWEIGHT! Yet, I'd argue that it's very badly designed (if you don't believe me, just try getting it to do anything other than the very very basics.)

I'm assuming that Hani is speaking about AppFuse and Equinox, because my other efforts in OSS are minimal (Roller, Display Tag, XDoclet and Struts Menu). The reason I'm writing this post is because I'm curious to know what Hani tried to do that didn't work? Was it AppFuse/Equinox that failed? Or was it the underlying framework? Did he try to do indexed properties with WebWork or modify build.xml to deploy to Orion? Is the feature he's looking for something we can fix?

As a defense of my use of patterns, lightweight containers, etc. - it's not so much my doing that these happen to exist - they're more of a reflection on what user's want. It's a problem with Java developers in general - if you're not using patterns - users want to know why. Furthermore, most of the J2EE patterns in AppFuse are from the underlying frameworks, not from anything that I did.

As far as the design of AppFuse, I agree it could use some work. There's a lot of stuff in AppFuse that I don't use - so when I start a project with it - I usually rip out about 20-30% percent of it's features b/c I won't use them. Unfortunately, it's not that easy for others to do this b/c they don't know what they'll break if they remove a bunch of stuff. I'd like to move to a more modular, plug-in type architecture - but I have a feeling that that's the path to over-engineering. Even so, it would be pretty cool if it was possible to turn on/off features (even the use of a particular web framework) by changing a properties file.

Posted in Java at Sep 14 2005, 08:58:58 PM MDT 8 Comments
Comments:

The first question always has to be "Does it work?" You and I assume others use AppFuse and Equinox so the answer must be yes. To be honest, I don't because there seems to be a lot in there I wouldn't use but I sort of like the concept. The acid test that Hani proposes, "A good design allows your code to do things you never expected it to have to do", I don't buy at all. Or at least I would not nor would I recommend anyone to think of it that way. First and fundamental question: Does it work? It would also be very nice if it's easy to understand. It would be even nicer if there also wasn't a lot of duplication. And it would be even nicer if it was also compact and minimal. But I'd very wary of emphasising the introduction of unnecessary flexibility which is a reasonable interpretation of "A good design allows your code to do things you never expected it to have to do". Flexibility in a good design falls out of responding to implementing features and refactoring. This is an old school framework design principle that still holds today though unfortunately many people still haven't learned it.

Posted by Jason Yip on September 15, 2005 at 08:48 AM MDT #

Hey Matt, actually my post was referring to appfuse (mostly for stuff I had blogged about earlier). I think (and you might even agree!) that it makes a certain kind of thing very easy, but once you start deviating from that and wanting to do infrastructure things (which invariabely, happens to ALL webapps) that the framework hasn't really dealt with, it gets hairy trying to slot it in.

Posted by Hani Suleiman on September 15, 2005 at 09:49 AM MDT #

I'm curious what software Hani Suleiman has put out there. Frankly, it looks like armchair quarterbacking to me.

Posted by Daniel Berger on September 15, 2005 at 04:02 PM MDT #

See my comments on the matter here: http://jroller.com/page/bsnyder?entry=the_biling_of_appfuse

Posted by Bruce Snyder on September 15, 2005 at 04:29 PM MDT #

Hani is generally thought provoking and entertaining. Matt, I'm looking forward to see what becomes of this train of thought.

Posted by Solomon on September 15, 2005 at 10:33 PM MDT #

OK. As someone who is currently up to my neck in Appfuse (spring-mvc 1.8.2) I can comment on a couple of specific items that have been more painful to change. I guess the most important part though, is that I would want to change these things with any appfuse install, and so I think they must be fairly common among some users. I think that's what Matt was asking for?
  1. Changing the default usernames, passwords, and roles
  2. Moving the UploadFile logic into a CustomEditor so that it can be used with any model
  3. Removing some of the "fluff" such as the picture on the 404 page, the link and pages for users to add themselves, the polite "welcome.message", the "newuser.email.message" that continues to say "Appfuse application", etc.
  4. Adding groups so that users can be grouped together
The reason why most of those things take so long is partly due to the nature of any MVC application, there are a LOT of duplicated references to those items. Changes need to be made in virtually all packages, including some esoteric files that effect test cases and random data generation for item #1. The applicationResources.properties file needs to be changed for each language as well, multiplying each "fluff" change by about 8. The thing I REALLY dread now is upgrading when the next appfuse rolls out... :/ Having said that, now that those changes are made, I have a re-usable meta-application that conforms to MVC best-practices in many ways. It's ideal for me because I need to produce multiple versions of the same application that are customized only slightly at the app-level and drastically at the DB level (content / data). Abstracting all of the code changes up to appfuse makes it extremely convenient to re-create a completely re-branded version of the app for different clients. All in all it's very worth my time to use it, and I think it's mostly a fine piece of work. Thanks for all the effort Matt (et al)!

Posted by Brendan Curran on September 17, 2005 at 02:21 PM MDT #

Hi,

I've just dug in (again) to AppFuse and Equinox to try to get an app running for my kids' school. I started with AppFuse but saw too much happening out of the box that I didn't understand. When you run the build you get an app, but an app that does what? If I haven't written any code, what's this nonsense about updating profiles and such? There's a lot going on behind the scenes and I want to learn how it all works.

So, I regressed to Equinox. Like you said, Matt, if I knew more about how AppFuse worked, it would probably be easier to remove stuff. Instead, I opted for Equinox and added stuff from AppFuse. It's silly, but at least that way I have a better understanding of how everything fits and I can control it. Maybe AppFuse and/or Equinox should not create any app, but provide an examples section (like Tomcat does) for implementing various features? Just a thought.

Keep up the good work!

Posted by Paul Carter on September 20, 2005 at 06:39 PM MDT #

I'm trying to use AppFuse 1.8.2 on Orion. Some of the Spring XML combining doesn't work in Orion, so I have to yank it out of the xDoclet generated code and stick it in to an applicationContext.xml file. I'd prefer to keep xDoclet (and metaprogramming frameworks in general) out of a sample application, as it makes the barrier to entry too high -- not only do I have to figure out all the different frameworks, I have to figure out the configuration generated from it.

Posted by Will Sargent on September 30, 2005 at 06:55 PM MDT #

Post a Comment:
  • HTML Syntax: Allowed