[gwt-contrib] Re: Add StyleInjector to GWT trunk

[Ray Cromwell]

The current solution of allowing you to inject as the first child of 
works just fine, at the loss of user defined stylesheets needing to use
!important, but it is also extremely simple to implement, and the low
hanging fruit. Iimposing that StyleInjector would have to use
addRule()/insertRule() would result in a performance hit for large
injections, while simultaneously reducing the coding efficiency of
ImmutableResourceBundle/ClientBundle, since it would have to break up the
cssText into an array of strings. I don't think the GWT team wants to make
large sweeping changes to StyleInjector/ClientBundle at this point. I'm also
skeptical that it would yield much practical benefit to most developers. Can
you give a practical example of how this would even be used and how the end
user (not generally aware of CSS and cascade rules) would even decide what
to do?

On Fri, Apr 3, 2009 at 8:52 PM, Miroslav Pokorny  wrote:

> That's correct because they cascade. The benefit of specifying which
> stylesheet to inject into is that the gwt stylesheet can contain defaults
> which are in turn overridden at will in user defined stylesheets.
>
> Currently it's a free for all with ordering being undpecified which makes
> it messy to start overriding some rules.
>
>
>
> On 04/04/2009,d at 2:33 PM, Ray Cromwell  wrote:
>
>
> You can get the CssRule/CSSStyleDeclaration as text via the cssText
> property, but AFAIK, there is no property on document.styleSheets[n] that
> allows setting the whole stylesheet at once using text. If there is, it's
> certainly not part of the W3C DOM CSS OM.
> -Ray
>
> On Fri, Apr 3, 2009 at 8:21 PM, Miroslav Pokorny <
> miroslav.poko...@gmail.com> wrote:
>
>> One does not have to add the rules one by one. If I recall it is possible
>> to get the entire content of a stylesheet using the "css" property append
>> your new rules and update that property. I'm pretty sure you can do
>> basically the same thing in all browsers.
>>
>> Ti
>>
>> On 04/04/2009, at 10:56 AM, Ray Cromwell < 
>> cromwell...@gmail.com> wrote:
>>
>> It seems to me that calling addRule/insertRule a hundred times would be
>> pretty slow (just look how many rules are in the GWT Theme CSS), not to
>> mention there are cross-browser issues to deal with, when a simple,
>> well-tested, mechanism exists already. Sometimes doing the 'proper' thing is
>> not an improvement (e.g. not using tables for layout because it's "wrong")
>>
>> -Ray
>>
>>
>> On Fri, Apr 3, 2009 at 4:47 PM, Miroslav Pokorny 
>> <
>> miroslav.poko...@gmail.com> wrote:
>>
>>> This is probably the wrong time to ask -but updating styles via the
>>> addition of style tags seems very limiting.
>>>
>>> If I recall IE (cant recall which vetsion was probably 7) chokes when a
>>> page has more than thirty odd style elements.
>>>
>>> Why not add new rules using StyleSheet.addRule/insertRule or appending
>>> the new CSS to a particular stylesheet's CSS ? Using style elements to
>>> "append" to a stylesheet seems a hack when proper mechanisms exist.
>>>
>>> If the StyleInjector bundle included a mechanism to say which stylesheet
>>> to modify.
>>>
>>> On 04/04/2009, at 8:49 AM, Ray Cromwell < 
>>> 
>>> cromwell...@gmail.com> wrote:
>>>
>>>
>>> I believe so. I don't see any harm. Personally, I think if you don't have
>>> a , your page is broken, since you don't even get a , but it
>>> would be nice to either throw an informative exception, or inject a head in
>>> this circumstance.
>>> -Ray
>>>
>>>
>>> On Fri, Apr 3, 2009 at 2:46 PM, Ray Ryan < 
>>> 
>>> rj...@google.com> wrote:
>>>
 Can we add safely add head if we don't find it?


 On Fri, Apr 3, 2009 at 2:43 PM, < 
 
 cromwell...@gmail.com> wrote:

>
>  
> 
> http://gwt-code-reviews.appspot.com/15803/diff/4001/4004
> File user/src/com/google/gwt/dom/client/StyleInjector.java (right):
>
>  
> 
> http://gwt-code-reviews.appspot.com/15803/diff/4001/4004#newcode35
> Line 35: "head").getItem(0));
> I mentioned this in another review, but this common idiom can fail if
> the user doesn't have a  element, which is certainly legal. Some
> browsers automatically insert a  if it's missing, but some don't.
> I guess we could simply declare we don't support leaving out head.
>
> Might be good to assert head != null
>
>
>  
> 
> http://gwt-code-reviews.appspot.com/15803
>


