Developers can never be trusted to do what they're told ;-) I'll pass
on your kind description of them!
But seriously, I have everything I need for css layout built in to my
widgets already (so no style is set in code; and no layout or style is
all-but-impossible in css). I was just wondering if
How about this: Create a new class that contains Composite and
extends nothing. Implement the methods using those from Composite
needed to make the new class work with GWT...and implement your own.
In other words:
class MyRestrictedWidget {
private Composite composite = new Composite() {
Hi,
I see how Composite is useful in theory for custom widgets, to wrap
rather than extend specific widgets prevent exposing all their
methods; but I have found that Composite itself has a LOT of methods
exposed, particularly the UIObject position/dimension/etc setters
which I had wanted hidden
On 05/21/2009 09:22 AM, alan m wrote:
Hi,
I see how Composite is useful in theory for custom widgets, to wrap
rather than extend specific widgets prevent exposing all their
methods; but I have found that Composite itself has a LOT of methods
exposed, particularly the UIObject
sure Jeff:
public class PanelWidget extends Composite {
private FlowPanel div;
public PanelWidget(){
super();
div = new FlowPanel();
initWidget(div);
}
public void add(Widget widget){
div.add(widget);
}
}
On
You are creating a composite widget which is going to be a UIObject so it
has UIObject methods.
But if you make a composite with three labels, then you probably don't want
(and it wouldn't be easy) to expose the setText method for all three.
Ian
http://examples.roughian.com
2009/5/21 alan m
On 05/21/2009 10:09 AM, alan m wrote:
sure Jeff:
Hi,
I'd misjudged your question, hence withdrawn my answer.
public class PanelWidget extends Composite {
private FlowPanel div;
public PanelWidget(){
super();
div = new FlowPanel();
So... Is there any better way of blocking all these Composite methods
other than kludgy myWidget @Override?
On Thu, May 21, 2009 at 6:23 PM, Ian Bambury ianbamb...@gmail.com wrote:
You are creating a composite widget which is going to be a UIObject so it
has UIObject methods.
But if you make
There is, by extending Widget, but it means more work and understanding the
way GWT works.
Do you have a reason for stopping certain UIObject methods being used or are
you just a control freak :-)
Generally speaking, those methods are there to allow your users to use the
widget you create more
Yes, I'm a control freak! ;-) But also my brief is to provide a widget
library with my (well, the client's) class names etc. and 100% css
layout and style, and prevent individual developers to use gwt's
setters (getters are less important) and diverge from the required
styles - consistency is
Sorry - I was going from memory and got the widget thing wrong. :-(
You'd have to go back to real basics to get around that.
Or tell your client to get developers they can trust to do as they are told
;-)
Is your client absolutely sure that their untrustworthy, pig-headed,
anarchic,
11 matches
Mail list logo
