When we have ISet<T> (what is really important is an interface for Sets) released, be sure that we will leave IesiCollections.
2008/11/11 Michael Teper <[EMAIL PROTECTED]> > 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]> > >> 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 > -- Fabio Maulo
