[Isomorphic]

Either version (positive or negative indication of whether something is an override point) would be equally easy to apply.

[twelve17]

Ok--I'll give it a shot with a positive annotation. I'm currently dealing with issues running a debug instance of Eclipse within Eclipse, so testing of the processor is delayed a bit. :)

[twelve17]

I have completed a preliminary version of the OverridePoint annotation processor.

It currently is not limiting its search of source files to those only in a particular package (e.g. com.smartclient, for example). Instead, it is doing the following:

1. generate an index of all methods marked with an @OverridePoint annotation, and their enclosing classes

2. search sources for classes that extend those from #1, then see if a method in the child class overrides any methods that do NOT have @OverridePoint.

For each method found, a warning will be printed, which, in eclipse, will show up in the "warnings" section of the Problems console. See "override-point-eclipse-warning.png" attachment for a sample of what that looks like in Eclipse.

There are various ways you could decide how to implement configuration/usage of the preprocessor. One way is to have a developer add a jar file to their Eclipse's annotation setting. See "annotation-support-kind-property.png" screen shot for an example. In addition, the screen shot shows a setting one can optionally include, which would cause the processor to report findings as errors instead of warnings, thus treating it with a same result as if it had been a compilation error.

The next attachment, "annotation-factory-path.png", shows the Eclipse configuration window for adding a jar file that contains the preprocessor.

I could not attach the actual processor jar file here, but can provide it, along with the source and example test maven projects and sources.

Suggestions welcome.

[twelve17]

I never received any feedback regarding my previous submission, and our team has since decided to migrate away from SmartGWT. Hence I have released the code in github for whoever would like to take a stab at implementing this in the SmartGWT framework.

The core module is available here:

https://github.com/twelve17/smartgwt-annotation-support

And a test module for testing said core module:

https://github.com/twelve17/smartgwt-annotation-test

Cheers,

Alex

[kevboy]

...

However, after giving this some more thought; I think I could see a way to use an extended form to solve this problem:

public abstract class AbstractCanvasItem extends CanvasItem {
	
	public abstract void setValue(JavaScriptObject jsObj);

}

and

public class CanvasItemForm extends DynamicForm {

	public CanvasItemForm() {
		super();
		// TODO Auto-generated constructor stub
	}

	public CanvasItemForm(JavaScriptObject jsObj) {
		super(jsObj);
		// TODO Auto-generated constructor stub
	}
	
	@Override
	public void editRecord(Record record)
	{
		FormItem[] fields = this.getFields();
		for(FormItem field : fields)
		{
			if(field.getClass().isAssignableFrom(AbstractCanvasItem.class))
			{
				JavaScriptObject jsObj = record.getAttributeAsJavaScriptObject(field.getName());
				
				((AbstractCanvasItem)field).setValue(jsObj);
			}
		}

super.editRecord(record);

	}
	
	@Override
	public void saveData()
	{
		FormItem[] fields = this.getFields();
		
		for(FormItem field : fields)
		{
			if(field.getClass().isAssignableFrom(AbstractCanvasItem.class))
			{
				this.setValue(field.getName(), (JavaScriptObject)field.getValue());
			}
		}
		
		super.saveData();
	}

}

look they would provide a generic solution that allows a DynamicForm to correctly set and get the values from custom canvasItems, provided those CanvasItems allow the setting and getting of their values as JavaScriptObjects.

I haven't actually tried this; I'd have to change quite a bit of code to make it work this way; but it looks like something that would work. Do you see any problems with this approach?
...

I'm trying out this approach but cannot get my CanvasItem to validate (i.e. get an error icon to appear). The item is essentially a TextItem with a hint that provides a dynamic float range from another data source. I've added a FloatRangeValidator to the CanvasItem and the debugger runs through the method but no error icon appears.

Any advice?

Do I need to propagate the setValidators call to the TextItem or override validate() in the CanvasItem?

Here is my code:

// In a class extending ValuesManager
    @Override
    public Boolean validate() {
        for (DynamicForm form : super.getMembers()) {
            FormItem[] fields = form.getFields();

            for (FormItem field : fields) {
                if (field instanceof ValueCanvasItem) {
                    this.setValue(field.getName(), field.getValue());
                    field.validate(); // doesn't work w/o this either
                }
            }
        }
        return super.validate();
    }

// In class extending AbstractCanvasItem
...
    private TextItem mainItem;
...
    @Override
    public void setValue(Object value) {
        mainItem.setValue(value);
    }
    
    @Override
    public Object getValue() {
        return mainItem.getValue();
    }

