Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integration with UI frameworks: packaging and classes #1

Closed
pioneer opened this issue Oct 19, 2014 · 3 comments
Closed

Integration with UI frameworks: packaging and classes #1

pioneer opened this issue Oct 19, 2014 · 3 comments

Comments

@pioneer
Copy link

pioneer commented Oct 19, 2014

Introduction.

There are several UI frameworks on JavaScript market, such as Dojo Toolkit, Ext JS, Qooxdoo, Google Closure Library. All of these listed products provide two important means, which are absent or have no estabilished standard in pure JavaScript: packages and classes. The purpose of this feature request is to add as seamless as possible configurable and pluggable integration of Grooscript with specific packaging and classes mechanisms present in a framework which is chosen for a project.

This will significantly help in writing large client applications using such a pleasant language as Groovy is, by reusing a lot of well-proven JavaScript code with huge amount of already implemented components and tooling.

Please note: I'm still a beginner in Groovy (mostly with 6 years of Python/JavaScript experience), so some of my suggestions can be naive.

Packages.

Problem: there are many packaging systems in JS world: AMD, NodeJS-style require, Ext.require, goog.require etc. Some of the languages which compile to JavaScript introduce their own packaging (GWT, Scala-JS, Dart) or force to use an existing one (CoffeeScript, ClojureScript). When using a compiler and UI framework which have different packaging systems, it's always tricky to do integration, combine both paradigms etc.

Suggested solution: configurable and pluggable packaging system for a compiler, so JS code can be easily imported and used within Groovy, as well as Groovy code within JS, using single selected packaging system, which is the most comfortable to use in given project.

Ideal implementation: import some.package.name.Class in Groovy code translates to require('...'), or Ext.require('...'), or AMD construct; package some.package.name translates to goog.provide("...") or whatever.

Possible implementation: maybe annotations, like @Grab.

Potential tricky things: AMD allows to "import" not only JS code, but also modules which should just be loaded (i.e. ensuring DOM is loaded), or even requiring an HTML template as if it's a module (AFAIK Groovy doesn't allow to do something like import dojo.text("./templates/SomeWidget.html") as template).

Classes.

Problem: in JS world, there are no classes, but OOP concept is still very usable thing. That's why many JS frameworks introduce their own OOP implementations, as well as some languages which compile to JavaScript, including Groovy. When using multiple implementations of objects and classes in one project, it may become very clumsy to deal with both styles (consider an example of creating a Dojo Toolkit/Ext JS/Qooxdoo widget completely in Groovy).

Solution: I don't really know what'll be the best way. Maybe a set of intermediate integration libraries, each for specific framework (i.e. Ext JS), which contain special Grooscript class (maybe classes?) with the following characteristics:

  • should be the wrapper for any existing JS class from the framework, allowing to reuse all the code from given class and all its parents, Groovy way
  • should be the base for any Groovy class intended to be used along with given JS framework
  • if used as a base for a component, written in Groovy, should be able to export itself to JS in given OOP style

Note: due to very different OOP implememtations, I doubt about an idea to replace Grooscript classes implementation with one from a JS framework, even in pluggable way, because of different logic behind Groovy's OOP and other OOPs. However, in ideal world it would be really beautiful to just import a JS class in Groovy or import some Groovy class in JS.


P.S. Maybe it's even worth to consider compiling Groovy to Java source, thus allowing GWT in Groovy?

@chiquitinxx
Copy link
Owner

Thank you very much, this is a very interesting improvement. I think this is related to grooscript, not the grails plugin, I think better you open this issue in grooscript. More people can participate there, if you are up to.

Anyway, I just use jquery or little libraries in my projects, not full UI frameworks. I need some code examples of what do you have in mind, what kind of groovy / js interactions.

For example in this code, I create a DSL in top of node / express. As you can see, some times I use @GsNative to put directly js code. I usually think in the groovy side, I create the logic of my application in groovy, tested in spock, and the execution of js code or js calls is hidden with @GsNative or in an easily mockable object. I have an interface and an implementation to work with jquery. Maybe can create common interfaces and distinct implementations. Also, I like bind dom elements to object properties and methods, then I can easy test the logic without the dom.

Totally agree that, if the application goes bigger, packages and classes have to be sorted in a correct way. Now, if I have a class com.test.MyClass, is just MyClass when you use it in javascript. It needs to be improved.

So, I need some days to take a look to other implementations, and thinking in a way to sort packages and classes.

No idea about gwt, ¿not working with groovy? I think convert from groovy to java, and then to js, not a good idea. Really, I need experiences of people using this UI's, what kind of problems they have, and how can we solve them with groovy.

@pioneer
Copy link
Author

pioneer commented Oct 20, 2014

Yes, it's my fault, I'll move this ticket to grooscript repository, along with code examples. As for compiling to Java source, it's mostly an idea of how to quickly solve the problem with packages and classes, rather than to keep the performance close to JavaScript, and it's not the best way, I think.

@pioneer
Copy link
Author

pioneer commented Oct 23, 2014

Closing here, as it more related to Grooscript itself, see chiquitinxx/grooscript#16

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants