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#7230<http://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
>>> answer<https://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.
