Proposal: Declarative Markup for JxLib Interfaces

[Jon Bomgardner]

Lately I've been thinking a lot about how we can make things a bit easier to get started with JxLib. One of the ideas I had was to allow people to markup interfaces using a declarative syntax. The two major versions would be to use XML and HTML custom data attributes (JSON would also be a possibility). So, what might this look like? Let's take a simple example...

In the examples we have an integrated, split dialog example. The code for that example is shown here:

var toolbar = new Jx.Toolbar().add(
    new Jx.Button({
    label:'b1'
    }),
    new Jx.Button({
    label:'b2'
    })
);

dialog3 = new Jx.Dialog({
    label: 'dialog with splitter',
    modal: false,
    width: 600,
    height: 400,
    toolbars: [toolbar],
    resize: true
});

var splitter = new Jx.Splitter(dialog3.content, {
    elements:['d3left','d3right']
});

var tabBox = new Jx.TabBox({parent: splitter.elements[0]}).add(
    new Jx.Tab({
    label: 'Tab 1',
    content: 'tab3'
    }),
    new Jx.Tab({
    label: 'Tab 2',
    content: 'tab4'
    })
);


I left off the button for launching the dialog. Using XML we could mark this up like so:

<dialog label="dialog with splitter" modal="false" width="600" height="400" resize="true" layout="splitter" id="splitterDialogExample">
  <toolbar>
    <button label="b1"/>
    <button label="b2" />
  </toolbar>
  <splitterElement index="0">
    <tabBox>
      <tab label="Tab 1">
    <content>
      <h3>Tab 1 Content</h3>
      <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. </p>
    </content>
      </tab>
      <tab label="Tab 2">
    <content>
      <h3>Tab 2 Contnet</h3>
      <p>Consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. </p>
    </content>
      </tab>
    </tabBox>
  </splitterElement>
  <splitterElement index="1">
    <content>
      <h3>Right Content</h3>
      <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>
    </content>
  </splitterElement>
</dialog>
     

I'm not 100% satisfied with the "content" elements above but I couldn't think of a better way to do it. We could also do this with HTML data attributes similar to this:

<div data-widget="dialog"
     data-dialog-options="{modal: false; width: 600; height: 400; resize: true}"
     data-dialog-id="splitterDialogExample"
     data-dialog-layout="splitter">
  <div data-widget="toolbar">
    <div data-widget="button" data-button-label="b1" />
    <div data-widget="button" data-button-label="b2" />
  </div>
  <div data-splitter-element="0">
    <div data-widget="tabBox">
      <div data-widget="tab" data-tab-label="Tab 1">
    <h3>Tab 1 Content</h3>
    <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. </p>
      </div>
      <div data-widget="tab" data-tab-label="Tab 2">
    <h3>Tab 2 Contnet</h3>
    <p>Consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. </p>
      </div>
    </div>
  </div>
  <div data-splitter-element="1">
    <h3>Right Content</h3>
    <p>Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>
  </div>
</div>

<div data-widget="button" data-button-label="Split Dialog" data-button-id="dialogButton" data-button-parent="splitterButton" />

Those of you familiar with Aaron Newton's Behaviour library will find this second example familiar. The only thing really different is that his library won't do nested widgets.

Now, how would these get translated into JxLib classes and be wired together, you ask? What I suggest is that we create a singleton class called Jx.Factory (or something similar). This class would be responsible for taking the XML or HTML and parse it and figure out which classes would be instantiated. Those classes would then be kept in a central store from which they could be retrieved by id (so you would want to be sure to give the main classes an id). Perhaps something like this:

window.addEvent('domReady',function(){
  Jx.Factory.parse(); //defaults to parsing the body of the document. For XML, perhaps we pass in the name of the XML file or a string of XML
  //assuming on of the items parsed was the button that launches the dialog...
  Jx.Factory.get('dialogButton').addEvent('click', function(){
    Jx.Factory.get('splitterDialogExample').open();
  });
});

and the HTML, besides the code from above, would have the div to contain the button:

<body>
<!-- widget code goes here -->
<div id="splitterButton"/>
</body>

