838797 - Create a xul module

Status: RESOLVED WONTFIX

(Add-on SDK Graveyard :: General, defect, P4)

Description

[Erik Vold [:erikvold] (please needinfo? me)]

Tracker bug.

Comment 1

[Erik Vold [:erikvold] (please needinfo? me)]

This module should be a easy way to create xul elements which can be used as building blocks.

So the code would something like:

    const { XUL } = require('sdk/xul');
    let tb = XUL({windowtype: 'navigator:browser'}, 'toolbar');
    let tbb = XUL({windowtype: 'navigator:browser'}, 'toolbarbutton');
    tb.appendChild(tbb); // errors if match options do not match

with a helper require('sdk/xul/browser') which does the `{windowtype: 'navigator:browser'}` part automatically.

So the code can be:

    const { XUL } = require('sdk/xul/browser');
    let tb = XUL('toolbar', {id: 'some-tb-id'});
    let tbb = XUL('toolbarbutton', {id: 'some-tbb-id'});
    tb.appendChild(tbb);

Comment 2

[Matteo Ferretti [:zer0] [:matteo]]

Not sure I like that. Have you discussed with Irakli? We shouldn't encourage the usage of XUL, and write a module for that gives the wrong messages, TBH.

Comment 3

[Erik Vold [:erikvold] (please needinfo? me)]

(In reply to Matteo Ferretti [:matteo] [:zer0] from comment #2)
> Not sure I like that. Have you discussed with Irakli? We shouldn't encourage
> the usage of XUL, and write a module for that gives the wrong messages, TBH.

Well we need something, we can't have every UI module that we write basically re-inventing the wheel, we need to dry our code.

We don't have to promote the module, and it should be clear that it'll die with xul.

Comment 4

[Matteo Ferretti [:zer0] [:matteo]]

Not sure what wheel are you talking about? It's just using DOM API to create element with the proper namespace; I honestly don't think it's something crazy to do; especially I don't think a module is required for this task, that also change the way the web standard is supposed to work. But maybe I'm missing something, I'm just talking for the example you reported in the bug.

Personally I'm -1 about it, but I'd like to have also Irakli opinion. In any case I don't feel comfortable to have such thing as high level API ('sdk/xul'), should be low level; and I'd like to have some API alternatives.

More than a API to creates XUL elements, I'd like something that keep the "view" and the "model" in sync across the windows, and it's really doesn't matter if the "view" are XUL or HTML nodes or whatever. We already use some pattern in `panel` and I'm using similar one in the new UX work, we should probably have something that "standardize" and simplify that.

Comment 5

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Erik, could you please explain in further more details what are the issues this is supposed to fix ? My first impression is jQuery like DOM manipulations, and I don't think we really do that much of DOM to justify layer of abstraction.

Comment 6

[Erik Vold [:erikvold] (please needinfo? me)]

(In reply to Irakli Gozilalishvili [:irakli] [:gozala] [@gozala] from comment #5)
> Erik, could you please explain in further more details what are the issues
> this is supposed to fix ? My first impression is jQuery like DOM
> manipulations, and I don't think we really do that much of DOM to justify
> layer of abstraction.

the abstraction is not for the DOM, it's for handling elements on multiple windows as well as the unload event.

Comment 7

[Matteo Ferretti [:zer0] [:matteo]]

Erik, it seems from the code you wrote that the DOM is created behind the scene, in the module itself. I think we should avoid that and we should avoid having something XUL-specific. If your goal is handling elements on multiple windows, then we are on the same page, as I wrote in my previous comment:

> More than a API to creates XUL elements, I'd like something that keep the
> "view" and the "model" in sync across the windows, and it's really doesn't
> matter if the "view" are XUL or HTML nodes or whatever. We already use some
> pattern in `panel` and I'm using similar one in the new UX work, we should
> probably have something that "standardize" and simplify that.

But in that case both the subject of the bug and the code example you wrote are totally misleading.

We can think about a JEP for API to handle "views" across the windows, and keep them in sync with the "models". We have already this thing in panels and in the upcoming buttons, we can maybe standardize and simplify it.