Re: Composite question
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 it could be further locked down - to spare the developers as much as constrict them: add widgets to views, connect them up to events and data, and don't waste your time with styles layout. And I don't want to spend hours pulling my hair out because css won't re-set a style, only to discover that some renegade terrorist has buried a setWidth() or DOM manipulation landmine somewhere in code where it doesn't belong IMHO... But it seems like what I want isn't easily possible. Thanks for your help. Alan On Thu, May 21, 2009 at 7:41 PM, Ian Bambury ianbamb...@gmail.com wrote: 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, f***-you-mentality programmers will *never* need to set a width to, say, 100%? Setting absolutely everything in css will really complicate the css under some circumstances. There are some settings which really should be set in code (like setting the cell width to 100% in a HorizontalPanel) because they are necessary in building other widgets and all-but-impossible in css and/or will break if Google change that widget's structure Ian http://examples.roughian.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Composite question
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() {
private FlowPanel flowPanel = new FlowPanel();
initWidget( flowPanel );
};
public MyRestrictedWidget() {}
public doMyControlFreakThing() {
}
public void removeFromParent() { // example of a method possibly
required by GWT framework.
composite.removeFromParent();
}
}
On May 22, 4:27 am, alan m alan.jame...@gmail.com wrote:
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 it could be
further locked down - to spare the developers as much as constrict
them: add widgets to views, connect them up to events and data, and
don't waste your time with styles layout. And I don't want to spend
hours pulling my hair out because css won't re-set a style, only to
discover that some renegade terrorist has buried a setWidth() or DOM
manipulation landmine somewhere in code where it doesn't belong
IMHO...
But it seems like what I want isn't easily possible. Thanks for your help.
Alan
On Thu, May 21, 2009 at 7:41 PM, Ian Bambury ianbamb...@gmail.com wrote:
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, f***-you-mentality programmers will *never* need to set a width
to, say, 100%? Setting absolutely everything in css will really complicate
the css under some circumstances. There are some settings which really
should be set in code (like setting the cell width to 100% in a
HorizontalPanel) because they are necessary in building other widgets and
all-but-impossible in css and/or will break if Google change that widget's
structure
Ian
http://examples.roughian.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Composite question
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 in the first place! It defeats the purpose of using it for me - to provide component/view developers with my widgets that have only my methods exposed (only mine - bwa-ha-ha-ha!). Am I missing something here? Is there any better way of blocking all these Composite methods other than kludgy myWidget @Override? Thanks, Alan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Composite question
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 position/dimension/etc setters
which I had wanted hidden in the first place! It defeats the purpose
of using it for me - to provide component/view developers with my
widgets that have only my methods exposed (only mine - bwa-ha-ha-ha!).
Am I missing something here?
At first glance, yes.
Can you post a short sample code snippet?
You should be writing something like:
public class MyWidget extends Composite {}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: Composite question
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 Thu, May 21, 2009 at 6:00 PM, Jeff Chimene jchim...@gmail.com wrote:
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 position/dimension/etc setters
which I had wanted hidden in the first place! It defeats the purpose
of using it for me - to provide component/view developers with my
widgets that have only my methods exposed (only mine - bwa-ha-ha-ha!).
Am I missing something here?
At first glance, yes.
Can you post a short sample code snippet?
You should be writing something like:
public class MyWidget extends Composite {}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: Composite question
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 alan.jame...@gmail.com 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 in the first place! It defeats the purpose of using it for me - to provide component/view developers with my widgets that have only my methods exposed (only mine - bwa-ha-ha-ha!). Am I missing something here? Is there any better way of blocking all these Composite methods other than kludgy myWidget @Override? Thanks, Alan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Composite question
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();
initWidget(div);
}
public void add(Widget widget){
div.add(widget);
}
}
On Thu, May 21, 2009 at 6:00 PM, Jeff Chimenejchim...@gmail.com wrote:
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 position/dimension/etc setters
which I had wanted hidden in the first place! It defeats the purpose
of using it for me - to provide component/view developers with my
widgets that have only my methods exposed (only mine - bwa-ha-ha-ha!).
Am I missing something here?
At first glance, yes.
Can you post a short sample code snippet?
You should be writing something like:
public class MyWidget extends Composite {}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: Composite question
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 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 alan.jame...@gmail.com 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 in the first place! It defeats the purpose of using it for me - to provide component/view developers with my widgets that have only my methods exposed (only mine - bwa-ha-ha-ha!). Am I missing something here? Is there any better way of blocking all these Composite methods other than kludgy myWidget @Override? Thanks, Alan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Composite question
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 flexibly. Is there a reason why you don't want them to know its height or set its style name? If you have a use case, there may be another way around the problem. Ian http://examples.roughian.com 2009/5/21 alan m alan.jame...@gmail.com So... Is there any better way of blocking all these Composite methods other than kludgy myWidget @Override? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Composite question
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 paramount. You mention that I could extend Widget rather than Composite? But Widget also extends UIObject... maybe I should just extend Object.. and write my own API/toolkit ;-) But I would be interested in hearing more on this. Regards, Alan On Thu, May 21, 2009 at 6:46 PM, Ian Bambury ianbamb...@gmail.com wrote: 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 flexibly. Is there a reason why you don't want them to know its height or set its style name? If you have a use case, there may be another way around the problem. Ian http://examples.roughian.com 2009/5/21 alan m alan.jame...@gmail.com So... Is there any better way of blocking all these Composite methods other than kludgy myWidget @Override? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Composite question
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, f***-you-mentality programmers will *never* need to set a width to, say, 100%? Setting absolutely everything in css will really complicate the css under some circumstances. There are some settings which really should be set in code (like setting the cell width to 100% in a HorizontalPanel) because they are necessary in building other widgets and all-but-impossible in css and/or will break if Google change that widget's structure Ian http://examples.roughian.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