>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
>
> >
>

--~-

[gwt-contrib] Re: Add StyleInjector to GWT trunk

[Miroslav Pokorny]

That's correct because they cascade. The benefit of specifying which  
stylesheet to inject into is that the gwt stylesheet can contain  
defaults which are in turn overridden at will in user defined  
stylesheets.

Currently it's a free for all with ordering being undpecified which  
makes it messy to start overriding some rules.



On 04/04/2009,d at 2:33 PM, Ray Cromwell  wrote:

>
> You can get the CssRule/CSSStyleDeclaration as text via the cssText  
> property, but AFAIK, there is no property on document.styleSheets[n]  
> that allows setting the whole stylesheet at once using text. If  
> there is, it's certainly not part of the W3C DOM CSS OM.
>
> -Ray
>
> On Fri, Apr 3, 2009 at 8:21 PM, Miroslav Pokorny  > wrote:
> One does not have to add the rules one by one. If I recall it is  
> possible to get the entire content of a stylesheet using the "css"  
> property append your new rules and update that property. I'm pretty  
> sure you can do basically the same thing in all browsers.
>
> Ti
>
> On 04/04/2009, at 10:56 AM, Ray Cromwell   
> wrote:
>
>> It seems to me that calling addRule/insertRule a hundred times  
>> would be pretty slow (just look how many rules are in the GWT Theme  
>> CSS), not to mention there are cross-browser issues to deal with,  
>> when a simple, well-tested, mechanism exists already. Sometimes  
>> doing the 'proper' thing is not an improvement (e.g. not using  
>> tables for layout because it's "wrong")
>>
>> -Ray
>>
>>
>> On Fri, Apr 3, 2009 at 4:47 PM, Miroslav Pokorny > > wrote:
>> This is probably the wrong time to ask -but updating styles via the  
>> addition of style tags seems very limiting.
>>
>> If I recall IE (cant recall which vetsion was probably 7) chokes  
>> when a page has more than thirty odd style elements.
>>
>> Why not add new rules using StyleSheet.addRule/insertRule or  
>> appending the new CSS to a particular stylesheet's CSS ? Using  
>> style elements to "append" to a stylesheet seems a hack when proper  
>> mechanisms exist.
>>
>> If the StyleInjector bundle included a mechanism to say which  
>> stylesheet to modify.
>>
>> On 04/04/2009, at 8:49 AM, Ray Cromwell   
>> wrote:
>>
>>>
>>> I believe so. I don't see any harm. Personally, I think if you  
>>> don't have a , your page is broken, since you don't even get  
>>> a , but it would be nice to either throw an informative  
>>> exception, or inject a head in this circumstance.
>>>
>>> -Ray
>>>
>>>
>>> On Fri, Apr 3, 2009 at 2:46 PM, Ray Ryan  wrote:
>>> Can we add safely add head if we don't find it?
>>>
>>>
>>> On Fri, Apr 3, 2009 at 2:43 PM,  wrote:
>>>
>>> http://gwt-code-reviews.appspot.com/15803/diff/4001/4004
>>> File user/src/com/google/gwt/dom/client/StyleInjector.java (right):
>>>
>>> http://gwt-code-reviews.appspot.com/15803/diff/4001/4004#newcode35
>>> Line 35: "head").getItem(0));
>>> I mentioned this in another review, but this common idiom can fail  
>>> if
>>> the user doesn't have a  element, which is certainly legal.  
>>> Some
>>> browsers automatically insert a  if it's missing, but some  
>>> don't.
>>> I guess we could simply declare we don't support leaving out head.
>>>
>>> Might be good to assert head != null
>>>
>>>
>>> http://gwt-code-reviews.appspot.com/15803
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
>
>
> >

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Add StyleInjector to GWT trunk

