I have fixed it in Extension.ext (forgot a stupid thing).
Junit test updated.
Please test more.
/Patrik
polly.c.chang wrote:
>
> Hi Patrik,
>
> I finally had a chance to test your changes. It looks good for the
> implementation of the "use" keyword and propagation of the "external"
> attribute to nested design files. However, it seems that it is not
> possible to reference an object defined inside a nested file. Given:
>
> model1
> import model2
> external import model3
> import model4
>
> It is not currently possible to have model1 reference something defined in
> model3. I say this because the following test case fails:
>
> import
> "platform:/resource/com.infor.mdd.generator/src/test/resources/nested2.design"
>
> Application Nested {
> basePackage = org.fornax.cartridges.sculptor.test.nested
>
> Module nested1 {
> ValueObject A {
> String a
> - @B b
> - @C c
> }
> }
>
> }
>
> Being able to reference objects defined inside a nested import is what I'd
> really like to have, because my "common" project has its model split over
> many files, and it would be nice if the "app" project can simply import
> its one top-level model file instead of specifying all the individual
> files.
>
> I'll take a look at the code to see if I can figure out how to do this,
> but you will probably be faster. ;)
>
> Thanks,
> Polly
>
>
>
> Patrik Nordwall wrote:
>>
>> I have started
>> http://www.fornax-platform.org/tracker/browse/CSC-262
>>
>> I have added possibility to mark an import as external, i.e. existing in
>> another project.
>> Syntax:
>> external import
>> "platform:/resource/fornax-cartridges-sculptor-generator/src/test/resources/nested3.design"
>> external import
>> "platform:/resource/fornax-cartridges-sculptor-generator/src/test/resources/nested4.design"
>>
>> ApplicationPart NestedPart2 {
>>
>> Module nested2 {
>> ValueObject B {
>> String b
>> - @C c
>> - @D d
>> }
>> }
>> }
>>
>> I have overwritten the model() function in Extensions.ext (dsl project).
>> It loads imports recursively and marks modules from external imports.
>> It will handle the case:
>> model1
>> import model2
>> external import model3
>> import model4
>>
>> Modules in model3 and model4 will be marked as external (in the context
>> of model1, model2).
>>
>> This is what I did in Extensions.ext
>> // recursive imports, and on the fly assignment of external
>> List[emf::EObject] model(DslImport this) :
>> (let loaded1 = model==null?{}:model.load().flatten() :
>> (this.external ?
>> (loaded1.typeSelect(DslModel).imports.setExternal(true) ->
>> loaded1.typeSelect(DslModel).app.modules.setExternal(true)
>> ):
>> null
>> ) ->
>> loaded1.union(loaded1.typeSelect(DslModel).imports.model().flatten()));
>>
>> I have tested this from junit NestedTransformationTest.
>>
>> The only thing I have done in the generation so far is to exclude the
>> DomainObjects belonging to external Modules. More excludes have to be
>> done.
>>
>> Maybe we have to do something for the package naming problem, I will look
>> in to that.
>>
>> /Patrik
>>
>
>
--
View this message in context:
http://www.nabble.com/-Sculptor--importing-nested-design-files-tp20269181s17564p20368963.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