Any widget markup would get removed from the document completely. And anything with a "parent" attribute would get added to that widget/DOM element with the appropriate id. That would allow you to load fragments from the server, parse it, and have it show up where it belongs.

Now, keep in mind that this was a first, very rough, draft of an idea. There are MANY things that would need to be figured out but I wanted to get something out to see what everyone thought. If most people don't think this would be worth it then we may not pursue it (though I may do so as a separate project as I believe this could have some merit at least for some projects I'm working on).

Also keep in mind that none of this currently works in any shape or form.

[netSQL]

(I know I'm new to jxLib but I did .as for 6 years.)
Please don't do that.

The beauty of jxLib is that you don't do mark up. You can even use an
IDE context sensitive javascript (w/ WebStorm).

Here's my example, in .as you can write Flex w/ MX-Spark mark up. This
generates such poor code and does not help people fix it (
http://blog.expensify.com/2011/03/25/ceo-friday-why-we-dont-hire-net-programmers/
)
If it's targeted at noobs, only noobs will use it. (a nice version).

I think please move in the other direction, help people lear more .js
so they can write it.

There are so many DOM and mark up approaches, and only jxLib is .js.

Vic

[Jon Bomgardner]

Vic,

 

First, thanks for the comments.

 

Keep in mind that I have no intention of changing the way things work at a fundamental level. If you like writing everything out in JS then go for it - that will never change. The need to write some JS is never going to go away. All this proposal is looking to do is to reduce the amount of JS needed to get going. I also have a specific use case in mind that involves a server side system I'm writing. In that scenario I would like the ability to remove parts of the interface depending on security permissions. This would be a lot easier to do if I can just use a templating language to remove those parts under certain conditions.

 

As I said before, if the majority of people don't want to move in this direction then I'm fine with that.

 

What do others think?

 

Jon

[Scott Elcomb]

On Fri, Sep 2, 2011 at 2:41 PM, Jon Bomgardner <jo...@comcast.net> wrote:
> What do others think?

+1 here, particularly in the second form (using data- attributes).

I've never worked with directly with Behaviour but have been learning
jQuery Mobile for a project at work. Definitely prefer it over
tangled solutions and possibly even over pure-javascript.

Cheers,
--
  Scott Elcomb
  @psema4 on Twitter / Identi.ca

  Atomic OS: Self Contained Microsystems
  http://code.google.com/p/atomos/

  Member of the Pirate Party of Canada
  http://www.pirateparty.ca/

[aek]

This is something like what spring-js does. What I saw in spring-js is
for Dojo, but in theory is a lightweight abstraction over common
JavaScript toolkits. I don't study spring-js inside, I only scratch
the surface of the whole stuffs that provide the new version of the
Spring Web Flow project that contains Spring Web Flow(the one I know),
Spring Faces and Spring JavaScript. Spring JavaScript provides
Spring.js file that can be adapted to the needs of JxLib.
I think that the old fashion way of JxLib could be keep it without
merge acting as a subproject for those who want something like that.

[Lee Goddard]

+1 fwiw

--
You received this message because you are subscribed to the Google Groups "JxLib" group.
To post to this group, send email to jx...@googlegroups.com.
To unsubscribe from this group, send email to jxlib+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jxlib?hl=en.

[aek]

what is the meaning of:
+1 fwiw

On Sep 5, 9:46 am, Lee Goddard <lee...@gmail.com> wrote:
> +1 fwiw
>

[Lee Goddard]

Abbreviated token of agreement with your post: please add my vote, should a vote take place. I think you made the case well, and so I have nothing else to add.

[Paul Spencer]

fwiw = for what its worth

Jon,

I have a couple of comments.

First, I'm not opposed to doing this at all.  I think it is a good idea to have as an option for building an interface, and works well in a lot of scenarios.  My personal preference would be to have something in JSON format as opposed to  *TML, but the data-<name> version also appeals to me.

Second, I think the HTML version's mechanism for handling content is pretty straight-forward.  I would add a data-content="[id|url]" option to the main tag so that you don't have to inline content.

Third, it might be quite fun to add event binding to the factory-created widgets via ids ...

<div id="addItem" data-widget="button" data-label="Add Item" />

and

Jx.Factory.parse({

  addItem: {

    onClick: function() { alert('Adding Item') }

  }

});

Third, I believe that we need to make sure that we think through the data-<name> things quite carefully so we don't end up with data-button-label and data-tab-label but rather data-label

Finally, Fred and I have been discussing an overhaul of the theme system.  There may be some interesting synergies with your proposal.  As a minimum, we could have a data-template="<template name>" option and a way of declaring named templates somewhere for overriding the default styles.  Ultimately I think we would look to produce a single theme file that is basically a set of named templates.

Cheers

Paul

[Conrad Barthelmes]

Hi all,

Jon, I like your idea with declarative markup, also the xml version because it looks very clean. this could also be adapted to a JSON parser Paul mentioned. 

I am also thinking about this for some time as this would make it possible to dynamically create content from ajax calls without the need of loading javascript 

Anyways, we should have a straight-forward, clean and extensible markup for that, which already looks great in Jon's xml scribble. So maybe the html data-attribute schema should inherit from the xml schema.. (and a JSON one should too)

2 more questions to this:

- does it make sense to abstract the data attribute with a jx prefix? <div data-jx-widget="dialog" data-jx-label="my Dialog"></div> ? 

- what about putting the data-information into 1 attribute, which would go very much into the JSON direction ? <div data-jx"{widget: "dialog", label:"my Dialog", options: { height: 400, width: 600, resizeable: false }"></div> 

Thanks,

Conrad

[Jon Bomgardner]

So, here are some of my most recent thoughts on this....

This is a pretty complex topic and includes several intersecting ideas:

• The declarative markup proposal
• A rewrite of the Theme system
• A change in how we lay out components with Jx.Container and the use of layout managers

All three of these ideas intersect which is both interesting and daunting all at the same time. However, I think all of them are great ideas that will drive the library forward. So, excuse me if I ramble on a bit here but I have quite a bit to say it seems...

First, I think the crux of the declarative proposal actually hinges in part on the Jx.Container and layout managers stuff. To recap for those who weren't following Paul and my conversation on the Jx.Container pull request (https://github.com/JxLib/JxLib/pull/32) the thought here is to provide a container that would have a layout manager applied that can accept an array of items (widgets) which could be created from JSON and subsequently laid out in some arrangement by the layout manager. The layout manager itself would come in several varieties such as:

• Jx.LayoutManager.Fill - lays out a single widget to fill the conatiner
• Jx.LayoutManager.Anchored - Basically this is the original Jx.Layout but setup as a manager.
• Jx.LayoutManager.Split - Uses the Splitter to create and manage layouts
• Jx.LayoutManager.Columns - a manager that creates columns for placing widgets in
• Jx.LayoutManager.Grid - a manager that works similar to Blueprint or some other CSS grid framework
• Jx.LayoutManager.Region - a manager that creates default "regions" (such as north, south, east, west, center) each with a specific layout manager itself. Items can be added to the different regions by specifying the region and the appropriate layout options for that region. (The name is not that great I know but is the best I could think of)
  

And those are just some of the ones I've thought of. The thing I see here is that Jx.Container can work in a nested fashion by allowing Jx.Container to contain other Containers.

So, this would provide us with a JSON form of markup to create entire layouts without any declarative markup at all. Where this intersects with the original proposal in this thread is that I now see Jx.Factory (or something similar) taking the declarative markup and turning it into a JSON object that would be fed into Jx.Container. I also can see that Paul's idea of including events in the parsing could work very well by adding those events into the JSON object that is passed to Jx.Container.

And a rewrite of the theme system, though not entirely defined, could have an impact here as well as noted in Paul's post above.

I really think all three of these are pretty important and obviously not going to make it into the next release if we stick to the current schedule (which releases in November by the way). I've already begun work on the Jx.Container and layout stuff in my personal fork. When I get something usable in I'll let you all know. As for the rest, how do we think we should tackle this? I think the majority of people are most favourable to the data-* style of markup so I think we should start there. And if Fred and/or Paul can give us an idea of what they're thinking by way of the theme system changes that would be excellent.

I hope I didn't ramble on to much and I hope most of this makes sense to everyone.

Jon

[Jon Bomgardner]

Paul and Fred,

I know it's been quite a while since this was posted but I was wondering if you've given any more thought to the theme system changes you were talking about above?

Jon

[Paul Spencer]

Hi Jon,

we did talk about it several times but I don't think we came to any practical solution yet :)  Since then I've done some more thinking on it.  I am currently looking at Google's Closure Templates (http://code.google.com/closure/templates/), either to use directly or as a model for how we might do it.  I like that templates can be compiled and you call the function with a data blob that automatically fills in the template.  What is missing is any direct relationship to the styles required to make the templates visually correct.

I don't think we will have anything for 3.1 for sure.

Paul

--
You received this message because you are subscribed to the Google Groups "JxLib" group.

To view this discussion on the web visit https://groups.google.com/d/msg/jxlib/-/Gbc-i9oRyE0J.

[Jon Bomgardner]

Paul,

 

I honestly didn't think you'd be able to have anything for 3.1 so that's ok. My only issue with Closure Templates is that they require a Java app to compile them. If there was a compile step in javascript I'd personnally be much happier. I think having to use the java app to compile them may be an issue for anyone wanting to write their own components. Granted, I'v eonly had a very quick look at them and haven't really worked with them so this may just be my bias showing through.....

 

 

Jon

[Paul Spencer]

I was at a javascript meetup last night and learned a ton of stuff about templating.  Here are some of the main libraries that came up in the discussions.

http://www.handlebarsjs.com/

https://github.com/raycmorgan/Mu

http://knockoutjs.com/

http://angularjs.org/#/

https://github.com/hij1nx/weld

Each I think needs to be investigated and evaluated against our needs.  Some quick thoughts though ...

The one that really interested me conceptually was knockoutjs.  It has a very interesting way of binding data to a UI and reflecting changes bidirectionally.  This would probably require a complete overhaul of how we deal with the UI but it might be fantastic in the end.

Handlebars is also very interesting in that templates can be pre-compiled (using node) into js files that can be loaded in the browser and require only a very small runtime library so the overhead would be minimal in terms of library size.

Cheers

Paul

--
You received this message because you are subscribed to the Google Groups "JxLib" group.

To view this discussion on the web visit https://groups.google.com/d/msg/jxlib/-/I79z9W4DqUoJ.

[Jon Bomgardner]

Paul,

 

So I spent some time reading up on the options you listed and here are my initial reactions/thoughts:

 

1) Knockout - I like the concepts here as well and you're right, this would require a pretty large overhaul. My only concern is that the default templating system it comes with is jQuery based. That could be a problem though it seems that we could use a different templating language. Overall, this library seems to be doing more than just templating in al of the data-binding and event control that it does. I think that in addition to having to write a templateEngine subclass to use we would almost need to rewrite a lot of the event controls and other parts. Though I think this would be a major overhaul I agree that it could prove to be interesting in the end.

 

