You can try the GWT polymer (web components) wrapper: https://github.com/manolo/gwt-polymer-elements
Wither you can use built-in polymer components; or create your own (just look at the source code) Also take a look at: https://github.com/manolo/gwt-api-generator which auto generates GWT api for polymer elements, so no need to be out of Java world for most cases. On Thursday, October 12, 2017 at 7:08:05 AM UTC-4, nikola wrote: > > Ok, Thanks! I'll try with web components. As a java programer I'v been > trying to avoid digging too much in javascript but it's inevitable it seems > :) > > On Thursday, October 12, 2017 at 12:43:56 PM UTC+2, Thomas Broyer wrote: >> >> This is not how the DOM works I'm afraid. How would your proposed code >> would translate to JS? (feel free to use ES2015 classes for clarity) >> (btw, I really do think Web Components would solve your issues, as I see >> them) >> >> On Thursday, October 12, 2017 at 12:21:11 PM UTC+2, nikola wrote: >>> >>> >>> When I say "custom element" I mean: >>> >>> >>> *public class *CustomElement *implements *IsElement { >>> >>> >>> >>> *// private HandlerManager handlerManager; ? *List<String> >>> *someUserObject*; >>> >>> *//state object of CustomElement *HTMLElement *root *= Js.*cast* >>> (DomGlobal.*document*.createElement(*"div"*)); >>> >>> @Override >>> *public *HTMLElement asElement() { >>> *return **root*; >>> } >>> >>> *public static void *test() { >>> CustomElement customElement = *new *CustomElement(); >>> customElement.asElement().addEventListener(*"click"*, evt -> { >>> >>> //evt.target is not CustomElement so we can't access e.g >>> *someUserObject * >>> >>> >>> * //We can map DOM events to custom events fired through >>> HandlerManager with source field set to CustomElement (double work.. ) >>> *}); >>> } >>> >>> *// *} >>> >>> >>> Also when working with custom elements constructed as above *we need >>> some discipline to remove objects both logically and from DOM (as you said >>> we need to keep them in sync).. * >>> >>> *We are coming to something that looks like a Panel* >>> >>> >>> *class *Panel *implements *IsElement { >>> >>> List<IsElement> *componentList*; >>> >>> HTMLElement *root*; >>> >>> @Override >>> *public *HTMLElement asElement() { >>> *return **root*; >>> } >>> >>> *public void *add(IsElement component) { >>> >>> >>> *// add to componentList // add to DOM *} >>> >>> *public void *remove(IsElement component) { >>> >>> >>> *//remove from componentList //remove from DOM *} >>> } >>> >>> >>> So it would be good to have something like this : >>> >>> >>> *public abstract class *CustomElementComposite *extends *HTMLElement >>> *implements >>> *IsElement { >>> >>> List<String> *someUserObject*; >>> >>> *protected void *initComposite(HTMLElement element) { >>> >>> *//If we could encapsulate element to become actually >>> CustomElementComposite like Widget Composite *} >>> >>> @Override >>> *public *HTMLElement asElement() { >>> *return this*; >>> } >>> >>> *public static void *test() { >>> CustomElementComposite element = *new *CustomElementComposite() >>> {}; >>> >>> element.addEventListener(*"click"*, evt -> { >>> >>> *// evt.target is CustomElementComposite *}); >>> >>> >>> *// we don't need any additional mapping for adding and removing >>> *HTMLElement parent = Js.*cast*(DomGlobal.*document*.createElement( >>> *"div"*)); >>> parent.appendChild(element); >>> parent.removeChild(element); >>> } >>> } >>> >>> This way we are adding events directly and there is no additional >>> synchronization with DOM when adding and removing components. >>> >>> I must inspect but I'm not sure if Web Component can solve this (in the >>> way widget's composite did).. I'd rather have web component as a option. >>> >>> >>> >>> >>> On Thursday, October 12, 2017 at 10:48:05 AM UTC+2, Thomas Broyer wrote: >>>> >>>> >>>> >>>> On Wednesday, October 11, 2017 at 4:12:14 PM UTC+2, nikola wrote: >>>>> >>>>> >>>>> Users would expect to have events with source from where event was >>>>> fired. That was source field in GWT events. In your implementation we >>>>> will >>>>> need to intercept DOM event and fire new event with source field of >>>>> custom >>>>> element. (e.g re-fire through EventHandler). This is kind of double work. >>>>> >>>>> Another thing that we need to care about is if add and then remove >>>>> some custom element from DOM like >>>>> *element.removeChild(customElement.asElement()) *we also need to >>>>> remove reference to custom element to be garbage collected? Since only >>>>> *asElement() *is removed from DOM not custom element object itself. >>>>> If I'm right... >>>>> >>>>> This is why it would be good if custom element can extends Element >>>>> and wrap inner element like Widget Composite. >>>>> >>>> >>>> I'm really not clear about what you want to do, and what you actually >>>> mean by "custom element". >>>> Do you mean Web Components? In this case, they'd have to extend >>>> HTMLElement and, at least with elemental2-dom 1.0.0-beta-1, set the >>>> connectedCallback, attachedCalback, etc. Encapsulation is then provided by >>>> the shadow DOM. >>>> Or do you mean "kind of widgets, that just happen to map one-to-one >>>> with a DOM element and its subtree"? In this case, you're indeed >>>> *wrapping* >>>> an element, and that means you're going to have parallel hierarchies or >>>> such widgets/components on one hand, and DOM elements on the other hand, >>>> and will need to maintain both in sync (this is what GWT Widgets do, and I >>>> believe more or less how React works too). >>>> >>> -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
