Make getHtmlImports final

[Bob Schellink <sa...@gmail.com>]

Hi all,

I've migrated the Controls to use getHeadElements instead of the old String based getHtmlImports. 
One of the dangers of this refactoring is the impact it can have on existing applications still 
using getHtmlImports. This is especially problematic where users have subclassed and overwritten
getHtmlImports in order to specify alternative imports.

Having a compile time error instead of a behavioral error is cheaper to fix, so I suggest we remove 
getHtmlImports completely and make it final in AbstractControl. That way if it is subclassed the IDE 
will complain straight away prompting folk to upgrade to getHeadElements.

Any thoughts?

kind regards

bob

Re: Make getHtmlImports final

["Adrian A." <a....@gmail.com>]

> I've migrated the Controls to use getHeadElements instead of the old
> String based getHtmlImports.
FieldSet and FormTable still seem to use the old getHtmlImports.

> One of the dangers of this refactoring is
> the impact it can have on existing applications still using
> getHtmlImports. This is especially problematic where users have
> subclassed and overwritten
> getHtmlImports in order to specify alternative imports.
>
> Having a compile time error instead of a behavioral error is cheaper to
> fix, so I suggest we remove getHtmlImports completely and make it final
> in AbstractControl.
Than in the next version, the final getHtmlImports could be completely 
removed from AbstractControl too?

> That way if it is subclassed the IDE will complain
> straight away prompting folk to upgrade to getHeadElements.
>
> Any thoughts?
+1

IMHO, this should be also mentioned in the upgrade path even if 
getHtmlImports was made deprecated in the previous version.

Adrian.