[Ray Cromwell]

You can get the CssRule/CSSStyleDeclaration as text via the cssText
property, but AFAIK, there is no property on document.styleSheets[n] that
allows setting the whole stylesheet at once using text. If there is, it's
certainly not part of the W3C DOM CSS OM.
-Ray

On Fri, Apr 3, 2009 at 8:21 PM, Miroslav Pokorny  wrote:

> One does not have to add the rules one by one. If I recall it is possible
> to get the entire content of a stylesheet using the "css" property append
> your new rules and update that property. I'm pretty sure you can do
> basically the same thing in all browsers.
>
> Ti
>
> On 04/04/2009, at 10:56 AM, Ray Cromwell  wrote:
>
> It seems to me that calling addRule/insertRule a hundred times would be
> pretty slow (just look how many rules are in the GWT Theme CSS), not to
> mention there are cross-browser issues to deal with, when a simple,
> well-tested, mechanism exists already. Sometimes doing the 'proper' thing is
> not an improvement (e.g. not using tables for layout because it's "wrong")
>
> -Ray
>
>
> On Fri, Apr 3, 2009 at 4:47 PM, Miroslav Pokorny <
> miroslav.poko...@gmail.com> wrote:
>
>> This is probably the wrong time to ask -but updating styles via the
>> addition of style tags seems very limiting.
>>
>> If I recall IE (cant recall which vetsion was probably 7) chokes when a
>> page has more than thirty odd style elements.
>>
>> Why not add new rules using StyleSheet.addRule/insertRule or appending the
>> new CSS to a particular stylesheet's CSS ? Using style elements to "append"
>> to a stylesheet seems a hack when proper mechanisms exist.
>>
>> If the StyleInjector bundle included a mechanism to say which stylesheet
>> to modify.
>>
>> On 04/04/2009, at 8:49 AM, Ray Cromwell < 
>> cromwell...@gmail.com> wrote:
>>
>>
>> I believe so. I don't see any harm. Personally, I think if you don't have
>> a , your page is broken, since you don't even get a , but it
>> would be nice to either throw an informative exception, or inject a head in
>> this circumstance.
>> -Ray
>>
>>
>> On Fri, Apr 3, 2009 at 2:46 PM, Ray Ryan < 
>> 
>> rj...@google.com> wrote:
>>
>>> Can we add safely add head if we don't find it?
>>>
>>>
>>> On Fri, Apr 3, 2009 at 2:43 PM, < 
>>> 
>>> cromwell...@gmail.com> wrote:
>>>

  
 
 http://gwt-code-reviews.appspot.com/15803/diff/4001/4004
 File user/src/com/google/gwt/dom/client/StyleInjector.java (right):

  
 
 http://gwt-code-reviews.appspot.com/15803/diff/4001/4004#newcode35
 Line 35: "head").getItem(0));
 I mentioned this in another review, but this common idiom can fail if
 the user doesn't have a  element, which is certainly legal. Some
 browsers automatically insert a  if it's missing, but some don't.
 I guess we could simply declare we don't support leaving out head.

 Might be good to assert head != null


  
 
 http://gwt-code-reviews.appspot.com/15803

>>>
>>>
>>
>>
>>
>>
>>
>
>
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Add StyleInjector to GWT trunk

[Miroslav Pokorny]

One does not have to add the rules one by one. If I recall it is  
possible to get the entire content of a stylesheet using the "css"  
property append your new rules and update that property. I'm pretty  
sure you can do basically the same thing in all browsers.

Ti

On 04/04/2009, at 10:56 AM, Ray Cromwell  wrote:

