Home » Modeling » EMF » Persisting to multiple destinations
| Persisting to multiple destinations [message #376692] |
Thu, 23 January 2003 18:07  |
Eclipse User |
|
|
|
I am working on an application which is going to be implemented as a
number of regional variants on a common codebase. The overall structure
of the application is defined in a set of XML files. The basic structure
of the application is the same for all regional variants - each variant
will add or remove some elements in the XML files, or provide a
different version of an element.
I have begun to model the structure of the XML using EMF, so that I can
edit them using an EMF generated editor (we'll get round to building our
own visual editor later). Each tag in the XML files will have a scope
attribute that indicates in which regional variants that tag exists.
Now, I had been thinking that I would just have one set of XML files
with all of the tags, and I would use ANT to build each regional
variants XML files, doing some filtering to ensure that only the
relevant tags get included in each variant's build.
However, it seems to me that it might be possible to do this directly
using EMF, if I can persist the same resource to multiple destinations.
If I had a different ResourceImpl for each variant, I could do the
filtering in the doSave() method. This would mean that there would be
one file for the core application model (which would be in the default
EMF serialisation format), and one file for each regional variant. The
model would be loaded only from the core file, but saved to that file
plus each of the variants.
Does this sound like a feasible idea? If so, how would I go about it?
Should my Resource implementation know about the multiple destinations,
or should it be implemented higher up, at the editor level. When I hit
control-S after editing the file, the core file and all of the variants
need to be updated (the variant files will exist at known locations in
the workspace) - so should this be one call to Resource.doSave() with
all the work done by the ResourceImpl, or several doSave calls on
ResourceImpls for each of the files?
TIA
--
Colin M Sharples/New Zealand/IBM, IT Architect, IBM Global Services
sharples@nz.ibm.com, t: 64-4-5769853, m: 64-21-402085, f: 64-4-5765616
"Sometimes I think the surest sign intelligent life exists
elsewhere in the Universe is that it's never tried to contact us"
|
|
|
| Re: Persisting to multiple destinations [message #376709 is a reply to message #376692] |
Tue, 28 January 2003 07:07  |
| Eclipse User |
|
|
|
Colin,
It seems that both approaches would be feasible. The choice seems to depend
too on what kind of "model" you want the user in the editor to see and what
kind of "model" you want client programmers to see. I.e., do you want the
core and variant files to be visible, or well hidden? By modeling all the
files explicitly, you will get more direct support from EMF with less hand
written code...
Colin Sharples wrote:
> I am working on an application which is going to be implemented as a
> number of regional variants on a common codebase. The overall structure
> of the application is defined in a set of XML files. The basic structure
> of the application is the same for all regional variants - each variant
> will add or remove some elements in the XML files, or provide a
> different version of an element.
>
> I have begun to model the structure of the XML using EMF, so that I can
> edit them using an EMF generated editor (we'll get round to building our
> own visual editor later). Each tag in the XML files will have a scope
> attribute that indicates in which regional variants that tag exists.
>
> Now, I had been thinking that I would just have one set of XML files
> with all of the tags, and I would use ANT to build each regional
> variants XML files, doing some filtering to ensure that only the
> relevant tags get included in each variant's build.
>
> However, it seems to me that it might be possible to do this directly
> using EMF, if I can persist the same resource to multiple destinations.
> If I had a different ResourceImpl for each variant, I could do the
> filtering in the doSave() method. This would mean that there would be
> one file for the core application model (which would be in the default
> EMF serialisation format), and one file for each regional variant. The
> model would be loaded only from the core file, but saved to that file
> plus each of the variants.
>
> Does this sound like a feasible idea? If so, how would I go about it?
> Should my Resource implementation know about the multiple destinations,
> or should it be implemented higher up, at the editor level. When I hit
> control-S after editing the file, the core file and all of the variants
> need to be updated (the variant files will exist at known locations in
> the workspace) - so should this be one call to Resource.doSave() with
> all the work done by the ResourceImpl, or several doSave calls on
> ResourceImpls for each of the files?
>
> TIA
>
> --
> Colin M Sharples/New Zealand/IBM, IT Architect, IBM Global Services
> sharples@nz.ibm.com, t: 64-4-5769853, m: 64-21-402085, f: 64-4-5765616
> "Sometimes I think the surest sign intelligent life exists
> elsewhere in the Universe is that it's never tried to contact us"
--
Ed Merks
|
|
|
| Re: Persisting to multiple destinations [message #376719 is a reply to message #376709] |
Tue, 28 January 2003 15:57 |
| Eclipse User |
|
|
|
Ed Merks wrote:
> It seems that both approaches would be feasible. The choice seems to depend
> too on what kind of "model" you want the user in the editor to see and what
> kind of "model" you want client programmers to see. I.e., do you want the
> core and variant files to be visible, or well hidden? By modeling all the
> files explicitly, you will get more direct support from EMF with less hand
> written code...
For the end user, or a programmer writing an editor for the model, it
should ideally appear as one single model in the editor. The actual XML
files will be stored somewhere else in the workspace, and so can be
inspected after they are generated. I'd rather keep all of the editing
on the EMF model, so that the XML files are regarded purely as generated
artefacts - changes in them will not be reflected back into the model,
and would be lost if the files are re-generated. This forces the
developers to make a conscious decision about the scope (i.e. core vs
regional variant) of every element - they can make a quick hack in the
generated XML files to test something, but to make their changes
permanent, they have to go to the model, and the model editor will
enforce the scope rules.
--
Colin M Sharples/New Zealand/IBM, IT Architect, IBM Global Services
sharples@nz.ibm.com, t: 64-4-5769853, m: 64-21-402085, f: 64-4-5765616
"Sometimes I think the surest sign intelligent life exists
elsewhere in the Universe is that it's never tried to contact us"
|
|
|
Goto Forum:
Current Time: Wed Nov 05 14:13:02 EST 2025
Powered by FUDForum. Page generated in 0.03482 seconds |
Home