Hi Predrag;
There is not currently an online demo of the framework just yet,
but the prototype application being built with it is designed to make
explaining complex ideas and processes as simple and as concise as possible,
and it will certainly contain tutorials on how the custom elements are
defined and generated.
When that demo is ready, I will post about it here and in the G+ group, as
well as pushing fresh jars to maven central.
I would set an ETA on that to mid-February; the demo project itself is
actually higher priority than the framework,
but that is a discussion for another thread.
As for Thomas' guess, he would be right that it is ....a bit on the complex
side internally,
though I am slimming it down to make each piece an independent, intelligent
unit that is easy to read and reason about.
The ultimate goal is that you can define an entire UI component in a single
file, and have that component run on any supported platform (currently GWT
and desktop; Android up next);
where some people like a minimum of magic bits, I like things to be as
declarative as possible, with all boilerplate generated (preferably before
GWT even starts).
My heuristic is "can I do something at build time so when I write
implementations, I am writing the minimum amount of code possible".
In most cases, the data model and the actual ui rendering is almost
everything; the actual wiring of elements, injecting css, managing shadow
dom, binding web components, etc is all generated.
The one Bad Part (tm) that I will admit to is that this currently relies on
a hacked GWT compiler (I maintain a fork of GWT);
I've been steadily reducing the amount of magic I need from that fork so I
can eventually deprecate it...
The primary use case being arbitrary magic method injection (making my own
GWT.create-like methods anywhere needed, like adding reflection support).
Instead of relying on whole-world knowledge from GWT to do that code
generation and method swapping,
I'm instead using javac plugins to do a "precompile phase" which generates
the necessary support classes, and swaps in the magic methods.
Since generators themselves appear to be on the way out, I was hoping to
offer something of a replacement for those who like generated
implementations;
if I find the time, someday, I might even expose the gwt.ext.typeinfo AST
classes, though I doubt it will ever actually become a priority, as I don't
really use Gwt generators anymore.
....Buuut, this is certainly a much lower priority goal; when J2CL is
closer to going public, and people start missing their generators, I will
likely polish it up and post about it then.
Because my javac generators run before the GWT compile, that means that,
provided it plays nicely with incremental javac, it will also play nicely
with incremental Gwtc.
By stripping all but standard compilation from GWT, it should become very
fast; the only (obvious) problem there is how to invalidate a java type
that depends on external resources...
Perhaps somebody here has some suggestions, but what I have been doing is
emitting a @Generated({ "/path/to/resource", "abcHASHofFILE", ... }),
containing all used source files,
and running a daemon process to monitor input files then forcibly recompile
any dependents when those inputs change (I use a development server that
runs javac or gwtc on demand).
It's a bit clunky, but it works.
Anyway,
I don't want to dangle something shiny and not deliver;
I'm hammering away at this demo every free minute,
but would be happy to discuss with anyone what features they think a good
UI Templating system should offer.
My reference for the UI templating part the project was actually ReactJs...
I liked JSX, but felt like it was too ...rigid and opinionated;
also, I don't like how React throws away DOM elements, which makes it hard
to integrate via standard HTML (yay custom elements / web components!).
The cross-platform aspect is due to the fact that my framework was born to
do cross-platform service injection,
and adding UI generation is a natural evolution of that effort.
Once I get this demo finished, I'll likely upgrade to Elemental 2
(currently using Elemental 1),
and some day, when it is released and I no longer need JSNI or GWT magic
methods, J2CL.
In the meanwhile, I'd love to hear what other developers would want in
terms of binding declarative UI to java classes.
My current implementation creates classes for UI templates, with references
to internal elements stored as fields (using the ref="name" attribute),
generates data models (which have generated CRUD endpoints), internal data
fields (with simple unary expression support; no binary, etc. yet),
and some rudimentary looping / conditional / compile time evaluation.
Adding compile time methods is as simple as defining java methods that take
either primitives or AST arguments,
so end users can add their own utilities without having to touch the more
complex services.
Sorry if this seems ranty; the demo site is an implementation of something
I call "structured markdown",
where I can embed tangential points [inside of a link]-> {
so you can read a concise summary of an idea before diving deeper into
subtopics that interest you.
}.
Part of the demo content is explaining the technology used in the site,
which will include examples of the framework, as well as the ability to
"view source" for any custom element (showing all generated java, css and
source .xapi files).
Most of the work for viewing / editing source borrowed from the CollIDE
project I took over when the Big G open sourced and ditched it.
Some might say I have too many irons in the fire... And they would probably
be right.
But, at least after a half decade or so, all the grand plans are (finally!)
coming to fruition. :-)
--
You received this message because you are subscribed to the Google Groups "GWT
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/8ca7c9fd-07c1-4792-977d-5714a8ec0f61%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
