MyGWT Support

[darrell]

I am the author of the MyGWT library. I have received a several requests and questions about using MyGWT widgets in GWT Designer. I took a look at the guidelines for custom widget support and I believe there are a few big issues.

1. Many of the MyGWT widgets do not have public constructors and use style bits in the same manner as SWT.
2. Many of the MyGWT widgets use public members without getters and setters.

I am not familiar with your product but thought I would initiate a conversation to see if there are things that could be done on either side to add support for MyGWT widgets.

If this is something you would be interested in just let me know.

Thanks,
Darrell Meyer

[peterblazejewicz]

hi Darrell,

I've written some custom components using GWT Desinger and posted few questions on that forum related to custom component development,

1. Many of the MyGWT widgets do not have public constructors and use style bits in the same manner as SWT.

GWT designer expects javabean-like component with single, public non-parametrized constructor. Support for GWT toolkit components (many of them do not have public no-argument contructor and use parametrized constructors) are done by Instantiations team by writting custom widget creation schemas especially for Design view.
viewtopic.php?t=1558

That is similiar issue that is sometimes raised on GWT constributors list when UI design solution are discussed (no non-argument public constructor, no getters/setters for some fields, private access rules used instead of protected, etc)

You can:
- rewrite your components to use one public no argumnet constructor:

Code: Select all

MyGWTWidget w = new MyGWTWidget();
w.setParams(params);
w.setModel(model);
w.addItem(myItem);
// etc
rootPanel.add(w);

- add specialized factory-like method to create instance of yoru widgets based on arguments:

Code: Select all

MyGWTWidget w = MyGWTWidgetImpl.create(Object props, Object model);
rootPanel.add(w);

- add setters/getters for parameters that are used in constructor

The best you can do however is to somehow team-up with Instantiations GWT team to provide flexible solution similiar to their own used for GWT toolkit UI widgets.

Except of that GWT designer provides e.g. custom bean icon for components (I was happy submitter for that feature ) in component list/view tree, etc.

I was wondering some time ago about porting your widget for use in GWT Designer or just write additional api as extension (e.g. some static factories to create widgets in designer friendly way) but I don't have really much time for that being father of 1-year old boy and having now non-java programming related job,

Hope guys from Instantiations post more useful information for you,

I'm fan of your extension to GWT and happy user of GWT Designer (it works fantastic for Safari-related WYSWIG development) so I'll try to help you somehow,

regards,
Peter

[Eric Clayberg]