> It seems to me that calling addRule/insertRule a hundred times would  
> be pretty slow (just look how many rules are in the GWT Theme CSS),  
> not to mention there are cross-browser issues to deal with, when a  
> simple, well-tested, mechanism exists already. Sometimes doing the  
> 'proper' thing is not an improvement (e.g. not using tables for  
> layout because it's "wrong")
>
> -Ray
>
>
> On Fri, Apr 3, 2009 at 4:47 PM, Miroslav Pokorny  > wrote:
> This is probably the wrong time to ask -but updating styles via the  
> addition of style tags seems very limiting.
>
> If I recall IE (cant recall which vetsion was probably 7) chokes  
> when a page has more than thirty odd style elements.
>
> Why not add new rules using StyleSheet.addRule/insertRule or  
> appending the new CSS to a particular stylesheet's CSS ? Using style  
> elements to "append" to a stylesheet seems a hack when proper  
> mechanisms exist.
>
> If the StyleInjector bundle included a mechanism to say which  
> stylesheet to modify.
>
> On 04/04/2009, at 8:49 AM, Ray Cromwell  wrote:
>
>>
>> I believe so. I don't see any harm. Personally, I think if you  
>> don't have a , your page is broken, since you don't even get  
>> a , but it would be nice to either throw an informative  
>> exception, or inject a head in this circumstance.
>>
>> -Ray
>>
>>
>> On Fri, Apr 3, 2009 at 2:46 PM, Ray Ryan  wrote:
>> Can we add safely add head if we don't find it?
>>
>>
>> On Fri, Apr 3, 2009 at 2:43 PM,  wrote:
>>
>> http://gwt-code-reviews.appspot.com/15803/diff/4001/4004
>> File user/src/com/google/gwt/dom/client/StyleInjector.java (right):
>>
>> http://gwt-code-reviews.appspot.com/15803/diff/4001/4004#newcode35
>> Line 35: "head").getItem(0));
>> I mentioned this in another review, but this common idiom can fail if
>> the user doesn't have a  element, which is certainly legal.  
>> Some
>> browsers automatically insert a  if it's missing, but some  
>> don't.
>> I guess we could simply declare we don't support leaving out head.
>>
>> Might be good to assert head != null
>>
>>
>> http://gwt-code-reviews.appspot.com/15803
>>
>>
>>
>>
>
>
>
>
> >

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Getting available TimeZones, Detecting Timezones?

[Ray Cromwell]

John,  A google hosted service would be great, sounds like a good, valuable
service, of use to everyone on the web. I don't mind asynchronously fetching
this data, because you typically have to ask the user which TZ he's in
anyway, unless you try to infer it from the browser's Date.toString()
method, which isn't always reliable. (Some browsers report actual TZ Common
names, others don't)

-Ray

On Fri, Apr 3, 2009 at 4:34 PM, John Tamplin  wrote:

> On Fri, Apr 3, 2009 at 7:28 PM, Ray Cromwell wrote:
>
>>
>> Am I missing something? There doesn't appear to be a way to query for all
>> of the supported Common Timezones, which makes it problematic to construct a
>> UI dialog that asks the user to specify a TimeZone without hard coding.
>> Simple Timezones have the problem that they don't provide DST information,
>> which makes the behavior of DateTimeFormat wrong in some TZs. I'm wondering
>> if it makes sense to either 1) provide a default RPC service for obtaining
>> TZ related info (localized), or revisit the issue of providing full TZ
>> introspection using code splitting to reduce some of the inefficiency.
>>
>
> Work is in progress to provide a JSONP service, either provided by Google
> or where you can run a servlet on your own infrastructure, and fetch the
> timezone data that way.  It is too large in its current form to include in
> the compiled output (though we may be able to improve that for certain
> common cases in the future) and the async nature of the interface means it
> won't be transparent to user code, but it should be out for review shortly.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Add StyleInjector to GWT trunk

[Ray Cromwell]

It seems to me that calling addRule/insertRule a hundred times would be
pretty slow (just look how many rules are in the GWT Theme CSS), not to
mention there are cross-browser issues to deal with, when a simple,
well-tested, mechanism exists already. Sometimes doing the 'proper' thing is
not an improvement (e.g. not using tables for layout because it's "wrong")

-Ray


On Fri, Apr 3, 2009 at 4:47 PM, Miroslav Pokorny  wrote:

> This is probably the wrong time to ask -but updating styles via the
> addition of style tags seems very limiting.
>
> If I recall IE (cant recall which vetsion was probably 7) chokes when a
> page has more than thirty odd style elements.
>
> Why not add new rules using StyleSheet.addRule/insertRule or appending the
> new CSS to a particular stylesheet's CSS ? Using style elements to "append"
> to a stylesheet seems a hack when proper mechanisms exist.
>
> If the StyleInjector bundle included a mechanism to say which stylesheet to
> modify.
>
> On 04/04/2009, at 8:49 AM, Ray Cromwell  wrote:
>
>
> I believe so. I don't see any harm. Personally, I think if you don't have a
> , your page is broken, since you don't even get a , but it
> would be nice to either throw an informative exception, or inject a head in
> this circumstance.
> -Ray
>
>
> On Fri, Apr 3, 2009 at 2:46 PM, Ray Ryan < 
> rj...@google.com> wrote:
>
>> Can we add safely add head if we don't find it?
>>
>>
>> On Fri, Apr 3, 2009 at 2:43 PM, < 
>> cromwell...@gmail.com> wrote:
>>
>>>
>>>  
>>> http://gwt-code-reviews.appspot.com/15803/diff/4001/4004
>>> File user/src/com/google/gwt/dom/client/StyleInjector.java (right):
>>>
>>>  
>>> http://gwt-code-reviews.appspot.com/15803/diff/4001/4004#newcode35
>>> Line 35: "head").getItem(0));
>>> I mentioned this in another review, but this common idiom can fail if
>>> the user doesn't have a  element, which is certainly legal. Some
>>> browsers automatically insert a  if it's missing, but some don't.
>>> I guess we could simply declare we don't support leaving out head.
>>>
>>> Might be good to assert head != null
>>>
>>>
>>>  
>>> http://gwt-code-reviews.appspot.com/15803
>>>
>>
>>
>
>
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Add StyleInjector to GWT trunk

[Miroslav Pokorny]

This is probably the wrong time to ask -but updating styles via the  
addition of style tags seems very limiting.

If I recall IE (cant recall which vetsion was probably 7) chokes when  
a page has more than thirty odd style elements.

Why not add new rules using StyleSheet.addRule/insertRule or appending  
the new CSS to a particular stylesheet's CSS ? Using style elements to  
"append" to a stylesheet seems a hack when proper mechanisms exist.

If the StyleInjector bundle included a mechanism to say which  
stylesheet to modify.

On 04/04/2009, at 8:49 AM, Ray Cromwell  wrote:

>
> I believe so. I don't see any harm. Personally, I think if you don't  
> have a , your page is broken, since you don't even get a  
> , but it would be nice to either throw an informative  
> exception, or inject a head in this circumstance.
>
> -Ray
>
>
> On Fri, Apr 3, 2009 at 2:46 PM, Ray Ryan  wrote:
> Can we add safely add head if we don't find it?
>
>
> On Fri, Apr 3, 2009 at 2:43 PM,  wrote:
>
> http://gwt-code-reviews.appspot.com/15803/diff/4001/4004
> File user/src/com/google/gwt/dom/client/StyleInjector.java (right):
>
> http://gwt-code-reviews.appspot.com/15803/diff/4001/4004#newcode35
> Line 35: "head").getItem(0));
> I mentioned this in another review, but this common idiom can fail if
> the user doesn't have a  element, which is certainly legal. Some
> browsers automatically insert a  if it's missing, but some  
> don't.
> I guess we could simply declare we don't support leaving out head.
>
> Might be good to assert head != null
>
>
> http://gwt-code-reviews.appspot.com/15803
>
>
>
> >

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Getting available TimeZones, Detecting Timezones?

