On 5/27/05, Ted Husted <[EMAIL PROTECTED]> wrote: > (Team iBATIS) examples, that we *always* assume people are going to be > deploying the same configuration to multiple project types. > Accordingly, I would suggest that we *never * use a relative path in > our project examples, but always use a properties variable. When we do > show a relative path in a reference guide, we should also remark that > it is *not* considered a best practice to use that form.
I agree. And because I'm not completely following what the final solution is going to look like I'll just summarize my current project and how it relates to my configuration wish list: iBatis should provide configuration options that do not require client code to know anything about iBatis. This means that client code should not have to know about any iBatis config files. (I'm basically defining client code as any non class library .NET project - web app, windows app, web service, console app, windows service, etc.) I am currently developing an application suite (client code, domain objects class library, BLL class library, DAL class library) for processing electronic real estate documents defined in XML. My DAL uses iBatis to map database entities to my domain objects. My BLL talks to my DAL. I currently have two clients -- a receiving web service and a web application that monitors the workflow associated with the web service. Those two clients only access my BLL and domain objects. They (and future client code) should not have any knowledge of the DAL which means that all configuration of iBatis should be done by the DAL. To allow for this I have been editing iBatis source so that I can difine absolute path locations for my sqlmap.config and sql maps. Because I wanted to minimize how much iBatis code I was changing, I've relunctantly left providers.config in my client projects but I'd obviously prefer that it stay with my DAL. Hopefully this gives a complete picture of what precipitated my originals emails to ibatis-user.
