RecordB extending on RecordA : Possible?

Topics: Core, Troubleshooting, Writing modules
Jul 10, 2013 at 2:43 PM
I know that NHibernate has the ability for letting a record B extend a record A class and it'll work.

I couldn't get it to work with Orchard' implementation though - any ideas?
Coordinator
Jul 10, 2013 at 11:10 PM
Orchard actively promotes composition over inheritance. Go with the flow.
Jul 10, 2013 at 11:13 PM
There is a difference between promoting and making something impossible though :/

And believe me, been going with the flow for the past few weeks, the flow may stop now, could use the rest :s
Coordinator
Jul 10, 2013 at 11:24 PM
Yes, there is a difference, but when you build something, you focus on the scenarios you care about, and don't spend expensive resources on scenarios you don't care about. Something like this is simply untested because we don't care (sorry). And as you know, what's not tested is almost guaranteed not to work.

What is it that you think you need inheritance for? (as the old joke goes, tell me what you think you need and I'll show you how to do without it).
Jul 15, 2013 at 7:37 AM
Well, separate from the part system, we want a record that has a list of child records that can be of different types.

When processing these child records, the type of the record would be used to decide on 'how' to handle the contained data.

We do not want to resort to storing data in text form (like field data is stored in XML) since then we cannot query the 'raw' data directly (we would require a separate search 'engine' then).
Coordinator
Jul 15, 2013 at 8:32 AM
That sounds extremely abstract and does not say much about the real scenario that requires it.
Jul 15, 2013 at 8:44 AM
Our client wants to link orchard with their current shop system.

The'abstract' idea would be for different kind of attributes, options that sometimes can be very specific.
We could make a giant 'single' attribute useful for all, but we'd prefer it to be extensible.
So per product we'd like to add 1 or more attributes that would be handled by our own 'handlers' based on the type of attribute.

Alternative solution we have in mind now is bit dirty and would be less performant (imho): a child record with a list property per attribute type instead of 1 list property for all attribute types.
Coordinator
Jul 15, 2013 at 9:14 PM
Still quite fuzzy. What's wrong with fields on different content types?