[jira] Created: (WICKET-1602) Wicket resources - wicket is requesting resources every 1 hour
Wicket resources - wicket is requesting resources every 1 hour -- Key: WICKET-1602 URL: https://issues.apache.org/jira/browse/WICKET-1602 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.3 Reporter: Stefan Simik There is a problem with wicket ajax javascripts - there are reloading by browser every 1 hour, because the Expire header is hardcoded to 3600 seconds in WebResource#setHeaders() method. This problem bubbles up to commonly used class ResourceReference class, which internally works with PackageResource that uses our problematic class - WebResource. SIMPLE AND FAST SOLUTION -- The only thing, that is needed to fix this, is to change WebResource#setHeaders() to take the caching time from some wicket settings, so it is not hardcoded and can be configured by developer. NABBLE about this problem: http://www.nabble.com/forum/ViewPost.jtp?post=17117009&framed=y -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1600) Wicket tree improvement
[ https://issues.apache.org/jira/browse/WICKET-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595404#action_12595404 ] Matej Knopp commented on WICKET-1600: - Hi, I haven't got time to go through the patch in depth, so some of my comments might be irrelevant :) Overall, I like the idea a lot. I had in mind something like this, but perhaps little less radical. The idea of TreeState separated from tree has it's excuse. I though of usecase when the tree state could be e.g. kept in session. I.e. you have a navigation tree and different page instances would share the set of expanded/selected nodes. There is a slight complication now that deaulttreestate holds reference to tree, so I'm not sure how much is this relevant at all. The other thing I'm not sure about is removal of listeners. I do agree that the concept is a bit foreign to wicket but it did serve it's purpose. On the other hand, I don't think lot of people register other listener than the tree itself so even this might not be a problem. Also, the patch is a bit premature :) I don't have where to apply it, are you willing to keep it in sync with wicket trunk so it can be applied once 1.5 is branched? > Wicket tree improvement > --- > > Key: WICKET-1600 > URL: https://issues.apache.org/jira/browse/WICKET-1600 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4-M1 >Reporter: Sven Meier >Assignee: Matej Knopp >Priority: Minor > Fix For: 1.5-M1 > > Attachments: tree.diff > > > I see the following issues with Wicket's tree implementation that should be > solved: > AbstractTree and its subclasses were written with the Swing JTree API in > mind. This is not a bad thing per se, but the JTree abstractions are not very > well suited for a web application. Matej recently removed some of these > dependencies, but there's still a lot of code that uses TreeNode, > TreeModelEvent and such. > AbstractTree holds a TreeModel in its model, attaching a listener to it. This > is an unusual approach for a Wicket component: > - It implies that changes in the TreeModel are automatically propagated to > the user interface. This is not always the case, as in an ajax request the > AbstractTree has to be explicitely notified to update itself. > - It requires the AbstractTree to monitor the model for a replaced TreeModel. > Most importantly the TreeModel API is complicated and ambiguous (just see the > javadoc of TreeModelEvent and TreeModelListener) which makes life harder > especially for those who want to use AbstractTree with their own TreeModel > implementation (which is difficult enough). Although not directly visible in > the API, an implementor has to privide the parent of a node - see > AbstractTree#getParentNode(). Tree listeners and events are an annoyance > which doesn't match Wicket's elegance. > Currently many components in the AbstractTree hierarchy hold a reference to > real nodes of the TreeModel (e.g. junctionLink). TreeState seems like a > foreign concept to Wicket, holding references to nodes too. To support > detachment AbstractTree tests wether a node implements IDetachable, > effectively duplicating functionality that is normally provider by Component > and its model out of the box. > The nodes are currently used to identify state (e.g. the parent) in the tree. > To add a node, the nodes have to implement equals() and hashCode() to be > correctly identified in the tree state. This might be unacceptable, e.g. if > entities (business objects) are used as nodes, probably loaded from a > database. > Therefore I propose to refactor AbstractTree and subclasses as follows: > A new interface INodeProvider (similar to IDataProvider) defines a concise > API to define a tree of nodes. The method #model(Object) gives an implementor > the possibility to wrap nodes in a suitable model, e.g. a detachable one. The > provided model can handle #equal() and #hashcode() for identification of > nodes in the tree. > References to nodes are always indirect through the model, never to the real > node object. > Handling of node parents is completely managed inside AbstractTree, no need > for an ExtendedTreeModel. > The model of an AbstractTree is used for node selection, similar to > AbstractChoices. > Listeners are replaced with notification methods on AbstractTree. No need for > tree paths on changes. > Expansion state is held in the AbstracTree#TreeItems (instead of former > ITreeState) - similar to component visibility. > The attached patch tries to achieve all this (or at least show how a solution > could look like), additionally: > - AbstractTree now utilizes AbstractRepeater and > #setOutputMarkupPlaceholderTag() instead of custom solutions. > - The examples
[jira] Assigned: (WICKET-1600) Wicket tree improvement
[ https://issues.apache.org/jira/browse/WICKET-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg reassigned WICKET-1600: - Assignee: Matej Knopp matej and i have been talking about this for a good while. we were discussing something pretty similar to the patch. i think matej is waiting for the point in time when he can break the api and do the refactor. this help will help much, thanks! > Wicket tree improvement > --- > > Key: WICKET-1600 > URL: https://issues.apache.org/jira/browse/WICKET-1600 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4-M1 >Reporter: Sven Meier >Assignee: Matej Knopp >Priority: Minor > Fix For: 1.5-M1 > > Attachments: tree.diff > > > I see the following issues with Wicket's tree implementation that should be > solved: > AbstractTree and its subclasses were written with the Swing JTree API in > mind. This is not a bad thing per se, but the JTree abstractions are not very > well suited for a web application. Matej recently removed some of these > dependencies, but there's still a lot of code that uses TreeNode, > TreeModelEvent and such. > AbstractTree holds a TreeModel in its model, attaching a listener to it. This > is an unusual approach for a Wicket component: > - It implies that changes in the TreeModel are automatically propagated to > the user interface. This is not always the case, as in an ajax request the > AbstractTree has to be explicitely notified to update itself. > - It requires the AbstractTree to monitor the model for a replaced TreeModel. > Most importantly the TreeModel API is complicated and ambiguous (just see the > javadoc of TreeModelEvent and TreeModelListener) which makes life harder > especially for those who want to use AbstractTree with their own TreeModel > implementation (which is difficult enough). Although not directly visible in > the API, an implementor has to privide the parent of a node - see > AbstractTree#getParentNode(). Tree listeners and events are an annoyance > which doesn't match Wicket's elegance. > Currently many components in the AbstractTree hierarchy hold a reference to > real nodes of the TreeModel (e.g. junctionLink). TreeState seems like a > foreign concept to Wicket, holding references to nodes too. To support > detachment AbstractTree tests wether a node implements IDetachable, > effectively duplicating functionality that is normally provider by Component > and its model out of the box. > The nodes are currently used to identify state (e.g. the parent) in the tree. > To add a node, the nodes have to implement equals() and hashCode() to be > correctly identified in the tree state. This might be unacceptable, e.g. if > entities (business objects) are used as nodes, probably loaded from a > database. > Therefore I propose to refactor AbstractTree and subclasses as follows: > A new interface INodeProvider (similar to IDataProvider) defines a concise > API to define a tree of nodes. The method #model(Object) gives an implementor > the possibility to wrap nodes in a suitable model, e.g. a detachable one. The > provided model can handle #equal() and #hashcode() for identification of > nodes in the tree. > References to nodes are always indirect through the model, never to the real > node object. > Handling of node parents is completely managed inside AbstractTree, no need > for an ExtendedTreeModel. > The model of an AbstractTree is used for node selection, similar to > AbstractChoices. > Listeners are replaced with notification methods on AbstractTree. No need for > tree paths on changes. > Expansion state is held in the AbstracTree#TreeItems (instead of former > ITreeState) - similar to component visibility. > The attached patch tries to achieve all this (or at least show how a solution > could look like), additionally: > - AbstractTree now utilizes AbstractRepeater and > #setOutputMarkupPlaceholderTag() instead of custom solutions. > - The examples are modified and enhanced with 'add' and 'remove' > functionality, org.apache.wicket.examples.nested.Home shows usage of an Swing > TreeModel adapter. > - Lots of generics are added (Swing's TreeModel will probably never be > generic). > - The code is (hopefully) simplified. > I apologies for putting all this stuff into a single patch, but I wasn't able > to split these issues apart - it all depends on the proposed INodeProvider > interface. > For users of AbstractTree this solution has the following impacts: > - minor API changes for subclasses > - if a node is collapsed, all state of descendants will be lost, i.e. if the > node is expanded once again, all previously expanded children will stay > collapsed (similar to how Gnome handles trees) > - optimization for adding multiple new
[jira] Updated: (WICKET-1600) Wicket tree improvement
[ https://issues.apache.org/jira/browse/WICKET-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg updated WICKET-1600: -- Fix Version/s: 1.5-M1 > Wicket tree improvement > --- > > Key: WICKET-1600 > URL: https://issues.apache.org/jira/browse/WICKET-1600 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4-M1 >Reporter: Sven Meier >Assignee: Matej Knopp >Priority: Minor > Fix For: 1.5-M1 > > Attachments: tree.diff > > > I see the following issues with Wicket's tree implementation that should be > solved: > AbstractTree and its subclasses were written with the Swing JTree API in > mind. This is not a bad thing per se, but the JTree abstractions are not very > well suited for a web application. Matej recently removed some of these > dependencies, but there's still a lot of code that uses TreeNode, > TreeModelEvent and such. > AbstractTree holds a TreeModel in its model, attaching a listener to it. This > is an unusual approach for a Wicket component: > - It implies that changes in the TreeModel are automatically propagated to > the user interface. This is not always the case, as in an ajax request the > AbstractTree has to be explicitely notified to update itself. > - It requires the AbstractTree to monitor the model for a replaced TreeModel. > Most importantly the TreeModel API is complicated and ambiguous (just see the > javadoc of TreeModelEvent and TreeModelListener) which makes life harder > especially for those who want to use AbstractTree with their own TreeModel > implementation (which is difficult enough). Although not directly visible in > the API, an implementor has to privide the parent of a node - see > AbstractTree#getParentNode(). Tree listeners and events are an annoyance > which doesn't match Wicket's elegance. > Currently many components in the AbstractTree hierarchy hold a reference to > real nodes of the TreeModel (e.g. junctionLink). TreeState seems like a > foreign concept to Wicket, holding references to nodes too. To support > detachment AbstractTree tests wether a node implements IDetachable, > effectively duplicating functionality that is normally provider by Component > and its model out of the box. > The nodes are currently used to identify state (e.g. the parent) in the tree. > To add a node, the nodes have to implement equals() and hashCode() to be > correctly identified in the tree state. This might be unacceptable, e.g. if > entities (business objects) are used as nodes, probably loaded from a > database. > Therefore I propose to refactor AbstractTree and subclasses as follows: > A new interface INodeProvider (similar to IDataProvider) defines a concise > API to define a tree of nodes. The method #model(Object) gives an implementor > the possibility to wrap nodes in a suitable model, e.g. a detachable one. The > provided model can handle #equal() and #hashcode() for identification of > nodes in the tree. > References to nodes are always indirect through the model, never to the real > node object. > Handling of node parents is completely managed inside AbstractTree, no need > for an ExtendedTreeModel. > The model of an AbstractTree is used for node selection, similar to > AbstractChoices. > Listeners are replaced with notification methods on AbstractTree. No need for > tree paths on changes. > Expansion state is held in the AbstracTree#TreeItems (instead of former > ITreeState) - similar to component visibility. > The attached patch tries to achieve all this (or at least show how a solution > could look like), additionally: > - AbstractTree now utilizes AbstractRepeater and > #setOutputMarkupPlaceholderTag() instead of custom solutions. > - The examples are modified and enhanced with 'add' and 'remove' > functionality, org.apache.wicket.examples.nested.Home shows usage of an Swing > TreeModel adapter. > - Lots of generics are added (Swing's TreeModel will probably never be > generic). > - The code is (hopefully) simplified. > I apologies for putting all this stuff into a single patch, but I wasn't able > to split these issues apart - it all depends on the proposed INodeProvider > interface. > For users of AbstractTree this solution has the following impacts: > - minor API changes for subclasses > - if a node is collapsed, all state of descendants will be lost, i.e. if the > node is expanded once again, all previously expanded children will stay > collapsed (similar to how Gnome handles trees) > - optimization for adding multiple new children in one AJAX request is not > (yet) supported, this was part of the former custom markup handling. > I will continue working on AbstractTree with tests and documentation. But > before doing that, I'd like to get a feedback from wicket committers
[jira] Updated: (WICKET-1601) Two RadioGroups on one page interfering with one another
[ https://issues.apache.org/jira/browse/WICKET-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Silbermann updated WICKET-1601: - Description: I created a simple Panel that contains a formatted RadioGroup with wantOnSelectionChangedNotifications() returning true. (Its constructor accepts an array of options, a PropertyModel to be controlled, and a caption for the label.) I put two instances of this panel on a single page, each controlling its own model variable. The page displays the two RadioGroup panels and displays the value of the two model variables. When I select a radiobutton from one group, all the radio buttons from the other group become unselected (i.e., the dot indicator disappears) -- as though the radio buttons belonged to the same button group. My quickstart project illustrating the behavior uses Wicket 1.3.3. Bring up the home page and begin clicking its radio groups to see the behavior. I discovered this problem in my Wicket 1.2 application when I tried to upgrade its libraries from Wicket 1.2.2 to Wicket 1.2.6. (With the new libraries, I also began seeing a great many puzzling new null value errors.) If the bug gets fixed in Wicket 1.3, I'll upgrade my application to it. was: I created a simple Panel that contains a formatted RadioGroup with wantOnSelectionChangedNotifications() returning true. (Its constructor accepts an array of options, a PropertyModel to be controlled, and a caption for the label.) I put two instances of this panel on a single page, each controlling its own model variable. The page displays the two RadioGroup panels and displays the value of the two model variables. When I select a radiobutton from one group, all the radio buttons from the other group become unselected (i.e., the dot indicator disappears) -- as though the radio buttons belonged to the same button group. My quickstart project illustrating the behavior (if I can figure out how to attach it) uses Wicket 1.3.3. Bring up the home page and begin clicking its radio groups to see the behavior. I discovered this problem in my Wicket 1.2 application when I tried to upgrade its libraries from Wicket 1.2.2 to Wicket 1.2.6. (With the new libraries, I also began seeing a great many puzzling new null value errors.) If the bug gets fixed in Wicket 1.3, I'll upgrade my application to it. > Two RadioGroups on one page interfering with one another > > > Key: WICKET-1601 > URL: https://issues.apache.org/jira/browse/WICKET-1601 > Project: Wicket > Issue Type: Bug >Affects Versions: 1.3.3 > Environment: generic >Reporter: Frank Silbermann > Attachments: myproject.zip, screenshot-1.jpg > > > I created a simple Panel that contains a formatted RadioGroup with > wantOnSelectionChangedNotifications() returning true. (Its constructor > accepts an array of options, a PropertyModel to be controlled, and a caption > for the label.) I put two instances of this panel on a single page, each > controlling its own model variable. The page displays the two RadioGroup > panels and displays the value of the two model variables. > When I select a radiobutton from one group, all the radio buttons from the > other group become unselected (i.e., the dot indicator disappears) -- as > though the radio buttons belonged to the same button group. > My quickstart project illustrating the behavior uses Wicket 1.3.3. Bring up > the home page and begin clicking its radio groups to see the behavior. > I discovered this problem in my Wicket 1.2 application when I tried to > upgrade its libraries from Wicket 1.2.2 to Wicket 1.2.6. (With the new > libraries, I also began seeing a great many puzzling new null value errors.) > If the bug gets fixed in Wicket 1.3, I'll upgrade my application to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1601) Two RadioGroups on one page interfering with one another
[ https://issues.apache.org/jira/browse/WICKET-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Silbermann updated WICKET-1601: - Attachment: screenshot-1.jpg Initially, both button groups had the first selection (Ay) chosen. Here, I clicked the third choice of the first group, changing the value of the first model variable. The second radio button group lost its indicator. > Two RadioGroups on one page interfering with one another > > > Key: WICKET-1601 > URL: https://issues.apache.org/jira/browse/WICKET-1601 > Project: Wicket > Issue Type: Bug >Affects Versions: 1.3.3 > Environment: generic >Reporter: Frank Silbermann > Attachments: myproject.zip, screenshot-1.jpg > > > I created a simple Panel that contains a formatted RadioGroup with > wantOnSelectionChangedNotifications() returning true. (Its constructor > accepts an array of options, a PropertyModel to be controlled, and a caption > for the label.) I put two instances of this panel on a single page, each > controlling its own model variable. The page displays the two RadioGroup > panels and displays the value of the two model variables. > When I select a radiobutton from one group, all the radio buttons from the > other group become unselected (i.e., the dot indicator disappears) -- as > though the radio buttons belonged to the same button group. > My quickstart project illustrating the behavior (if I can figure out how to > attach it) uses Wicket 1.3.3. Bring up the home page and begin clicking its > radio groups to see the behavior. > I discovered this problem in my Wicket 1.2 application when I tried to > upgrade its libraries from Wicket 1.2.2 to Wicket 1.2.6. (With the new > libraries, I also began seeing a great many puzzling new null value errors.) > If the bug gets fixed in Wicket 1.3, I'll upgrade my application to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1601) Two RadioGroups on one page interfering with one another
[ https://issues.apache.org/jira/browse/WICKET-1601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Silbermann updated WICKET-1601: - Attachment: myproject.zip I modified the QuickStart project to define a panel component constructed with an array of options for a radio button group, a String to label the group, and a PropertyModel so the RadioGroup can control the value of a variable. The component posts back on selection changes. The home page displays two instances of this panel, each radio button group controlling a different model variable. The two model variables are also displayed. Changing the selection of one radio group causes the indicator to disappear from the other radio group. > Two RadioGroups on one page interfering with one another > > > Key: WICKET-1601 > URL: https://issues.apache.org/jira/browse/WICKET-1601 > Project: Wicket > Issue Type: Bug >Affects Versions: 1.3.3 > Environment: generic >Reporter: Frank Silbermann > Attachments: myproject.zip > > > I created a simple Panel that contains a formatted RadioGroup with > wantOnSelectionChangedNotifications() returning true. (Its constructor > accepts an array of options, a PropertyModel to be controlled, and a caption > for the label.) I put two instances of this panel on a single page, each > controlling its own model variable. The page displays the two RadioGroup > panels and displays the value of the two model variables. > When I select a radiobutton from one group, all the radio buttons from the > other group become unselected (i.e., the dot indicator disappears) -- as > though the radio buttons belonged to the same button group. > My quickstart project illustrating the behavior (if I can figure out how to > attach it) uses Wicket 1.3.3. Bring up the home page and begin clicking its > radio groups to see the behavior. > I discovered this problem in my Wicket 1.2 application when I tried to > upgrade its libraries from Wicket 1.2.2 to Wicket 1.2.6. (With the new > libraries, I also began seeing a great many puzzling new null value errors.) > If the bug gets fixed in Wicket 1.3, I'll upgrade my application to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1601) Two RadioGroups on one page interfering with one another
Two RadioGroups on one page interfering with one another Key: WICKET-1601 URL: https://issues.apache.org/jira/browse/WICKET-1601 Project: Wicket Issue Type: Bug Affects Versions: 1.3.3 Environment: generic Reporter: Frank Silbermann I created a simple Panel that contains a formatted RadioGroup with wantOnSelectionChangedNotifications() returning true. (Its constructor accepts an array of options, a PropertyModel to be controlled, and a caption for the label.) I put two instances of this panel on a single page, each controlling its own model variable. The page displays the two RadioGroup panels and displays the value of the two model variables. When I select a radiobutton from one group, all the radio buttons from the other group become unselected (i.e., the dot indicator disappears) -- as though the radio buttons belonged to the same button group. My quickstart project illustrating the behavior (if I can figure out how to attach it) uses Wicket 1.3.3. Bring up the home page and begin clicking its radio groups to see the behavior. I discovered this problem in my Wicket 1.2 application when I tried to upgrade its libraries from Wicket 1.2.2 to Wicket 1.2.6. (With the new libraries, I also began seeing a great many puzzling new null value errors.) If the bug gets fixed in Wicket 1.3, I'll upgrade my application to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1600) Wicket tree improvement
[ https://issues.apache.org/jira/browse/WICKET-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sven Meier updated WICKET-1600: --- Attachment: tree.diff Patch implementing the proposed solution. > Wicket tree improvement > --- > > Key: WICKET-1600 > URL: https://issues.apache.org/jira/browse/WICKET-1600 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4-M1 >Reporter: Sven Meier >Priority: Minor > Attachments: tree.diff > > > I see the following issues with Wicket's tree implementation that should be > solved: > AbstractTree and its subclasses were written with the Swing JTree API in > mind. This is not a bad thing per se, but the JTree abstractions are not very > well suited for a web application. Matej recently removed some of these > dependencies, but there's still a lot of code that uses TreeNode, > TreeModelEvent and such. > AbstractTree holds a TreeModel in its model, attaching a listener to it. This > is an unusual approach for a Wicket component: > - It implies that changes in the TreeModel are automatically propagated to > the user interface. This is not always the case, as in an ajax request the > AbstractTree has to be explicitely notified to update itself. > - It requires the AbstractTree to monitor the model for a replaced TreeModel. > Most importantly the TreeModel API is complicated and ambiguous (just see the > javadoc of TreeModelEvent and TreeModelListener) which makes life harder > especially for those who want to use AbstractTree with their own TreeModel > implementation (which is difficult enough). Although not directly visible in > the API, an implementor has to privide the parent of a node - see > AbstractTree#getParentNode(). Tree listeners and events are an annoyance > which doesn't match Wicket's elegance. > Currently many components in the AbstractTree hierarchy hold a reference to > real nodes of the TreeModel (e.g. junctionLink). TreeState seems like a > foreign concept to Wicket, holding references to nodes too. To support > detachment AbstractTree tests wether a node implements IDetachable, > effectively duplicating functionality that is normally provider by Component > and its model out of the box. > The nodes are currently used to identify state (e.g. the parent) in the tree. > To add a node, the nodes have to implement equals() and hashCode() to be > correctly identified in the tree state. This might be unacceptable, e.g. if > entities (business objects) are used as nodes, probably loaded from a > database. > Therefore I propose to refactor AbstractTree and subclasses as follows: > A new interface INodeProvider (similar to IDataProvider) defines a concise > API to define a tree of nodes. The method #model(Object) gives an implementor > the possibility to wrap nodes in a suitable model, e.g. a detachable one. The > provided model can handle #equal() and #hashcode() for identification of > nodes in the tree. > References to nodes are always indirect through the model, never to the real > node object. > Handling of node parents is completely managed inside AbstractTree, no need > for an ExtendedTreeModel. > The model of an AbstractTree is used for node selection, similar to > AbstractChoices. > Listeners are replaced with notification methods on AbstractTree. No need for > tree paths on changes. > Expansion state is held in the AbstracTree#TreeItems (instead of former > ITreeState) - similar to component visibility. > The attached patch tries to achieve all this (or at least show how a solution > could look like), additionally: > - AbstractTree now utilizes AbstractRepeater and > #setOutputMarkupPlaceholderTag() instead of custom solutions. > - The examples are modified and enhanced with 'add' and 'remove' > functionality, org.apache.wicket.examples.nested.Home shows usage of an Swing > TreeModel adapter. > - Lots of generics are added (Swing's TreeModel will probably never be > generic). > - The code is (hopefully) simplified. > I apologies for putting all this stuff into a single patch, but I wasn't able > to split these issues apart - it all depends on the proposed INodeProvider > interface. > For users of AbstractTree this solution has the following impacts: > - minor API changes for subclasses > - if a node is collapsed, all state of descendants will be lost, i.e. if the > node is expanded once again, all previously expanded children will stay > collapsed (similar to how Gnome handles trees) > - optimization for adding multiple new children in one AJAX request is not > (yet) supported, this was part of the former custom markup handling. > I will continue working on AbstractTree with tests and documentation. But > before doing that, I'd like to get a feedback from wicket committers > (especially Matej), if thi
[jira] Created: (WICKET-1600) Wicket tree improvement
Wicket tree improvement --- Key: WICKET-1600 URL: https://issues.apache.org/jira/browse/WICKET-1600 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-M1 Reporter: Sven Meier Priority: Minor I see the following issues with Wicket's tree implementation that should be solved: AbstractTree and its subclasses were written with the Swing JTree API in mind. This is not a bad thing per se, but the JTree abstractions are not very well suited for a web application. Matej recently removed some of these dependencies, but there's still a lot of code that uses TreeNode, TreeModelEvent and such. AbstractTree holds a TreeModel in its model, attaching a listener to it. This is an unusual approach for a Wicket component: - It implies that changes in the TreeModel are automatically propagated to the user interface. This is not always the case, as in an ajax request the AbstractTree has to be explicitely notified to update itself. - It requires the AbstractTree to monitor the model for a replaced TreeModel. Most importantly the TreeModel API is complicated and ambiguous (just see the javadoc of TreeModelEvent and TreeModelListener) which makes life harder especially for those who want to use AbstractTree with their own TreeModel implementation (which is difficult enough). Although not directly visible in the API, an implementor has to privide the parent of a node - see AbstractTree#getParentNode(). Tree listeners and events are an annoyance which doesn't match Wicket's elegance. Currently many components in the AbstractTree hierarchy hold a reference to real nodes of the TreeModel (e.g. junctionLink). TreeState seems like a foreign concept to Wicket, holding references to nodes too. To support detachment AbstractTree tests wether a node implements IDetachable, effectively duplicating functionality that is normally provider by Component and its model out of the box. The nodes are currently used to identify state (e.g. the parent) in the tree. To add a node, the nodes have to implement equals() and hashCode() to be correctly identified in the tree state. This might be unacceptable, e.g. if entities (business objects) are used as nodes, probably loaded from a database. Therefore I propose to refactor AbstractTree and subclasses as follows: A new interface INodeProvider (similar to IDataProvider) defines a concise API to define a tree of nodes. The method #model(Object) gives an implementor the possibility to wrap nodes in a suitable model, e.g. a detachable one. The provided model can handle #equal() and #hashcode() for identification of nodes in the tree. References to nodes are always indirect through the model, never to the real node object. Handling of node parents is completely managed inside AbstractTree, no need for an ExtendedTreeModel. The model of an AbstractTree is used for node selection, similar to AbstractChoices. Listeners are replaced with notification methods on AbstractTree. No need for tree paths on changes. Expansion state is held in the AbstracTree#TreeItems (instead of former ITreeState) - similar to component visibility. The attached patch tries to achieve all this (or at least show how a solution could look like), additionally: - AbstractTree now utilizes AbstractRepeater and #setOutputMarkupPlaceholderTag() instead of custom solutions. - The examples are modified and enhanced with 'add' and 'remove' functionality, org.apache.wicket.examples.nested.Home shows usage of an Swing TreeModel adapter. - Lots of generics are added (Swing's TreeModel will probably never be generic). - The code is (hopefully) simplified. I apologies for putting all this stuff into a single patch, but I wasn't able to split these issues apart - it all depends on the proposed INodeProvider interface. For users of AbstractTree this solution has the following impacts: - minor API changes for subclasses - if a node is collapsed, all state of descendants will be lost, i.e. if the node is expanded once again, all previously expanded children will stay collapsed (similar to how Gnome handles trees) - optimization for adding multiple new children in one AJAX request is not (yet) supported, this was part of the former custom markup handling. I will continue working on AbstractTree with tests and documentation. But before doing that, I'd like to get a feedback from wicket committers (especially Matej), if this proposed solution matches their conception. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1329) AutoCompleteTextField's suggestion list *disappeared* when it is used inside a ModalWindow
[ https://issues.apache.org/jira/browse/WICKET-1329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595358#action_12595358 ] Gerolf Seitz commented on WICKET-1329: -- Erik, why do you think so? afaik, the z-index is independent from the position. so we need both fixes. > AutoCompleteTextField's suggestion list *disappeared* when it is used inside > a ModalWindow > -- > > Key: WICKET-1329 > URL: https://issues.apache.org/jira/browse/WICKET-1329 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-final >Reporter: Andy Chu >Assignee: Gerolf Seitz > Fix For: 1.3.3 > > > When an AutoCompleteTextField is used in panel showed inside a ModalWindow, > the dropdown list for suggestions will be disappeared. The reason is that the > z-index of a normal ModalWindow is 2 while the z-index of the dropdown > list is 1. And there is no way to set this parameter programatically. > Therefore, the dropdown list is masked by the ModalWindow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595347#action_12595347 ] Erik van Oosten commented on WICKET-1355: - Richard, that change was the whole point of the fix. Apparently there is still a problem with the z-index, but reverting this line will not fix the problem of this issue. > Autocomplete window has wrong position in scrolled context > -- > > Key: WICKET-1355 > URL: https://issues.apache.org/jira/browse/WICKET-1355 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.3.1 >Reporter: Erik van Oosten >Assignee: Janne Hietamäki > Fix For: 1.3.4 > > Attachments: wicket-autocomplete.js > > > When the autocompleted field is located in a scrolled div, the drop-down > window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1594) AutoCompleteTextField Throwing Out a TypeError in IE6/IE7
[ https://issues.apache.org/jira/browse/WICKET-1594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerolf Seitz resolved WICKET-1594. -- Resolution: Duplicate see WICKET-1504, fixed in 1.3.4 adn 1.4-M1 > AutoCompleteTextField Throwing Out a TypeError in IE6/IE7 > - > > Key: WICKET-1594 > URL: https://issues.apache.org/jira/browse/WICKET-1594 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.3.3 > Environment: IE6/IE7 >Reporter: Andy Chu > > Wicket 1.3.3. fixed many bugs of AutoCompleteTextField. However, it may > induce some new problems: > I create a very simple page only containing an AutoCompleteTextField and > visit the page using IE6/IE7/FF. I found that IE will prompt me a javascript > TypeError but FF doesn't . > The TypeError is thrown by the following statement in the showAutoComplete > method when zIndex is assigned to "auto": > menu.style.zIndex = index=="auto"?index:Number(index)+1; > I guess IE may not allow us to assign "auto" to zIndex but in FF. However if > I change the statement into the following one, everything works fine. > menu.style.zIndex = index=="auto"?0:Number(index)+1; > Because I do not completely understand wicket-autocomplete.js, I can not > make sure if this modification will bring up another bug. Hope can get the > answer from here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-271) investigate Ajax back button support
[ https://issues.apache.org/jira/browse/WICKET-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595308#action_12595308 ] Eelco Hillenius commented on WICKET-271: The difficult part is still how to do versioning on the server side. I don't recall all the details anymore, but Johan, Matej and I got stuck on that part. The > investigate Ajax back button support > > > Key: WICKET-271 > URL: https://issues.apache.org/jira/browse/WICKET-271 > Project: Wicket > Issue Type: Improvement > Components: wicket >Reporter: Eelco Hillenius > Fix For: 1.4-M2 > > > Investigate what we can do to support the back button with Ajax. Currently, > we don't support versioning with Ajax, so the back button always takes you > back to the location before the ajax calls. > See discussion here: > http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (WICKET-271) investigate Ajax back button support
[ https://issues.apache.org/jira/browse/WICKET-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595308#action_12595308 ] ehillenius edited comment on WICKET-271 at 5/8/08 9:09 AM: The difficult part is still how to do versioning on the server side. I don't recall all the details anymore, but Johan, Matej and I got stuck on that part. The JavaScript part by itself is doable (though the problem is that we don't 'own' the UI). was (Author: ehillenius): The difficult part is still how to do versioning on the server side. I don't recall all the details anymore, but Johan, Matej and I got stuck on that part. The > investigate Ajax back button support > > > Key: WICKET-271 > URL: https://issues.apache.org/jira/browse/WICKET-271 > Project: Wicket > Issue Type: Improvement > Components: wicket >Reporter: Eelco Hillenius > Fix For: 1.4-M2 > > > Investigate what we can do to support the back button with Ajax. Currently, > we don't support versioning with Ajax, so the back button always takes you > back to the location before the ajax calls. > See discussion here: > http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-271) investigate Ajax back button support
[ https://issues.apache.org/jira/browse/WICKET-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595277#action_12595277 ] James Carman commented on WICKET-271: - I don't mind helping, but I'm definitely not the best-qualified Javascript person. Would someone be willing to help point me in the right direction? > investigate Ajax back button support > > > Key: WICKET-271 > URL: https://issues.apache.org/jira/browse/WICKET-271 > Project: Wicket > Issue Type: Improvement > Components: wicket >Reporter: Eelco Hillenius > Fix For: 1.4-M2 > > > Investigate what we can do to support the back button with Ajax. Currently, > we don't support versioning with Ajax, so the back button always takes you > back to the location before the ajax calls. > See discussion here: > http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-271) investigate Ajax back button support
[ https://issues.apache.org/jira/browse/WICKET-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595270#action_12595270 ] Johan Compagner commented on WICKET-271: i will see the patch coming in then... > investigate Ajax back button support > > > Key: WICKET-271 > URL: https://issues.apache.org/jira/browse/WICKET-271 > Project: Wicket > Issue Type: Improvement > Components: wicket >Reporter: Eelco Hillenius > Fix For: 1.4-M2 > > > Investigate what we can do to support the back button with Ajax. Currently, > we don't support versioning with Ajax, so the back button always takes you > back to the location before the ajax calls. > See discussion here: > http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (WICKET-271) investigate Ajax back button support
[ https://issues.apache.org/jira/browse/WICKET-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595268#action_12595268 ] jwcarman edited comment on WICKET-271 at 5/8/08 7:39 AM: - If you don't want to globally enable it, perhaps you can add it in as a behavior (AjaxBackButtonSupportBehavior)? This could be added to your page? was (Author: jwcarman): If you don't want to globally enable it, perhaps you can add it in as a behavior (AjaxBackButtonSupportBehavior)? > investigate Ajax back button support > > > Key: WICKET-271 > URL: https://issues.apache.org/jira/browse/WICKET-271 > Project: Wicket > Issue Type: Improvement > Components: wicket >Reporter: Eelco Hillenius > Fix For: 1.4-M2 > > > Investigate what we can do to support the back button with Ajax. Currently, > we don't support versioning with Ajax, so the back button always takes you > back to the location before the ajax calls. > See discussion here: > http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-271) investigate Ajax back button support
[ https://issues.apache.org/jira/browse/WICKET-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595268#action_12595268 ] James Carman commented on WICKET-271: - If you don't want to globally enable it, perhaps you can add it in as a behavior (AjaxBackButtonSupportBehavior)? > investigate Ajax back button support > > > Key: WICKET-271 > URL: https://issues.apache.org/jira/browse/WICKET-271 > Project: Wicket > Issue Type: Improvement > Components: wicket >Reporter: Eelco Hillenius > Fix For: 1.4-M2 > > > Investigate what we can do to support the back button with Ajax. Currently, > we don't support versioning with Ajax, so the back button always takes you > back to the location before the ajax calls. > See discussion here: > http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-271) investigate Ajax back button support
[ https://issues.apache.org/jira/browse/WICKET-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595259#action_12595259 ] James Carman commented on WICKET-271: - Or, perhaps this: http://developer.yahoo.com/yui/history/ > investigate Ajax back button support > > > Key: WICKET-271 > URL: https://issues.apache.org/jira/browse/WICKET-271 > Project: Wicket > Issue Type: Improvement > Components: wicket >Reporter: Eelco Hillenius > Fix For: 1.4-M2 > > > Investigate what we can do to support the back button with Ajax. Currently, > we don't support versioning with Ajax, so the back button always takes you > back to the location before the ajax calls. > See discussion here: > http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-271) investigate Ajax back button support
[ https://issues.apache.org/jira/browse/WICKET-271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595258#action_12595258 ] James Carman commented on WICKET-271: - Has anyone looked into RSH for this? http://code.google.com/p/reallysimplehistory/ It's BSD-licensed, so it's ASF license compatible. > investigate Ajax back button support > > > Key: WICKET-271 > URL: https://issues.apache.org/jira/browse/WICKET-271 > Project: Wicket > Issue Type: Improvement > Components: wicket >Reporter: Eelco Hillenius > Fix For: 1.4-M2 > > > Investigate what we can do to support the back button with Ajax. Currently, > we don't support versioning with Ajax, so the back button always takes you > back to the location before the ajax calls. > See discussion here: > http://www.nabble.com/Single-page-applications%3A-bad-idea-in-Wicket---tf3182341.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595188#action_12595188 ] richardwilko edited comment on WICKET-1355 at 5/8/08 7:16 AM: --- I tried this on my code, but now the autocomplete div appears behind some of the content on my page (its not flash or anything, just normal html + css) On firefox . Didnt have this problem with wicket 1.3.0 Edit: the problem seems to be how the div is added to the page. In the newer version it is like this: wicketGet(elementId).parentNode.appendChild(choiceDiv); (line 159) and in the older version it was like this: document.body.appendChild(choiceDiv); I changed it back to the old way and everything works as before. was (Author: richardwilko): I tried this on my code, but now the autocomplete div appears behind some of the content on my page (its not flash or anything, just normal html + css) On firefox . Didnt have this problem with wicket 1.3.0 > Autocomplete window has wrong position in scrolled context > -- > > Key: WICKET-1355 > URL: https://issues.apache.org/jira/browse/WICKET-1355 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.3.1 >Reporter: Erik van Oosten >Assignee: Janne Hietamäki > Fix For: 1.3.4 > > Attachments: wicket-autocomplete.js > > > When the autocompleted field is located in a scrolled div, the drop-down > window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1599) RequestUtils.toAbsolutePath()'s bug
RequestUtils.toAbsolutePath()'s bug
---
Key: WICKET-1599
URL: https://issues.apache.org/jira/browse/WICKET-1599
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.3
Environment: Firefox
Reporter: smallufo
Suppose the following code in a bookmarkable page , say "FirstPage" :
When user pushes an AJAX button , the page builds a bookmarkable link :
Map parameterMap = new HashMap();
parameterMap.put("index" , myObj.getIndex());
PageParameters pps = new PageParameters(parameterMap);
String absUrl =
RequestUtils.toAbsolutePath(getRequestCycle().urlFor(SecondPage.class ,
pps).toString());
If the user navigates properly (by clicking links to the FirstPage) ,
the absUrl is correct : foobar/SecondPage/index/1/
after pre-adding "http://"; + req.getServerName() + contextPath + "/" , I can
correctly build the (bookmarkable) link like this :
http://www.foobar.com/app/foobar/SecondPage/index/1
BUT , if the user directly links to the FirstPage(copy / paste the FirstPage's
url in the browser's url bar) ,
or clicks the SecondPage's link and back (by browser) , and pushes the AJAX
button again...
SOMETIMES , absUrl becomes :
http://foobar/SecondPage/index/1/ , the preceding "http://"; is redundant !!!
And , my bookmarkable link becomes :
http://www.foobar.com/app/http://foobar/SecondPage/index/1
I can not successfully re-produce this error every time. but sometimes it just
occurs .
It seems it is a bug...
PS : I know how to build a BookmarkablePageLink in the wicket way , But I have
to do this for a special purpose.(parsing an article and adding links to
some keywords)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595188#action_12595188 ] richardwilko edited comment on WICKET-1355 at 5/8/08 4:08 AM: --- I tried this on my code, but now the autocomplete div appears behind some of the content on my page (its not flash or anything, just normal html + css) On firefox . Didnt have this problem with wicket 1.3.0 was (Author: richardwilko): I tried this on my code, but now the autocomplete div appears behind some of the content on my page (its not flash or anything, just normal html + css). Didnt have this problem with wicket 1.3.0 > Autocomplete window has wrong position in scrolled context > -- > > Key: WICKET-1355 > URL: https://issues.apache.org/jira/browse/WICKET-1355 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.3.1 >Reporter: Erik van Oosten >Assignee: Janne Hietamäki > Fix For: 1.3.4 > > Attachments: wicket-autocomplete.js > > > When the autocompleted field is located in a scrolled div, the drop-down > window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1355) Autocomplete window has wrong position in scrolled context
[ https://issues.apache.org/jira/browse/WICKET-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12595188#action_12595188 ] Richard Wilkinson commented on WICKET-1355: --- I tried this on my code, but now the autocomplete div appears behind some of the content on my page (its not flash or anything, just normal html + css). Didnt have this problem with wicket 1.3.0 > Autocomplete window has wrong position in scrolled context > -- > > Key: WICKET-1355 > URL: https://issues.apache.org/jira/browse/WICKET-1355 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.3.1 >Reporter: Erik van Oosten >Assignee: Janne Hietamäki > Fix For: 1.3.4 > > Attachments: wicket-autocomplete.js > > > When the autocompleted field is located in a scrolled div, the drop-down > window is positioned too far down. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1598) Typos in JavaDoc of IMarkupResourceStreamProvider.java
Typos in JavaDoc of IMarkupResourceStreamProvider.java -- Key: WICKET-1598 URL: https://issues.apache.org/jira/browse/WICKET-1598 Project: Wicket Issue Type: Bug Reporter: Martin Funk Priority: Trivial Index: src/main/java/org/apache/wicket/markup/IMarkupResourceStreamProvider.java === --- . (revision 654460) +++ . (working copy) @@ -20,8 +20,8 @@ import org.apache.wicket.util.resource.IResourceStream; /** - * To be implemented by MarkupContainer which whish to implement there own algorithms for loading - * the markup resource stream. + * To be implemented by MarkupContainer which wish to implement their own algorithms for loading the + * markup resource stream. * * Note: IResourceStreamLocators should be used in case the strategy to find a markup resource is * meant to be applied to ALL components of your application. @@ -26,7 +26,7 @@ * Note: IResourceStreamLocators should be used in case the strategy to find a markup resource is * meant to be applied to ALL components of your application. * - * Note: See IMarkupCacheKeyProvider if you whish to implement your own cache key algorithm, which + * Note: See IMarkupCacheKeyProvider if you wish to implement your own cache key algorithm, which * sometimes is useful when the MarkupContainer implements its own IMarkupResourceStreamProvider as * well. * -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