[John Tamplin]

On Fri, Apr 3, 2009 at 7:28 PM, Ray Cromwell  wrote:

>
> Am I missing something? There doesn't appear to be a way to query for all
> of the supported Common Timezones, which makes it problematic to construct a
> UI dialog that asks the user to specify a TimeZone without hard coding.
> Simple Timezones have the problem that they don't provide DST information,
> which makes the behavior of DateTimeFormat wrong in some TZs. I'm wondering
> if it makes sense to either 1) provide a default RPC service for obtaining
> TZ related info (localized), or revisit the issue of providing full TZ
> introspection using code splitting to reduce some of the inefficiency.
>

Work is in progress to provide a JSONP service, either provided by Google or
where you can run a servlet on your own infrastructure, and fetch the
timezone data that way.  It is too large in its current form to include in
the compiled output (though we may be able to improve that for certain
common cases in the future) and the async nature of the interface means it
won't be transparent to user code, but it should be out for review shortly.

-- 
John A. Tamplin
Software Engineer (GWT), Google

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Getting available TimeZones, Detecting Timezones?

[Ray Cromwell]

Am I missing something? There doesn't appear to be a way to query for all of
the supported Common Timezones, which makes it problematic to construct a UI
dialog that asks the user to specify a TimeZone without hard coding. Simple
Timezones have the problem that they don't provide DST information, which
makes the behavior of DateTimeFormat wrong in some TZs. I'm wondering if it
makes sense to either 1) provide a default RPC service for obtaining TZ
related info (localized), or revisit the issue of providing full TZ
introspection using code splitting to reduce some of the inefficiency.

-Ray

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] RR: shorten filenames for SOYC reports

[Lex Spoon]

Bob, can you review this patch for me?

Currently SOYC can run into some really long file names when
generating output for large packages.  The attached patch shortens the
package names to reduce the frequency this happens.

It's likely worth doing such shortening more consistently, but package
names seem to be the easiest offender.

If it looks good, I'll additionally re-sort MakeTopLevelHtmlForPerm in
a separate commit.

Lex

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Add StyleInjector to GWT trunk

[Ray Cromwell]

I believe so. I don't see any harm. Personally, I think if you don't have a
, your page is broken, since you don't even get a , but it
would be nice to either throw an informative exception, or inject a head in
this circumstance.
-Ray


On Fri, Apr 3, 2009 at 2:46 PM, Ray Ryan  wrote:

> Can we add safely add head if we don't find it?
>
>
> On Fri, Apr 3, 2009 at 2:43 PM,  wrote:
>
>>
>> http://gwt-code-reviews.appspot.com/15803/diff/4001/4004
>> File user/src/com/google/gwt/dom/client/StyleInjector.java (right):
>>
>> http://gwt-code-reviews.appspot.com/15803/diff/4001/4004#newcode35
>> Line 35: "head").getItem(0));
>> I mentioned this in another review, but this common idiom can fail if
>> the user doesn't have a  element, which is certainly legal. Some
>> browsers automatically insert a  if it's missing, but some don't.
>> I guess we could simply declare we don't support leaving out head.
>>
>> Might be good to assert head != null
>>
>>
>> http://gwt-code-reviews.appspot.com/15803
>>
>
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Add StyleInjector to GWT trunk

[Ray Ryan]

Can we add safely add head if we don't find it?

On Fri, Apr 3, 2009 at 2:43 PM,  wrote:

>
> http://gwt-code-reviews.appspot.com/15803/diff/4001/4004
> File user/src/com/google/gwt/dom/client/StyleInjector.java (right):
>
> http://gwt-code-reviews.appspot.com/15803/diff/4001/4004#newcode35
> Line 35: "head").getItem(0));
> I mentioned this in another review, but this common idiom can fail if
> the user doesn't have a  element, which is certainly legal. Some
> browsers automatically insert a  if it's missing, but some don't.
> I guess we could simply declare we don't support leaving out head.
>
> Might be good to assert head != null
>
>
> http://gwt-code-reviews.appspot.com/15803
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Add StyleInjector to GWT trunk

