Re: [orion-dev] AMD + UI = Wrong Combination

[lamine <laminba2003@xxxxxxxx>]

Hi John

Yes, my mail was a good way for me to better understand your vision. And I can only say that you have really a huge ambition which is really a good thing. And to make it short, you want to be everywhere. And if I'm not wrong, Orion is not just a cloud environment for coding, building, and debugging any kind of apps but also a set of components that can be consumed by any application running in any web platform. And for that last goal to be attainable in the UI, the UI components must be designed to be generic and agnostic of the context and the environment in which they are running. Like mine and this argument is not applicable for all of them, they should only know how to interact with a Restful web service and how to post and get a JSON data to render it on the client-side using maybe a client-side templating system like Handlebars. Now the problem is how will you package your components to make them stand alone? How can you encapsulate their logic (component.js), their structure (component.html) and their style (component.css) if the client-side has not yet the concept of component?

If your editor did have a reference to Dojo, I will never be able to integrate it into my application and if you did not use AMD to make it modular, I will never be able to reuse the KeyBindings.js file. But one can truly ask if we should use everywhere and for everything?

Without my tiny runtime, no one can embed the Orion Editor into a JSF application. The resource handling system of JSF cannot serve an AMD module. You have first to turn it off and replace it by your own. And even if you succeed in doing that,  how will you give the content of the file to the editor? Using its awful programming model?


Best Regards
Lamine

________________________________
De : John Arthorne <John_Arthorne@xxxxxxxxxx>
À : lamine <laminba2003@xxxxxxxx>; Orion developer discussions <orion-dev@xxxxxxxxxxx>
Envoyé le : Jeudi 20 décembre 2012 21h26
Objet : Re: [orion-dev] AMD + UI = Wrong Combination


Hi Lamine,

To be clear I don't think the Orion
team thinks JavaEE has nothing to offer. Our primary server technology
right now is a Java EE server, and we are using OSGi modules to define
reusable component pieces for both the client and server. We will continue
to make sure Orion is consumable by Java EE servers. You are clearly consuming
Orion components using Java EE technology as well, and that is great.

However there is a large web community
that cares nothing about Java EE, and we want to enable those people to
consume Orion as well. For example there are large communities of people
building web apps using Rails, PHP, Python, ASP, etc, all of whom might
want to consume Orion pieces. Therefore we are committed to avoiding tying
Orion client technology to any particular server technology, be it Java,
node.js, or anything else for that matter. Doing both Java and node.js
server implementations helps to make sure we avoid those hard dependencies
in our client side code. However given that we want some form of modularity
in our client code, AMD is the only server-neutral _javascript_ modularity
story with any wide level of acceptance right now. Build-time techniques
could perhaps be used to translate those AMD modules into some other form
suitable for other kinds of web application deployments.  

John




From:      
 lamine <laminba2003@xxxxxxxx>
To:      
 "orion-dev@xxxxxxxxxxx"
<orion-dev@xxxxxxxxxxx>,  
Date:      
 12/20/2012 10:36 AM
Subject:    
   [orion-dev]
AMD + UI = Wrong Combination
Sent by:    
   orion-dev-bounces@xxxxxxxxxxx
________________________________




Hi,

For me, your only mistake is within the wrong argument that JavaEE has
nothing to offer to you and that the story of Eclipse in the Cloud cannot
be written within it. We are definitely the only community from which you
can expect a help and a lot of adoption, of course if you can target us
from what we know the most (abstractions). You should also know that we
are very reluctant to use _javascript_. If we don't even care about Project
Nashorn, how could we ever do it for Node.js?

1) http://en.wikipedia.org/wiki/Nashorn_(_javascript__engine)

I have learned what an AMD module does mean only when I had the requirement
to integrate your editor into my application. And it was really a big pain
and the answer of how to do it, did come to me only after having downloaded
the Scripted project. But now, for any JavaEE developer, this pain is over
since with just one tag in their web pages,

<c:fileEditor folder="myFolder"/>

they will be able to use the Orion editor, these lovely wysiwyg editors
below

2) http://www.jquery4u.com/plugins/html5-wysiwyg/

and even my new css3 gallery to view their images without a knowledge of
how things are working and without even writing a single line of html,
css, _javascript_.

3)http://youcontrol.lamine.cloudbees.net/faces/admin/editors/edit.xhtml?id=CSS3Gallery


A key player in this area is the one who
knows how to best embrace the existing communities by bringing innovation
without really innovating. And the concept of a "_javascript_ Library
independence" could be also a big mistake for you. At the very beginning
of my vision, I have chosen to put JQuery at the heart of my strategy since
its ecosystem of plugins and users is more larger than the universe itself..


Best Regards
Lamine_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev