« - »

Notification Service: A little minor enhancement

1 April 2009

OK, I have to admit that this a little backwards compared to my normal approach to these types of things. Usually, when an idea comes to mind, I get busy and build out all of the parts and try it out, and if it works the way in which I had envisioned, I make it a permanent part of the portfolio and roll it out to where all can.

Today, though, I’m just going to toss out a little idea without actually doing any real coding, and then hopefully follow this up later on with some tangible parts that will actually work. But first, a little background, just to provide the context.

It’s been a while since I completed the major work on the Notification Service. Since that time, it’s been used for a variety of purposes, and in a number of different ways, which was the intent. The basic approach to sending out a notice is something like this:

notifier.sendNotification(sendTo, templateId, noticeData);

… where sendTo is a list of recipients, tempateId is the id of the stock language for the message to be sent out, and noticeData is the data from which values are extracted to resolve variables in the template. Now, the format of the “data” passed was intentionally left obscure so that you could choose to implement this element in any way that best fit your particular use of the service. This actually worked quite well, as many people chose many different approaches to populating this element before making the call to send out the notifications.

However, in order for all of this work as it should, there must be a clear understanding between the template designer and the individual passing the data so that the person laying out the message understands what data is going to be made available and how it is to be acessed in the template language. In our standard implementation of the Notifier interface, we use Velocity to resolve all of the variable data, so the templates are written using Velocity syntax. The recipient data is loaded into the Velocity context under the name recipient, and the notice data, in whatever form it is passed, is loaded into the context under the name data. In this way, all recipient data is referenced using the Velocity syntax $recipient.whatever and all notice data is similarly referenced using $data.whatever. It’s the format of the “whatever” portion of the field names that changes with each developer’s unique way of bundling up the data to send into the notice process.

So, from the template designer’s perspective, it seems rather confusing that you have to code $data.user.id in one instance and $data.request.remoteUser in another when the result turns out to be the same value. Shouldn’t you guys all get together and come up with a consistent approach or a standard as to how you are going to do this?

Well, yes and no …

Consistency is good, but flexibility is good, too. I don’t really want to force people into doing things the way that I do them. The whole point was to create something that everyone could use in the way that best fit their needs. Still, it would be nice, for a lot of different reasons, if everything were approached in some kind of consistent maner.

So, I had this idea.

What if we created some kind of static utility or method call that included as much “standard” stuff as possible, yet still left room for individual elements to be added into the mix as well. Something like:

noticeData = notifier.getStandardNoticeData(request, response);

This would return a Map with some standard elements already populated in a consistent format, and then you could add other data to the map as well for your own unique purposes; however, the standard stuff would always be the same if you used this method. And if you didn’t want to for some reason, you could go without. That would retain the original flexibility, and yet provide some common framework for common elements such as the current date, the current user, incoming form fields, the request object, the session object, and any number of other elements commonly used in web applications. The best of both worlds: consistency right there for easy picking if you want it, and the flexibility to ignore that for those that don’t.

That’s the theory, anyway. Now I just have to code it!


Leave a reply

You must be logged in to post a comment.