Design Patterns and You: The Decorator

So, I’ve been doing some work on my Framework for Package API-Based ADF BC (locking doesn’t work as-is, and it turns out the framework needs some pretty significant re-architecture to get it to), and between that and my regular work, I’ve been a little ADF’ed out. So for a couple of weeks or so, I’m going to do something I haven’t done a lot of in this blog, and post a bit about pure Java. This will, hopefully, contain techniques of interest to ADF developers, and I’m probably going to use some ADF-based examples, but I’m mostly going to be talking about “Java techniques that they don’t teach you in a 5-day Java class.”

While working on the new version of the Framework, I’ve run into some significant annoyances, by which I mean the sort of coding work that a monkey–or better yet, a tool–could do but is long and fiddly to do by hand. This isn’t something that will primarily bug your average ADF developer, but it’s a sufficiently common Java technique that it would be a useful add-on for any Java IDE, JDeveloper included. It’d be a neat project for my Copious Free Time, but for now I’m just going to throw it out there in case anyone’s interested: The automatic generation of a decorator. Even if you’re not interested in that, you might want to read this article, just to get a feel for an important design pattern.

Continue reading Design Patterns and You: The Decorator

Framework for Package-Based ADF BC, My ODTUG Schedule, and More

Like the poltergeists, I’m baaack. I’m back to my usual health, and while I’m still pretty horribly snowed under, I think that enough of the worst of it is over that I can generally commit to my “Updates Mondays” schedule again. This has been a *long* hiatus (over 6 motnths), and I’m very glad to be back among the lang of the living. I’ve missed this blog and the ADF community generally.

Although I plan to get back to the ADF BC Tuning series soon, I want to use this post to announce two things: The first piece of software I’m releasing on this site and my public (that is, not just as an audience member) at ODTUG Kaleidoscope, which will be next week in Monterey, CA.

First, the software. This is actually related to one of the talks I’ll be giving at ODTUG, and tangentially related to another. But even if you aren’t going to the conference, I hope you’ll find it useful. It’s an extension of the ADF BC framework that allows you to create the following 100% declaratively:

  • Entity object definitions (including support for optimistic or pessimistic locking and Refresh After… settings) that use Package APIs instead of DML
  • View object definitions (whether entity-based or not, and including support for query parameters) that use Package APIs instead of SELECT statements
  • Associations and view link definitions involving the above

You can get the framework here.

At ODTUG, I’ll  be participating in the following:

Hope to see you there!

The Power of Properties II: The View Object

Hey, did you know that, even if you create a “Programmatic View Object” (rows populated programmatically, not based on a query), you can set “bind variables” for it? Neither did I until very recently. You can’t do it in the Create View Object wizard (because the Query page never appears), but once you’ve got that VO, you can indeed add bind variables in the editor.

“Why on earth would you want to do that?” you ask (or, at least, I imagine you asking). “Bind variables are meant to allow the application or user to specify bind parameters for a query, and a programmatic VO doesn’t have a query.” Indeed, that’s what bind variables are usually for, but here, I’m going to show you, at least in outline, how to use this feature to make the ultimate 100% declaratively customizable framework classes (one view object class, one view definition class) for view object definitions based on REF cursors (i.e., whose instances will call a package function to retrieve their row set, rather than execute a query).

Continue reading The Power of Properties II: The View Object

Extreme Reusability, Part II

Last week, I introduced the ADF development methodology I’m proposing, “Extreme Reusability,” articulated its goals, and discussed the techniques of “Generalize, Push up, and Customize” and “Think Globally, Deploy Locally” that are critical to the methodology. I didn’t, however, describe the actual…well, methodology, meaning the development cycle prescribed by Extreme Reusability.

Notice I didn’t say the application development lifecycle. That’s because developing under Extreme Reusability, like developing under SOA, isn’t primarily about the creation of standalone applications. You should think of the development cycle for extreme reusability as part of an enterprise-wide effort.

Development under Extreme Reusability involves developing along three separate but interacting (and communicating–communication is absolutely vital under this system) tracks: framework development, service development, and application development. These tracks are assigned to different individuals on the team, in (at a guess–remember this is a proposed methodology) somewhere around a 20-60-20 division for a typical organization’s needs.

Continue reading Extreme Reusability, Part II

Extreme Reusability, Part I

As promised, I’m posting of the presentation I’d been hoping to give at the OOW Unconference Methodology Symposium last week, expanded slightly for the more forgiving medium of a blog. As it turns out, it’s expanded substantially more than I thought, so I’m going to divide it into two parts. This week, I’ll talk about the basics of the methodology, its goals, and the two techniques it relies heavily upon. Next week, I’ll talk about the actual development process it specifies.

“Extreme Reusability” (the name is not mine, but rather Chris Muir’s; however, I decided I like it) is an idea for an ADF development methodology for mid-sized teams (generally around 4-20 developers) that I’ve been recently expanding on. Continue reading Extreme Reusability, Part I