2) Handlebars sounds like a compelling choice as well. I like the thought of being able to precompile the templates using node as we could just add it to the current build process.

 

3) Mu - this doesn't appear to work in the browser.

 

4) angular - Very similar to knockout but provides even more stuff with it's own services and would probably require an even bigger overhaul than Knockout.

 

5) Weld - I like this one because it uses ids, classes, and names to map data to DOM nodes.

 

I'd also suggest we look at this one as well:

 

https://github.com/darkwing/Templated

 

This one is a mootools implementation similar to the dojo widget system. It provides a way to not only add data to a template but to attach events and map dom elements to class properties. I honestly think a version of this one may be the best way to go. My only problem with this one is I think the data-widget-* syntax ia a bit verbose and could be simplified and we would need to make it "Theme-aware" as it has the ability to download templates on demand.

 

Well, that's my 2 cents..... what do you think?

 

Jon

[Paul Spencer]

I slept on this and I'm starting to think that these are all solutions without a problem (at least in our domain) :)  For all intents and purposes, we already have a templating system that works - we could replace or enhance it based on what we see in some of these projects but that isn't really the problem we are trying to solve.  So what is the problem?  

The physical structure (HTML) of a widget is hard-coded in the widget and matches the structure that the built-in themes (delicious and crispin) expect. 

