Notification Service: NoticeTemplate bean
30 October 2008You have to start somewhere, and for our new Notification Service, I decided I would start with the templates for the notifications, and all of the things necessary to persist such data on some kind of database. I originally thought of placing all of the code for the notice template maintenance into the core project, since the templates were relatively universal components, but then I decided that the Notification Service itself was large enough to have its own project, just like the Approval Service and Authorization Service, so I changed my mind and started a brand new Maven project just for notifications. My first Java package in the new project was org.restafarian.notify.beans, and my first Java class in the package was the NoticeTemplate:
package org.restafarian.notify.beans;
import org.restafarian.core.beans.PersistentBeanBase;
/**
* <p>This entity bean defines a single notice template.</p>
*/
public class NoticeTemplate extends PersistentBeanBase {
private static final long serialVersionUID = 1;
private int id = -1;
private String context = null;
private String name = null;
private String description = null;
private String contentType = null;
private String defaultDeliveryMethod = null;
private String titleSubject = null;
private String body = null;
/**
* @return the id
*/
public int getId() {
return id;
}
/**
* @param id the id to set
*/
public void setId(int id) {
this.id = id;
}
/**
* @return the context
*/
public String getContext() {
return context;
}
/**
* @param context the context to set
*/
public void setContext(String context) {
this.context = context;
}
/**
* @return the name
*/
public String getName() {
return name;
}
/**
* @param name the name to set
*/
public void setName(String name) {
this.name = name;
}
/**
* @return the description
*/
public String getDescription() {
return description;
}
/**
* @param description the description to set
*/
public void setDescription(String description) {
this.description = description;
}
/**
* @return the contentType
*/
public String getContentType() {
return contentType;
}
/**
* @param contentType the contentType to set
*/
public void setContentType(String contentType) {
this.contentType = contentType;
}
/**
* @return the defaultDeliveryMethod
*/
public String getDefaultDeliveryMethod() {
return defaultDeliveryMethod;
}
/**
* @param defaultDeliveryMethod the defaultDeliveryMethod to set
*/
public void setDefaultDeliveryMethod(String defaultDeliveryMethod) {
this.defaultDeliveryMethod = defaultDeliveryMethod;
}
/**
* @return the titleSubject
*/
public String getTitleSubject() {
return titleSubject;
}
/**
* @param titleSubject the titleSubject to set
*/
public void setTitleSubject(String titleSubject) {
this.titleSubject = titleSubject;
}
/**
* @return the body
*/
public String getBody() {
return body;
}
/**
* @param body the body to set
*/
public void setBody(String body) {
this.body = body;
}
}
Because I have visions of having templates on file from more than one project, I refrained from creating a template id that was the primary key to the table. Instead, I opted for an auto-generated key that will pretty much be hidden from everything, and will use the combination of context and template name as the primary key for all intents and purposes. I haven’t worked out all of the details in my head just yet as far how the context comes into play, but the basic idea here is that templates will be organized into specialized groups (the “context”), and then have unique, unix-like names within their respective context. The combination of context and name (myContext/myTemplate) will form the complete key to the template.
The description has no useful purposes in processing, and is simply informational metadata, but the content type, delivery method, and title/subject will all have potential implications at run time, as will the body of the notice. I am assuming at this point that the only delivery method initially will be e-mail and that the content type will be valid MIME types applicable to e-mail messages. When we get to the maintenance screens, I can see both the delivery method and content type fields being rendered as HTML select/option statements on the input form, with the available options possibly coming from look-up tables created specifically for that purpose.
I am also assuming that both the title/subject and the body of the message may contain variables that will need to be resolved, and at this point, such resolution will be accomplished using the Simple Velocity Service introduced earlier. I am also assuming that, depending on the content type, I may want to invoke some type of rich text editor such as Xinha for maintaing the body. We’ll worry about that when we get to that point, though.
Of course, having the bean defined is just a start. I now need to create the Hibernate mapping file (unless, of course, I want to start using annotations instead, but I’m thinking no, not at this time) and then the betwixt mapping file. Maybe those are good pieces to get into next time …
Leave a reply
You must be logged in to post a comment.
