These two constraints will be removed when we support multi levels
inheritance.
The first means that the base class must be abstract. 
The second is the check for that only one level of extension is used.

I'm not sure what needs to be done, but I don't think it is very much. I
appreciate if you can test and try different scenarios.

E.g. 
    Module sandbox {
      abstract Entity Aaa {
        String aaaProp
      }
      
      Entity Bbb extends Aaa {
        String bbbProp key
      }
      
      Entity Ccc extends Aaa {
        String cccProp key
      }
      
      Entity Ddd extends Ccc {
        String dddProp key
      }
    }

Verify:
- Java classes. One thing I see that is not correct is the key at several
levels.
- Hibernate mapping
- DDL

E.g. of variants:
- not changable
- not persistent
- not auditable
- ValueObject

All combinations will not be supported.

I think we can take the details in a private conversation. 

/Patrik


amphoras wrote:
> 
> Cool, thank you!
> 
> I have another couple of questions.  I found this rule in the
> constraints.chk file:
> 
> context DomainObject if extends != null ERROR "Extended class must be
> abstract " + extends.name:
>     this.extends.abstract;    
> 
> Would you mind explaining what this rule is for?  I'm sure there's a good
> reason for it.  I'm just trying to understand Sculptor better.
> 
> I also found this rule:
>     
> context DomainObject if extends != null ERROR "Only one level of extension
> is supported " + name + " extends " + extends.name + " extends " +
> extends.extends.name:
>    this.extends.extends == null;
> 
> I found that if I disable this rule, the domain objects seem to be
> generated successfully.  But I know it can't be as easy as that to turn on
> multi-level inheritance.  What else is broken or messed up if I disable
> this rule?  Again, I'm asking these detailed questions because I'm trying
> to understand what goes on under the covers.  That way if my company
> decides that it can't wait for the fix and tells me I have to hack it, I
> can at least put in something that makes sense.
> 
> Thanks!
> 
> --Polly
> 
> 
> 
> Patrik Nordwall wrote:
>> 
>> I have created an issue in jira for this:
>> http://www.fornax-platform.org/tracker/browse/CSC-226
>> 
>> If you and others think it is important we will of course give it
>> priority and I think we can implement the support for the domain objects
>> first, rather soon.
>> 
>> /Patrik
>> 
>> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/problem-with-multi-levels-class-inheritance%3A-Best-practices-tp17598981s17564p18988410.html
Sent from the Fornax-Platform mailing list archive at Nabble.com.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Fornax-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fornax-developer

Reply via email to