The solution we are looking for is a theme system where the templates can be extracted from the code and associated with the styles that make up the theme.   Some characteristics of the ideal theme system:

* run-time loading of a theme

* ability to change themes while running an application

* simple for web designers to develop themes or theme components

* easily overridable theme components, i.e. a new style of button

I think we will need a new singleton object, perhaps Jx.ThemeManager that will be the quarterback for all the theming stuff.  We'll need a new set of events (themechanged etc) and apis at the widget level and remove most of the theming stuff from the actual widgets.  One part of the existing templating that we may want to revisit is how the widget attaches to its UI once it is created.

I think that on the structure side, a theme could really simply be an HTML file - that follows specific conventions using class names, ids, data attributes etc - to provide the template snippets required for each widget.  I am wondering if we can load that HTML file in a hidden iframe and extract all the templates and grab a reference to the stylesheet associated with that template.  When the ThemeManager activates a theme, it could inject the appropriate stylesheet reference and fire an event to tell all existing widgets to rebuild their UI and new widgets would request specific templates from the ThemeManager.

Using an HTML file to capture the theme has the advantage that a web designer could develop it independently of the code and get the visual aspect of each template worked out.  I think this is something that Fred would love to have :)

Comments, discussion?

Cheers

Paul

--
You received this message because you are subscribed to the Google Groups "JxLib" group.

