About the split: I think that doesn't makes sense. AR is mostly used on web applications, and doing this split would be a useless breaking change to the majority of our users.
Maybe an ifdef (excluding the non supported classes/features) can do the tricky. Cheers, Henry Conceição On Mon, Aug 30, 2010 at 9:19 AM, Michael Maddox <[email protected]> wrote: > I'd like to see Option 1 happen (split non-client profile code off > into Castle.ActiveRecord.Extended). > > Option 2 feels like it would cause confusion for users. > > Michael Ketting's blog post mentioned by Fabian seems more like a > workaround after the fact than a fundamental solution. It's a useful > workaround, but I wouldn't want to encourage it's use when better > options are available. > > -Michael Maddox > http://www.capprime.com/software_development_weblog/ > > On Mon, Aug 30, 2010 at 1:47 AM, Patrick Earl <[email protected]> wrote: >> Hi all. >> >> With NHibernate now supporting the client profile, I'd like to see >> client profile support for Castle.ActiveRecord. Unfortunately, as far >> as I can see, there's no easy way to do it. SessionScopeWebModule is >> an IHttpModule and people configure it by providing the qualified >> class name in the httpModule section of the config file. I don't see >> how to fix that without moving SessionScopeWebModule to a separate >> assembly or using compilation directives. For comparison, NLog has >> gone through a similar process and split the web components into a >> NLog.Extended to match the split between the client and extended >> frameworks. I'd like to suggest a couple possibilities. >> >> 1. Split off at least SessionScopeWebModule (and potentially other >> web things) into a Castle.ActiveRecord.Extended (or >> Castle.ActiveRecord.Web) assembly. This would be a breaking change >> requiring certain web users to add a reference to the new project. >> 2. Use #ifdefs and distribute two different versions of the >> Castle.ActiveRecord assembly. One for web, one for not. >> >> My personal preference is #1, since it is a one time change, even if >> it's a breaking change. The second one causes all sorts of >> distribution / build headaches as mentioned in my other message >> pertaining to Castle.Core. >> >> What are people's thoughts on this? >> >> Patrick Earl >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Castle Project Development List" 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/castle-project-devel?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Development List" 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/castle-project-devel?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Castle Project Development List" 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/castle-project-devel?hl=en.
