Home » Modeling » EMF » Manipulating files with EMF
| Manipulating files with EMF [message #1194175] |
Mon, 18 November 2013 11:23  |
 Leonid Ripeynih
Messages: 150
Registered: February 2012 |
Senior Member |
|
|
Hello everybody!
This will be more of a design question.
Say, I have a model, representing some kind of linked files. Let it be serrializable in XML as follows:
<file name="other_file.txt" />
other_file.txt is not a EMF model, and attribute 'name' is just a EString (or some custom File data type).
The problem is - when attribute 'name' changes value, file should be renamed. To be more precise, persisted model should be consistent - i.e.' after user hits 'save'.
It's even more of a problem, since 'file' can be stored both in regular workspace and in CDO repository (as binary resource).
I have two possible solutions to this problem (and both looks quite scary and bug-prone):
1. Wrap each command in some kind of wrapper, which will perform operation on files in the moment of command execution. By files here I mean URI since they can easily be dispatched to some store-specific handlers. Question is - how to handle deletes and their undo's?
2. Wrap each command in some kind of wrapper, which will record the file (URI) operation with some kind of homebrew file operations framework, with commands like
Delete(URI what), Create(URI where, byte[] content), Move(URI from, URI to), and execute them after save (and flushing EMF Command Stack afterwards).
Both solutions have its cons (the only pro, is that they're probably solving the problem), and I'd like to know, which one is better (and, maybe, there is some better options), and, maybe, have something like this was already implemented, and where to look to find better solution?
Many thanks in advance.
|
|
|
| Re: Manipulating files with EMF [message #1194314 is a reply to message #1194175] |
Mon, 18 November 2013 12:52  |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Leonid,
Comments below.
On 18/11/2013 12:23 PM, Leonid Ripeynih wrote:
> Hello everybody!
>
> This will be more of a design question. Say, I have a model,
> representing some kind of linked files. Let it be serrializable in XML
> as follows:
>
>
> <file name="other_file.txt" />
>
>
> other_file.txt is not a EMF model, and attribute 'name' is just a
> EString (or some custom File data type).
>
> The problem is - when attribute 'name' changes value, file should be
> renamed.
Really, and what if you just wanted it to refer to a different file?
> To be more precise, persisted model should be consistent - i.e.' after
> user hits 'save'.
Do you save something to that file too? How do you populate this in the
first place?
>
> It's even more of a problem, since 'file' can be stored both in
> regular workspace and in CDO repository (as binary resource).
Then it seems you have a resource of some sort for it in CDO...
>
> I have two possible solutions to this problem (and both looks quite
> scary and bug-prone):
>
> 1. Wrap each command in some kind of wrapper, which will perform
> operation on files in the moment of command execution.
And what if the user closes the editor without saving?
> By files here I mean URI since they can easily be dispatched to some
> store-specific handlers. Question is - how to handle deletes and their
> undo's?
So is it really a name you have here or is it some specific object
you're referencing?
>
> 2. Wrap each command in some kind of wrapper, which will record the
> file (URI) operation with some kind of homebrew file operations
> framework, with commands like Delete(URI what), Create(URI where,
> byte[] content), Move(URI from, URI to), and execute them after save
> (and flushing EMF Command Stack afterwards).
> Both solutions have its cons (the only pro, is that they're probably
> solving the problem), and I'd like to know, which one is better (and,
> maybe, there is some better options), and, maybe, have something like
> this was already implemented, and where to look to find better solution?
Could you model your text resource so that it appears as an EMF resource
with a single root object containing the text or whatever, is in the
*.txt and then you have a reference to that root object. You'll end up
with "other_file.txt#/" as the reference to that. You can specialize
the resource implementation (for the non CDO case) for doSave/doLoad to
create that EObject and populate it's "contents" feature. Now you have
the separate problem of renaming a resource's URI (and whether renaming
is really moving in the non-CDO case).
>
> Many thanks in advance.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Manipulating files with EMF [message #1194346 is a reply to message #1194314] |
Mon, 18 November 2013 13:16 |
Leonid Ripeynih
Messages: 150
Registered: February 2012 |
Senior Member |
|
|
Ed, thanks for you reply!
Some comments:
Quote:Really, and what if you just wanted it to refer to a different file?
Quote:Do you save something to that file too? How do you populate this in the
first place?
Actually, this is never the case. It's not just a random file, it's generated following some special rules. File content itself is generated as well, and it's name can not be easly changed. File name is a kind if versioning schema for generated content.
Quote:Then it seems you have a resource of some sort for it in CDO...
Yeah, but it's a binary, non-emf resource. It's put there just for easy access and revision control.
[quote]And what if the user closes the editor without saving?[/quout]
Yeah, that's another flaw. We can record it and undo, but that just doesn't sound nice.
Quote:So is it really a name you have here or is it some specific object
you're referencing?
It looks something like this:
We have a model, with objects, containing some data. Based on the data in the attributes of an object we can generate file contentes and file name.
Basically: we derive name attribute and file contentes from other attrs/children. Then we should have a file with derived content and name (in sync).
When attributes changes, file contents (and name) should change too.
When object deleted, file should be deleted to.
And when the object of type created, file should be created (when object is filled with valid data)
Quote:
Could you model your text resource so that it appears as an EMF resource
with a single root object containing the text or whatever, is in the
*.txt and then you have a reference to that root object. You'll end up
with "other_file.txt#/" as the reference to that. You can specialize
the resource implementation (for the non CDO case) for doSave/doLoad to
create that EObject and populate it's "contents" feature. Now you have
the separate problem of renaming a resource's URI (and whether renaming
is really moving in the non-CDO case).
Hmm, quite a nice idea, i will think about it, thanks. Basically, there is only one problem with it, that what serrialization should look like is very restricting, so, i can not afford references which looks like other_file.txt#/. And other file format is actually very restricting too, so, resource customozation will be nessesary).
And I didn't see (yet) how it solves the problem of file creation / deletion.
|
|
|
| Re: Manipulating files with EMF [message #1194431 is a reply to message #1194346] |
Mon, 18 November 2013 14:02 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Leonid,
Comments below.
On 18/11/2013 2:16 PM, Leonid Ripeynih wrote:
> Ed, thanks for you reply!
> Some comments:
>
> Quote:
>> Really, and what if you just wanted it to refer to a different file?
>
> Quote:
>> Do you save something to that file too? How do you populate this in
>> the first place?
>
> Actually, this is never the case. It's not just a random file, it's
> generated following some special rules. File content itself is
> generated as well, and it's name can not be easly changed. File name
> is a kind if versioning schema for generated content.
>
> Quote:
>> Then it seems you have a resource of some sort for it in CDO...
>
> Yeah, but it's a binary, non-emf resource. It's put there just for
> easy access and revision control.
If it's a resource it can be an EMF resource. By specializing
ResourceImpl.doSave/doLoad you can read or write anything,even just a
binary blob...
>
> [quote]And what if the user closes the editor without saving?[/quout]
> Yeah, that's another flaw. We can record it and undo, but that just
> doesn't sound nice.
>
> Quote:
>> So is it really a name you have here or is it some specific object
>> you're referencing?
>
>
> It looks something like this:
> We have a model, with objects, containing some data. Based on the data
> in the attributes of an object we can generate file contentes and file
> name.
>
> Basically: we derive name attribute and file contentes from other
> attrs/children. Then we should have a file with derived content and
> name (in sync). When attributes changes, file contents (and name)
> should change too.
> When object deleted, file should be deleted to.
> And when the object of type created, file should be created (when
> object is filled with valid data)
>
> Quote:
>> Could you model your text resource so that it appears as an EMF
>> resource with a single root object containing the text or whatever,
>> is in the *.txt and then you have a reference to that root object.
>> You'll end up with "other_file.txt#/" as the reference to that. You
>> can specialize the resource implementation (for the non CDO case) for
>> doSave/doLoad to create that EObject and populate it's "contents"
>> feature. Now you have the separate problem of renaming a resource's
>> URI (and whether renaming is really moving in the non-CDO case).
>
> Hmm, quite a nice idea, i will think about it, thanks. Basically,
> there is only one problem with it, that what serrialization should
> look like is very restricting, so, i can not afford references which
> looks like other_file.txt#/.
You can always specialize things like
org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.getHREF(Resource,
EObject)/org.eclipse.emf.ecore.xmi.impl.XMLHelperImpl.resolve(URI, URI)
or play games with
org.eclipse.emf.ecore.xmi.XMLResource.OPTION_URI_HANDLER to strip/append
the fragment.
> And other file format is actually very restricting too, so, resource
> customozation will be nessesary).
> And I didn't see (yet) how it solves the problem of file creation /
> deletion.
If you know the URIs of the resources you had when the editor started,
you'll be able to detect that they're different when you save...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 12:58:48 GMT 2024
Powered by FUDForum. Page generated in 0.02921 seconds |
] 
Search
Help
Register
Login
Home
