Code for GSS support (GssResource) pushed. Please review.

[Julien Dramaix]

Hi,

I've pushed the code for the so called GssResource. 

The code has been split in two patches:

- The first one contains the code for the converter. The converter can be used in order to convert the existing css files to a GSS compatible file.

- The second one contains the code for the generator that parses and compiles the GSS file and produces the implementation of the related CssResources.

It would be nice to get this code in GWT 2.7, so could you review the two patches ? 

The GSS support won't be enabled by default. In order to enable it, you will have to set the configuration property named "CssResource.enableGss" to true. When enabled, all of the CssResource will be generated by using the GssGenerator.

If your application is using a third-party library that defines some CssResource that aren't converted to GSS, you can also enable the in-memory conversion (of css files with .css extension) to GSS by setting the configuration property "CssResource.legacy" to true. This conversion can run in strict (throw error if the original file contains some errors) or lenient mode (does its best to fix the original file) .

Now I think we should allow the inverse: give the ability to third party libraries to use GSS in their CssResource even if the CssResource.enableGss is set to false. This could be done by either using an annotation or by using a configuration property in the module file. 

What do you think it would be the best ? I'm more in favor of the annotation.

Julien

[Jens]

Now I think we should allow the inverse: give the ability to third party libraries to use GSS in their CssResource even if the CssResource.enableGss is set to false. This could be done by either using an annotation or by using a configuration property in the module file. 

You said that CssResource.enableGss means that CssResources are now generated using GssGenerator. If a library wants to use GSS shouldn't it use GssResource directly instead of CssResource? In that case GssResources could always be generated using GssGenerator regardless of CssResource.enableGss settings.

I don't think libraries should take their existing CssResources and add CSS3 stuff to it. I would force them to use GssResource then. Wasn't the plan to remove CssResource (and the in-memory conversation) in GWT 3.0 anyways?

-- J.

[Julien Dramaix]

Oh I forgot to mention that we had decided to use only the CssResource interface and not create a new GssResource interface. 

And we use the extension of the file in order to know if the file has to be converted or not.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/d4cf2cb9-ddea-4ef9-a8d1-73eea1ee402e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jens]

Oh I forgot to mention that we had decided to use only the CssResource interface and not create a new GssResource interface. 

And we use the extension of the file in order to know if the file has to be converted or not

Oh I see.

I think a config property is better since a library might have widgets with inline UiBinder styles and you don't want to force them to declare a CssResource in their widget class just to be able to place an annotation on it.

-- J.

[Julien Dramaix]

In fact, my question is stupid... If third party library want to use GSS, they just have to use file with .gss extension. 

For inline UiBinder styles, we can add an attribute useGss="true".

--

You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/84c99c30-abca-46e4-855b-c2152968ef73%40googlegroups.com.

[Jens]

For inline UiBinder styles, we can add an attribute useGss="true".

Hmm but still a bit of work if a library has lots of inline styles and wants to use GSS stuff. A multi-valued config property like "CssResource.GssRequired" that takes GWT module names could be used to enable GSS for inline styles on a per module basis.

-- J.

[Julien Dramaix]

> Hmm but still a bit of work if a library has lots of inline styles and wants to use GSS stuff. 

If you want to use GSS in all of your inline styles, you have first to convert them to GSS and it will take more time than simply adding an attribute that say that this inline style is using GSS.

The problem with UiBinder is that we don't know if the developer is using CSS or GSS because  the CssResource interface is generated and we cannot based our logic on the file extension as we do with normal CssResource. 

I have still to investigate but I'm pretty sure that adding an attribute will be the easiest way to support correctly GSS in uibinder inline style.

[Goktug Gokdogan]

We worked on a migration plan a few weeks back. I don't think we need to mix css and gss together inside the same app.

At this point, the libraries have multiple reasonable options on compatibility:

1- Provide both css and gss file for the resource (recommended).

The library will work fine regardless if the app enables gss or not as the right file will be chosen for the app. That's what we will do for internal resources in the SDK.

2- Keep providing the css file and make sure it works in strict mode.

The library will work fine in css mode and will work with gss only if the legacy mode is enabled.

3- Keep the old css that requires lenient mode.

The library will work fine in css mode and *may* work with gss if lenient legacy mode is enabled. 

More problematic part is the css inside uibinder. Like you said, simplest option is to introduce a temporary attribute in <ui:style> tag that marks the content as gss. In this case it is more tricky for the library to support compatibility mode similar to the mode (1) above. Either the lib should write the style that both compiles with css and gss or if it is not feasible then it should extract the resource to a file and follow the two file approach described above.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D4gaeww%3DY4cTkvNXXKKNmig6_s1CaOpwNAAemHXemb%2BjQ%40mail.gmail.com.

[Julien Dramaix]

I think we are making the things too complex. Initially, we wanted to remove the code of the existing generator for the CssResource and deprecated the existing syntax. It's why we have introduced the in-memory automatic conversion.

Now, we've decided to keep the existing generator in GWT 2.7. So I think that we had better to remove this automatic conversion and choose the right generator in fonction of the file extension. People that want to use GSS have to use files with .gss extension. Old files with .css extension will continue to work because the current generator will be used for these kind of files. For the uibinder, we add a temporary attributes (and/or we can foreseen an configuration property that enable GSS by default in UiBinder.)

That simplify a lot the implementation, removes three configuration properties (CssResource.enableGss, CssResource.legacy, CssResource.conversionMode) and we support all uses cases of application using third party libraries that will result of a mix of GSS and CSS. So it's simpler for the user and simpler for us.

In the next release of GWT, when we remove the code for the existing generator, we 
will be able to reintroduce this automatic in-memory conversion if we want still to support the old syntax.

Now I think we have to mark the current syntax of CssResource as deprecated in favor of GSS. In order to able to remove the generator in the next releases.

Another idea: In order to ease the conversion of existing CssResource to GSS, we could maybe during the compilation convert every .css file with the converter and write the result on disk (in the "extra" directory) if the -extra flag is set.

Julien

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2FYLyv%3DWYfOi0TqtojPbCTPkgzApW6J3BwnmJP19HVAQ%40mail.gmail.com.

[Goktug Gokdogan]

I didn't take notes in the meetup so I cannot recall all the reasons (perhaps someone else did?) but I think one of the reasons to introduce in memory conversion was to get rid of the CSS generator code with the GSS release and another one was the possible complications of coexisting css and gss in the same page (e.g. name collisions).

Given that we cannot get rid of the CSS generator in 2.7 and if you think everything would be fine with css/gss mixed together (e.g. with prefixes), I'm totally fine with kicking in-memory conversion out and it is definitely not required for 2.7 even if we decide to keep it.

However, arguably there might be still value in having an experimental flag to enable GSS as it is not well tested yet.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D6X1b-ZW21UjF3MPABTsofnqQ1G1BUH00fk8pR9KTh2yQ%40mail.gmail.com.

[Daniel Kurka]

Hi all,

summarizing the discussion I just had with Julien: We want to have the in memory conversion in GWT 2.7 (even if it is not battle tested yet), since this is the way to move foward. We can even do a followup release (2.8) as soon as google is using it in production and we sorted all issues out.

If GSS is turned on we will:

 - We will make a decision which generator to use based on file extension

 - You can not mix gss / css on the same interface

 - In UiBinder we will add a new attribute to tell that this interface needs gss (default css)

 - If lib has gss in it the app using that lib needs to have it enabled.

I think there is good value in including this in GWT 2.7 since we can ask for external feedback as well, while at the same time making sure its mature within google.

-Daniel

On Tuesday, October 7, 2014 8:55:27 AM UTC-7, Goktug Gokdogan wrote:

I didn't take notes in the meetup so I cannot recall all the reasons (perhaps someone else did?) but I think one of the reasons to introduce in memory conversion was to get rid of the CSS generator code with the GSS release and another one was the possible complications of coexisting css and gss in the same page (e.g. name collisions).

Given that we cannot get rid of the CSS generator in 2.7 and if you think everything would be fine with css/gss mixed together (e.g. with prefixes), I'm totally fine with kicking in-memory conversion out and it is definitely not required for 2.7 even if we decide to keep it.

However, arguably there might be still value in having an experimental flag to enable GSS as it is not well tested yet.

On Tue, Oct 7, 2014 at 1:37 AM, Julien Dramaix <julien....@gmail.com> wrote:

I think we are making the things too complex. Initially, we wanted to remove the code of the existing generator for the CssResource and deprecated the existing syntax. It's why we have introduced the in-memory automatic conversion.

Now, we've decided to keep the existing generator in GWT 2.7. So I think that we had better to remove this automatic conversion and choose the right generator in fonction of the file extension. People that want to use GSS have to use files with .gss extension. Old files with .css extension will continue to work because the current generator will be used for these kind of files. For the uibinder, we add a temporary attributes (and/or we can foreseen an configuration property that enable GSS by default in UiBinder.)

That simplify a lot the implementation, removes three configuration properties (CssResource.enableGss, CssResource.legacy, CssResource.conversionMode) and we support all uses cases of application using third party libraries that will result of a mix of GSS and CSS. So it's simpler for the user and simpler for us.

In the next release of GWT, when we remove the code for the existing generator, we 
will be able to reintroduce this automatic in-memory conversion if we want still to support the old syntax.

Now I think we have to mark the current syntax of CssResource as deprecated in favor of GSS. In order to able to remove the generator in the next releases.

Another idea: In order to ease the conversion of existing CssResource to GSS, we could maybe during the compilation convert every .css file with the converter and write the result on disk (in the "extra" directory) if the -extra flag is set.

Julien

On Mon, Oct 6, 2014 at 11:43 PM, 'Goktug Gokdogan' via GWT Contributors <google-web-toolkit-contri...@googlegroups.com> wrote:

We worked on a migration plan a few weeks back. I don't think we need to mix css and gss together inside the same app.

At this point, the libraries have multiple reasonable options on compatibility:

1- Provide both css and gss file for the resource (recommended).

The library will work fine regardless if the app enables gss or not as the right file will be chosen for the app. That's what we will do for internal resources in the SDK.

2- Keep providing the css file and make sure it works in strict mode.

The library will work fine in css mode and will work with gss only if the legacy mode is enabled.

3- Keep the old css that requires lenient mode.

The library will work fine in css mode and *may* work with gss if lenient legacy mode is enabled. 

More problematic part is the css inside uibinder. Like you said, simplest option is to introduce a temporary attribute in <ui:style> tag that marks the content as gss. In this case it is more tricky for the library to support compatibility mode similar to the mode (1) above. Either the lib should write the style that both compiles with css and gss or if it is not feasible then it should extract the resource to a file and follow the two file approach described above.

On Mon, Oct 6, 2014 at 12:54 PM, Julien Dramaix <julien....@gmail.com> wrote:

> Hmm but still a bit of work if a library has lots of inline styles and wants to use GSS stuff. 

If you want to use GSS in all of your inline styles, you have first to convert them to GSS and it will take more time than simply adding an attribute that say that this inline style is using GSS.

The problem with UiBinder is that we don't know if the developer is using CSS or GSS because  the CssResource interface is generated and we cannot based our logic on the file extension as we do with normal CssResource. 

I have still to investigate but I'm pretty sure that adding an attribute will be the easiest way to support correctly GSS in uibinder inline style.

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

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABb_3%3D4gaeww%3DY4cTkvNXXKKNmig6_s1CaOpwNAAemHXemb%2BjQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

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

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA2FYLyv%3DWYfOi0TqtojPbCTPkgzApW6J3BwnmJP19HVAQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

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

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

[Goktug Gokdogan]

Can you also summarize why we need in memory conversion as opposed to simpler alternative?

So it is documented for the next time when we will have similar discussion :)

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/7187f2b7-024e-4c5a-94d4-71e6f5f58456%40googlegroups.com.

[Julien Dramaix]

Just to summarize:

- GSS will be available in GWT 2.7

- GSS will use the CssResource interface and your file needs to end with the .gss extension

- GSS will not be enabled by default. To enable it: add  <set-configuration-property name="CssResource.enableGss" value="true" /> in your module file.

- Once enabled, all the CssResource interfaces will be generated by the new GssResourceGenerator 

- If your app uses still old css file compatible with the GWT-CSS syntax you will need to enable the automatic conversion of these files to GSS. To do that: add <set-configuration-property name="CssResource.legacy" value="true" /> in your module file.

- The GSS parser and compiler is more strict than the old one. If you meet some issue in this automatic conversion, you can also enable the lenient mode: <set-configuration-property name="CssResource.conversionMode" value="lenient" />

- When GSS is enabled, we have to use an attribute gss="true" in your uibinder inline style (<ui:style>) in order to enable GSS

We decide to go with the memory conversion because it is the way to move forward. The goal is to enable GSS (with the automatic conversion not enabled by default) and remove the CssResourceGenerator in the next release. So we want people test this strategy in order to fix possible issue and ensure that the automatic conversion is stable.

[Thomas Broyer]

On Thursday, October 23, 2014 11:40:08 PM UTC+2, Julien Dramaix wrote:

Just to summarize:

- GSS will be available in GWT 2.7

- GSS will use the CssResource interface and your file needs to end with the .gss extension

- GSS will not be enabled by default. To enable it: add  <set-configuration-property name="CssResource.enableGss" value="true" /> in your module file.

- Once enabled, all the CssResource interfaces will be generated by the new GssResourceGenerator 

- If your app uses still old css file compatible with the GWT-CSS syntax you will need to enable the automatic conversion of these files to GSS. To do that: add <set-configuration-property name="CssResource.legacy" value="true" /> in your module file.

- The GSS parser and compiler is more strict than the old one. If you meet some issue in this automatic conversion, you can also enable the lenient mode: <set-configuration-property name="CssResource.conversionMode" value="lenient" />

- When GSS is enabled, we have to use an attribute gss="true" in your uibinder inline style (<ui:style>) in order to enable GSS

Great summary! That should go into the release notes.

[Paul Stockley]

Is there a way to do an explicit one-time conversion to the new gss format? I would want to do this on my major css files so I can take advantage of the new features.

[Julien Dramaix]

For the time being, you have to use the converter externally, see https://github.com/jDramaix/gss.gwt/wiki/Migration-guide#the-converter (Now the support of GSS is included in GWT, you don't need any other dependencies than gwt-user.jar)

I've proposed to store the result of the conversion on disk id the -extra flag is set, but I don't have any reaction about that:

> Another idea: In order to ease the conversion of existing CssResource to GSS, we could maybe during the compilation convert every .css file with the converter and write the result on disk (in the "extra" directory) if the -extra flag is set.

[Goktug Gokdogan]

On Sat, Oct 25, 2014 at 2:27 AM, Julien Dramaix <julien....@gmail.com> wrote:

For the time being, you have to use the converter externally, see https://github.com/jDramaix/gss.gwt/wiki/Migration-guide#the-converter (Now the support of GSS is included in GWT, you don't need any other dependencies than gwt-user.jar)

I've proposed to store the result of the conversion on disk id the -extra flag is set, but I don't have any reaction about that:

> Another idea: In order to ease the conversion of existing CssResource to GSS, we could maybe during the compilation convert every .css file with the converter and write the result on disk (in the "extra" directory) if the -extra flag is set.

I am not sure if we need that. I think all we need to able to run the converter tool on a directory including subdirectories. That gives enough flexibility for projects to gradually convert while for others it gives a simple one shot conversion.

 

On Friday, October 24, 2014 4:34:32 PM UTC+2, Paul Stockley wrote:

Is there a way to do an explicit one-time conversion to the new gss format? I would want to do this on my major css files so I can take advantage of the new features.

On Friday, October 24, 2014 4:37:18 AM UTC-4, Thomas Broyer wrote:

On Thursday, October 23, 2014 11:40:08 PM UTC+2, Julien Dramaix wrote:

Just to summarize:

- GSS will be available in GWT 2.7

- GSS will use the CssResource interface and your file needs to end with the .gss extension

- GSS will not be enabled by default. To enable it: add  <set-configuration-property name="CssResource.enableGss" value="true" /> in your module file.

- Once enabled, all the CssResource interfaces will be generated by the new GssResourceGenerator 

- If your app uses still old css file compatible with the GWT-CSS syntax you will need to enable the automatic conversion of these files to GSS. To do that: add <set-configuration-property name="CssResource.legacy" value="true" /> in your module file.

- The GSS parser and compiler is more strict than the old one. If you meet some issue in this automatic conversion, you can also enable the lenient mode: <set-configuration-property name="CssResource.conversionMode" value="lenient" />

- When GSS is enabled, we have to use an attribute gss="true" in your uibinder inline style (<ui:style>) in order to enable GSS

Great summary! That should go into the release notes.

--

You received this message because you are subscribed to the Google Groups "GWT Contributors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/b8776c8c-309a-440b-aba6-adc6d3ecdb84%40googlegroups.com.

[confile]

Is there an option to enable code completion in eclipse for gss files like it is done for css files?

Michael 

[Julien Dramaix]

If you want css auto completion in gss file, you have to modify your ide preference to add the extension .gss as css file.

If you want autocompletion for gss syntax, you should open an issue to the Intellij issue tracker (https://youtrack.jetbrains.com/issues/IDEA) in order that they add support for GSS in the GWT plugin. For eclipse we need an external contribution to GPE.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/6e402d91-dd17-4dce-acc4-8bfb22459b52%40googlegroups.com.