Google Web Toolkit: April 2018

Saturday, April 28, 2018

Re: Discussion: gwt-user.jar-like uber jar for T.Broyer's multi-module project.

What you have is a gwt-app that you use as a playground/sandbox to help you test gwt-lib⋅s. It happens that the gwt-app was initialized from the archetype, but it could have not been the case and wouldn't have changed anything to your gwt-lib issue. It also happens that your gwt-app is built in the same Maven multi-module project, but again it could have been different, and it wouldn't have changed your gwt-lib issue. This is why I said, and keep saying, the archetype is not part of the equation.

Oh wow. Now I can very well see that indeed, multi-module archetype hasn't been the part of the equation this whole time. In fact the original problem was eventually reduced to a simple question of ideal use case for gwt:generate-module and gwt:generate-module-metadata, and whether its use would be appropriate for gwt-lib modules with deep inheritence structure.

Your insight on the problems raised by the upcoming (hopefully) release of GWT3.0 makes me think about many things. I guess a well thought architecture of an app is not a subject of depreciation and it will easily surpass those days with grace. But it's hard to be optimistic about the fate of actual client components. Not the the best time to invest time and efforts into building castles, it may turn out that you built them on a swamp.

--
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 google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Discussion: gwt-user.jar-like uber jar for T.Broyer's multi-module project.

On Friday, April 27, 2018 at 9:36:04 PM UTC+2, vitrums wrote:

If your lib does not have one single main gwt.xml entry point but really is more like a gwt-user.jar "set of libraries", then you'd probably better skip the gwt:generate-module and gwt:generate-module-metadata and put all your modules in src/main/resources (and not use src/main/module.gwt.xml).

To recap. Are you suggesting to get rid of module.gwt.xml and related to it gwt:generate-module and gwt:generate-module-metadata in the build process, because you don't think using this pattern to be a good practice anymore? So I should simply get back to the roots of GWT, where I had to manually put MyTextBox.gwt.xml in the directory that is root for client folder, but this time under resources (as opposed to src), shouldn't I?

There are two things:

if you want to produce a JAR that contains several "unrelated" GWT modules (in the sense that you want to tell users "add that JAR/Maven dependency, then choose among those GWT modules which one(s) to inherit"), then you can skip the src/main/module.gwt.xml+gwt:-generate-module, and you should skip gwt:generate-module-metadata as that doesn't fit with the way you want your artifact to be used. And I'm suggesting that you should do all that, rather than splitting into smaller Maven modules just to follow some convention of using src/main/module.gwt.xml+gwt:generate-module, and then repackage everything into a bigger JAR.
I'm also suggesting, and that would be a third point, that you shouldn't produce such a bigger JAR in the first place; most people use dependency managers (Maven, Gradle, Ivy, etc.) so producing bigger JARs (which used to help setting up projects when you had to download things and put them in a folder in your project and add them to your build scripts, etc. all manually) brings no real benefits these days (for a bit of history: when GWT was born, the world was much different, so you would download the GWT SDK as a ZIP file, compile against gwt-user.jar and then run GWT using both gwt-dev.jar and gwt-user.jar; this organisation didn't age well, and led to circular dependencies between GWT modules making it really hard if not impossible in some cases to modularize it; this modularization work is however finally happening)
I'm really not sure gwt:generate-module-metadata and the generateInheritsFromDependencies facet of gwt:generate-module is a good thing after all, it doesn't look like many people use it either, and I don't know of any other plugin / build tool that copied it. Sometimes, I even wonder if gwt:generate-module (and src/main/module.gwt.xml then) is a good thing, as it leads to such questioning like yours; but overall I think it is, I maybe just need to make it clearer that it really is optional.

The real question is why you're developing my-client-lib and my-client-lib-a separately if your goal is to ship them as a single artifact (there can be use cases of course, but it's the exception rather than the rule).

Because I look at module.gwt.xml in my-client-lib and simply don't fully understand how I can have my little widget-size modules like TextBox.gwt.xml as a part of this module, since it would go against the gwt:generate-module idiom. Therefore I'm left to think, that have to physically slice the project into many little modules... That is a big part of the my overall confusion.

See above.

Look at gwt-user.jar. Googlers made it the way that it logically contains dozens of modules. But imagine they were using Maven and this archetype. Did they really have to physically keep them as different modules?

