I would just like to make sure that I have the right design approach here before I start coding.
Everything I've done with SmartGWT to date has been around manipulating data; and for that the DataSources approach has of course been very useful.
However, I now have a requirement that doesn't really fit the standard datasource mold.
In nutshell, I need to give users to ability to re-send an automatically generated email.
The system I've been working on deals with processing orders. As part of that process, emails get automatically sent out to customers at certain stages of the order. The way this has been implemented is as follows:
1) On the client-side, the order is submitted as pretty standard SmartGWT DynamicForm.
2) On the server side I use DMI to access services in Spring.
3) The order is first processed by a Facade class, a Server DataSource implementation that I wrote.
4) The Facade class interacts with 1 or more Hibernate DAO objects to persist data.
5) I use Spring AOP to advice the calls between the Facade and the DAO. This allows me to detect when objects are successfully persisted.
6) When the order object has been successfully persisted, AOP advice triggers an Email aspect which sents out the email.
7) The actual email body is by executing a Velocity template
8) The email aspect in turn triggers an audit aspect, logging the actual sending of the email in a separate audit table.
9) The SmartGWT client interface displays data from the audit table so that the user can seen what emails, if any, have been sent to the customer.
10) If an order is modified after the email is sent (let's say, to fix some data), we don't automatically send out a new email to prevent spamming our customers.
All this is already fully operational and works great. However, we need to give users the ability to re-send an email if required. This isn't strictly a datasource operation - we're not persisting any data. All I need to do is pass the ID of the order to the server and the stage of the order for which we want to send out the email; server-side logic can then do the rest (i.e. retrieve the order details, find the appropriate Velocity template, send out the email, and so on). I know I can probably implement this as a DataSource fetch operation; but that seems a bit like abuse to me - I'm not fetching data, I just want to invoke some logic on the server side.
I've been looking at the FAQ and the API docs on RPCRequest and RPCManager - I was thinking of writing a simple servlet that takes a the order ID and a string representing the order phase as parameters. The servlet would be wired up in Spring (using Spring's HttpRequestHandlerServlet as a proxy in the web.xml). The servlet would invoke the email service and that service (which already exists) would handle the rest.
On the client side, I was thinking of simple hitting the Servlet via an RPCRequest and wrapping the ID and order phase into the request (probably using a RPCRequest.setData(Map).
Does that sound like a good approach?
Everything I've done with SmartGWT to date has been around manipulating data; and for that the DataSources approach has of course been very useful.
However, I now have a requirement that doesn't really fit the standard datasource mold.
In nutshell, I need to give users to ability to re-send an automatically generated email.
The system I've been working on deals with processing orders. As part of that process, emails get automatically sent out to customers at certain stages of the order. The way this has been implemented is as follows:
1) On the client-side, the order is submitted as pretty standard SmartGWT DynamicForm.
2) On the server side I use DMI to access services in Spring.
3) The order is first processed by a Facade class, a Server DataSource implementation that I wrote.
4) The Facade class interacts with 1 or more Hibernate DAO objects to persist data.
5) I use Spring AOP to advice the calls between the Facade and the DAO. This allows me to detect when objects are successfully persisted.
6) When the order object has been successfully persisted, AOP advice triggers an Email aspect which sents out the email.
7) The actual email body is by executing a Velocity template
8) The email aspect in turn triggers an audit aspect, logging the actual sending of the email in a separate audit table.
9) The SmartGWT client interface displays data from the audit table so that the user can seen what emails, if any, have been sent to the customer.
10) If an order is modified after the email is sent (let's say, to fix some data), we don't automatically send out a new email to prevent spamming our customers.
All this is already fully operational and works great. However, we need to give users the ability to re-send an email if required. This isn't strictly a datasource operation - we're not persisting any data. All I need to do is pass the ID of the order to the server and the stage of the order for which we want to send out the email; server-side logic can then do the rest (i.e. retrieve the order details, find the appropriate Velocity template, send out the email, and so on). I know I can probably implement this as a DataSource fetch operation; but that seems a bit like abuse to me - I'm not fetching data, I just want to invoke some logic on the server side.
I've been looking at the FAQ and the API docs on RPCRequest and RPCManager - I was thinking of writing a simple servlet that takes a the order ID and a string representing the order phase as parameters. The servlet would be wired up in Spring (using Spring's HttpRequestHandlerServlet as a proxy in the web.xml). The servlet would invoke the email service and that service (which already exists) would handle the rest.
On the client side, I was thinking of simple hitting the Servlet via an RPCRequest and wrapping the ID and order phase into the request (probably using a RPCRequest.setData(Map).
Does that sound like a good approach?
Comment