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.