It is important that each Java widget toolkit (whether it be Swing, SWT or GWT) establish a standard. For Swing, Sun established the JavaBean standard and all Swing widgets (including 3rd party widgets) adhere to that standard. SWT uses a modified form of that standard, but then adheres to that modified form consistently. With GWT, Google has pretty much adopted the JavaBean standard with almost all of their widgets (although they don't state that formally).

These standards are very important from a GUI Builder's point of view as they provide a uniform way for the GUI Builder to talk to unknown components like random third party widgets. The toolkit provider (Sun, Eclipse, Google, etc.) can cheat a bit because they are providing the baseline set of widgets that the GUI builder needs to deal with. As GUI builder providers, we can build in special support for any widget that deviates from the standard. We can also build in special support for complex widgets with unique design time requirements (like tables, tabpanels, layouts, etc.). With third party widgets, there is no way for us to do this in advance. Either the third party widgets need to conform to the established standards (in which case, they should simply work in the GUI builder), or we need to look at each widget and provide special design time support (special parsing, special code gen, special layout interaction, etc.).

Our plan for 2008 is to look more closely at the various emerging GWT widget packages (MyGWT, GWT-EXT, GWT-WK, etc.) and consider adding built-in support for them. All of these packages are still in beta to my knowledge, so any serious effort we put in now could be wasted as the widget package APIs change. We already have indications from the GWT-EXT author that the GWT-EXT package will be moving to adopt the JavaBean standard already in place with the base GWT widgets. That is a good thing and will make it much easier for GWT-EXT to work with GWT Designer out of the box. We will still need to do some work on our end in order to handle any complex widgets with unique layout needs (the JavaBean spec does not address that issue).

1. Many of the MyGWT widgets do not have public constructors and use style bits in the same manner as SWT.

I would strongly suggest adding support for the standard JavaBean-compliant default constructor. GWT Designer doesn't care if you have additional constructors, but you must have a zero-argument constructor at minimum. We do not plan to add support for SWT-style constructors in GWT Designer. That only works in SWT Designer because the list of styles is defined in the SWT class. Even then, we need to define extra meta data in SWT Designer to handle all of the base SWT widgets,

2. Many of the MyGWT widgets use public members without getters and setters.

That approach does not conform to any GUI standard that I am aware off. Adding getters and setters would be very easy and highly advisable.

I am not familiar with your product but thought I would initiate a conversation to see if there are things that could be done on either side to add support for MyGWT widgets.

As stated above, we do plan to look at MyGWT once it is out of beta. In the mean time, there are many easy things you can do to make it play nicer with potential GUI builders. As the creator of an open source tool, you are entitled to a free copy of GWT Designer, if you wish (we have provided copies to the other widget library providers as well).

[darrell]

Peter - Thanks for the suggestions.

Eric - Thanks for the information. I think it would be a win for MyGWT if it's widgets could be used in your product. The changes needed would be easy to implement. I just need to figure out if this is what the MyGWT users want and if they are OK with the API changes as this would require them to refactor their code. This is where GWT shines as we are in Java and it is easy to find the code that needs to be updated.

When I first started creating the MyGWT widgets I was not lazily rendering the widgets. So the SWT style bits worked well as it allowed the widget to receive configuration details before the UI was rendered. Now, the widgets are rendered lazily, which will allow the widget to be configured prior to the DOM elements are created. The public fields can be made private and gettters and setters added. I think the changes would be good idea even without taking GWT Designer consideration as it is how GWT behaves and more in line with the Java bean model.

I still believe there will need to be some custom support for some of the MyGWT to allow specialized design time behavior. We do not have to worry about that now as the API changes will need to come first and the API needs to become stable.

In the short term, I will get familiar with GWT Designer and see how it works with the existing GWT widgets. I will also poll the current MyGWT developers to see if and when the API should be changed.

[Eric Clayberg]

Thanks for the information. I think it would be a win for MyGWT if it's widgets could be used in your product. The changes needed would be easy to implement. I just need to figure out if this is what the MyGWT users want and if they are OK with the API changes as this would require them to refactor their code. This is where GWT shines as we are in Java and it is easy to find the code that needs to be updated.

Keep in mind that GWT Designer only requires there to be a default constructor. It doesn't care about additional constructors, so you could leave those in place.

When I first started creating the MyGWT widgets I was not lazily rendering the widgets. So the SWT style bits worked well as it allowed the widget to receive configuration details before the UI was rendered. Now, the widgets are rendered lazily, which will allow the widget to be configured prior to the DOM elements are created. The public fields can be made private and getters and setters added. I think the changes would be good idea even without taking GWT Designer consideration as it is how GWT behaves and more in line with the Java bean model.

Note that you can add the getters and setters while keeping your fields public for existing code.

IOW, it is very likely you could enhance the MyGWT widgets to play nice with GWT Designer while preserving your existing API.

I still believe there will need to be some custom support for some of the MyGWT to allow specialized design time behavior. We do not have to worry about that now as the API changes will need to come first and the API needs to become stable.

I agree.

In the short term, I will get familiar with GWT Designer and see how it works with the existing GWT widgets. I will also poll the current MyGWT developers to see if and when the API should be changed.

Send an e-mail to opensource@instantiations.com to request a free GWT Designer license. Free licenses are available to any open source project developer.

[peterblazejewicz]

Hello,

Keep in mind that GWT Designer only requires there to be a default constructor. It doesn't care about additional constructors, so you could leave those in place.

@Eric
wow, that's new feature I was wating for, thanks!,
I quickly tested and it works:

Code: Select all

package com.mycompany.project.client;

import com.google.gwt.user.client.DOM;
import com.google.gwt.user.client.ui.HasText;
import com.google.gwt.user.client.ui.Widget;

public class MyButton extends Widget implements HasText {
   public MyButton() {
      setElement(DOM.createDiv());
      DOM.setStyleAttribute(getElement(), "backgroundColor", "#000");
      DOM.setStyleAttribute(getElement(), "color", "#FFF");
   }

   public MyButton(String text) {
      this();
      setText(text);
   }

   /* @Override */
   public String getText() {
      return DOM.getInnerText(getElement());
   }

   /* @Override */
   public void setText(String text) {
      DOM.setInnerText(getElement(), (text == null) ? "" : text);
   }
}

@Darrell:

n the short term, I will get familiar with GWT Designer and see how it works with the existing GWT widgets.

You will have to redesign way you are adding widgets to document I think,
From what I learned so far GWT Designer expects standart GWT-ish way of adding items to have WHYSWIG drag&drop feature. For example I think design view at least expects that parent component extends ComplexPanel (which enables adding widget feature). When I want to have drag&drop feature e.g. in custom list (based on <UL><li></li></UL> tags) had to inerit from either ComplexPanel or FlowPanel (using flow panel has a quirk because GWT designer adds "Empty flow panel" label in design view even if I'm using custom component),
this is pattern I had to follow:

Code: Select all

package code.google.com.gwt.iuilibrary.ui;

import com.google.gwt.user.client.DOM;
import com.google.gwt.user.client.ui.ComplexPanel;
import com.google.gwt.user.client.ui.Widget;
public class Screen extends ComplexPanel {
   public Screen() {
      setElement(DOM.createDiv());
      setStyleName("iui-Screeen");
   }
   /* @Override */
   public void add(Widget w) {
      super.add(w, getElement());
   }
   /* @Override */
   public void insert(Widget w, int beforeIndex) {
      super.insert(w, getElement(), beforeIndex, true);
   }
}

or:

Code: Select all

package code.google.com.project.iui.client;

import com.google.gwt.user.client.DOM;
import com.google.gwt.user.client.DeferredCommand;
import com.google.gwt.user.client.Element;
import com.google.gwt.user.client.Event;
import com.google.gwt.user.client.Timer;
import com.google.gwt.user.client.ui.ComplexPanel;
import com.google.gwt.user.client.ui.Widget;

public class List extends ComplexPanel {
   class UnselectTaskTimer extends Timer {
   }

   private boolean selected;
   private ListItem selectedItem;

   private Timer unselectTaskTimer;

   public List() {
      setElement(DOM.createElement("ul"));
   }
   /* @Override */
   public void add(Widget w) {
   }
   /* @Override */
   public void clear() {
   }

   public void clearItems() {
   }

   private ListItem findItem(Element eventSource) {
   }

   public String getID() {
   }

   public ListItem getSelectedItem() {
   }
   /* @Override */
   public void insert(Widget w, int beforeIndex) {
   }

   public boolean isSelected() {
   }
   /* @Override */
   public void onBrowserEvent(Event event) {
   }
   /* @Override */
   protected void onDetach() {
   }

   public void setID(String id) {
   }

   public void setSelected(boolean selected) {
   }

   public void setSelectedItem(ListItem item) {
   }

}

regards,
Peter

[Eric Clayberg]

wow, that's new feature I was wating for, thanks!, I quickly tested and it works:

New feature? GWT Designer has always supported that (e.g., multiple constructors for a widget as long as there is a default constructor present).

[peterblazejewicz]

wow, that's new feature I was wating for, thanks!, I quickly tested and it works:

New feature? GWT Designer has always supported that (e.g., multiple constructors for a widget as long as there is a default constructor present).

hi Eric,

I was sure that I had that error occuring before:
this is from yesterday build release:

eclipse.buildId=M20070921-1145
[...]
Error
Sat Jan 19 02:15:52 CET 2008
Designer internal error [6.5.1.20080117125226]: Only one constructor supported. Mark correct one with @wbp.parser.constructor JavaDoc tag.
java.lang.IllegalArgumentException: Only one constructor supported. Mark correct one with @wbp.parser.constructor JavaDoc tag.
at com.swtdesigner.gwt.model.widgets.panel.TopLevelUtils.getSingleConstructor(TopLevelUtils.java:173)
at com.swtdesigner.gwt.model.widgets.panel.ThisCompositeInfo.getMethodDeclaration(ThisCompositeInfo.java:169)
at com.swtdesigner.model.parser.JavaInfoParser.isParentAndChild(JavaInfoParser.java:1021)
at com.swtdesigner.model.parser.JavaInfoParser.findParentFor(JavaInfoParser.java:955)
at com.swtdesigner.model.parser.JavaInfoParser.getRootNodes(JavaInfoParser.java:526)
at com.swtdesigner.gef.DesignerEditor.parseCompilationUnit(DesignerEditor.java:1141)
[...]

This happens with Composite widgets in Design view,
unless fixed as noted in stack trace,

e.g.:

Code: Select all

/**
* @wbp.parser.constructor
*/
public LogReaderFilter() {
   this(LogReaderFilter.INFO, "info");
}

public LogReaderFilter(int type) {
   this(type, null);
}

public LogReaderFilter(int type, String text) {
   checkBox = new CheckBox();
   initWidget(checkBox);
   setStyleName("yui-log-filtergrp");
   setType(type);
   setText((text == null) ? "Checkbox" : text);
}

regards,
Peter

[Eric Clayberg]

I think we are talking about two different things.

I was referring to the fact that GWT Designer only needs a default constructor to consume a custom widget in another class.

The @wbp.parser.constructor is used to tell GWT Designer which constructor to edit in the deisgn view.

Those are unrelated issues.

[mwaschkowski]

Hi Eric,

Just a followup on what Peter was saying. Please bear with me as I just started using Designer.

Eric Clayberg wrote:Keep in mind that GWT Designer only requires there to be a default constructor. It doesn't care about additional constructors, so you could leave those in place.

I noticed that with 3.0.1 GWT designed does seem to care about additional constructors. If I have a no arg constructor and another constructor, I too get the same error message when switching to design mode. From what you are saying, I can't tell if thats proper behavior or not. Yes, there are separate consumption/design issues, but both relate to the use of a default constructor, but I do get an ERROR message is saying 'only one constructor supported' which seems a bit misleading.

Cannot Designer just choose to use the default constructor rather than having an error message come up?

Also, not sure what you meant by

The @wbp.parser.constructor is used to tell GWT Designer which constructor to edit in the deisgn view.

If I mark my 3 arg constructor with @wbp.parser.constructor and goto the design view, when I click on the constructor, I see a 0 show up in the row beneath, not the parameters of the constructor, which is exactly what happens when I mark my default constructor with the @wbp.parser.constructor comment, so not sure if that is correct or not either now <g>

Clarification appreciated!

Thanks,

Mark

[mwaschkowski]

Just noticed something further, you get an error only when adding something to the initWidget() call.

For example:

Code: Select all

import com.google.gwt.user.client.ui.Composite;
import com.google.gwt.user.client.ui.Label;

public class Test extends Composite {

  public Test() {
    //initWidget(new Label());
    initWidget(this);
  }

  public Test(String s){
   
  }
}

I can switch to the designer mode without error as the code stands, but if I uncomment the first line of the first constructor and comment the second, when I switch to designer mode the error below pops up.

HTH,

Mark

[peterblazejewicz]

hi Mark,

just guessing:
yoru composite "Design" view shows cosntructor for wrapped widget, not for your composite instance,
so for example:

Code: Select all

package com.mycompany.project.client;

import com.google.gwt.user.client.ui.Composite;
import com.google.gwt.user.client.ui.Label;

public class MyTooltip extends Composite {
  /**
   *
   */
  public MyTooltip() {
    this("Tooltip");
  }

  /**
   * @param text
   */
  public MyTooltip(String text) {
    this(text, false);
  }

  /**
   * @wbp.parser.constructor
   * @param text
   * @param wrap
   */
  public MyTooltip(String text, boolean wrap) {
    final Label label = new Label("test");
    label.setWordWrap(wrap);
    initWidget(label);
  }

}


will show constructor args which are default to GWT Label component (one argument for text indexed from 0);

However if I wrap my Tootlip into new composite:

Code: Select all

package com.mycompany.project.client;

import com.google.gwt.user.client.ui.Composite;
import com.mycompany.project.client.MyTooltip;

public class MyTootlipComposite extends Composite {

  public MyTootlipComposite() {
    final MyTooltip myTooltip = new MyTooltip("Tooltip", false);
    initWidget(myTooltip);
  }

}

and change generated code to use 2 argument constructor then properties view will show correct arguments,
so I guess GWT Designer *always* use no-argument default constructor undless changed explicitely and

Code: Select all

@wbp.parser.constructor

is used only internally when generating widget preview (plugin needs somehow to now what arguments to use by java reflection and what should be used as default arugments for constructor,

regards,
Peter

[Eric Clayberg]

The @wbp.parser.constructor tag tells Designer which constructor to add new widgets to when editing the class.

Having multiple constructors is not an issue when using a Composite within another class (as long as there is at least a default constructoir present).

Multiple constructors is an issue when editing the Composite itself. In that case, which constructor should be parsed and edited in the design view is somewhat arbitrary.

[mwaschkowski]

OK, thanks for the clarification, esp about the tag, thats clear now.

Best,

Mark

[Eric Clayberg]

The latest GWT Designer build now includes some preliminary (beta level) support for MyGWT. Most MyGWT widgets are now droppable and renderable.

Fully supported widgets include: Button, ButtonBar, ToolBar, Tree, KeyPressTextBox and List.

Partially supported widgets include: ExpandBar, TabFolder, ContentPanel and WidgetContainer (these require additional edit time support)

Not supported yet: Table (requires significant special parsing and edit time support).