You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Sam Hough (JIRA)" <ji...@apache.org> on 2007/09/26 16:31:50 UTC

[jira] Created: (WICKET-1012) make setVisible, setEnable, add, addOrReplace, remove and removeAll non-final

make setVisible, setEnable, add, addOrReplace, remove and removeAll non-final
-----------------------------------------------------------------------------

                 Key: WICKET-1012
                 URL: https://issues.apache.org/jira/browse/WICKET-1012
             Project: Wicket
          Issue Type: Wish
          Components: wicket
    Affects Versions: 1.3.0-beta3
            Reporter: Sam Hough


I'd like to hook into them to track dirty components... The best alternative I've come up with so far is to iterate through all the components and keep a copy of their old state :(  Nice in that it will be smart about setVisible(false); setVisible(true) but not sure that is worth it.

Seems like it may also be useful to other developers for many other reasons including avoiding unwanted states ("don't add X here", "this must never be invisible"...). 

I'm not sure I fully understand the pros/cons of making things final as I've never produced code meant to be use by many developers with their various bad habits. If it is dangerous to alter the behaviour of these methods maybe add a warning comment e.g. "ALTER BEHAVIOUR AT OWN RISK - MAY BE CHANGED TO FINAL"

If Wicket code doesn't have a need to hook into these events then adding new hooks seems overkill. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Closed: (WICKET-1012) tracking dirty state (was:make setVisible, setEnable, add, addOrReplace, remove and removeAll non-final)

Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Johan Compagner closed WICKET-1012.
-----------------------------------

    Resolution: Fixed

Fixed this by giving Page one extra protected method:
componentChanged(Component,MarkupContainer)

This method will be called for everything that is changed so also auto components or none versionable components
its up to you what to do with that.

If the parent is given then it is a remove or add of the given component from the parent.

> tracking dirty state (was:make setVisible, setEnable, add, addOrReplace, remove and removeAll non-final)
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WICKET-1012
>                 URL: https://issues.apache.org/jira/browse/WICKET-1012
>             Project: Wicket
>          Issue Type: Wish
>          Components: wicket
>    Affects Versions: 1.3.0-beta3
>            Reporter: Sam Hough
>            Assignee: Johan Compagner
>             Fix For: 1.3.0-beta5
>
>
> I'd like to hook into them to track dirty components... The best alternative I've come up with so far is to iterate through all the components and keep a copy of their old state :(  Nice in that it will be smart about setVisible(false); setVisible(true) but not sure that is worth it.
> Seems like it may also be useful to other developers for many other reasons including avoiding unwanted states ("don't add X here", "this must never be invisible"...). 
> I'm not sure I fully understand the pros/cons of making things final as I've never produced code meant to be use by many developers with their various bad habits. If it is dangerous to alter the behaviour of these methods maybe add a warning comment e.g. "ALTER BEHAVIOUR AT OWN RISK - MAY BE CHANGED TO FINAL"
> If Wicket code doesn't have a need to hook into these events then adding new hooks seems overkill. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (WICKET-1012) tracking dirty state (was:make setVisible, setEnable, add, addOrReplace, remove and removeAll non-final)

Posted by "Johan Compagner (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/WICKET-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Johan Compagner updated WICKET-1012:
------------------------------------

    Assignee: Johan Compagner
     Summary: tracking dirty state (was:make setVisible, setEnable, add, addOrReplace, remove and removeAll non-final)  (was: make setVisible, setEnable, add, addOrReplace, remove and removeAll non-final)

> tracking dirty state (was:make setVisible, setEnable, add, addOrReplace, remove and removeAll non-final)
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WICKET-1012
>                 URL: https://issues.apache.org/jira/browse/WICKET-1012
>             Project: Wicket
>          Issue Type: Wish
>          Components: wicket
>    Affects Versions: 1.3.0-beta3
>            Reporter: Sam Hough
>            Assignee: Johan Compagner
>             Fix For: 1.3.0-beta5
>
>
> I'd like to hook into them to track dirty components... The best alternative I've come up with so far is to iterate through all the components and keep a copy of their old state :(  Nice in that it will be smart about setVisible(false); setVisible(true) but not sure that is worth it.
> Seems like it may also be useful to other developers for many other reasons including avoiding unwanted states ("don't add X here", "this must never be invisible"...). 
> I'm not sure I fully understand the pros/cons of making things final as I've never produced code meant to be use by many developers with their various bad habits. If it is dangerous to alter the behaviour of these methods maybe add a warning comment e.g. "ALTER BEHAVIOUR AT OWN RISK - MAY BE CHANGED TO FINAL"
> If Wicket code doesn't have a need to hook into these events then adding new hooks seems overkill. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.