To view this discussion on the web visit https://groups.google.com/d/msg/jxlib/-/Zd4HflQelb4J.

[aek]

I think that some of this changes may complicate a little the theme system that it's working right now. The idea of having separated the html structure from the code is good for the process of develop a new widget, but that is not way the widgets get done?.

The different from the actual template system and https://github.com/darkwing/Templated I think that is in event attach to the dom and this can be added to the current.

I propose another way to manage the themes and events related to display and change of the theme selected by the user.

steps:

1- Change the css rules names of the themes to have a prefix or suffix with the name of the theme.

2- Singleton object Jx.ThemeManager knows what is the current theme and how to scan the page to change the classname of the dom elements that are jxlib based in the page from the last theme to the next reacting to the event themeChange that contains the new theme name. The change of the classname only involve the substitution of the theme prefix or suffix. Jx.ThemeManager could know how to load another themes by a given name from the server.

3- When a widget want to get render, pass the template to the Jx.ThemeManager to get the current theme applied to the template having the possibility of passing a dom object too for scan and theme apply.

Another important feature that can be developed once the theme system get established is a Theme designer like the jquery ui one(Theme Roller).

[Paul Spencer]

I think this assumes the current structure in which widget is in control of its DOM structure and the theme is just css.  The theme developer has to know the structure of the widget in order to style it.  If the structure is insufficient to obtain the style required then it becomes very difficult to create a drop-in theme as a replacement for the built-in themes.  For specific overrides, its always possible to subclass or provide an alternate template when creating a widget right now, but it is not possible to provide a drop-in replacement for crispin/delicious that needs a fundamentally different DOM structure to any widget.

Buttons are the most obvious example of this.  Right now we have a fairly heavy DOM structure for buttons to accommodate the CSS sliding doors technique used to allow the buttons to stretch horizontally.  They do not stretch vertically and there is no easy way to do things like put the image in a different place in relation to the text in the button.  Lets say you want to create an entirely CSS3 based theme and distribute it.  The DOM structure for a CSS3 button would be a single A tag because you can use fancy borders, backgrounds, gradients etc to get what you want without requiring multiple nested elements.

Just namespacing css class names won't achieve this because we'll be stuck with the hard-coded DOM structure.

It does make developing new widgets a bit more complicated and we will need to think about what happens if someone uses a theme which does not include support for a specific type of widget.  I suspect that we will have a default theme that always has a template/style for all widgets in the core distribution.  The ThemeManager will provide a fallback mechanism to select a template from the default if the current theme doesn't have support for a given widget.

Cheers

Paul

--
You received this message because you are subscribed to the Google Groups "JxLib" group.

To view this discussion on the web visit https://groups.google.com/d/msg/jxlib/-/GJLa5sUAEkIJ.

[Jon Bomgardner]

