Are there any LLBL templates to generate NHibernate classes and mappings? If not, is it possible to easily translate the MyGeneration templates to LLBL templates?

Frans, do you see the value in providing a template conversion tool? There seem to be a lot of useful templates in MyGeneration (http://www.mygenerationsoftware.com/templatelibrary/default.aspx) and/or CodeSmith format and it would be great to be able to use these in LLBL Gen Pro!

Hint CodeSmith-2-MyGeneration Converter: http://www.mygenerationsoftware.com/portal/CodeSmithConverter/tabid/90/Default.aspx

Mountain wrote:

Are there any LLBL templates to generate NHibernate classes and mappings? If not, is it possible to easily translate the MyGeneration templates to LLBL templates?

Yes, please check the .ltp template syntaxis in the SDK documentation. (extra's section in the customer area). Also, if you want to utilize meta-data (of course) like db schema info, you've to convert that to the llblgen pro project model, but that's fairly straight forward.

Frans, do you see the value in providing a template conversion tool? There seem to be a lot of useful templates in MyGeneration (http://www.mygenerationsoftware.com/templatelibrary/default.aspx) and/or CodeSmith format and it would be great to be able to use these in LLBL Gen Pro!

Code conversion requires parsing of the actual code and re-writing that, which is a bit of a pain to create in general form.

I'll not provide templates for competing O/R mapper frameworks btw.

Otis wrote:

I'll not provide templates for competing O/R mapper frameworks btw.

Does the childhood taunt "chicken!" mean the same thing in the Netherlands as it does here?

--Bruce

bonder wrote:

Otis wrote:

I'll not provide templates for competing O/R mapper frameworks btw.

Does the childhood taunt "chicken!" mean the same thing in the Netherlands as it does here? --Bruce

No, but I do know what you mean . It's not that, I just don't help competition getting part of our marketshare, they should do that by themselves. Reading the hibernate blog yesterday, I have a bit doubts about the future of nhibernate, as they're looking into automatic porting hibernate 3.x to .net, which is IMHO the same as starting from scratch with 3.0, not a wise move.

Otis wrote:

It's not that, I just don't help competition getting part of our marketshare, they should do that by themselves.

Actually, I was thinking that if there were NHibernate templates available for your product it would only help you sell more LLBLGen.

We have looked at using MyGen and Codesmith to do NHibernate templates and they just don't contain the UI to specify fields/names etc that your UI has. (Well you could build it all.) But, LLBLGen seems to have all the UI stuff and metadata that would enable us to do a nice job.

Also, some one that might buy your product to run the NHibernate templates may also want to check out the LLBLGen code templates.

Can you tell we have been considering writting NHibernate templates for LLBLGen?

BOb

pilotboba wrote:

Otis wrote:

It's not that, I just don't help competition getting part of our marketshare, they should do that by themselves.

Actually, I was thinking that if there were NHibernate templates available for your product it would only help you sell more LLBLGen.

We have looked at using MyGen and Codesmith to do NHibernate templates and they just don't contain the UI to specify fields/names etc that your UI has. (Well you could build it all.) But, LLBLGen seems to have all the UI stuff and metadata that would enable us to do a nice job.

Also, some one that might buy your product to run the NHibernate templates may also want to check out the LLBLGen code templates.

Can you tell we have been considering writting NHibernate templates for LLBLGen?

Recently (last week) I saw (NDA) documents of what DLinq will get. It's going into the wrong direction for all O/R mapper vendors out there. Still, we have the code generator core which is a big asset and we're considering making it more important in future versions, so open up the code generator for other data-access solutions which requires changes in the GUI but at the same time makes us more robust for future stuff released by MS.

So, long-term plans indeed might include support for other data-access solutions, however we'll always keep our own core as the only first class citizen.