Overridding DefaultWidgetSet class in 6.2+

Prior to 6.2 I was using a customised version of TextField (to allow input character constraints among other things).

On the server side I have a class extending TextField, and on the client side are classes extending VTextField and VTextArea - to determine which of these client side classes are used, I looked to the way it was implemented for TextField itself and copied it:

public class CustomWidgetSet extends DefaultWidgetSet
{
    @Override
    protected Class<?> resolveWidgetType(UIDL uidl)
    {
        final String tag = uidl.getTag();
        if ("customtextfield".equals(tag))
        {
            if (uidl.hasAttribute("multiline"))
                return VCustomTextArea.class;
            else if (uidl.getBooleanAttribute("secret"))
                return VPasswordField.class;
            else
                return VCustomTextField.class;
        }
        return super.resolveWidgetType(uidl);
    }

    @Override
    public Paintable createWidget(UIDL uidl)
    {
        final Class<?> type = resolveWidgetType(uidl);
        if (VCustomTextArea.class == type)
            return new VCustomTextArea();
        if (VCustomTextField.class == type)
            return new VCustomTextField();
        return super.createWidget(uidl);
    }
}

The above class was of-course specified as entry-point in the .gwt.xml file, now however this class seems more or less ignored, I can even have the new methods which are analogous to the old (ie: getImplementationByClassName(), resolveWidgetType() and createWidget()) all return null and it makes no difference.

Is there really no way for custom components to have custom mappings like some of the vaadin ones do, or am I stuck with the 1 to 1 mappings generated directly from @ClientWidget annotations?

Looks like you are doing it the 6.1-style...

protected Class<?> resolveWidgetType(UIDL uidl)

and

public Paintable createWidget(UIDL uidl)

are now (in Vaadin 6.2+)

protected Class<? extends Paintable> resolveWidgetType(UIDL uidl, ApplicationConfiguration conf)
public Paintable createWidget(UIDL uidl, ApplicationConfiguration conf)

When resolving the widget type, try

Class<? extends Paintable> widgetClass = conf.getWidgetClassByEncodedTag(uidl.getTag());
if (widgetClass == VMyWidget.class) { if uidl.hasAttribute(..) {..} ..}

and when creating a widget:

public Paintable createWidget(UIDL uidl, ApplicationConfiguration conf) {
		Paintable widget= super.createWidget(uidl, conf);

		if (widget instanceof VUnknownComponent) {

			final Class<? extends Paintable> classType = resolveWidgetType(uidl, conf);
			if (classType == VMyWidget.class) return new VMyWidget();

		}

		return widget; 
 }

It is strange if you are using 6.2 and your compiler is not complaining on the @Override annotations. So I guess you somehow are using old code extending the 6.1 DefaultWidgetSet

Johan Anas: Looks like you are doing it the 6.1-style...

The code displayed was to show how I used to do it, it's only there to give some clarification on what I'm trying to do, I thought it best to show what worked before, not what isn't now - I had changed it to pretty much exactly what you posted, but it didn't work any differently to me not specifying a custom entry-point at all. Then (as I described above) I tried changing the methods to return null to see if they were even making any difference, they weren't because everything still built and ran exactly the same when you would expect it not to work at all.

And I assume other custom widgets are shown correctly? Have you updated your build-widgetsets.xml file according to the 6.2 specs?

Fuzz F Fuzzalo: ... but it didn't work any differently to me not specifying a custom entry-point at all.

This might be related to the order in which your entry point is defined vs. the default entry point inherited from DefaultWidgetSet is executed. In previous Vaadin versions this did not matter as the DefaultWidgetSet GWT module did not contain an entry point.

I cannot recall for sure which is the correct order, but try moving your entry point above (or below) the inherits statements for the default widgetset.

Henri Sara: I cannot recall for sure which is the correct order, but try moving your entry point above (or below) the inherits statements for the default widgetset.

The entry-point was after the inherits - actually it was right at the end and the inherits was at the start, I put it at the start and everything works fine now, thanks a lot for your help.