So, I kinda came to the same conclusion last night as well. I realised that much of what something like knockout and angular do we already had a means of accomplishing.

With that said, I'm on board with what you're proposing. I think that it makes a whole lot of sense and would be highly beneficial. Further, I think that we could incorporate a few ideas from something like Templated - specifically using data- attributes for specifying things like event connection points and/or node references that should be passed back to the calling Widget from ThemeManager. That could help lighten the load of what the base Widget class would be expected to handle. Though, it would also place the burden of making sure those things are correct on the theme designer or developer (though at the very least they would need to make sure the proper CSS classes are there anyway).

A few questions -

• Would we keep the HTML fragments in the same directory as the css?
• Should we still distribute a full-blown css file?
• What do you think of using something like SASS or LESS for the CSS? It may provide an easy way for people to change things in a theme without rewriting every CSS file. This would be especially handy for a CSS3 based theme. It could also be used to help enforce consistent attributes throughout a theme.
  

Jon

[aek]

I came with another idea here. One of the most important thing that every JavaScript toolkit and even other technologies lacks is a visual designer. Attempts for complain this in several JavaScript toolkit are failed in a highly number of situation. This is not a topic related only to UI in JavaScript toolkits, you can see the same in report designers and others areas. If you create your own markup language what tools will support this?.

I suggest the use of an existing designer that meet the requirements and can be used in the library with a transformation step. My suggestion is the great framework Qt from Nokia that has bindings for so many programming languages such as C++, Python, Java, Ruby, etc ... and is the one used for KDE applications.

Qt have a visual designer and works with a slots systems that act as events. The Qt designer generate xml files with the description of th UI and have a large number of widgets.

I think that would be great if JxLib can use Qt designer xml descriptors to generate the UI. This is not new, qooxdoo library is doing something like this, but qooxdoo solution involve an Python tool for the transformation step to qooxdoo code. I think that this could be do it directly in JavaScript.

This is my 2 cents on this. If this idea are accepted by this community I can come back with a proof of concept latter.

[aek]

this is the link for the project that do the transformation from Qt designer ui files to qooxdoo code.

http://code.google.com/p/jsqt/

[Jon Bomgardner]

Axel,

 

The creation of a UI designer of some form was actually part of the reason I brought up this idea. The only difference was that I was planning on writing one from scratch in javascript (sort of like the one for Ext). This is a great idea however and once we get the declarative language done I would love for you to give this a go....

 

Thanks,

Jon

[aek]

I saw this coming, but why waste time and resources building something from scratch if we can use an advanced project with defined markup language like others are doing. KDE, Java, Python, C++, qooxdoo, etc. We can bring up with an UI representation in JavaScript for widgets designed in Qt Designer and even create our new widgets based on Qt's .ui file format xml.

For example I have planned an report generator for PHP using JasperReports .jrxml files format generated by IReports to have the designer done and only take care of the rendering process.

The same apply here to the Qt Designer. If we go this way, we only need to develop the bindings for .ui, JavaScript and JxLib.

[Jon Bomgardner]

Granted I haven't had a chance to look at this but my only concern us that people might expect the JxLib rendered UI to look like the one they mocked together in QT Designer.... do you think that might be a concern?

 

Thanks,

Jon

[Jon Bomgardner]

Paul,

I was just going to start working on this enhancement but wanted to hash out a few details...

1) Do we still want to load all of the CSS via a single file?  I'm currently leaning to using XHR to fetch individual style sheets and activate them using Jx.Styles. The reason being that if a theme doesn't provide styles for a specific widget then we would need to be able to access the base theme (or parent theme if you like) to get the styles we need...

2) What do you think about using something similar to LESS or SASS for this and then building the "compilation" of those into the build process?

3) I'm thinking the rendering phase of a widget is going to need to be decoupled from the initialization. Currently, we have init() calling render() for widgets. I'm thinking we would need to instead have init() call out to ThemeManager to get the theme related components. Then ThemeManager either fires an event or some kind of callback to pass everything back to the widget for it's use. 

4) I'm also considering having each theme have a theme.js file that does a couple of things:

• Define a base, or parent, theme that it inherits from. If none is specified then we assume either crispin or delicious.
  
