15 Jul
2011
15 Jul
'11
6:12 p.m.
Hi guys
We are implementing a way to export a model and filter some entities.
Now we have a question:
--
Andre Hora
15 Jul
15 Jul
6:14 p.m.
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.
On Fri, Jul 15, 2011 at 6:12 PM, Andre Hora <andrehoraa(a)gmail.com> wrote:
Hi guys
We are implementing a way to export a model and filter some entities.
Now we have a question:
--
Andre Hora
stef and andre
--
Andre Hora
8:02 p.m.
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:
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.
On Fri, Jul 15, 2011 at 6:12 PM, Andre Hora <andrehoraa(a)gmail.com> wrote:
Hi guys
We are implementing a way to export a model and filter some entities.
Now we have a question:
--
Andre Hora
stef and andre
--
Andre Hora
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
9:17 p.m.
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.
Cheers,
Doru
On 15 Jul 2011, at 18:14, Andre Hora wrote:
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.
On Fri, Jul 15, 2011 at 6:12 PM, Andre Hora <andrehoraa(a)gmail.com> wrote:
Hi guys
We are implementing a way to export a model and filter some entities.
Now we have a question:
--
Andre Hora
stef and andre
--
Andre Hora
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:51 p.m.
Hi Stef,
On 15 Jul 2011, at 21:17, Stéphane Ducasse wrote:
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.
--
www.tudorgirba.com
"What we can governs what we wish."
On Jul 15, 2011, at 8:02 PM, Tudor Girba wrote:
It does.
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.
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 :( 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.
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
Cheers,
Doru
On 15 Jul 2011, at 18:14, Andre Hora wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
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.
On Fri, Jul 15, 2011 at 6:12 PM, Andre Hora <andrehoraa(a)gmail.com> wrote:
Hi guys
We are implementing a way to export a model and filter some entities.
Now we have a question:
--
Andre Hora
stef and andre
--
Andre Hora
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:57 p.m.
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.
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 :( The next step would be to have the
MooseImportingContext work directly with Fame and use this filtering mechanism directly.
yes I know.
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.
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.
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
Cheers,
Doru
--
www.tudorgirba.com
"What we can governs what we wish."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Cheers,
Doru
On 15 Jul 2011, at 18:14, Andre Hora wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
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.
On Fri, Jul 15, 2011 at 6:12 PM, Andre Hora <andrehoraa(a)gmail.com> wrote:
Hi guys
We are implementing a way to export a model and filter some entities.
Now we have a question:
--
Andre Hora
stef and andre
--
Andre Hora
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"We cannot reach the flow of things unless we let go."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:04 p.m.
I think that your solution is cleaner so we will implement it or at least try.
Stef
4909
days inactive
4909
days old
6 comments
3 participants
participants (3)
-
Andre Hora -
Stéphane Ducasse -
Tudor Girba