Re: [gwt-contrib] Re: [RFC] GWT Widgets that ROCK!
Nice. And will you have the shorter: progress value=250 max=1000 / For permutations that are guaranteed to support it? On Wed, Mar 23, 2011 at 11:11 AM, John LaBanca jlaba...@google.com wrote: @dflorey - We do plan to include some HTML5 widgets using the Appearance pattern. HTML5 widgets follow a cool pattern where you can inline the fallback into the HTML5 element. Browsers that do not support the HTML5 element naturally show the fallback, while browsers that do support the HTML5 widgets hide the fallback. Example: progress value=250 max=1000 span id=downloadProgress25/span% !-- Only visible if progress not supported. -- /progress Source: http://www.quackit.com/html_5/tags/html_progress_tag.cfm For performance, we will use deferred bindings if we know that the element is or is not supported. However, its ambiguous for some user agents. For example, older versions of webkit do not support progress, but newer versions do. In IE6, IE8 (will never support HTML5 elements): span id=downloadProgress25/span% !-- Only visible if progress not supported. -- In all other browsers (might support the element now or in the future): progress value=250 max=1000 span id=downloadProgress25/span% !-- Only visible if progress not supported. -- /progress Thanks, John LaBanca jlaba...@google.com On Wed, Mar 23, 2011 at 10:06 AM, dflorey daniel.flo...@gmail.com wrote: I am wondering if you are considering to use html5 widgets if available and provide a fallback gwt implementation for browsers that do not (yet) support widgets like http://slides.html5rocks.com/#semantic-tags-2 I think in general GWT has the right tools for using native browser stuff whenever available and providing some js-pendants if they are not supported. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: [RFC] GWT Widgets that ROCK!
On Mon, Feb 28, 2011 at 3:22 AM, Thomas Broyer t.bro...@gmail.com wrote: On Saturday, February 26, 2011 9:14:37 PM UTC+1, Philippe Beaudoin wrote: 1) The ButtonCell(DefaultAppearance.Resources) constructor can be confusing, I think it should be dropped. 2) Providing a custom DefaultAppearance.Resources lead to somewhat smelly code. -1 on both the above (note: ClientBundle only reads the annotations from the method definition, it does not look at the overridden methods) Agreed on (2), still not sure about (1) even after the discussing it with Jeff. I'd like to see his reply on this. Also, I'd love to hear your thoughts on why the extra constructor is not confusing in the use case I proposed (and why it is needed). 3) Minor one-time style modifications are hard to make. There's no one-time style modification; if you style an instance slightly differently, it's related to the context in which you use it, which means that you're likely to find that context a second time in your app (where you'd want/need to apply the same style modification); if not today, then tomorrow when you'll add a feature. It's similar to I won't externalize this value –golden number– into a constant because it's only used once (until it's used a second time, and you're still not sharing the value definition, so next time you'll want to change the value, you'll miss an instance). And it's actually not that hard to override a CssResource: 5 lines of Java and a CSS file. I don't like the comparison with a golden number: I think design is all about balancing the level of abstractions. Sure, using a golden number is a smell showing a missing abstraction level, but you can't say every decision about decreasing abstraction is similar to not externalizing a golden number. In that specific case, I disagree with you: in practice most people do not build webapps by abstracting out all the possible styles that they will need. The occasional float, the occasion padding, the occasional wider button to match a margin, the occasional combination of flush-left + rounded-right are typically described on a case-by-case basis. This is for four reasons: - Even in a well-styled app, styling is about choosing many components from a tool box. Abstracting all the styles lead to hard-to-manage combinatorial explosions (flush-left/rounded-right, flush-left/flush-right, ...) In that case, 5 lines of Java and a CSS resource are, in fact, a lot. - Many people are happy trading good-styling for increased development speed. - CSS is notoriously hard for most people, and is prone to context-dependent behaviors. If you find a fix that correct the look of a specific use of a widget, being forced to fix the global widget style can prove very hard. - It's really hard to apply aggressive refactoring to styling because it's typically not part of automated tests. Moreover, GWT already acknowledges that local/one-time styling can be useful by providing support for UiBinder's local ui:style (among other things). Cheers, Philippe 4) Contrary to Stephen, I think this design makes it hard to use selector-based CSS that assumes the widget obeys a precise DOM structure. 5) We should make sure GIN can be used to inject Appearance into ButtonCell and Resources into Appearance. 6) I agree with Thomas about: - Not being sure making Appearance an abstract class is the right choice I didn't give an opinion on the subject; I was just dismissing the argument. I believe in most cases Appearance classes would have only 'public' methods (and it could be documented as being how they would evolve, if ever: only adding 'public' methods), and specific subclasses would only override those methods and add non-public ones (private or protected). If a new 'public' method is added in a later version with a signature that conflicts with one you added in a subclass, because your method would have a lesser visibility, your code would no longer compile. If you need public to add methods, then it's probably a sign of code smell, and you could still detect conflicts by configuring your IDE to mark as errors an overridden method missing the @Overrides annotation (it wouldn't work if the class is a third-party lib you're using though; should there be an equivalent compiler switch?). Finally, I don't think there would be much inheritance among Appearance classes (even user-made ones), so the case of classes turning into interfaces as we saw in GWT 2.2 is unlikely to happen. In brief, I'm fine with abstract classes, and I'd be fine interfaces too; it's just that the argument about compatibility when the API evolves is to be taken with care. Widgets already have see a few methods added in their lifetime and I don't think anyone complained about a new method breaking their code; it's just how OOP works after all. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: [RFC] GWT Widgets that ROCK!
On Mon, Feb 28, 2011 at 10:30 AM, Jeff Larsen larse...@gmail.com wrote:
By forcing the user to do
new DefaultAppearance(Resource)
you're removing their ability to globally change the appearance. You've now
introduced a much tighter coupling than was there previously. As a for
instance, lets say I wanted different button styles, I go ahead and extend
the ClientBundle and apply then everything gets styled to my liking.
Now lets say there is some html5 new button hotness that we want to have
access to, or we need to add different Aria support etc. I can swap out the
Appearance class globally with deferred binding by keeping both constructors
in its current form. By getting rid of the constructor, I have to find every
instance of my classes and change them programmatically to not use
DefaultAppearance, but the new appearance. Now I'm good and I'm in a even
more difficult refactor if I need to change the appearance based on
locale/browser etc.
In its current form, I don't think the constructor accepting a
CssResource lets GWT swap the default appearance without impacting the
user's code that relies on it. Let's look at your proposed
implementation for the constructor in question:
// Replace the styles used by this cell instance.
public ButtonCell(DefaultAppearance.Resources resources) {
this(new DefaultAppearance(resources));
}
This constructor is not using deferred binding. Therefore, if you want
user's code relying on it to switch to the new appearance you have to
roll-out a new implementation of the constructor. Let's say you do
that:
// Replace the styles used by this cell instance.
public ButtonCell(DefaultAppearance.Resources resources) {
this(new NewDefaultAppearance(resources));
}
The problem, here, is that you are passing DefaultAppearance.Resources
to NewDefaultAppearance. It means that your new appearance
implementation cannot use CSS classes that did not exist in the
original CssResource. In fact, in the current implementation, the
CssResource is defined by the Appearance _implementation_ (it's
DefaultAppearance.Resource, not Appearance.Resource).
The confusion therefore is:
a) Will ButtonCell(DefaultAppearance.Resources resources) update its
appearance automatically when GWT upgrades to a new default
appearance; OR
b) Will it bind me forever to DefaultAppearance?
My proposition of dropping it was assuming you wanted to go with (b),
now I understand that you want the behavior of (a) -- which I agree is
much preferable -- but the current design does not seem to allow for
that goal. Maybe we should discuss ways to decouple the CssResource
from the Appearance implementations instead?
Also: I agree with the rest of your post and your reasoning.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: [RFC] GWT Widgets that ROCK!
Ok, I understand better now. In that case I see no difference between:
new ButtonCell(myResources)
and
new ButtonCell(new DefaultAppearance(myResources))
I prefer the second one, as the first one does not make it obvious that:
new ButtonCell()
and
new ButtonCell(myResources)
lead to potentially different appearances. The first one using
DefaultAppearance2013 and the second using DefaultAppearance.
You say people will get to injecting the ClientBundle, but even if
they do that they are tied to the old appearance -- unless they change
the type of the injected ClientBundle wherever they use it. It's
clearer in code:
@Inject ProviderButtonCell buttonCellProvider;
@Inject ProviderDefaultAppearance.Resouces resourcesProvider;
...
buttonCellProvider.get(); // Leads to DefaultAppearance2013
new ButtonCell(resourcesProvider.get()); // Leads to DefaultAppearance
If you inject the ClientBundle you cannot change the global appearance
simply by switching one binding. In other words: the convenience
constructor doesn't buy you anything.
(What you can do, however, is inject the appearance itself, and this
should be the recommended pattern given the fact that the ClientBundle
depends on the Appearance implementation.)
Cheers,
Philippe
On Mon, Feb 28, 2011 at 11:34 AM, John LaBanca jlaba...@google.com wrote:
Let me clarify what I had in mind for replacing the default GWT appearance.
In the future, we might add a new DefaultAppearance implementation, but
would leave the existing one. We would probably give it some trendy name,
like ModernAppearance or DefaultAppearance2013, leaving DefaultAppearance.
The GWT deferred binding for Appearance would be changed to point to
DefaultAppearance2013.
Using the default constructor will result in being automatically upgraded to
the new appearance:
new ButtonCell(); // Always uses the most recent Apperance.
Using the Resources convenience constructor will use the old Appearance.
new ButtonCell(myResources); // Uses DefaultAppearance. May be deprecated
when new appearances are added.
We would add a new convenience constructor for the new Appearance:
public ButtonCell(DefaultAppearance2013.Resources resources);
There is no way around the fact that DefaultAppearance.Resources are tied to
DefaultAppearance and won't carry over to the new DefaultAppearance2013.
On Mon, Feb 28, 2011 at 2:23 PM, Philippe Beaudoin
philippe.beaud...@gmail.com wrote:
On Mon, Feb 28, 2011 at 10:30 AM, Jeff Larsen larse...@gmail.com wrote:
By forcing the user to do
new DefaultAppearance(Resource)
you're removing their ability to globally change the appearance. You've
now
introduced a much tighter coupling than was there previously. As a for
instance, lets say I wanted different button styles, I go ahead and
extend
the ClientBundle and apply then everything gets styled to my liking.
Now lets say there is some html5 new button hotness that we want to have
access to, or we need to add different Aria support etc. I can swap out
the
Appearance class globally with deferred binding by keeping both
constructors
in its current form. By getting rid of the constructor, I have to find
every
instance of my classes and change them programmatically to not use
DefaultAppearance, but the new appearance. Now I'm good and I'm in a
even
more difficult refactor if I need to change the appearance based on
locale/browser etc.
In its current form, I don't think the constructor accepting a
CssResource lets GWT swap the default appearance without impacting the
user's code that relies on it. Let's look at your proposed
implementation for the constructor in question:
// Replace the styles used by this cell instance.
public ButtonCell(DefaultAppearance.Resources resources) {
this(new DefaultAppearance(resources));
}
This constructor is not using deferred binding. Therefore, if you want
user's code relying on it to switch to the new appearance you have to
roll-out a new implementation of the constructor. Let's say you do
that:
// Replace the styles used by this cell instance.
public ButtonCell(DefaultAppearance.Resources resources) {
this(new NewDefaultAppearance(resources));
}
The problem, here, is that you are passing DefaultAppearance.Resources
to NewDefaultAppearance. It means that your new appearance
implementation cannot use CSS classes that did not exist in the
original CssResource. In fact, in the current implementation, the
CssResource is defined by the Appearance _implementation_ (it's
DefaultAppearance.Resource, not Appearance.Resource).
The confusion therefore is:
a) Will ButtonCell(DefaultAppearance.Resources resources) update its
appearance automatically when GWT upgrades to a new default
appearance; OR
b) Will it bind me forever to DefaultAppearance?
My proposition of dropping it was assuming you wanted to go with (b),
now I understand that you want the behavior of (a) -- which
Re: [gwt-contrib] Re: [RFC] GWT Widgets that ROCK!
On Monday, February 28, 2011 12:42:30 PM UTC-8, John LaBanca wrote: On Mon, Feb 28, 2011 at 3:14 PM, Jeff Larsen lars...@gmail.com wrote: On Mon, Feb 28, 2011 at 1:34 PM, John LaBanca jlab...@google.com wrote: Let me clarify what I had in mind for replacing the default GWT appearance. In the future, we might add a new DefaultAppearance implementation, but would leave the existing one. We would probably give it some trendy name, like ModernAppearance or DefaultAppearance2013, leaving DefaultAppearance. The GWT deferred binding for Appearance would be changed to point to DefaultAppearance2013. Using the default constructor will result in being automatically upgraded to the new appearance: new ButtonCell(); // Always uses the most recent Apperance. Using the Resources convenience constructor will use the old Appearance. new ButtonCell(myResources); // Uses DefaultAppearance. May be deprecated when new appearances are added. We would add a new convenience constructor for the new Appearance: public ButtonCell(DefaultAppearance2013.Resources resources); There is no way around the fact that DefaultAppearance.Resources are tied to DefaultAppearance and won't carry over to the new DefaultAppearance2013. That wouldn't have to be the case though would it? Couldn't we stick the Resource in the Appearance, then if the new DefaultAppearance2013 for Button doesn't need to add new css definitions, there then is no need to add an additional constructor or change up the style definitions. Should something happen where DefaultAppearance2013 needs additional classes you still have the option of creating a new ctor for that new theme, you've just given yourself some more options down the road. The main drawback here is that the Appearance.Resources may have css classes that are unused in descendant appearances. If that burden seems too high, then there still is nothing stopping you from implementing the multiple ctor solution. Thats actually a big problem. DefaultAppearance.Resources may specify a background gradient image, but in the future we can use CSS to specify a background gradient. So, we end up with an unused image and users are confused about why the gradient doesn't apply. Worse, if we want to add a style name or resources to the interface, thats a breaking change. Still, if DefaultAppearance2013 is a minor change that uses all of the same style names, we could subclass Appearance and use the same Resources. It would depend on how much of a change we make to the DOM structure. I agree, I think defining the ClientBundle outside the Appearance implementation is a bit smelly... But, IMHO this smell is still present in the constructor accepting a DefaultAppearance.Resources, and the constructor-explosion problem mentioned by Jeff tends to confirm it. I think we should acknowledge that ClientBundle depends on the Appearance implementation and invite users to inject Appearance rather than the ClientBundle. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: [RFC] GWT Widgets that ROCK!
John, I really like this idea. It's well thought-out and the customization
hooks seem at once powerful and easy to use. I like the use of
replace-with to provide a simple way to perform an app-wide appearance
switch. Here are a couple of remarks:
Sorry it's so long. Here is the *tl;dnr* version:
1) The ButtonCell(DefaultAppearance.Resources) constructor can be confusing,
I think it should be dropped.
2) Providing a custom DefaultAppearance.Resources lead to somewhat smelly
code.
3) Minor one-time style modifications are hard to make.
4) Contrary to Stephen, I think this design makes it hard to use
selector-based CSS that assumes the widget obeys a precise DOM structure.
5) We should make sure GIN can be used to inject Appearance
into ButtonCell and Resources into Appearance.
6) I agree with Thomas about:
- Not being sure making Appearance an abstract class is the right choice
- Favoring :hover and other pseudoclasses in the DefaultAppearance.
- - - - -
Now the long version...
*1) The ButtonCell(DefaultAppearance.Resources) constructor can be
confusing, I think it should be dropped.*
This constructor gives the impression that you are using the app-wide
Appearance where in fact you are using DefaultAppearance. This could lead to
the following confusing use case:
- The user has two type of buttons: some initialized with new ButtonCell()
and some with new ButtonCell(otherCellButtonResources)
- He changes the style app-wide via replace-with
- Buttons initialized with new ButtonCell() change, the ones initialized
with new ButtonCell(otherCellButtonResources) don't.
Dropping that constructor would make it explicit you are actually forcing
the use of DefaultAppearance.
*2) Providing a custom DefaultAppearance.Resources lead to somewhat smelly
code.*
DefaultAppearance.Resources ties buttonCellStyle() to a specific CSS
@Source. Therefore, I believe overriding it means writing something like:
public interface MyResources extends
ButtonCell.DefaultAppearance.Resources {
@Override
@Source(com/mygroup/myapp/client/ButtonCell.css)
Style buttonCellStyle();
}
Maybe it's just me, but this looks slightly smelly. Also, does GWT.create()
like two @Source for the same method?
*3) Minor one-time style modifications are hard to make.*
Defining a custom Appearance or Resources is good when you want to style all
the buttons in your app, but impractical for small changes like adjusting
padding for a single button. We should think about a way to allow that (and
make sure it works in UiBinder). Ideas:
- Provide an addStyleName() in CellButton and Appearance. I don't like this,
however, as it creates the problem mentioned by Stephen (see point 4 below)
-- moreover, I really like the idea of Appearance moving us to more
semantic styling.
- Provide a setProperty(String name, String value) in CellButton and
Appearance and let Appearance apply it however it likes
- Provide semantic methods for frequently applied properties, like
setMargin(), setPadding()...
I'm really not sure I like any of the above proposals however. Maybe we
should just acknowledge that as a limitation of the new styling mechanism?
Is it too limiting?
*4) Contrary to Stephen, I think this design makes it hard to use
selector-based CSS that assumes the widget obeys a precise DOM structure.*
This is because:
- There is no public addStyleName on ButtonCell so the user cannot apply a
custom CSS class and then rely on CSS selectors to style deeper elements.
- The CSS styles are obfuscated (right?), therefore writing a CSS rule that
affects the widget needs an access to DefaultAppearance.Resources.
- DefaultAppearance.Resources is Appearance-specific. So if we modernize the
widget look and feel in a way that changes the widget's DOM structure, we
simply provide a new Resources type. CSS styles developed for the old
DefaultAppearance.Resources cannot be used with the new widget because the
types are not compatible.
*5) We should make sure GIN can be used to inject Appearance
into ButtonCell and Resources into Appearance.*
Weak coupling between ButtonCell, Appearance, and Resource seems like a
perfect use-case for DI. I have not reviewed the code from that perspective,
but it would be nice if we allowed users to subclass ButtonCell and
Appearance to provide @Inject-ed versions.
*6) I agree with Thomas about:*
- Not being sure making Appearance an abstract class is the right choice.
- Favoring :hover and other pseudoclasses in the DefaultAppearance.
Cheers,
Philippe
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: [RFC] GWT Widgets that ROCK!
*1) The ButtonCell(DefaultAppearance.Resources) constructor can be confusing, I think it should be dropped. * I would prefer the option. Lets say you have a 2 styles of buttons. A blue cancel button and a grey standard type button. With the current proposal, I would be able to use button and just inject different styles into the class. With your proposal, I have to extend button to be able to provide a different style than the norm for my cancel button, and what is worse, is that the style substitution is now buried in the .gwt.xml file. I'd much rather do my programming in the code than in .gwt.xml files. I would definitely like the ability to override styles without being forced to extend the widget classes. I thinks there is a misunderstanding. My proposal is just to not provide the convenience constructor, so instead of: new ButtonCell(resources); You'd do: new ButtonCell(new DefaultAppearance(resources)); Making it crystal-clear that your ButtonCell is using DefaultAppearance. The convenience constructor leads you to believe you're using resources together with the Appearance you bound in the .gwt.xml -- which is not true: you are using DefaultAppearance no matter which replace-with you provided. *3) Minor one-time style modifications are hard to make. * Is that really necessary as ButtonWidget extends CellWidget which extends Widget which gives you access to addStyleName and removeStyle name, making it easy to add padding and margin around widgets without having to get all Appearance.Resouce extendy. Somehow I missed that... Which makes my point (4) kind of moot as pointed out by Stephen. Now, addStyleName is very limited since you can only style the wrapping div. It's good enough to add blank padding, but it wont let you make the internal part of the button wider or taller... Unless you use CSS type selectors but, as Stephen points out, this makes the app dependent on a specific widget style, and the app breaks as soon as this widget DOM structure changes. (So you can't easily upgrade to newer styles.) In fact, I almost wish CellWidgets did not have a addStyleName given that it's really not that useful. I would rather have a slightly richer set of semantic styling methods in Appearance and having ways to access them from ButtonWidget (and UiBinder). * * Could/should we add javax.inject to the list of dependencies for GWT allowing for DI on some of the components out of the box? Interesting idea. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: [RFC] GWT Widgets that ROCK!
On Sat, Feb 26, 2011 at 4:35 PM, Jeff Larsen larse...@gmail.com wrote: Sorry, that is far better, but there still is a problem. With that way of doing things is then you've lost your ability to use the .gwt.xml file to swap out the Appearance as you're now using a new instead of a GWT.create. There are still two constructors: - The default (empty) constructor uses GWT.create() - A constructor accepting an Appearance. This appearance can be instantiate with new, if you want to inject a Resources manually, or with GWT.create if you're happy with the Appearance's default resource. Now, addStyleName is very limited since you can only style the wrapping div. It's good enough to add blank padding, but it wont let you make the internal part of the button wider or taller... Unless you use CSS type selectors but, as Stephen points out, this makes the app dependent on a specific widget style, and the app breaks as soon as this widget DOM structure changes. (So you can't easily upgrade to newer styles.) In fact, I almost wish CellWidgets did not have a addStyleName given that it's really not that useful. I would rather have a slightly richer set of semantic styling methods in Appearance and having ways to access them from ButtonWidget (and UiBinder). All true, I guess if I'm looking to alter the height/width of a cell widget's internals or its internal structure I would expect to extend the bundle. If I'm just looking to do things like set the float, padding/margine addStyleName is the perfect tool. Maybe there is a better way for dealing with boilerplate code, maybe with UiBinder as the hook. I'm not sure I'm still a little foggy on the best practices when dealing with CssResources especially with UiBinder. Another option would be an enhancement GEP to make it codegen that boilerplate for you. Admittedly it doesn't get rid of the code smell, but it does save your fingers some work. Ok, I think we're on the same page... I guess what I'd like is the ability to both add semantic styling methods to Appearance (a-la setFlatLeft, setFlatRight, setInnerWidth...) and to access these methods from UiBinder. (Also: GEP?) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Breaking change proposed: future proofing Activity in 2.1.1
Exactly, this is where I ran into this. On Fri, Dec 17, 2010 at 3:36 AM, Thomas Broyer t.bro...@gmail.com wrote: On Wednesday, December 8, 2010 9:16:16 PM UTC+1, PhilBeaudoin wrote: Just ran into an interesting little hack today. Basically, the interface includes a method: public void __do_not_implement_this_interface_extend_FooImpl_instead(); I'm far from convinced I like it, but it sure is right in your face in case you don't read javadocs! ;) interestingly, that's exactly what Hamcrest (used in many testing tools: JUnit, Mockito, etc.) does: http://code.google.com/p/hamcrest/source/browse/trunk/hamcrest-java/hamcrest-core/src/main/java/org/hamcrest/Matcher.java?r=645 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
Re: [gwt-contrib] Re: Breaking change proposed: future proofing Activity in 2.1.1
Just ran into an interesting little hack today. Basically, the interface includes a method: public void __do_not_implement_this_interface_extend_FooImpl_instead(); I'm far from convinced I like it, but it sure is right in your face in case you don't read javadocs! ;) Philippe On Wed, Dec 8, 2010 at 12:11 PM, Ray Ryan rj...@google.com wrote: I hope that doesn't come across as having ignored Neil, John et al. I do prefer using interface + abstract class, but I don't really believe that people actually read JavaDoc, and I'm certain we need to mess with this interface just a bit more. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
