Web Components require using ES2015 class syntax, so you would need some trickery make them work from GWT (see https://github.com/webcomponents/custom-elements#es5-vs-es2015 or https://github.com/webcomponents/webcomponentsjs#custom-elements-es5-adapterjs) At least this is the theory…
On Friday, October 13, 2017 at 11:58:14 AM UTC+2, nikola wrote: > > Thanks for the link.. But I can't see what I was looking for.. > > Can someone please create and register custom web component using only > elemental 2. e.g that says "hello from shadow DOM!". > Cause I'm not able to do it or find working example .. at least without > losing whole week on it... > Thanks in advance > > On Thursday, October 12, 2017 at 4:04:16 PM UTC+2, harshyadav wrote: >> >> 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.
