Hey folks, +1 for Ed's arguments, DOM event model is not so easy (events bubbling, capture, etc). Please think about databinding (will e4 UI bind to DOM datasets?). Also many DOM implementations out there do not support (implement) DOM mutation events... So full support of the features required for DOM-based UI may take as much efforts as implementing EMF runtime from scratch. Also DOM-based stuff can't beat other arguments (which was mentioned earlier like performance and memory usage) without employing (byte)code generation technologies. And most important field where DOM sucks is no metamodel for your DOM elements available (at least at runtime)...
Finally, are communities intersted to "feel" like accessing DOM from JavaScript? Not a pleasant feeling sometimes :) Kind Regards, Andrey ----- Original Message ----- From: "Ed Merks" <[EMAIL PROTECTED]> To: "E4 developer list" <[email protected]> Cc: "E4 developer list" <[email protected]>, [EMAIL PROTECTED] Sent: Friday, April 25, 2008 12:23:51 AM GMT +06:00 Almaty, Novosibirsk Subject: Re: [eclipse-incubator-e4-dev] What I dislike about using EMF for e4... McQ, I'm definitely aware that EMF's core runtime likely contains some things that aren't needed in all cases. It's likely though that a good fraction of the Eclipse applications are using EMF already, based on the EclipseCon survey and the download stats on the Ganymede packages: http://phoenix.eclipse.org/packages/ I would also assert that that EObjects really do feel just like DOM. http://www.theserverside.com/tt/articles/article.tss?l=BindingXMLJava And I would argue strongly that DOM is not nealy as simple and folks like to believe. The amount of time I have to explain basic DOM things to people continues to surprise me. For example, the mysteries of xmlns prefix scoping seem to escape even people I assume to be experts. The listener model is far from trivial. So if being as good as DOM is our bar, it's a very low bar indeed, only slightly higher that the hash map bar. :-P Ed Merks/Toronto/[EMAIL PROTECTED] mailto: [EMAIL PROTECTED] 905-413-3265 (t/l 313) [EMAIL PROTECTED] wrote on 04/24/2008 11:14:16 AM: > Ed, > > You have seen us make these mistakes before. I get it. But you need > to at least consider the possibility that the full generality of > EMF, after years of it being applied to increasingly general > problems might not *always* be required. > > In any case, if we are going to talk about communities, shouldn't we > be trying to end up with something that "feels" like accessing the > browser DOM from JavaScript (+ listeners)? I'm certain that people > who understand *that* dwarf all Eclipse communities. > > McQ. > > > [image removed] Ed Merks---04/24/2008 10:28:19 AM---McQ, > > Ed Merks/Toronto/[EMAIL PROTECTED] > Sent by: [EMAIL PROTECTED] > 04/24/08 10:20 AM > > Please respond to > E4 developer list <[email protected]> > > [image removed] > To > > [image removed] > E4 developer list <[email protected]> > > [image removed] > cc > > [image removed] > E4 developer list <[email protected]>, eclipse- > [EMAIL PROTECTED] > > [image removed] > Subject > > [image removed] > Re: [eclipse-incubator-e4-dev] What I dislike about using EMF for e4... > > [image removed] > > [image removed] > > > McQ, > > Comments below. > > > Ed Merks/Toronto/[EMAIL PROTECTED] > mailto: [EMAIL PROTECTED] > 905-413-3265 (t/l 313) > > > > [EMAIL PROTECTED] wrote on 04/24/2008 09:40:11 AM: > > > Ed Merks wrote on 04/24/2008 08:16:43 AM: > > > Keep in mind that there is a very large modeling community > > > exploiting EMF models as well as providing services around them, so > > > in terms of growing a large e4 community, leveraging existing ones > > > seems like a good approach, at least on the surface. > > > > > Whoa! The decision to use *any* part of EMF *must* be based on it > > being the best technical solution. > > The presence of a large established community with a wide range of > useful services is a technical reason, though obviously a social one > as well. How important that one technical reason is weighed against > all the other important technical considerations is of course > subject to debate. Likewise and in fact more so for social issues. > But it is important to keep in mind that communities are made of > people and people, however much they like to think they are driven > purely by facts, are just as often driven by social considerations... > > > We're already having that > > technical discussion, which is great, so I don't think using the > > "Come on, all your friends are doing it" argument is a strong point. > > In my opinion a number of very weak points have been made, but I > find it not all that useful to tell someone their point is weak > because people don't tend to react well to that. So generally I try > to ignore the weak points or provide a counter points. > > > > > From my POV, having a separation between specifying the API that we > > *need* and using an underlying, more general mechanism that > > implements it is a no brainer. > > The question is defining what we really need and being sure those > needs will never grow or change. I've seen time and time again > people claiming not to need something only to discover later that > they do need it when they get farther along. This is how simple > things grow complex over time and how many different solutions to > the same problem will often tend to converge on something where the > two are only different superficially but not fundamentally. > > > > > The way to win the EMF argument is to define the API, then hold EMF > > up against it and say "See this is smaller, faster, better tooled, > > handles concurrency better, etc.". Honestly, how hard can it be to > > beat hashtables-of-strings? > > It seemed there was an explicit constraint put in place that EMF > APIs must not be surfaced. That's based on my reading of the statement: > > I also think that there should be -no- EMF classes/ifaces in the > modeling API (including the event notification). > > I agree with the approach you've just outlined, but I didn't get the > sense that a comparison followed by a choice was the approach being > proposed before your note. It may well be the best approach to > ensure that a non-EMF implementation can underly the model, but my > experience tells me that this is going down the path of defining yet > another metamodel so I'd like to see that decision made with a great > deal of careful consideration rather than as a no brainer... > > > > > > McQ._______________________________________________ > > 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 > [image removed] _______________________________________________ > 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 _______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