• A flag that indicates whether there are browser specific files available. The use case for this that I'm mainly thinking of is older IE as well as CSS3 techniques specific to certain browsers. This may indicate separate HTML and/or CSS files. We could also handle this through browser-scoped rules that are loaded regardless of browser but obviously not activated unless the body tag has the appropriate class.

5) The changing of themes.... The Theme Manager would have a method that could be called to start the theme change process. I envision it working similar to:

• First, ThemeManager should fire a preThemeChanging event that all widgets (and layouts possibly) will listen for. This will allow the individual widgets to do any necessary preparation on their part.
• Next, ThemeManager will fire off the necessary requests to gather the resources (CSS and HTML) for the new theme.
• ThemeManager then fires an event that the resources are available (perhaps ThemeResourcesReady or similar).
• The ThemeManager then deactivates all old style and activates the new ones
• Widgets then need to request and rebuild their DOM objects being sure they return to their current state (including data and other stateful information).

Thoughts, modifications?

Jon

Paul

To unsubscribe from this group, send email to jxlib+unsubscribe@googlegroups.com.

[Paul Spencer]

Hi Jon,

sorry for the delay.   Comments inline ...

On Sun, Mar 11, 2012 at 11:43 PM, Jon Bomgardner <jo...@comcast.net> wrote:

Paul,

I was just going to start working on this enhancement but wanted to hash out a few details...

1) Do we still want to load all of the CSS via a single file?  I'm currently leaning to using XHR to fetch individual style sheets and activate them using Jx.Styles. The reason being that if a theme doesn't provide styles for a specific widget then we would need to be able to access the base theme (or parent theme if you like) to get the styles we need...

I'm a little nervous about loading CSS this way but if it works across our supported browsers (and it should, right?) then perhaps it is a good way to go

 

2) What do you think about using something similar to LESS or SASS for this and then building the "compilation" of those into the build process?

Fred and I have had an opportunity to work with LESS extensively recently, I think we would both vote for LESS because of familiarity.

 

3) I'm thinking the rendering phase of a widget is going to need to be decoupled from the initialization. Currently, we have init() calling render() for widgets. I'm thinking we would need to instead have init() call out to ThemeManager to get the theme related components. Then ThemeManager either fires an event or some kind of callback to pass everything back to the widget for it's use. 

That makes sense.

 

4) I'm also considering having each theme have a theme.js file that does a couple of things:

• Define a base, or parent, theme that it inherits from. If none is specified then we assume either crispin or delicious.
  

Okay.

• A flag that indicates whether there are browser specific files available. The use case for this that I'm mainly thinking of is older IE as well as CSS3 techniques specific to certain browsers. This may indicate separate HTML and/or CSS files. We could also handle this through browser-scoped rules that are loaded regardless of browser but obviously not activated unless the body tag has the appropriate class.
  

The HTML 5 boilerplate project might be a good starting point, or modernizr, or both.  They would have to documented as best practices I think. The danger there is that we can't depend on the *user* of the theme to develop according to those best practices so it may be worth even pulling in part of modernizr in order to define those cases where some support should or shouldn't be added.

 

5) The changing of themes.... The Theme Manager would have a method that could be called to start the theme change process. I envision it working similar to:

• First, ThemeManager should fire a preThemeChanging event that all widgets (and layouts possibly) will listen for. This will allow the individual widgets to do any necessary preparation on their part.
• Next, ThemeManager will fire off the necessary requests to gather the resources (CSS and HTML) for the new theme.
• ThemeManager then fires an event that the resources are available (perhaps ThemeResourcesReady or similar).
• The ThemeManager then deactivates all old style and activates the new ones
• Widgets then need to request and rebuild their DOM objects being sure they return to their current state (including data and other stateful information).

Sounds good.  I can't think of anything at the moment that you are missing - although I'm sure in practice there will be some minor things that will need adjustment along the way :)

 

To view this discussion on the web visit https://groups.google.com/d/msg/jxlib/-/RCigfDvB8sMJ.

To post to this group, send email to jx...@googlegroups.com.

To unsubscribe from this group, send email to jxlib+un...@googlegroups.com.