See historical note above. Had they started today, no doubt it would have been different (Google's build system works better with many small libraries)

I noticed your note of criticism about how erroneously I use this archetype. Basically you imply that I should not use it to develop library code. But I'm not sure why it would be such a bad idea.

This is not what I said. What I say is you keep saying "archetype" when you're actually talking about the gwt-lib packaging and building GWT libraries.

I mean I have to develop it somewhere. This way I have a separate "playground" project dedicated to develop some components that are frequently reused in other projects. It's not a huge scale widget library, but still a set of shared interfaces, classes and resources common to more than one project. And in terminology of sandbox example I have a gwt-app packaged sandbox-client with Entry Point. I add dependencies to lib-packaged client modules like my-client-lib to debug and develop them.

What you have is a gwt-app that you use as a playground/sandbox to help you test gwt-lib⋅s. It happens that the gwt-app was initialized from the archetype, but it could have not been the case and wouldn't have changed anything to your gwt-lib issue. It also happens that your gwt-app is built in the same Maven multi-module project, but again it could have been different, and it wouldn't have changed your gwt-lib issue. This is why I said, and keep saying, the archetype is not part of the equation.

Advice required - how do I hide a Tab in a TabPanel

Hi,

I have defined a screen which has a tab panel and the same has multiple tabs.

Code is as given below

<g:HTMLPanel width="950px" height="550px">
 <g:TabPanel ui:field="tabPanel" width="900px" height="600px">
 <g:Tab text="Page 1">
                             ------- 
            </g:Tab>
 <g:Tab text="Page 2">
                             ------- 
            </g:Tab>
 <g:Tab text="Page 3">
                             ------- 
            </g:Tab>
                </g:TabPanel>
</g:HTMLPanel>

With this I can see three tabs in my page

Page 1 | Page 2 | Page 3

I want to hide Page 2 so that my page will display only

Page 1 | Page 3

Can someone please let me know the easiest way to do this?

Thanks

Sachin

Friday, April 27, 2018

Re: Discussion: gwt-user.jar-like uber jar for T.Broyer's multi-module project.

On Friday, April 27, 2018 at 7:38:41 PM UTC+3, Thomas Broyer wrote:

- <executions>

I must say I don't understand what you're talking about here (i.e. how you'd use them here)

In context of maven-jar-plugin I was simply referring to something like e.g. https://maven.apache.org/plugins/maven-jar-plugin/examples/attached-jar.html

- BOM parent to manage dependencies better. I think it also helps to keep versioning clean.

I'm not sure how this is related to the issue, but that can be useful to the users of the libraries yes.

I've seen a hack for large multi-module projects. It introduced another bom-like parent with a dynamic list of child modules to better controll what has to be rebuild. Plus it allowed a "multiartifact" nature of build.

If your lib does not have one single main gwt.xml entry point but really is more like a gwt-user.jar "set of libraries", then you'd probably better skip the gwt:generate-module and gwt:generate-module-metadata and put all your modules in src/main/resources (and not use src/main/module.gwt.xml).

To recap. Are you suggesting to get rid of module.gwt.xml and related to it gwt:generate-module and gwt:generate-module-metadata in the build process, because you don't think using this pattern to be a good practice anymore? So I should simply get back to the roots of GWT, where I had to manually put MyTextBox.gwt.xml in the directory that is root for client folder, but this time under resources (as opposed to src), shouldn't I?

The real question is why you're developing my-client-lib and my-client-lib-a separately if your goal is to ship them as a single artifact (there can be use cases of course, but it's the exception rather than the rule).

Because I look at module.gwt.xml in my-client-lib and simply don't fully understand how I can have my little widget-size modules like TextBox.gwt.xml as a part of this module, since it would go against the gwt:generate-module idiom. Therefore I'm left to think, that have to physically slice the project into many little modules... That is a big part of the my overall confusion. Look at gwt-user.jar. Googlers made it the way that it logically contains dozens of modules. But imagine they were using Maven and this archetype. Did they really have to physically keep them as different modules?

I noticed your note of criticism about how erroneously I use this archetype. Basically you imply that I should not use it to develop library code. But I'm not sure why it would be such a bad idea. I mean I have to develop it somewhere. This way I have a separate "playground" project dedicated to develop some components that are frequently reused in other projects. It's not a huge scale widget library, but still a set of shared interfaces, classes and resources common to more than one project. And in terminology of sandbox example I have a gwt-app packaged sandbox-client with Entry Point. I add dependencies to lib-packaged client modules like my-client-lib to debug and develop them. But then I stumbled across the "one module.gwt.xml per one Maven module" limitation and started to think about workarounds like uber-jar one. That's where the whole buzz came from.

Re: Using StyleInjector with Polymer and Custom CSS Properties

Can't figure out how to edit posts, last line should be

Document.get().getHead().appendChild(element);

On Friday, April 27, 2018 at 1:57:01 PM UTC-4, Tyler Moore wrote:

Made a workaround for this.

Instead of using StyleInjector. I just created a wrapper class that treats it like a mundane style element with loaded innerHTML from the resource:

public interface CSSStuff extends ClientBundle { public static final PageCSSResources INSTANCE = GWT.create(PageCSSResources.class); @Source("styles.css") TextResource siteCss(); } //...Somewhere else StyleElement element = Document.get().createStyleElement(); element.setInnerHTML(CSSStuff.INSTANCE.siteCss().getText());
Document.get().getHead().appendChild(shared.getElement());

On Friday, April 27, 2018 at 10:01:11 AM UTC-4, Tyler Moore wrote:
I use StyleInjector to inject CSS rules that work with Shadow DOM Custom Properties: https://www.polymer-project.org/2.0/docs/devguide/shadow-dom

A snippit from the CSS I inject:

event-action-table.event-action-list-editor { --table-height: 200px; a-property-with-no-double-minus-prefix: 0; }

A snippit from the custom element template:
<style> vaadin-grid { width: 100%; height: var(--table-height); } </style>

However, at run time, it looks like anything that is prefixed with '--' get's ignored by the injector. In the above case, my output element style looks like:
event-action-table.event-action-list-editor { a-property-with-no-double-minus-prefix: 0; }

Why is that?

Re: Using StyleInjector with Polymer and Custom CSS Properties

Made a workaround for this.

Instead of using StyleInjector. I just created a wrapper class that treats it like a mundane style element with loaded innerHTML from the resource:

public interface CSSStuff extends ClientBundle {

public static final PageCSSResources INSTANCE = GWT.create(PageCSSResources.class);

@Source("styles.css")
TextResource siteCss();

}

//...Somewhere else
StyleElement element = Document.get().createStyleElement();        
element.setInnerHTML(CSSStuff.INSTANCE.siteCss().getText());

Document.get().getHead().appendChild(shared.getElement());

On Friday, April 27, 2018 at 10:01:11 AM UTC-4, Tyler Moore wrote:

I use StyleInjector to inject CSS rules that work with Shadow DOM Custom Properties: https://www.polymer-project.org/2.0/docs/devguide/shadow-dom

A snippit from the CSS I inject:

event-action-table.event-action-list-editor { --table-height: 200px; a-property-with-no-double-minus-prefix: 0; }

A snippit from the custom element template:
<style> vaadin-grid { width: 100%; height: var(--table-height); } </style>

However, at run time, it looks like anything that is prefixed with '--' get's ignored by the injector. In the above case, my output element style looks like:
event-action-table.event-action-list-editor { a-property-with-no-double-minus-prefix: 0; }

Why is that?

Re: Using StyleInjector with Polymer and Custom CSS Properties

Made a workaround for this.

Instead of using StyleInjector. I just created a wrapper class that treats it like a mundane style element with loaded innerHTML from the resource:

public interface CSSStuff extends ClientBundle {

public static final PageCSSResources INSTANCE = GWT.create(PageCSSResources.class);

@Source("styles.css")
TextResource siteCss();

}

//...Somewhere else
StyleElement element = Document.get().createStyleElement();        
element.setInnerHTML(CSSStuff.INSTANCE.siteCss().getText());

On Friday, April 27, 2018 at 10:01:11 AM UTC-4, Tyler Moore wrote:

I use StyleInjector to inject CSS rules that work with Shadow DOM Custom Properties: https://www.polymer-project.org/2.0/docs/devguide/shadow-dom

A snippit from the CSS I inject:

event-action-table.event-action-list-editor { --table-height: 200px; a-property-with-no-double-minus-prefix: 0; }

A snippit from the custom element template:
<style> vaadin-grid { width: 100%; height: var(--table-height); } </style>

However, at run time, it looks like anything that is prefixed with '--' get's ignored by the injector. In the above case, my output element style looks like:
event-action-table.event-action-list-editor { a-property-with-no-double-minus-prefix: 0; }

Why is that?

Re: Discussion: gwt-user.jar-like uber jar for T.Broyer's multi-module project.

On Friday, April 27, 2018 at 4:34:25 PM UTC+2, vitrums wrote:

Any experienced developer tends to reuse existing components and organize his own code to allow reusability in future whenever it is possible. Division of labor further encourages a group of developers to physically split a big project into modules and work independently on each part. I think T.Broyer's multi-module project archetype for Maven introduces a great platform enabling these features and making versioning task look effortless.

However I personally start to have issues with the last part, when it comes to the release. Specifically, should I aggregate the build artifacts into one gwt-user.jar kind of unit? I know it's a broad topic, and there're multiple angles to look at this problem, one of which says "it's not Maven way" (though I start to doubt that I applied "Maven way" concept in the appropriate contex). Therefore I want to hear your advice regarding this matter and avoid reinventing the wheel. If there's a sample project already configured to do the similar task with grace, then I guess a link to github will be sufficient.

First, the archetypes are all about applications, not libraries. The archetypes will produce one WAR with the full application, that you can deploy effortlessly to any servlet container.

If you're going to talk about libraries, then let's step away from the archetypes and concentrate on the gwt-lib packaging from the net.ltgt.gwt.maven:gwt-maven-plugin (as that's what you're talking about).

Imagine you're developing gwt-user. Inside com\google\gwt\user folder you'll find client direcotry and a bunch of <module>.gwt.xml files such as User.gwt.xml, UI.gwt.xml, TextBox.gwt.xml. The latter contains a bunch of deferred binding instructions, e.g.:

 <replace-with class="com.google.gwt.user.client.ui.impl.TextBoxImplIE8"> <when-type-is class="com.google.gwt.user.client.ui.impl.TextBoxImpl"/> <when-property-is name="user.agent" value="ie8"/> </replace-with>

User inherits UI and UI inherits TextBox. But then we also have a subfolder datepicker with DatePicker.gwt.xml and it's own client directory.

So my view on this is that you don't wanna ship datepicker.jar to your clients, but instead combine the components from all related projects and modules into one library.

--------------------------------------------------------------------------------------------------------------------------------

Further in the text I'm gonna present my hack to multi-module archetype build configuration based on maven-shade-plugin, so let's get into details.

There were three strong candidates to do this job: maven-jar-plugin, maven-assembly-plugin and maven-shade-plugin. However the latter was specifically made for:
- This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies.
- The Shade Plugin has a single goal: shade:shade is bound to the package phase and is used to create a shaded jar.

In multi-module structure of my sandbox project I have two gwt-lib packaged modules my-client-lib and my-client-lib-a. The task is to gather their build artifacts inside one jar. My solution was to create a subsidiary module sandbox-gwt (though it could as well be another project) with the same groupId as my-client-lib* and to include only such artifacts in the uber-jar. Making it this way automates the task of naming by exploiting ${project.groupId} and ${project.version} properties.

The real question is why you're developing my-client-lib and my-client-lib-a separately if your goal is to ship them as a single artifact (there can be use cases of course, but it's the exception rather than the rule).

