Fabio, Apologies for taking this thread on a tangent, but what do you think about the capabilities coming in .Net 4 with respect to the set implementation (ISet<T>, etc.) ? Will that bridge the gap between Iesi and FW?
Thanks! -Michael ________________________________ From: [email protected] [EMAIL PROTECTED] On Behalf Of Fabio Maulo [EMAIL PROTECTED] Sent: Tuesday, November 11, 2008 9:32 AM To: [email protected] Subject: [nhibernate-development] Re: Non-XML-based Mapping Model Revisited Hi Chad. There is a difference between what do in NH-Core and what to for NH-Core. In NH-Core we can continue using XML and XMLbinders. As you read in Fluent-NH-list we are completely open to have some other "mapping source". More than one year ago I write about the possibility to have some other "mapping source" without use XML. NH metadata are decoupled from XML because we had moved a lot of responsibility from XMLbinders to MetaData classes (sometime not all responsibility). A demonstration is available in NHibernate.Validator. As I write in Fluent-NH-list, and here in the past, who want can inherits from Configuration and extend it, and the method CreateMappings is public and is the same used for all XMLBinders (HbmBinder in H3.2.6). If you, or somebody else, want start a project to map classes without use XML we are here to help. IMO is better to start the prj in NH-Contrib but there is no problem to start the prj in some other place. The advantage of NH-Contrib are: 1) More closer to all NH developers (and there are more than one that know how metada are working) 2) More easy for users to find all NH related projects 3) NHForge available for wiki, blog and so on (available even for "external" project too) 4) JIRA available If somebody speak Spanish or Italian I can explain how much we are interested to create another "mapping source"... if the name NHibernate.ORuM is not clear. NH is extensible and injectable, we are working for that but... if nobody try to create alternatives nobody can understand what is possible without deep changes in NH-Core. I don't understand why, each time somebody want write something to extend NH capability, the first step is: "we need change NH APIs because NH is coupled with...". Let me know where NH is coupled with something and I will decoupled it. Sometime I must write the first class of NH.ORuM to be more clear (I write C# better than I write English). Fabio. P.S. don't ask to decouple NH from Iesi.Collection because .NET FW don't give us an alternative (btw Iesi.Collections are part of NH sources). 2008/11/11 Chad Myers <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> I approached this list about 6 months ago about the possibility of redoing the mapping configuration in NHibernate to remove the strong XML dependency. The decision, at that time, was to not proceed for a number of good and prudent reasons at the time. The subject has since come up again on the fluent-nhibernate development list and several people have suggested that we re-visit this decision again and see if the feeling is still the same. I was wondering if any of you have interest in this. There are several thoughts about how best to approach the XML-decoupling and I'd like to discuss them if anyone is open to hear them. If the will of the team is still that the configuration should remain the same (XML-based), then I won't bother you further. Thank you for your time! Sincerely, Chad Myers -- Fabio Maulo
