John, For your shared code, you could have packages like:
com.john.cms.model.* com.john.cms.layout.* com.john.cms.content.* There's no rule that says every package deployed has to have the client's name in it and you can easily reuse the same code, even reusing it easily. Say you need to override basic behavior of a class in the in the content package: com.john.cms.content.Image Not hard to have com.clientName.cms.content.Image extend com.john.cms.content.Image, implement the one method you need to, and boom, you're in business. A ContentObjectFactory with a getImageObject () method would then (based on either config or convention) return com.john.cms.content.Image, and since the client's specialized implementation extends it, there's no problem. Also, for those clients who haven't picked their domain name yet, no problem... just use a package name for the _client_, not the domain in question, so that you can reuse any code you write for them on any domain without having to worry about duplicating code. In order to use names like com.john.cms, though, you may need a mapping per package depending on how your app lays out. If you have: com.cms.john.content com.cms.clientName.content you'd probably need a mapping for /com/cms/john and /com/cms/client, otherwise CF may have issues finding things. Honestly, I can't remember the details of why I needed these mappings, but I do recall that under certain circumstances I've had to set them up. Just remember that the goal is organization toward maximizing semantics and reuse... so if you set your package names up you're going to really beef up your reuse. Put things that can apply to more than one client in non-client-specific packages, put things pertaining to one client in client specific packages and only put things that actually apply to one specific domain/site in site- specific folders. Hell, you could even use org.clientName as a package prefix to insure that the org.* classes apply to the organization as a whole, not to com.clientSiteName1 as opposed to com.client And yeah, Peter is def the Magic Man. :) J On Dec 4, 2008, at 5:39 AM, John Whish wrote: > Thanks Chris and Sean, > > One of the things that bothers me with the "com.broadchoice.foo" or > "com.chrispetersweb.blog" path approach is that occasionally I > build sites for clients that have 4 domain names and haven't > decided which one they want as the primary one! > > Also if I have a CMS solution, then that code base gets used on a > lot of sites. I suppose I could use a deployment tool like ANT to > set up the correct paths for the client domain but copy and paste > is pretty simple :) > > As a result I tend to just stick it all in a "cfc.services.remote" > structure. > > As for Peter's code - I think it just runs on Magic :) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
