[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [wtp-incubator-dev] EMF2DOMSSE
|
Konstantin Komissarchik wrote:
In the wrapper solution that I implemented, a wrapper object only holds a reference to a DOM Element. There is not other model state in the wrapper. When a getter is called, it reaches directly into the DOM Element. There are no events to process. The more complicated case is a when a model element has to retrieve sub-elements. The method first retrieves all candidate DOM elements. It then consults a map kept in the wrapper that maps DOM elements to wrapper instances. Existing wrappers are re-used. New wrappers are created as necessary. Old wrappers are disposed. This all happens in the getter call. The caller always gets the state as represented in DOM, but wrapped in model API.
It's a very similar concept, the method you describe works well, and is
an approach I typically recommend when any type of data binding needs to
do be done, and you have a good mapping from the DOM to the a data model
used in multipage editors that use forms. Where this starts to fall
apart is when you have to carry extra information that isn't in the DOM
or can't be represented there, but where changes in the DOM could affect
the positioning of text in the other model (i.e. offsets becoming
different and having to be tracked differently). There are indeed some
items I have in VEX where I can and will use the DOM directly as I don't
need to track anything differently. So I basically still have a wrapper
approach, it's just an enhanced wrapper that has to have some
notifications at certain points. It's limited notifications, but not
much I could have done, without reimplementing the whole DOM which was
more work than I needed.
Always interested in other ways that this can be implemented though, I'm
not stuck on a single way of doing it.
Dave
