About passing an exporting context to an exporter

Hi guys

We are implementing a way to export a model and filter some entities.
Now we have a question:


--
Andre Hora


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

we could add an extra parameter to a lot of methods (exportingContext:...) or we could just set the context in the moose model
and the exporter ask the model for its exportingContext.

What do you think is the best?
We have the impression that the second is better.
we will implement it like that and write tests of course :) so this can be changed if necessary.




stef and andre

--
Andre Hora


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi,

I discussed a bit with Andre, and we came to the following conclusion:
- the meta-model already acts as a context for the Fame import/export. Thus we do not need to pass another context to the basic mechanism
- the MooseImportingContext can be used to produce a sub-meta-model that can easily be passed to the export

Cheers,
Doru


On 15 Jul 2011, at 18:14, Andre Hora wrote:

--
www.tudorgirba.com

"We cannot reach the flow of things unless we let go."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On Jul 15, 2011, at 8:02 PM, Tudor Girba wrote:

> Hi,
>
> I discussed a bit with Andre, and we came to the following conclusion:
> - the meta-model already acts as a context for the Fame import/export. Thus we do not need to pass another context to the basic mechanism

I do not think it does. And we should pass the information at least up to the FMrepository because else we cannot sort it out.

> - the MooseImportingContext can be used to produce a sub-meta-model that can easily be passed to the export

It looks a bit too meta for me. so we will have to filter meta model before filtering model :(
Now this is clear that linked MooseContext to fame is ugly. It would be good that FAME take this idea of context a bit better.
Because right now there is no dependencies checks done so we could filter out inconsistent model.

Still the question was also about passing another param vs. storing the context in a moose object.

Finally the FMmodel serialization has a problem because it does not have any idea of the model. so we cannot simply
save a model with for example a version number that is passed by the model. so the API of basing everything on elements
and not on a holder of elements which can have extra properties is not really good because we lose the opportunity to hook more information in it.
So I was thinking to add
        addModel: to FMRepository and to be able to query this model to get extra information.
I think that tracability is important.



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi Stef,

On 15 Jul 2011, at 21:17, Stéphane Ducasse wrote:

>
> On Jul 15, 2011, at 8:02 PM, Tudor Girba wrote:
>
>> Hi,
>>
>> I discussed a bit with Andre, and we came to the following conclusion:
>> - the meta-model already acts as a context for the Fame import/export. Thus we do not need to pass another context to the basic mechanism
>
> I do not think it does.

It does.

> And we should pass the information at least up to the FMrepository because else we cannot sort it out.

No. FMRepository works with a meta-model, which is nothing but a description of what you want to manipulate. This is the context of the import/export mechanism.

>> - the MooseImportingContext can be used to produce a sub-meta-model that can easily be passed to the export
>
> It looks a bit too meta for me. so we will have to filter meta model before filtering model :(

It's not more meta then what the implementation of Andre is doing right now. Right now, you create a filter in MooseImportingContext then you pass it to the import/export of Fame, and this exactly filters which parts of the meta-model are to be used.

What I am saying is that the filtering should be done before passing it to Fame and the result is a subset of the complete meta-model. Like this we can have the basic mechanism clear and simple and the filtering as a nice add-on that can be used in other contexts as well (not just import / export). The next step would be to have the MooseImportingContext work directly with Fame and use this filtering mechanism directly.

A model is an entity. Currently we just do not pass it to the Fame export and this is why it is not serialized:

MooseModel class>>export: aModel withMetamodel: aMetamodel to: aStream
        ...
        tower model: (repository := (FMRepository with: aMetamodel) addAll: aModel entities).
        tower model exportOn: aStream

If you add aModel, it will get exported as well. This is what we had in VW, but then we decided to change it because it was not so nice from the point of view of the meta-model. Now, VerveineJ takes FAMIX which is independent of the way Moose is implemented and it exports based on this information. So, VerveineJ does not really know about MooseModel. If you add MooseModel to the file, it gets messy because the meta-model will have to know about MooseEntity and MooseModel which are not quite at the same level as FAMIX entities.

We can change that, but before I want to think of the impact. For example, for SourceLanguage we now have a proper FAMIX entity that describes that. And this is stored in the file. It works quite well. We can something similar for other kinds of entities. Including some FAMIXExtraInformation that can store a dictionary of properties.

Cheers,
Doru


--
www.tudorgirba.com

"What we can governs what we wish."




_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

not of moose. Of fame.


>
>>> - the MooseImportingContext can be used to produce a sub-meta-model that can easily be passed to the export
>>
>> It looks a bit too meta for me. so we will have to filter meta model before filtering model :(
>
> It's not more meta then what the implementation of Andre is doing right now. Right now, you create a filter in MooseImportingContext then you pass it to the import/export of Fame, and this exactly filters which parts of the meta-model are to be used.
>
> What I am saying is that the filtering should be done before passing it to Fame and the result is a subset of the complete meta-model. Like this we can have the basic mechanism clear and simple and the filtering as a nice add-on that can be used in other contexts as well (not just import / export).

yes I see. But this is boring :)

yes I know.

> If you add aModel, it will get exported as well.

not necessarily we do not have to add it to the elements, just have it around.

> This is what we had in VW, but then we decided to change it because it was not so nice from the point of view of the meta-model. Now, VerveineJ takes FAMIX which is independent of the way Moose is implemented and it exports based on this information. So, VerveineJ does not really know about MooseModel. If you add MooseModel to the file, it gets messy because the meta-model will have to know about MooseEntity and MooseModel which are not quite at the same level as FAMIX entities.

This is not what I meant.
More passing the holder of elements instead of a collection of entities so that we can attach extra info to the exporter that can do what it wants with it.

> We can change that, but before I want to think of the impact. For example, for SourceLanguage we now have a proper FAMIX entity that describes that. And this is stored in the file. It works quite well. We can something similar for other kinds of entities. Including some FAMIXExtraInformation that can store a dictionary of properties.

Ok this is the idea.

now does the sourceLanguage encodes
        name of the extracting tools
        version
        date
        actions run on the model?
because I think that it would be good to have such information in model.

Stef



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

I think that your solution is cleaner so we will implement it or at least try.

Stef


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev