Re: [gwt-contrib] Re: Making user.agent easier to extend to add new permutations
I finally manage to come back to this; sorry for the delay.
@Jens: What you are suggesting (i.e. plugins) makes sense. But right now
compiler doesn't really have a real understanding of user agents and that
is a much bigger change than what I'm am planning here.
@Colin: If CssResource generator starts respecting fallback values; it will
generate for ie7, ie9 and ie10. We can also extend the syntax so you can
say !ie9 and that will prevent the rule to match generating ie9 and also
ie10 (because it will follow ie9). That would solve most of the problems,
right?
- Or alternatively we can have a special syntax for opting-in to fallback:
e.g. ~ie6 will match ie6 and anything that falls back to ie6 (i.e. ie7).
@Thomas: I agree it is not an easy task however people who thinks that they
need to add a new user.agent, is already copying the code and adding it
anyway so I'm not sure if we are going to save much by not making it little
bit easier. I think most important question is; if you guys think that this
change adds value and useful in the long run or not. If it is not, I'm ok
with dropping it.
On Thu, Sep 12, 2013 at 11:50 AM, Goktug Gokdogan gok...@google.com wrote:
Sorry guys, I didn't have time to read the feedback, too many things to
handle right now.
I'll go through them when I have the chance to look into this change again.
On Wed, Sep 11, 2013 at 8:10 AM, Colin Alworth niloc...@gmail.com wrote:
I've got to second Thomas on this point - adding a new user.agent is very
non-trivial at least without an overhaul of CssResource generation. In GXT
3 we took the route of providing our own PropertyProviderGenerator and
adding a few new user agents (ie7, ie10 for a start), but quickly found
that doing this broke internals of a variety of GWT widgets. The fallback
attribute let ie7 behave as ie6 (and ie10 as ie9) if a replace-with rule
set did not define specific behavior for it, but the CssResource generation
process creates types based on all properties available, not just the
properties that the CSS file was written to expect. This means that if you
have
@if user.agent ie6 ie8 {
//...
}
then the enclosed content will only be in the _ie6 and _ie8 generated
classes, not _ie9 (good), _ie10 (good), or ie7 (bad). Without a fallback
mechanism that makes sense in CssResource, any existing GWT widget that
uses ClientBundle may be unusable in a project that builds its own user
agents.
This is the only case we ran into before we decided it wasn't worth it -
GXT 3 can and should run along side or in conjunction with standard GWT
widgets, so this was a deal-breaker right off the bat.
On Wed, Sep 11, 2013 at 4:40 AM, Thomas Broyer t.bro...@gmail.comwrote:
On Wednesday, September 11, 2013 3:10:56 AM UTC+2, Goktug Gokdogan wrote:
I recently noticed that developers are forking c.g.gwt.useragent in
order to be able to add new browser permutations to existing ones. This is
suboptimal and causes code duplication and possibly trying keep it in sync
with the original during updates.
The root cause of this is the determination of user.agent during
runtime is statically defined in this package. I created a patch so that
code snippets to extract user agent can be defined and injected from
outside so that new permutations can be added externally without forking
the original package.
If you hit this issue before, please take a look at https://gwt-review.
**googlesource.com/4500 https://gwt-review.googlesource.com/4500 and
see if would make your life easier.
Not opposed to it in principle, but adding a new user.agent is not an
easy task, and more often than not people actually want to add a new
property to be used in conjunction to user.agent in deferred-binding rules
(e.g.
https://code.google.com/p/google-web-toolkit/wiki/ConditionalProperties#Example_2:_Avoiding_permutation_explosion);
so I'm not sure this is the right move, as it makes it easier to do things
the wrong way.
As a side note, I think we should add a way to alias property values
so we can progressively rename gecko1_8 to gecko and possibly safari
to webkit [1] without breaking anyone. I think this can be faked today
using fallback-value and excluding the fallback value from the possible
values (i.e. extend-property name=user.agent value=gecko
fallback-value=gecko1_8/set-property name=user.agent
value=ie6,ie8,ie9,gecko,safari,opera/ notice the absence of gecko1_8
here but thanks to the fallback-value, if-property-is name=user.agent
value=gecko1_8/ should continue to work and match the gecko
permutation) but we cannot set-property the user.agent property in GWT
proper as it would break those who new values and expect the set of
possible values to automatically grow with their new value.
[1] Daniel thinks we should add a chromium permutation –he said
blink, but I believe chromium would be a better name: it's not only
about the rendering engine, but also the JS engine–, I know webkit can be
Re: [gwt-contrib] Re: Making user.agent easier to extend to add new permutations
Sorry guys, I didn't have time to read the feedback, too many things to
handle right now.
I'll go through them when I have the chance to look into this change again.
On Wed, Sep 11, 2013 at 8:10 AM, Colin Alworth niloc...@gmail.com wrote:
I've got to second Thomas on this point - adding a new user.agent is very
non-trivial at least without an overhaul of CssResource generation. In GXT
3 we took the route of providing our own PropertyProviderGenerator and
adding a few new user agents (ie7, ie10 for a start), but quickly found
that doing this broke internals of a variety of GWT widgets. The fallback
attribute let ie7 behave as ie6 (and ie10 as ie9) if a replace-with rule
set did not define specific behavior for it, but the CssResource generation
process creates types based on all properties available, not just the
properties that the CSS file was written to expect. This means that if you
have
@if user.agent ie6 ie8 {
//...
}
then the enclosed content will only be in the _ie6 and _ie8 generated
classes, not _ie9 (good), _ie10 (good), or ie7 (bad). Without a fallback
mechanism that makes sense in CssResource, any existing GWT widget that
uses ClientBundle may be unusable in a project that builds its own user
agents.
This is the only case we ran into before we decided it wasn't worth it -
GXT 3 can and should run along side or in conjunction with standard GWT
widgets, so this was a deal-breaker right off the bat.
On Wed, Sep 11, 2013 at 4:40 AM, Thomas Broyer t.bro...@gmail.com wrote:
On Wednesday, September 11, 2013 3:10:56 AM UTC+2, Goktug Gokdogan wrote:
I recently noticed that developers are forking c.g.gwt.useragent in
order to be able to add new browser permutations to existing ones. This is
suboptimal and causes code duplication and possibly trying keep it in sync
with the original during updates.
The root cause of this is the determination of user.agent during runtime
is statically defined in this package. I created a patch so that code
snippets to extract user agent can be defined and injected from outside so
that new permutations can be added externally without forking the original
package.
If you hit this issue before, please take a look at https://gwt-review.*
*googlesource.com/4500 https://gwt-review.googlesource.com/4500 and
see if would make your life easier.
Not opposed to it in principle, but adding a new user.agent is not an
easy task, and more often than not people actually want to add a new
property to be used in conjunction to user.agent in deferred-binding rules
(e.g.
https://code.google.com/p/google-web-toolkit/wiki/ConditionalProperties#Example_2:_Avoiding_permutation_explosion);
so I'm not sure this is the right move, as it makes it easier to do things
the wrong way.
As a side note, I think we should add a way to alias property values so
we can progressively rename gecko1_8 to gecko and possibly safari to
webkit [1] without breaking anyone. I think this can be faked today
using fallback-value and excluding the fallback value from the possible
values (i.e. extend-property name=user.agent value=gecko
fallback-value=gecko1_8/set-property name=user.agent
value=ie6,ie8,ie9,gecko,safari,opera/ notice the absence of gecko1_8
here but thanks to the fallback-value, if-property-is name=user.agent
value=gecko1_8/ should continue to work and match the gecko
permutation) but we cannot set-property the user.agent property in GWT
proper as it would break those who new values and expect the set of
possible values to automatically grow with their new value.
[1] Daniel thinks we should add a chromium permutation –he said
blink, but I believe chromium would be a better name: it's not only
about the rendering engine, but also the JS engine–, I know webkit can be
used with other JS engines than JavaScriptCore but I'm unsure anyone would
do it nowadays, and webkit probably still better matches reality than
safari.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
218.248.6165
niloc...@gmail.com
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups GWT
Contributors group.
To unsubscribe from this group and stop
[gwt-contrib] Re: Making user.agent easier to extend to add new permutations
Sounds nice, although the next logical step would be to ask for permutation
processing hooks. What happens if I define a user.agent safari-mobile but
the JavaToJavaScriptCompiler executes some visitors for the webkit user
agent? I assume they won't get executed anymore.
As an example, I had forked JavaToJavaScriptCompiler because I wanted to
add a visitor that disables JIT in Safari on mobile devices because of some
issues. Instead of forking, it would be a lot cooler if I could do:
extend-property name=user.agent value=safari-mobile /
// instead of your user.agent.xyz.predicate
extend-property name=user.agent.safari-mobile.permutation.plugin
value=com.example.gwt.permutation.SafariMobilePlugin /
class SafariMobilePlugin extends WebKitPlugin {
@Override
String getRuntimeMatcher(String userAgent) {
return some detection JavaScript for the bootstrap file;
}
// methods to customize permutation compilation, e.g. adding additional
visitors. By calling a super method the WebKitPlugin code/visitors would
also execute if desired.
}
Even if we now do not provide compilation hooks I think it could be a
future proof approach having classes that stand for one permutation.
Generating the user agent detection code could then easily be done by
iterating through all permutation plugin.getRuntimeMatcher() and combine
them into one JS method.
-- J.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Making user.agent easier to extend to add new permutations
On Wednesday, September 11, 2013 11:00:36 AM UTC+2, Jens wrote:
Sounds nice, although the next logical step would be to ask for
permutation processing hooks. What happens if I define a user.agent
safari-mobile but the JavaToJavaScriptCompiler executes some visitors for
the webkit user agent? I assume they won't get executed anymore.
As an example, I had forked JavaToJavaScriptCompiler because I wanted to
add a visitor that disables JIT in Safari on mobile devices because of some
issues. Instead of forking, it would be a lot cooler if I could do:
extend-property name=user.agent value=safari-mobile /
// instead of your user.agent.xyz.predicate
extend-property name=user.agent.safari-mobile.permutation.plugin
value=com.example.gwt.permutation.SafariMobilePlugin /
class SafariMobilePlugin extends WebKitPlugin {
@Override
String getRuntimeMatcher(String userAgent) {
return some detection JavaScript for the bootstrap file;
}
// methods to customize permutation compilation, e.g. adding additional
visitors. By calling a super method the WebKitPlugin code/visitors would
also execute if desired.
}
Even if we now do not provide compilation hooks I think it could be a
future proof approach having classes that stand for one permutation.
Generating the user agent detection code could then easily be done by
iterating through all permutation plugin.getRuntimeMatcher() and combine
them into one JS method.
I believe you shouldn't create a new user.agent value in this case, but
rather create a new property. See
https://code.google.com/p/google-web-toolkit/wiki/ConditionalProperties#Example_2:_Avoiding_permutation_explosion
for
an example of what I mean.
safari-mobile would still use the safari permutation, so things done in
JavaToJavaScriptCompiler will still match.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Making user.agent easier to extend to add new permutations
On Wednesday, September 11, 2013 3:10:56 AM UTC+2, Goktug Gokdogan wrote: I recently noticed that developers are forking c.g.gwt.useragent in order to be able to add new browser permutations to existing ones. This is suboptimal and causes code duplication and possibly trying keep it in sync with the original during updates. The root cause of this is the determination of user.agent during runtime is statically defined in this package. I created a patch so that code snippets to extract user agent can be defined and injected from outside so that new permutations can be added externally without forking the original package. If you hit this issue before, please take a look at https://gwt-review.googlesource.com/4500 and see if would make your life easier. Not opposed to it in principle, but adding a new user.agent is not an easy task, and more often than not people actually want to add a new property to be used in conjunction to user.agent in deferred-binding rules (e.g. https://code.google.com/p/google-web-toolkit/wiki/ConditionalProperties#Example_2:_Avoiding_permutation_explosion); so I'm not sure this is the right move, as it makes it easier to do things the wrong way. As a side note, I think we should add a way to alias property values so we can progressively rename gecko1_8 to gecko and possibly safari to webkit [1] without breaking anyone. I think this can be faked today using fallback-value and excluding the fallback value from the possible values (i.e. extend-property name=user.agent value=gecko fallback-value=gecko1_8/set-property name=user.agent value=ie6,ie8,ie9,gecko,safari,opera/ notice the absence of gecko1_8 here but thanks to the fallback-value, if-property-is name=user.agent value=gecko1_8/ should continue to work and match the gecko permutation) but we cannot set-property the user.agent property in GWT proper as it would break those who new values and expect the set of possible values to automatically grow with their new value. [1] Daniel thinks we should add a chromium permutation –he said blink, but I believe chromium would be a better name: it's not only about the rendering engine, but also the JS engine–, I know webkit can be used with other JS engines than JavaScriptCore but I'm unsure anyone would do it nowadays, and webkit probably still better matches reality than safari. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: Making user.agent easier to extend to add new permutations
I've got to second Thomas on this point - adding a new user.agent is very
non-trivial at least without an overhaul of CssResource generation. In GXT
3 we took the route of providing our own PropertyProviderGenerator and
adding a few new user agents (ie7, ie10 for a start), but quickly found
that doing this broke internals of a variety of GWT widgets. The fallback
attribute let ie7 behave as ie6 (and ie10 as ie9) if a replace-with rule
set did not define specific behavior for it, but the CssResource generation
process creates types based on all properties available, not just the
properties that the CSS file was written to expect. This means that if you
have
@if user.agent ie6 ie8 {
//...
}
then the enclosed content will only be in the _ie6 and _ie8 generated
classes, not _ie9 (good), _ie10 (good), or ie7 (bad). Without a fallback
mechanism that makes sense in CssResource, any existing GWT widget that
uses ClientBundle may be unusable in a project that builds its own user
agents.
This is the only case we ran into before we decided it wasn't worth it -
GXT 3 can and should run along side or in conjunction with standard GWT
widgets, so this was a deal-breaker right off the bat.
On Wed, Sep 11, 2013 at 4:40 AM, Thomas Broyer t.bro...@gmail.com wrote:
On Wednesday, September 11, 2013 3:10:56 AM UTC+2, Goktug Gokdogan wrote:
I recently noticed that developers are forking c.g.gwt.useragent in order
to be able to add new browser permutations to existing ones. This is
suboptimal and causes code duplication and possibly trying keep it in sync
with the original during updates.
The root cause of this is the determination of user.agent during runtime
is statically defined in this package. I created a patch so that code
snippets to extract user agent can be defined and injected from outside so
that new permutations can be added externally without forking the original
package.
If you hit this issue before, please take a look at https://gwt-review.**
googlesource.com/4500 https://gwt-review.googlesource.com/4500 and see
if would make your life easier.
Not opposed to it in principle, but adding a new user.agent is not an easy
task, and more often than not people actually want to add a new property to
be used in conjunction to user.agent in deferred-binding rules (e.g.
https://code.google.com/p/google-web-toolkit/wiki/ConditionalProperties#Example_2:_Avoiding_permutation_explosion);
so I'm not sure this is the right move, as it makes it easier to do things
the wrong way.
As a side note, I think we should add a way to alias property values so
we can progressively rename gecko1_8 to gecko and possibly safari to
webkit [1] without breaking anyone. I think this can be faked today
using fallback-value and excluding the fallback value from the possible
values (i.e. extend-property name=user.agent value=gecko
fallback-value=gecko1_8/set-property name=user.agent
value=ie6,ie8,ie9,gecko,safari,opera/ notice the absence of gecko1_8
here but thanks to the fallback-value, if-property-is name=user.agent
value=gecko1_8/ should continue to work and match the gecko
permutation) but we cannot set-property the user.agent property in GWT
proper as it would break those who new values and expect the set of
possible values to automatically grow with their new value.
[1] Daniel thinks we should add a chromium permutation –he said blink,
but I believe chromium would be a better name: it's not only about the
rendering engine, but also the JS engine–, I know webkit can be used with
other JS engines than JavaScriptCore but I'm unsure anyone would do it
nowadays, and webkit probably still better matches reality than safari.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
218.248.6165
niloc...@gmail.com
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
