Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 18 Next »

Core changes

Javascript replaced by TypeScript

One cannot really deny that Javascript sucks like a black hole, really, for bigger projects (in my opinion - like any other dynamically typed language). Inside DomUI the Javascript code became huge and was very hard to maintain - and buggy as well because no one knew what was called with what and returned whatever.

So, the Javascript code inside domui.js has been completely converted to TypeScript. TypeScript, while having its own oddities, greatly helps with adding almost full static typing to Javascript, so things can be defined like this:

export function truncateUtfBytes(str: string, nbytes: number): number

In the process a great many bugs have been found and hopefully solved. Not everything is properly typescripted yet, but at least the current code forms a good basis to fix more. It is so unimaginably nice to actually get a compiler error for a mistake instead of some obscure console log line during testing.

The domui.js module has been split into several files that all together form a single namespace called WebUI, and almost all functions there are exported so they are globally visible. This ensures that existing calls to code remain working at the cost of still having bad TypeScript code. A later iteration will replace the namespace with several modules - but that requires all call sites to be visited.

One pretty huge sadness in TypeScript is that using a namespace with multiple files, while supported, is horribly implemented: you cannot easily define order between the files inside the namespace. To circumvent this for now the files are added to the _files section of the tsconfig.json file in the correct order.

setClicked() argument changed (breaking)

The setClicked(IClickBase) method has been replaced by two separate methods:

  • setClicked(IClicked<?>)
  • setClicked2(IClicked2<?>)

This change allows for easier use of lambda's as the type for the method is now well-defined. So instead of having to write


d.setClicked((IClicked<Div>) b -> setCurrentTab(ti));

you can now invoke the lambda without a cast:

d.setClicked(b -> setCurrentTab(ti));

This change will some existing code as all calls to setClicked that passed a IClicked2 instance now need to use setClicked2.

INodeContentRenderer removed (breaking change)

This interface was the main interface to render generic content inside some NodeContainer. Its definition was this:

public interface INodeContentRenderer<T> {
   void renderNodeContent(@Nonnull NodeBase component, @Nonnull NodeContainer node, @Nullable T object, @Nullable Object parameters) throws Exception;
}

This interface was abused all over the place and makes it very unclear what parameters are actually passed into renderers, as the parameters component and parameters were often used in non-obvious ways. It also opened the doors for wide abuse, because renderers could abuse the values in component to actually "fix" the components rendering. This of course makes it impossible to maintain those components.

In addition the "object" parameter needed to be @Nullable because a lot of usages of this interface sometimes do pass a null value. But this makes it hard for the zillion places where this value is never null: it forces a check to be needed inside the implementation always.

The interface was replaced by the following:

public interface IRenderInto<T> {
   void render(@Nonnull NodeContainer node, @Nonnull T object) throws Exception;

   default void renderOpt(@Nonnull NodeContainer node, @Nullable T object) throws Exception {
      if(null != object)
         render(node, object);
   }
}

The implementer usually implements the render() method only. When there is a need to also handle nulls in a special way then the renderOpt() method needs to be overridden too.

This interface is used at most places where INodeContentRenderer was used. At places where indeed more than these two parameters are needed new interfaces will have been introduced which better describe the parameters and their expected use. Also see the notes about the content renderers for the LookupInput control.

For those not eager to replace all occurrences of INodeContentRenderer: you might be able to define it again in your own code, making it extend IRenderInto, and make the render() method call the old method inside INodeContentRenderer, something like:

public interface INodeContentRenderer<T> extends IRenderInto<T> {
   void renderNodeContent(@Nonnull NodeBase component, @Nonnull NodeContainer node, @Nullable T object, @Nullable Object parameters) throws Exception;
   default void render(@Nonnull NodeContainer node, @Nonnull T object) throws Exception {
       renderNodeContent(node, node, object, null);
   }
}


Private and protected properties can be used in binding/metadata

When binding was used to connect properties to controls it required that the property bound to was public. But in many cases the binding and the properties are part of one (set of) classes, with no need to have those properties propagated to the outside world.

