<Swing Dev> <AWT Dev> Review request #3: 6852592 (revalidate() must be smarter)

[Artem Ananiev]

Christopher Deckers wrote:
> Anthony,
> 
> I think I disagree with Applet returning true to isValidateRoot. If I
> am not mistaken, I think I saw some people placing an applet in their
> component hierarchy as if it was a normal component. Invalidation
> should propagate so that outer components can revalidate and thus have
> proper layout calculations. Thus I think the only AWT components that
> should return true are the ones with an outer parent (window class
> hierarchy).

There's a reason to mark an Applet as a validate root: user should be 
able to call validate() on all the validate roots. If invalidate() goes 
up to the applet's parent (embedded frame), what code will call 
validate() on it? Do we want developers to write something like this:

     applet.getParent().validate();

? Embedded frame being a parent of any applet is an implementation 
details of the current AWT/Plugin code, so we shouldn't expose this to 
developers.

As for applets inserted to some regular applications as just plain 
Panels... If it's my own applet, a workaround is to override 
isValidateRoot() to return false. If it's not - do you expect it will 
call validate() on its top-level window? I don't think so. It's a 
responsibility of the host application. At least, we won't make any 
application worse than now.

> For the window method, shouldn't it be marked as final?

This looks like a good idea.

> And what about the AWT ScrollPane? Shouldn't it return true as well?

As well as this one.

Thanks,

Artem

> Hope this helps,
> -Christopher
> 
> 
> On Thu, Jul 23, 2009 at 1:57 PM, Anthony Petrov<Anthony.Petrov at sun.com> wrote:
>> Hello Swing and AWT teams,
>>
>> So here's the latest version of the fix:
>>
>> http://cr.openjdk.java.net/~anthony/7-23-invalidate-6852592.2/
>>
>> The specification has been modified, some stuff has been moved around.
>> Currently the spec is being reviewed by the CCC at Sun, and therefore is
>> kind of frozen. However, if anyone happen to find major problems with the
>> javadoc, please feel free to speak up.
>>
>> Suggestions for the code changes are still very welcome. Thank you in
>> advance!
>>
>> --
>> best regards,
>> Anthony
>>