Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-incubator-e4-dev] What I dislike about using EMF for e4...

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" <merks@xxxxxxxxxx>
To: "E4 developer list" <eclipse-incubator-e4-dev@xxxxxxxxxxx>
Cc: "E4 developer list" <eclipse-incubator-e4-dev@xxxxxxxxxxx>, eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
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/IBM@IBMCA 
mailto: merks@xxxxxxxxxx 
905-413-3265 (t/l 313) 



eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx 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/IBM@IBMCA 
> Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx 
> 04/24/08 10:20 AM 
> 
> Please respond to 
> E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx> 
> 
> [image removed] 
> To 
> 
> [image removed] 
> E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx> 
> 
> [image removed] 
> cc 
> 
> [image removed] 
> E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>, eclipse- 
> incubator-e4-dev-bounces@xxxxxxxxxxx 
> 
> [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/IBM@IBMCA 
> mailto: merks@xxxxxxxxxx 
> 905-413-3265 (t/l 313) 
> 
> 
> 
> eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx 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 
> > eclipse-incubator-e4-dev@xxxxxxxxxxx 
> > https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev 
> _______________________________________________ 
> eclipse-incubator-e4-dev mailing list 
> eclipse-incubator-e4-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev 
> [image removed] _______________________________________________ 
> eclipse-incubator-e4-dev mailing list 
> eclipse-incubator-e4-dev@xxxxxxxxxxx 
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev 

_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev


Back to the top