Home » Eclipse Projects » Eclipse Platform » Saving in a multipage form editor
| Saving in a multipage form editor [message #296667] |
Thu, 29 December 2005 18:54  |
Eclipse User |
|
|
|
Originally posted by: eclipse.20.offby1.spamgourmet.com
So...
I want to save the contents of a form editor. Simple enough, I assume.
However, it seems I'm missing a few steps. Hopefully one of you kind
folks will assist?
What I have is a MultiPage editor with several form pages and one source
page (a lot like the MevenIDE POM editor, or the pre-3.0 plugin
editor... sorta).
When text is edited in an edit component, say... the ID of an element in
my data model, the editor is marked dirty. That much works just fine.
What I want to know is when should I commit the change in the editor to
the underlying model, and what is the difference between a dirty editor
(ie: there's a change in that text field that isn't in the source page,
for one) and a file that needs saving.
I also want to know what order of actions I should be undertaking, at
this point: doSave() should call... what, exactly, on the FormPage
subclasses that make up the rest of the editor?
Basically, I want a more or less complete tutorial on the lifestyles...
cycles... of the editor and page resource model. Anyone up for it?
Thanks, in advance.
--
Chris Rose
Not to be taken literally, internally, or seriously
|
|
|
| Re: Saving in a multipage form editor [message #296668 is a reply to message #296667] |
Thu, 29 December 2005 20:44  |
| Eclipse User |
|
|
|
Originally posted by: daniel.rohe.stud.tu-ilmenau.de
Chris Rose schrieb:
> So...
>
> I want to save the contents of a form editor. Simple enough, I assume.
> However, it seems I'm missing a few steps. Hopefully one of you kind
> folks will assist?
>
> What I have is a MultiPage editor with several form pages and one source
> page (a lot like the MevenIDE POM editor, or the pre-3.0 plugin
> editor... sorta).
>
> When text is edited in an edit component, say... the ID of an element in
> my data model, the editor is marked dirty. That much works just fine.
>
> What I want to know is when should I commit the change in the editor to
> the underlying model, and what is the difference between a dirty editor
> (ie: there's a change in that text field that isn't in the source page,
> for one) and a file that needs saving.
>
> I also want to know what order of actions I should be undertaking, at
> this point: doSave() should call... what, exactly, on the FormPage
> subclasses that make up the rest of the editor?
>
> Basically, I want a more or less complete tutorial on the lifestyles...
> cycles... of the editor and page resource model. Anyone up for it?
>
> Thanks, in advance.
I've written my thoughts about IFormPart under
http://daro.da.funpic.de/blog/?p=42 in German.
So here now a shortend version:
The form editor has two states normal and dirty. When you change
something in the form editor it should go to dirty and after doSave is
called or the change is undone it should go back to normal.
What should be done in doSave(): First commit any changes in the form
pages of your form editor, then if necessary let the source editor save
the document and/or save the document in the form editor.
for (Iterator iter = pages.iterator(); iter.next(); ) {
Object obj = iter.next();
if (obj instanceof IFormPage) {
((IFormPage) obj).doSave();
}
}
This code snippets commits any pending changes of the IFormParts. This
results in a call to commit() where you should apply the changes to the
model. A page change in the form editor also results in a call to
commit() and a call to refresh() for the new active page. So the refresh
method is a good point to update the state of the input fields in the
IFormPart.
The source page should always reflect the current state of the document.
This means every change should be commited to the document but not to
the file.
Kind regards,
Daniel
|
|
|
| Re: Saving in a multipage form editor [message #296677 is a reply to message #296668] |
Thu, 29 December 2005 23:54 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.20.offby1.spamgourmet.com
Daniel Rohe wrote:
> Chris Rose schrieb:
>> So...
>>
>> I want to save the contents of a form editor. Simple enough, I
>> assume. However, it seems I'm missing a few steps. Hopefully one of
>> you kind folks will assist?
>>
>> What I have is a MultiPage editor with several form pages and one
>> source page (a lot like the MevenIDE POM editor, or the pre-3.0 plugin
>> editor... sorta).
>>
>> When text is edited in an edit component, say... the ID of an element
>> in my data model, the editor is marked dirty. That much works just fine.
>>
>> What I want to know is when should I commit the change in the editor
>> to the underlying model, and what is the difference between a dirty
>> editor (ie: there's a change in that text field that isn't in the
>> source page, for one) and a file that needs saving.
>>
>> I also want to know what order of actions I should be undertaking, at
>> this point: doSave() should call... what, exactly, on the FormPage
>> subclasses that make up the rest of the editor?
>>
>> Basically, I want a more or less complete tutorial on the
>> lifestyles... cycles... of the editor and page resource model. Anyone
>> up for it?
>>
>> Thanks, in advance.
>
> I've written my thoughts about IFormPart under
> http://daro.da.funpic.de/blog/?p=42 in German.
>
> So here now a shortend version:
> The form editor has two states normal and dirty. When you change
> something in the form editor it should go to dirty and after doSave is
> called or the change is undone it should go back to normal.
>
> What should be done in doSave(): First commit any changes in the form
> pages of your form editor, then if necessary let the source editor save
> the document and/or save the document in the form editor.
>
> for (Iterator iter = pages.iterator(); iter.next(); ) {
> Object obj = iter.next();
> if (obj instanceof IFormPage) {
> ((IFormPage) obj).doSave();
> }
> }
>
> This code snippets commits any pending changes of the IFormParts. This
> results in a call to commit() where you should apply the changes to the
> model. A page change in the form editor also results in a call to
> commit() and a call to refresh() for the new active page. So the refresh
> method is a good point to update the state of the input fields in the
> IFormPart.
>
> The source page should always reflect the current state of the document.
> This means every change should be commited to the document but not to
> the file.
>
> Kind regards,
> Daniel
I think I get that, generally. What mechanism do I use to tell the
source editor that the document that backs it has changed? The problem
is, the XML file on disk is NOT the representation I'm editing -- I'm
using XmlBeans to generate objects to modify the XML, and the source
editor should just be displaying the textual representation of that
model. So... I'm not sure how to make it pick up changes in the text.
What I'm trying to do, in general, is two-way editing with the XMLBeans
tools. I'm beginning to think it may not be possible.
--
Chris Rose
Not to be taken literally, internally, or seriously
|
|
|
| Re: Saving in a multipage form editor [message #296687 is a reply to message #296677] |
Fri, 30 December 2005 07:40 |
| Eclipse User |
|
|
|
Originally posted by: daniel.rohe.stud.tu-ilmenau.de
Chris Rose schrieb:
> Daniel Rohe wrote:
>
>> Chris Rose schrieb:
>>
>>> So...
>>>
>>> I want to save the contents of a form editor. Simple enough, I
>>> assume. However, it seems I'm missing a few steps. Hopefully one of
>>> you kind folks will assist?
>>>
>>> What I have is a MultiPage editor with several form pages and one
>>> source page (a lot like the MevenIDE POM editor, or the pre-3.0
>>> plugin editor... sorta).
>>>
>>> When text is edited in an edit component, say... the ID of an element
>>> in my data model, the editor is marked dirty. That much works just
>>> fine.
>>>
>>> What I want to know is when should I commit the change in the editor
>>> to the underlying model, and what is the difference between a dirty
>>> editor (ie: there's a change in that text field that isn't in the
>>> source page, for one) and a file that needs saving.
>>>
>>> I also want to know what order of actions I should be undertaking, at
>>> this point: doSave() should call... what, exactly, on the FormPage
>>> subclasses that make up the rest of the editor?
>>>
>>> Basically, I want a more or less complete tutorial on the
>>> lifestyles... cycles... of the editor and page resource model.
>>> Anyone up for it?
>>>
>>> Thanks, in advance.
>>
>>
>> I've written my thoughts about IFormPart under
>> http://daro.da.funpic.de/blog/?p=42 in German.
>>
>> So here now a shortend version:
>> The form editor has two states normal and dirty. When you change
>> something in the form editor it should go to dirty and after doSave is
>> called or the change is undone it should go back to normal.
>>
>> What should be done in doSave(): First commit any changes in the form
>> pages of your form editor, then if necessary let the source editor
>> save the document and/or save the document in the form editor.
>>
>> for (Iterator iter = pages.iterator(); iter.next(); ) {
>> Object obj = iter.next();
>> if (obj instanceof IFormPage) {
>> ((IFormPage) obj).doSave();
>> }
>> }
>>
>> This code snippets commits any pending changes of the IFormParts. This
>> results in a call to commit() where you should apply the changes to
>> the model. A page change in the form editor also results in a call to
>> commit() and a call to refresh() for the new active page. So the
>> refresh method is a good point to update the state of the input fields
>> in the IFormPart.
>>
>> The source page should always reflect the current state of the
>> document. This means every change should be commited to the document
>> but not to the file.
>>
>> Kind regards,
>> Daniel
>
>
> I think I get that, generally. What mechanism do I use to tell the
> source editor that the document that backs it has changed? The problem
> is, the XML file on disk is NOT the representation I'm editing -- I'm
> using XmlBeans to generate objects to modify the XML, and the source
> editor should just be displaying the textual representation of that
> model. So... I'm not sure how to make it pick up changes in the text.
>
> What I'm trying to do, in general, is two-way editing with the XMLBeans
> tools. I'm beginning to think it may not be possible.
>
>
The simplest way is to call document.set(xmlString) with the current
text representation. In the form editor you should override
pageChange(int pageIndex). In this method serialize the XMLBean model to
a String and set the String as input of the source editor when the
source editor gets activated. When the user leaves the source editor
and it is dirty then retrieve the text and reload the XMLBean model.
Every IFormParts refresh() method in the active form page is called.
Here you should retrieve the model from the page or editor and set the
text in the input fields.
If you implement it this way, the doSave method of the form editor
should not call doSave on the source editor!
Kind regards,
Daniel
|
|
|
| Re: Saving in a multipage form editor [message #296688 is a reply to message #296687] |
Fri, 30 December 2005 07:51 |
| Eclipse User |
|
|
|
Originally posted by: eclipse.20.offby1.spamgourmet.com
Daniel Rohe wrote:
> Chris Rose schrieb:
>> Daniel Rohe wrote:
>>
>>> Chris Rose schrieb:
>>>
>>>> So...
>>>>
>>>> I want to save the contents of a form editor. Simple enough, I
>>>> assume. However, it seems I'm missing a few steps. Hopefully one
>>>> of you kind folks will assist?
>>>>
>>>> What I have is a MultiPage editor with several form pages and one
>>>> source page (a lot like the MevenIDE POM editor, or the pre-3.0
>>>> plugin editor... sorta).
>>>>
>>>> When text is edited in an edit component, say... the ID of an
>>>> element in my data model, the editor is marked dirty. That much
>>>> works just fine.
>>>>
>>>> What I want to know is when should I commit the change in the editor
>>>> to the underlying model, and what is the difference between a dirty
>>>> editor (ie: there's a change in that text field that isn't in the
>>>> source page, for one) and a file that needs saving.
>>>>
>>>> I also want to know what order of actions I should be undertaking,
>>>> at this point: doSave() should call... what, exactly, on the
>>>> FormPage subclasses that make up the rest of the editor?
>>>>
>>>> Basically, I want a more or less complete tutorial on the
>>>> lifestyles... cycles... of the editor and page resource model.
>>>> Anyone up for it?
>>>>
>>>> Thanks, in advance.
>>>
>>>
>>> I've written my thoughts about IFormPart under
>>> http://daro.da.funpic.de/blog/?p=42 in German.
>>>
>>> So here now a shortend version:
>>> The form editor has two states normal and dirty. When you change
>>> something in the form editor it should go to dirty and after doSave
>>> is called or the change is undone it should go back to normal.
>>>
>>> What should be done in doSave(): First commit any changes in the form
>>> pages of your form editor, then if necessary let the source editor
>>> save the document and/or save the document in the form editor.
>>>
>>> for (Iterator iter = pages.iterator(); iter.next(); ) {
>>> Object obj = iter.next();
>>> if (obj instanceof IFormPage) {
>>> ((IFormPage) obj).doSave();
>>> }
>>> }
>>>
>>> This code snippets commits any pending changes of the IFormParts.
>>> This results in a call to commit() where you should apply the changes
>>> to the model. A page change in the form editor also results in a call
>>> to commit() and a call to refresh() for the new active page. So the
>>> refresh method is a good point to update the state of the input
>>> fields in the IFormPart.
>>>
>>> The source page should always reflect the current state of the
>>> document. This means every change should be commited to the document
>>> but not to the file.
>>>
>>> Kind regards,
>>> Daniel
>>
>>
>> I think I get that, generally. What mechanism do I use to tell the
>> source editor that the document that backs it has changed? The problem
>> is, the XML file on disk is NOT the representation I'm editing -- I'm
>> using XmlBeans to generate objects to modify the XML, and the source
>> editor should just be displaying the textual representation of that
>> model. So... I'm not sure how to make it pick up changes in the text.
>>
>> What I'm trying to do, in general, is two-way editing with the XMLBeans
>> tools. I'm beginning to think it may not be possible.
>>
>>
>
> The simplest way is to call document.set(xmlString) with the current
> text representation. In the form editor you should override
> pageChange(int pageIndex). In this method serialize the XMLBean model to
> a String and set the String as input of the source editor when the
> source editor gets activated. When the user leaves the source editor
> and it is dirty then retrieve the text and reload the XMLBean model.
> Every IFormParts refresh() method in the active form page is called.
> Here you should retrieve the model from the page or editor and set the
> text in the input fields.
>
> If you implement it this way, the doSave method of the form editor
> should not call doSave on the source editor!
>
> Kind regards,
> Daniel
Daniel, thank you. That's bloody perfect.
I'll get that together ASAP, it should make my life MUCH easier.
--
Chris Rose
Not to be taken literally, internally, or seriously
|
|
|
| Re: Saving in a multipage form editor [message #306070 is a reply to message #296668] |
Wed, 19 July 2006 20:59 |
 Alex Le
Messages: 649
Registered: July 2009 |
Senior Member |
|
|
Daniel Rohe wrote:
> Chris Rose schrieb:
>
>> So...
>>
>> I want to save the contents of a form editor. Simple enough, I
>> assume. However, it seems I'm missing a few steps. Hopefully one of
>> you kind folks will assist?
>>
>> What I have is a MultiPage editor with several form pages and one
>> source page (a lot like the MevenIDE POM editor, or the pre-3.0 plugin
>> editor... sorta).
>>
>> When text is edited in an edit component, say... the ID of an element
>> in my data model, the editor is marked dirty. That much works just fine.
>>
>> What I want to know is when should I commit the change in the editor
>> to the underlying model, and what is the difference between a dirty
>> editor (ie: there's a change in that text field that isn't in the
>> source page, for one) and a file that needs saving.
>>
>> I also want to know what order of actions I should be undertaking, at
>> this point: doSave() should call... what, exactly, on the FormPage
>> subclasses that make up the rest of the editor?
>>
>> Basically, I want a more or less complete tutorial on the
>> lifestyles... cycles... of the editor and page resource model. Anyone
>> up for it?
>>
>> Thanks, in advance.
>
>
> I've written my thoughts about IFormPart under
> http://daro.da.funpic.de/blog/?p=42 in German.
>
> So here now a shortend version:
> The form editor has two states normal and dirty. When you change
> something in the form editor it should go to dirty and after doSave is
> called or the change is undone it should go back to normal.
>
> What should be done in doSave(): First commit any changes in the form
> pages of your form editor, then if necessary let the source editor save
> the document and/or save the document in the form editor.
>
> for (Iterator iter = pages.iterator(); iter.next(); ) {
> Object obj = iter.next();
> if (obj instanceof IFormPage) {
> ((IFormPage) obj).doSave();
> }
> }
>
> This code snippets commits any pending changes of the IFormParts. This
> results in a call to commit() where you should apply the changes to the
> model. A page change in the form editor also results in a call to
> commit() and a call to refresh() for the new active page. So the refresh
> method is a good point to update the state of the input fields in the
> IFormPart.
>
> The source page should always reflect the current state of the document.
> This means every change should be commited to the document but not to
> the file.
>
> Kind regards,
> Daniel
There is one more thing to do before your editor exits the doSave().
Call editor.editorDirtyStateChanged() to remove the '*' on the tab of
the editor page.
|
|
|
Goto Forum:
Current Time: Sat Apr 27 16:48:56 GMT 2024
Powered by FUDForum. Page generated in 0.03898 seconds |
] 
Search
Help
Register
Login
Home
