Re: Uibinder inheriting and extending css classes (not just sharing them), best method?

2013-06-15 Thread RyanZA 
I might be way off here, but is there any reason to extend myTestClass at 
all? You can have multiple css classes per element, so simply doing:

ui:style
  .myLOCALTestClass{ ...more properties specific for this binder...}
/ui:style

And then assigning both myTestClass and myLOCALTestClass to the element 
should have the local specific changes overwriting the global ones.

On Saturday, June 15, 2013 2:59:35 AM UTC+2, GWTter wrote:

 Hi Joseph,

 Thanks for the reply. You're right and I actually do this elsewhere 
 extending cssresource interfaces and using the @shared which also works; 
 it's definitely the way to go for larger extensions/additions that aren't 
 as local.
 However what I like about the ui:binder approach is you don't have to 
 worry about ensuring the styles are injected and less boilerplate to 
 utilize the cssresource (even though it's not THAT much of a hassle). The 
 other really nice thing is you can override/extend styles more easily with 
 the approach I described for local changes (at least in my opinion). That's 
 why I just wanted to see if there was a way to extend it without having to 
 specify the src like in the approach above, or if it's even recommended.

 Thanks again,

 -Seth

 On Friday, June 14, 2013 6:01:12 PM UTC+2, Joseph Lust wrote:

 Seth,

 Currently I can do this by setting ui:style 
 src='relativepath/MyCss.css in A and B and it works nicely, uibinder 
 takes care of injecting the styles and everything. However I'm not sure if 
 this is the best way. There's also the issue that if I move A and B then 
 the relative path breaks (since absolute paths still aren't 100% functional 
 issue#7230http://code.google.com/p/google-web-toolkit/issues/detail?id=7230).
  
 Does anyone have a clue or is this the preferred method?


 You might want to look at this previous 
 answerhttps://groups.google.com/forum/?fromgroups#!searchin/google-web-toolkit/lust$20cssresource/google-web-toolkit/XDTiBioiIuo/ZFHeGB1jT0IJ.
  
 If you do the overriding in the Java class backing your UI binder, then the 
 refactoring worries won't be a problem. You can still handle the 
 refactoring in UiBinder, but you'll have to set Eclipse (or IDE of choice) 
 to do FQN replacements in all .xml files.


 Sincerely,
 Joseph



-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Uibinder inheriting and extending css classes (not just sharing them), best method?

2013-06-15 Thread GWTter 
Hi Ryan,

I don't think you're way off, this is definitely a way to do it but there 
are a few caveats. 

You have to consider that in order to do it this way (assuming you're style 
is coming from another cssresource) you would have to:
- declare the cssresource that had the original style via ui:with and then 
make sure it is injected since uibinder only takes care of injecting the 
ui:style. 
- (maintainability): you would have to make sure to set all the styles that 
were set on the object originally (or any future ones if other classes are 
added) including your new extension since setStyleName would clear them all 
out (this would make your local style less maintainable and have to know 
more about the external one than just what it wanted to extend). With the 
extension approach even if the original style is deleted the local 
extension would still apply with no errors.

These were the things I was trying to avoid with this approach. Either way 
thanks for your reply, it should help clarify options.

-Seth

On Saturday, June 15, 2013 3:35:25 PM UTC+2, RyanZA wrote:

 I might be way off here, but is there any reason to extend myTestClass at 
 all? You can have multiple css classes per element, so simply doing:

 ui:style
   .myLOCALTestClass{ ...more properties specific for this binder...}
 /ui:style

 And then assigning both myTestClass and myLOCALTestClass to the element 
 should have the local specific changes overwriting the global ones.

 On Saturday, June 15, 2013 2:59:35 AM UTC+2, GWTter wrote:

 Hi Joseph,

 Thanks for the reply. You're right and I actually do this elsewhere 
 extending cssresource interfaces and using the @shared which also works; 
 it's definitely the way to go for larger extensions/additions that aren't 
 as local.
 However what I like about the ui:binder approach is you don't have to 
 worry about ensuring the styles are injected and less boilerplate to 
 utilize the cssresource (even though it's not THAT much of a hassle). The 
 other really nice thing is you can override/extend styles more easily with 
 the approach I described for local changes (at least in my opinion). That's 
 why I just wanted to see if there was a way to extend it without having to 
 specify the src like in the approach above, or if it's even recommended.

 Thanks again,

 -Seth

 On Friday, June 14, 2013 6:01:12 PM UTC+2, Joseph Lust wrote:

 Seth,

 Currently I can do this by setting ui:style 
 src='relativepath/MyCss.css in A and B and it works nicely, uibinder 
 takes care of injecting the styles and everything. However I'm not sure if 
 this is the best way. There's also the issue that if I move A and B then 
 the relative path breaks (since absolute paths still aren't 100% 
 functional 
 issue#7230http://code.google.com/p/google-web-toolkit/issues/detail?id=7230).
  
 Does anyone have a clue or is this the preferred method?


 You might want to look at this previous 
 answerhttps://groups.google.com/forum/?fromgroups#!searchin/google-web-toolkit/lust$20cssresource/google-web-toolkit/XDTiBioiIuo/ZFHeGB1jT0IJ.
  
 If you do the overriding in the Java class backing your UI binder, then the 
 refactoring worries won't be a problem. You can still handle the 
 refactoring in UiBinder, but you'll have to set Eclipse (or IDE of choice) 
 to do FQN replacements in all .xml files.


 Sincerely,
 Joseph



-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Uibinder inheriting and extending css classes (not just sharing them), best method?

2013-06-14 Thread Joseph Lust 
Seth,

Currently I can do this by setting ui:style 
 src='relativepath/MyCss.css in A and B and it works nicely, uibinder 
 takes care of injecting the styles and everything. However I'm not sure if 
 this is the best way. There's also the issue that if I move A and B then 
 the relative path breaks (since absolute paths still aren't 100% functional 
 issue#7230http://code.google.com/p/google-web-toolkit/issues/detail?id=7230).
  
 Does anyone have a clue or is this the preferred method?


You might want to look at this previous 
answerhttps://groups.google.com/forum/?fromgroups#!searchin/google-web-toolkit/lust$20cssresource/google-web-toolkit/XDTiBioiIuo/ZFHeGB1jT0IJ.
 
If you do the overriding in the Java class backing your UI binder, then the 
refactoring worries won't be a problem. You can still handle the 
refactoring in UiBinder, but you'll have to set Eclipse (or IDE of choice) 
to do FQN replacements in all .xml files.


Sincerely,
Joseph

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Uibinder inheriting and extending css classes (not just sharing them), best method?

2013-06-14 Thread GWTter 
Hi Joseph,

Thanks for the reply. You're right and I actually do this elsewhere 
extending cssresource interfaces and using the @shared which also works; 
it's definitely the way to go for larger extensions/additions that aren't 
as local.
However what I like about the ui:binder approach is you don't have to worry 
about ensuring the styles are injected and less boilerplate to utilize the 
cssresource (even though it's not THAT much of a hassle). The other really 
nice thing is you can override/extend styles more easily with the approach 
I described for local changes (at least in my opinion). That's why I just 
wanted to see if there was a way to extend it without having to specify the 
src like in the approach above, or if it's even recommended.

Thanks again,

-Seth

On Friday, June 14, 2013 6:01:12 PM UTC+2, Joseph Lust wrote:

 Seth,

 Currently I can do this by setting ui:style 
 src='relativepath/MyCss.css in A and B and it works nicely, uibinder 
 takes care of injecting the styles and everything. However I'm not sure if 
 this is the best way. There's also the issue that if I move A and B then 
 the relative path breaks (since absolute paths still aren't 100% functional 
 issue#7230http://code.google.com/p/google-web-toolkit/issues/detail?id=7230).
  
 Does anyone have a clue or is this the preferred method?


 You might want to look at this previous 
 answerhttps://groups.google.com/forum/?fromgroups#!searchin/google-web-toolkit/lust$20cssresource/google-web-toolkit/XDTiBioiIuo/ZFHeGB1jT0IJ.
  
 If you do the overriding in the Java class backing your UI binder, then the 
 refactoring worries won't be a problem. You can still handle the 
 refactoring in UiBinder, but you'll have to set Eclipse (or IDE of choice) 
 to do FQN replacements in all .xml files.


 Sincerely,
 Joseph


-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Uibinder inheriting and extending css classes (not just sharing them), best method?

2013-06-13 Thread GWTter 
Hi all,

I have a Css resource that I would like to have inherited in other 
uibinders and be able to have these binders extend the css classes if need 
be. 

For example:
Let's say I have .myTestClass{ ...properties...} in MyCss.css which is 
setup as a CssResource syntactically.

Then I have UiBinder A and B. I want to inherit the class in both of them 
and extend the properties so that in binder A and B I would have
ui:style
  .myTestClass{ ...more properties specific for this binder...}
/ui:style

finally when I would access style.myTestClass respectively in A and B all 
the properties would be available (including the inherited ones).

Currently I can do this by setting ui:style 
src='relativepath/MyCss.css in A and B and it works nicely, uibinder 
takes care of injecting the styles and everything. However I'm not sure if 
this is the best way. There's also the issue that if I move A and B then 
the relative path breaks (since absolute paths still aren't 100% functional 
issue#7230http://code.google.com/p/google-web-toolkit/issues/detail?id=7230). 
Does anyone have a clue or is this the preferred method?

Thanks in advance,

-Seth

-- 
You received this message because you are subscribed to the Google Groups 
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.