[cromwellian]

http://gwt-code-reviews.appspot.com/15803/diff/4001/4004
File user/src/com/google/gwt/dom/client/StyleInjector.java (right):

http://gwt-code-reviews.appspot.com/15803/diff/4001/4004#newcode35
Line 35: "head").getItem(0));
I mentioned this in another review, but this common idiom can fail if
the user doesn't have a  element, which is certainly legal. Some
browsers automatically insert a  if it's missing, but some don't.
I guess we could simply declare we don't support leaving out head.

Might be good to assert head != null

http://gwt-code-reviews.appspot.com/15803

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Add StyleInjector to GWT trunk

[rjrjr]

LGTM

Some nits, do with them what you will and commit this puppy.


http://gwt-code-reviews.appspot.com/15803/diff/4001/4004
File user/src/com/google/gwt/dom/client/StyleInjector.java (right):

http://gwt-code-reviews.appspot.com/15803/diff/4001/4004#newcode35
Line 35: "head").getItem(0));
line too long

http://gwt-code-reviews.appspot.com/15803/diff/4001/4004#newcode79
Line 79: private static final JsArrayInteger STYLE_ELEMENT_LENGTHS =
JavaScriptObject.createArray().cast();
two lines too long

http://gwt-code-reviews.appspot.com/15803/diff/4001/4004#newcode195
Line 195: * previously-created element and adding a new one.
Should mention in the doc on these methods returning StyleElement that
on IE they may include more than just the injected contents. Tempted to
suggest making them void return.

http://gwt-code-reviews.appspot.com/15803

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] [google-web-toolkit commit] r5183 - Hooking up a couple of missing cause chains in the server-side RPC exception handling code.

[codesite-noreply]

Author: sco...@google.com
Date: Fri Apr  3 09:36:11 2009
New Revision: 5183

Modified:
 
trunk/user/src/com/google/gwt/user/client/rpc/impl/RequestCallbackAdapter.java
 
trunk/user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamReader.java

Log:
Hooking up a couple of missing cause chains in the server-side RPC  
exception handling code.

Also added a hack to dump a particular exception case to the console, to  
help us debug
an intermittent RPC test failure condition.

Modified:  
trunk/user/src/com/google/gwt/user/client/rpc/impl/RequestCallbackAdapter.java
==
---  
trunk/user/src/com/google/gwt/user/client/rpc/impl/RequestCallbackAdapter.java  
 
(original)
+++  
trunk/user/src/com/google/gwt/user/client/rpc/impl/RequestCallbackAdapter.java  
 
Fri Apr  3 09:36:11 2009
@@ -201,7 +201,8 @@
  caught = new InvocationException(encodedResponse);
}
  } catch (com.google.gwt.user.client.rpc.SerializationException e) {
-  caught = new IncompatibleRemoteServiceException();
+  caught = new IncompatibleRemoteServiceException(
+  "The response could not be deserialized", e);
  } catch (Throwable e) {
caught = e;
  } finally {

Modified:  
trunk/user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamReader.java
==
---  
trunk/user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamReader.java
  
(original)
+++  
trunk/user/src/com/google/gwt/user/server/rpc/impl/ServerSerializationStreamReader.java
  
Fri Apr  3 09:36:11 2009
@@ -537,8 +537,20 @@
throw new SerializationException(e);

  } catch (InvocationTargetException e) {
-  throw new SerializationException(e);
+  /*
+   * HACK(scottb): temporary hack to print internal exceptions to the
+   * console while we try to pin down a flaky RPC test that fails very
+   * intermittently. The stack trace gets lost when we send this server
+   * exception back to the client, because we currently don't serialize
+   * cause and stacktrace across the wire. We end up with a useless
+   * client-side stacktrace that has no cause, and that's what JUnit  
sees.
+   * We can remove this spam if we serialize cause/stacktrace back to  
the
+   * client even if we haven't yet solve the flaky RPC test issue.
+   */
+  e.getTargetException().printStackTrace(System.out);
+  e.getTargetException().printStackTrace(System.err);

+  throw new SerializationException(e.getTargetException());
  } catch (NoSuchMethodException e) {
throw new SerializationException(e);
  }

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Feature request: Better compiler error message

