My initial code contribution already had this feature [1] so this is a feature we are of course providing. It doesn't matter to us who is changing the EMF-DOM (JavaScript, ....).
1) Yes 2) ASAP I already worked on it Eric and Boris have an example code which does a minimal thing of this. The key here is EMF-Databinding / JFace-Databinding which bridges the gap. 3) This reaction on those changes is a topic Eric, Boris and me discussed but we are not ready with the Model yet so this doesn't make sense. My point of view was a complete MVC implementation whereas Eric wants to keep the Class count down. 4) Tom [1]http://tom-eclipse-dev.blogspot.com/2008/05/radical-approach-to-explore-new-paths.html Ed Merks schrieb: > Kevin, > > I recall some discussions involving Tom, Boris,and Eric about supporting > exactly this kind of live feedback based on changes to the model. It > makes the running application just like a WYSIWYG view of the model. > Tom argued that it's best to investigate this sooner rather than later > to ensure that all the necessary infrastructure is in place. > > > Kevin McGuire wrote: >> >> When showing the photo app demo in the two talks I did, one question >> that came up was (an obvious one), "Why do you need to keep restarting >> the RCP app after every model change?". >> >> I don't think we've discussed this aspect, but I assume that we >> eventually want to get to the point where model changes can be >> realized against the live app. This matches the web DOM approach where >> the way I change what is on screen is via DOM element >> creation/deletion. My understanding is that EMF can provide the >> change notification, its a matter of us listening and doing the >> appropriate element deletion and running the factories on the new >> nodes. >> >> Btw, a super cool demo would be to modify the structure of the live >> app via javascript, which you hacked live. >> >> Some questions: >> >> 1) Do we agree this is the behaviour we want? >> >> 2) When do we we think we'd provide it? >> >> 3) I think I can imagine with the current code base how we handle >> on-the-fly creation and deletion, but what about modification? Right >> now the factories 'make', they don't 'modify existing'. >> >> 4) Do we need batching? Does every model change result immediately in >> on-screen changes? I'm not sure how the web handles this; it doesn't >> seem to require explicit batching but the changes appear to come out >> as one change (might just be it all happens so fast it looks like one >> change). >> >> Because of the implications for (3), I think we'd like to do this work >> sooner rather than later. It would also help to tell the story of why >> the modelled UI is more interesting than just "I don't need this all >> in plugin.xml anymore". >> >> Regards, >> Kevin >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> eclipse-incubator-e4-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev >> > > ------------------------------------------------------------------------ > > _______________________________________________ > eclipse-incubator-e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev -- B e s t S o l u t i o n . a t EDV Systemhaus GmbH ------------------------------------------------------------------------ tom schindl leiter softwareentwicklung/CSO ------------------------------------------------------------------------ eduard-bodem-gasse 8/3 A-6020 innsbruck phone ++43 512 935834 _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