DomUI now detects private properties in its metamodel, and allows getting/setting the value of these properties through the metamodel. Some restrictions apply, however:

  • Private properties are only detected in the actual class, not in parent classes.
  • Odd definitions, like private setter and public getter, might have undesired results. The default for DomUI is to treat the private method as non-existing, so in this case it would present the property as read-only even though a private setter exists.

Logger changes

DomUI uses the "etclogger" SLF4J backend by default. The code to initialize this was quite old, and had a lot of nasty things related to the config file's location. The initialization part has been rewritten to have less oddities surrounding the config file, so that no directories are created at wrong places.

The new default config file will be in WEB-INF if it is not expressly specified with a full path.

The default name of the config file is now etclogger.config.xml

Changed/new functionality

Animations

The animation methods slideUp(), slideDown(), fadeIn() and fadeOut() have been removed from the Div tag. They should be replaced by calling Animations.xxxx with the node to animate.

DataTable

  • The RowRenderer now sets columns that are defined from metadata to SORT_ASCENDING if the metadata specifies unknown sort. To prevent set the metadata to UNSORTABLE. This change means that tables are by default sortable.

Todo:

  • Default table without widths specified takes 100% width, and any click on a header causes the column widths to jump around.

New Tree2 component

The new Tree2 component is a rewrite of the now deprecated Tree component. It uses mostly the same interface but is rewritten with cleaner code and renders without using tables.

LookupInput

This component moved to legacy.

The test IDs for the buttons on the LookupInput have changed, so that it is easy to click one of the buttons of a specific lookup. With a LookupInput with testID = "one" the buttons would be called:

  • one-lookup for the search button
  • one-clear for the clear button

The generated html code for the control has been changed so that style fixes could be applied. This breaks the existing legacy stylesheets. For fixes look at _lookupInput.scss.

The value renderers used by this component have changed. In 1.0 the value renderers were not just responsible for rendering a value: they also placed the control's buttons and did a lot for the layout for the control. This was a bad plan, because it tightly couples those renderers to the control and anyone overridding those also need to know how the control renders. This made it impossible to change the rendering of the control.

The new renderers are solely responsible for rendering the value in some reasonable way. All of the main layout of the control is done by the control itself. Consequently these renderers no longer need all the extra "hidden" parameters passed to INodeContentRenderer, and they now implement IRenderInto.

In addition, to reduce the maintenance of both LookupInput components, both components as they render the exact same layou now also share a common stylesheet.

Look and feel

The following things have changed regarding themes, styles and look-and-feel.

Using FontAwesome with DomUI

You can use FontAwesome icons in most places where you would usually add an image resource.

Sass scss support

The main theme is now a scss theme. Support for scss style sheets is natively included in DomUI: there is no need to translate scss to css, it is done by DomUI's embedded sass part.

Theme and stylesheet changes

  • The new core stylesheet (scss/winter) removes all of the kludges:
    • The stylesheet reset has been removed, as it also removes any proper support for just displaying html. Components themselves are responsible for resetting browser specifics where needed.
    • The negative margins kludge has been removed.
    • Components themselves will not have margins anymore, so when two components are placed next to each other they will touch. In the new style sheet it is the responsibility of the container to handle the layout of its components properly.
  • The DefaultButton (_defaultbutton.scss) no longer uses a background image. It is restyled to use css3 with css3 transitions. The button also lost its margins; it is now properly the responsibility of the container css to layout its components properly.
  • There was a duplicate component style sheet for LookupInput called _lookupForm. It has been removed and its styles have been merged in the _lookupInput stylesheet (scss only).

UrlPage default classes removed

In DomUI 1.0 UrlPage set the classes ui-content and ui-kludge on the body. These were needed to be able to fix some mistakes made in the css on a per-page basis, mainly the margins added to the default page.

The new scss style no longer does this, so these classes are removed. For code still depending on this it is easy to add them again by using a page listener registered in DomApplication, something like:

addNewPageInstantiatedListener(new INewPageInstantiated() {
   @Override
   public void newPageCreated(@Nonnull UrlPage body) throws Exception {}

   @Override
   public void newPageBuilt(@Nonnull UrlPage body) throws Exception {
     body.addCssClass("ui-content ui-kludge");
   }
}


DataPager

The DataPager's look has been fixed so that it properly shows the overflow indicator, and that it uses CSS only for its presentation:

Fixes




  • No labels