Hi David, recent change made by you (use Component as super type for AceEdi

Hi David,
recent change made by you (use Component as super type for AceEditor) caused unusability for our application.
The reason is, that we are creating fields automatically based on metamodel of bean that is bound to the form. Our FieldBuilder is built to use at least AbstractField<T,C> as supertype.
I understand that there were reasons to make such a change, but is it good approach make a field (AceEditor is field) no as subtype of at least AbstractField?

I guess we are not alone who got into trouble by this move. I know there is possibility to create a “wrapper” that will make this field AbstractField again, but it is kind a cumbersome.

Thanks

JS

Hei JS,

I really hoped that my changes would not cause such inconvenience. As I was using a AbstractSingePropertyField and not a AbstractField I will give it some consideration and some testing.
I had to switch away from the AbstractSinglePropertyField as it was causing racing conditions when the value of the editor exceeded a lot of lines (or the string was just super long). Maybe I’ll find a way. I’ll keep you updated.

Thanks,
David

Hi David,
are you still considering/testing to switch back to AbstractField as base class for your component? We are upgrading our application from Vaadin 8 to Vaadin 23 and we were already using an Ace Editor Plugin for Vaadin 8. This Plugin is not supported anymore and I’m evaluating your component as an alternative. It would be easier to integrate your component with our framework if it inherits from AbstractField.

Thanks,
Gregor

We have exactly the same problem now, when this is just component and not implementing HasValue.