> AR is mostly used on web applications If this is the case, then we may as well not support Client Profile and get it done and over with it.
Cheers John ________________________________ From: Henry Conceição <[email protected]> To: [email protected] Sent: Tue, 31 August, 2010 8:13:10 AM Subject: Re: Castle.ActiveRecord Client Profile Support 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. -- 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.
