You want a templating engine and/or rules engine. (Templating engine is really a subset of a rules engine.)
There's more than a single pattern involved in order to abstract away the need to code a new pattern every time. You may also want to consider writing a simple DSL. ∞ Andy Badera ∞ +1 518-641-1280 ∞ This email is: [ ] bloggable [x] ask first [ ] private ∞ Google me: http://www.google.com/search?q=andrew%20badera On Sat, Oct 3, 2009 at 12:52 PM, rbr <[email protected]> wrote: > > Hello, > > I have a problem to solve and have come up with a few solutions. > however, none are as clean as I would like them. I was hoping that > someone would have done something similar and have good suggestions > for solving the following problem: > > Problem: > > We receive data via a webservice from clients. They come in as XML and > we map these elements to one of our Domain objects. We do not receive > a few required elements currently and build them using the included > elements via a hard-coded pattern. We now have the request from our > clients to allow them to define this pattern. > > Example: > > We receive user credentials in mass uploads to our system. Currently > we do not recieve an email. Our system requires an email so we build > an email for each user by contatenating elements we do receive. In our > case we use firstnamelastn...@[client.com]. Our clients are requesting > the ability to define this pattern. So, for example, one client wants > the following pattern. > > [firstname.firstletter][lastnam...@[client.com] > > (I just made up a faux pattern definition language for illustration > purposes. We have not defined this aspect yet.) > > So, we would like the ability to define this patter per client in a > config file, read it in, and build it appropriately. > > Does anybody have experience with this type of problem? It does not > seem like it would be uncommon and we have come up with a few > solutions. However, I would like to get outside input to make sure we > are not missing something. > > We have certainly considered the strategy pattern. And that is > porbably our "best" solution thus far. However, I would prefer a > solution that would not require new coding when a new (not previously > defined) pattern is introduced. > > Thanks in advance! > > rbr >