[kevboy]

Validation works fine now. I changed it to the following...

@Override
public Boolean validate() {
    for (DynamicForm form : super.getMembers()) {
        for (FormItem field : form.getFields()) {
            if (field instanceof ValueCanvasItem) {
                // Set field value
                field.setValue(field.getValue());
            }
        }
    }
    return super.validate();
}

However, saving doesn't working. Here is the code I have for saving:

// In a class extending ValuesManager
    @Override
    public void saveData() {
        onSaveData();
        super.saveData();
    }
    
    // Called from overloaded saveData()'s
    private void onSaveData() {
        for (DynamicForm form : super.getMembers()) {
            for (FormItem field : form.getFields()) {
                if (field instanceof ValueCanvasItem) {
                    // Calls overridden setValue(String, Object)
                    this.setValue(field.getName(), field.getValue());
                }
            }
        }
    }

In the debugger, after the setValue call, I called ValuesManager.getValue() with the field name but the value is not set. I can see that field.getValue() has a value so I'm not sure why it's not getting set. I think I tried calling form.setValue() too but that didn't work. Any ideas? Thanks!

[kevboy]

Another clue: Before calling ValuesManager.saveData(), I tried called ValuesManager.setValue() by manually getting the value from the CanvasItem and it works. It'd be tediuous to manually get the values from all the CanvasItems though.

[Isomorphic]

Hi Kevboy, this approach is out of date (and actually wasn't right in the first place) - see the new CanvasItem samples as well as the latest CanvasItem docs.

[jac001]

Dont be surpised if they never get back to you. It is so typical of them to only answer the easy questions or to mention some obscure post made by someone that you now have to go and look for as answers.

Typical! Never mind the fact that if they had better and more in depth documentation maybe we wouldnt be asking 'stupid' questions as how they see it.

[Isomorphic]

Someone appears to be having a bad day. But we'd just like to point out the irony that you've posted here complaining about Isomorphic not addressing issues when in reality, in response to a recurring question about CanvasItem, we created several new APIs, an extensive discussion of how to use them, and several samples :)

And here we get a post like yours when we provide a link to the new samples and docs! :)

[twelve17]

Someone appears to be having a bad day. But we'd just like to point out the irony that you've posted here complaining about Isomorphic not addressing issues[...]

Someone appears to be having a bout of short term memory. But I'd just like to point out that he does have a point that can be observed by the fact that you replied to the easy question which required a pointer to documentation and never bothered to reply to my suggested programattic implementation to address the fact that your API is fundamentally implemented in javadoc via usage of "this is a override point" text phrase, despite you stating that a suggested annotation implementation would be "easy for us to pervasively apply".

Also, I'd like to point out that the scenario you described in your response is not actually ironic. More likely to be ironic is your usage of smiley faces, which conveys the opposite meaning of your message, which is primarily condescending.

[Isomorphic]

The irony, to spell it out, is that when we take the time to create samples and documentation to address a recurring question, the response to this is someone complaining that we don't address questions. The textbook definition of irony.

Also, remember that when you read text, the sentiment is just in your head. Here the actual sentiment was chagrin.

It's not clear what you think could be improved about this approach - it seems clearly better than previously discussed approaches. But if you see an improvement, constructive feedback like that is always very welcome.

[twelve17]

I am speaking of the other subject in this post, regarding my submission.

[Isomorphic]

Regarding your submission, thanks for that, however, you are, to date, the only person who has requested any type of compile-time checking for whether something can be overridden - this is across all support, all training and all consulting that we do. Other people are informed about the JavaDoc cue for overrides and that's enough. Also, you've reportedly stopped using the product anyway, so that makes zero.

We have to work on what people are requesting first, so this submission is unfortunately going to have be parked for now.

[twelve17]

Regarding your submission, thanks for that, however, you are, to date, the only person who has requested any type of compile-time checking for whether something can be overridden - this is across all support, all training and all consulting that we do. Other people are informed about the JavaDoc cue for overrides and that's enough. Also, you've reportedly stopped using the product anyway, so that makes zero.

We have to work on what people are requesting first, so this submission is unfortunately going to have be parked for now.

I actually wasn't looking for an answer now, seeing that the post is quite old and we moved on. I was simply pointing out the other poster's point in that questions are not answered.

Also, funny and annoying that you mention that this is not be done based on my being the only one requesting. If such was the case, why would you waste my time having entertained the idea and discussed requirements with me in the first place (see earlier part of this thread) if you had no intention of following through?