[Vitali Lovich]

  [java]Scanning for additional dependencies:
file:/home/vlovich/workspace/sacred_heart/src/ece456/client/services/ResourceFactory.java
 [java]   Computing all possible rebind results for
'ece456.client.services.comm.rpc.StaffService'
 [java]  Rebinding
ece456.client.services.comm.rpc.StaffService
 [java] Invoking 
 [java]Generating client proxy for remote service
interface 'ece456.client.services.comm.rpc.StaffService'
 [java]   Analyzing
'ece456.client.services.comm.rpc.StaffService' for serializable types
 [java]  Analyzing methods:
 [java] public abstract void
addVisit(ece456.client.services.comm.types.DBPatientVisit visit)
throws ece456.client.services.comm.types.RPCError
 [java]Parameter:
ece456.client.services.comm.types.DBPatientVisit visit
 [java]
ece456.client.services.comm.types.DBPatientVisit
 [java]  [ERROR] Type
'ece456.client.services.comm.types.DBPatientVisit' was not
serializable and has no concrete serializable subtypes

Took me a good amount of time before I remembered I had missed the
default constructor.  At the very least it should print the
requirements for serializability - it would be nicer if it actually
told you the specific problem it found though.

Would that be possible?

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Re: Comment on NoClassMetadataOptimization in google-web-toolkit

[Joel Webber]

The RPC subsystem has been updated in trunk to deal with this properly
(using a server-side type map). If you're seeing breakage as a result of
this, please describe the scenario in detail.

On Fri, Apr 3, 2009 at 10:43 AM,  wrote:

>
> Comment by kibork:
>
> Enabling this option breaks all RPC calls that do return some "complex"
> type(also not void or primitive).
>
>
>
> For more information:
>
> http://code.google.com/p/google-web-toolkit/wiki/NoClassMetadataOptimization
>
> >
>

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Comment on NoCastCheckingOptimization in google-web-toolkit

[codesite-noreply]

Comment by kibork:

First impression is that this really makes some performance boost. At least  
it's noticeable. I'll try to make some benchmarking and calculate absolute  
values.


For more information:
http://code.google.com/p/google-web-toolkit/wiki/NoCastCheckingOptimization

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] Comment on NoClassMetadataOptimization in google-web-toolkit

[codesite-noreply]

Comment by kibork:

Enabling this option breaks all RPC calls that do return some "complex"  
type(also not void or primitive).



For more information:
http://code.google.com/p/google-web-toolkit/wiki/NoClassMetadataOptimization

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---

[gwt-contrib] More interfaces part 2

[Ed]

Hellu,

I would like to know whtat the current status is of "incoparating more
basis interface in GWT"?

We talked about this a long time ago, but there more important issues
then:
http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/2aad0c3459e2c7f/cd59f6b35714ed31?lnk=gst&q=more+interfaces

I still keep on bouncing my head against these kind of interface
issues:
Below another example, which I hope would give some more priority to
the issue:

I need a general TextWidget that "extends/implements" from Widget and
implements HasText, HasHtml.

I thought I could easily solve this with Generics... Not.. really (see
below).

I want to return a Widget as result of a method that creates a Widget
that implements HasHtml/HasText.
I tried something like this:
  CmsFormatResultText  create
(String item);

But calling this method isn't possible as the compiler complaints that
Widget isn't a valid substitute.

Body example:
 return new HTML("aaa");
Which isn't correct as the compiler also complaints  about not able to
convert HTML to W...

To solve this, I think I need a basis Widget interface instead of a
Widget class.

Please some feedback/advice on this.

-- Ed

--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---