If your lib does not have one single main gwt.xml entry point but really is more like a gwt-user.jar "set of libraries", then you'd probably better skip the gwt:generate-module and gwt:generate-module-metadata and put all your modules in src/main/resources (and not use src/main/module.gwt.xml).

But maybe please consider the future where J2Cl in GWT3 will transpile all source files from JARs, without any kind of filtering. You'd better have many small jars then, than a bigger jar containing several libs users won't necessarily all use.

But there's a set of techniques mentioned in different sources, which might do the task better?! Those include the use of:
- <profiles>

Don't use profiles, that's not what they're made for: https://www.cloudbees.com/blog/maven-profiles-and-%E2%80%9C-maven-way%E2%80%9D

- <executions>

I must say I don't understand what you're talking about here (i.e. how you'd use them here)

- BOM parent to manage dependencies better. I think it also helps to keep versioning clean.

I'm not sure how this is related to the issue, but that can be useful to the users of the libraries yes.

--------------------------------------------------------------------------------------------------------------------------------

I also noticed, that gwt-maven-plugin can generate some code in <actual-module-name>.gwt.xml, such as adding

<inherits name="com.google.gwt.core.Core"/>

Let me be clear about this: I'm hesitating for about a year if not more about deprecating gwt:generate-module-metadata and setting generateInheritsFromDependencies to false by default in gwt:generate-module. I even hesitate sometimes about deprecating gwt:generate-module (and the use of src/main/module.gwt.xml) altogether.

This is probably what refrains me from finally tagging a 1.0 "final" release.

In the context of a large uber-jar such as gwt-user.jar if it could establish the crossreferencing between modules based only on Maven dependencies, that would be interesting. E.g. to put

<inherits name="net.coolcode.gwt.mvp.MyCoolCodeAppA" />

inside MyCoolCodeApp.gwt.xml, if my-client-lib depends on my-client-lib-a.

--------------------------------------------------------------------------------------------------------------------------------

Lastly I'm curious, in a context of development of gwt-user project it seems that due to an unconventional for GWT applications module structure (src/main/module.gwt.xml not src/main/package/MyModule.gwt.xml) if we want to strictly follow the archetype's idiom, we must have one module per one <module>.gwt.xml, e.g. TextBox.gwt.xml. I'm not sure what I'm trying to ask, but is it the way?

See above about skipping gwt:generate-module and gwt:generate-module-metadata.

And since we manually manage <source path="client" /> in module.gwt.xml, is it so evil to put server-lib artifacts in the same uber-jar?

See above about what it'd mean with J2Cl and GWT3.

Also, that means you're shipping your client-side classes and their sources into your server app. That could possibly make it quite heavier.

Discussion: gwt-user.jar-like uber jar for T.Broyer's multi-module project.

Any experienced developer tends to reuse existing components and organize his own code to allow reusability in future whenever it is possible. Division of labor further encourages a group of developers to physically split a big project into modules and work independently on each part. I think T.Broyer's multi-module project archetype for Maven introduces a great platform enabling these features and making versioning task look effortless.

However I personally start to have issues with the last part, when it comes to the release. Specifically, should I aggregate the build artifacts into one gwt-user.jar kind of unit? I know it's a broad topic, and there're multiple angles to look at this problem, one of which says "it's not Maven way" (though I start to doubt that I applied "Maven way" concept in the appropriate contex). Therefore I want to hear your advice regarding this matter and avoid reinventing the wheel. If there's a sample project already configured to do the similar task with grace, then I guess a link to github will be sufficient.

Imagine you're developing gwt-user. Inside com\google\gwt\user folder you'll find client direcotry and a bunch of <module>.gwt.xml files such as User.gwt.xml, UI.gwt.xml, TextBox.gwt.xml. The latter contains a bunch of deferred binding instructions, e.g.:

  <!-- IE has a completely different TextBox implementation -->
  <replace-with class="com.google.gwt.user.client.ui.impl.TextBoxImplIE8">
    <when-type-is class="com.google.gwt.user.client.ui.impl.TextBoxImpl"/>
    <when-property-is name="user.agent" value="ie8"/>
  </replace-with>

User inherits UI and UI inherits TextBox. But then we also have a subfolder datepicker with DatePicker.gwt.xml and it's own client directory.

So my view on this is that you don't wanna ship datepicker.jar to your clients, but instead combine the components from all related projects and modules into one library.

--------------------------------------------------------------------------------------------------------------------------------

Further in the text I'm gonna present my hack to multi-module archetype build configuration based on maven-shade-plugin, so let's get into details.

There were three strong candidates to do this job: maven-jar-plugin, maven-assembly-plugin and maven-shade-plugin. However the latter was specifically made for:

- This plugin provides the capability to package the artifact in an uber-jar, including its dependencies and to shade - i.e. rename - the packages of some of the dependencies.

- The Shade Plugin has a single goal: shade:shade is bound to the package phase and is used to create a shaded jar.

In multi-module structure of my sandbox project I have two gwt-lib packaged modules my-client-lib and my-client-lib-a. The task is to gather their build artifacts inside one jar. My solution was to create a subsidiary module sandbox-gwt (though it could as well be another project) with the same groupId as my-client-lib* and to include only such artifacts in the uber-jar. Making it this way automates the task of naming by exploiting ${project.groupId} and ${project.version} properties.

pom.xml of sandbox-gwt module:

<project xmlns="http://maven.apache.org/POM/4.0.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <parent>
   <groupId>com.example.project</groupId>
   <artifactId>sandbox</artifactId>
   <version>0.0.1-SNAPSHOT</version>
 </parent>
 <groupId>net.coolcode.gwt</groupId>
 <artifactId>sandbox-gwt</artifactId>

 <dependencies>
   <dependency>
     <groupId>${project.groupId}</groupId>
     <artifactId>my-client-lib</artifactId>
     <version>${project.version}</version>
   </dependency>
   <dependency>
     <groupId>${project.groupId}</groupId>
     <artifactId>my-client-lib-a</artifactId>
     <version>${project.version}</version>
   </dependency>
 </dependencies>

 <build>
   <plugins>
     <plugin>
       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-shade-plugin</artifactId>
       <version>3.1.1</version>
       <configuration>
         <artifactSet>
           <includes>
             <include>${project.groupId}</include>
           </includes>
         </artifactSet>
         <createDependencyReducedPom>true</createDependencyReducedPom>
       </configuration>
       <executions>
         <execution>
           <phase>package</phase>
           <goals>
             <goal>shade</goal>
           </goals>
         </execution>
       </executions>
     </plugin>
   </plugins>
 </build>
</project>

artifactSet - Artifacts to include/exclude from the final artifact. Artifacts are denoted by composite identifiers of the general form groupId:artifactId:type:classifier.

But there's a set of techniques mentioned in different sources, which might do the task better?! Those include the use of:

- <profiles>

- <executions>

- BOM parent to manage dependencies better. I think it also helps to keep versioning clean.

--------------------------------------------------------------------------------------------------------------------------------

I also noticed, that gwt-maven-plugin can generate some code in <actual-module-name>.gwt.xml, such as adding

<inherits name="com.google.gwt.core.Core"/>

In the context of a large uber-jar such as gwt-user.jar if it could establish the crossreferencing between modules based only on Maven dependencies, that would be interesting. E.g. to put

<inherits name="net.coolcode.gwt.mvp.MyCoolCodeAppA" />

inside MyCoolCodeApp.gwt.xml, if my-client-lib depends on my-client-lib-a.

--------------------------------------------------------------------------------------------------------------------------------

Lastly I'm curious, in a context of development of gwt-user project it seems that due to an unconventional for GWT applications module structure (src/main/module.gwt.xml not src/main/package/MyModule.gwt.xml) if we want to strictly follow the archetype's idiom, we must have one module per one <module>.gwt.xml, e.g. TextBox.gwt.xml. I'm not sure what I'm trying to ask, but is it the way? And since we manually manage <source path="client" /> in module.gwt.xml, is it so evil to put server-lib artifacts in the same uber-jar?

--------------------------------------------------------------------------------------------------------------------------------

p.s. It actually began to get into my habit to revisit this archetype once in a while, and then find myself seriously confused shortly after ^^.

Using StyleInjector with Polymer and Custom CSS Properties

I use StyleInjector to inject CSS rules that work with Shadow DOM Custom Properties: https://www.polymer-project.org/2.0/docs/devguide/shadow-dom

A snippit from the CSS I inject:

event-action-table.event-action-list-editor {
    --table-height: 200px;
    a-property-with-no-double-minus-prefix: 0;
}

A snippit from the custom element template:

    <style>
        vaadin-grid {
          width: 100%;
          height: var(--table-height);
        }
    </style>

However, at run time, it looks like anything that is prefixed with '--' get's ignored by the injector. In the above case, my output element style looks like:

event-action-table.event-action-list-editor {
    a-property-with-no-double-minus-prefix: 0;
}

Why is that?

Re: Documentation: incorrect mixing of Dev Mode and SuperDev Mode in 'Overview' article

Yeah you are right, the GWT site needs a little love here and there. It is a community effort to keep it up to date. The GWT site is available on Github and accepts pull requests (requires a CLA though) so you could invest some time to improve it.

-- J.

Re: Docs on debugging

Out of date. GWT site is a community effort and it is not uncommon that some documentation has become outdated over time. But that also means you could start working on an update and make a pull request on github ;-)

-- J.