| [RCP] Form-Based EditorPart for Working With Data Stored in a Database [message #268057] |
Fri, 20 August 2004 12:28  |
Eclipse User |
|
|
|
Originally posted by: evan_yap.mindspring.com
Hi All!
I'm seeking advice on a design approach. If you were tasked to
build the desired EditorPart, what would you do? Most Editor examples
I've seen use EditorInputs with PersistableElements that load
and save data into XML-based IMementos.
I'm thinking that if I were to stick to the
Editor-EditorInput-ElementFactory
design pattern, I would just ignore the Memento in my implementations
of the create and save Memento methods, and use my own "data-handlers".
I would probably pass some kind of a lazy-loading datahandler to my
EditorInput, and use the same datahandler to save data to the database.
What do you think? Do I have to stick to the
Editor-EditorInput-ElementFactory
Design Pattern in order to leverage existing support infrastructure for
Editors
within the Eclipse Platform, or can I deviate from it (I'm thinking I pretty
much have to stick with it, but also build from it to handle non-file-based
load and save scenarios, but maybe there are alternate routes I can take?)
Does my proposal sound OK? Are there issues I need to be aware of?
Thank you in advance for any constructive feedback, pointers,
or suggested readings.
|
|
|
| Re: [RCP] Form-Based EditorPart for Working With Data Stored in a Database [message #268875 is a reply to message #268057] |
Thu, 26 August 2004 12:37  |
| Eclipse User |
|
|
|
Originally posted by: nick_edgar._no.spam.please_.ca.ibm.com
Editors need an IEditorInput, which -refers- to the content. It doesn't
represent the actual content.
If you want to preserve the editor across sessions, the editor input must
implement IPersistableElement, and have a corresponding IElementFactory (and
its extension in the plugin.xml).
However, this typically doesn't persist the whole -contents- of the editor,
just enough data to recreate the input.
For example, FileEditorInput only saves the workspace file path.
If you're getting content from a database, then you'll want the editor input
to contain enough info to point at the appropriate object or entry in the
database, and persist that pointer, but not the data itself.
Nick
"Evan Chua-Yap" <evan_yap@mindspring.com> wrote in message
news:cg58lm$kgh$1@eclipse.org...
> Hi All!
>
> I'm seeking advice on a design approach. If you were tasked to
>
> build the desired EditorPart, what would you do? Most Editor examples
>
> I've seen use EditorInputs with PersistableElements that load
>
> and save data into XML-based IMementos.
>
>
>
> I'm thinking that if I were to stick to the
> Editor-EditorInput-ElementFactory
>
> design pattern, I would just ignore the Memento in my implementations
>
> of the create and save Memento methods, and use my own "data-handlers".
>
> I would probably pass some kind of a lazy-loading datahandler to my
>
> EditorInput, and use the same datahandler to save data to the database.
>
>
>
> What do you think? Do I have to stick to the
> Editor-EditorInput-ElementFactory
>
> Design Pattern in order to leverage existing support infrastructure for
> Editors
>
> within the Eclipse Platform, or can I deviate from it (I'm thinking I
pretty
>
> much have to stick with it, but also build from it to handle
non-file-based
>
> load and save scenarios, but maybe there are alternate routes I can take?)
>
> Does my proposal sound OK? Are there issues I need to be aware of?
>
>
>
> Thank you in advance for any constructive feedback, pointers,
>
> or suggested readings.
>
>
|
|
|
|
Powered by
FUDForum. Page generated in 0.03675 seconds
Home