[jira] [Updated] (WICKET-4630) StatelessDataTable (like DefaultDataTable but for use in stateless pages)

["Trejkaz (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trejkaz updated WICKET-4630:
----------------------------

    Attachment: brokenstatelesstables.zip

Here's what I've got. It's basically surgically removed from the real application. I just removed all the other pages, stubbed out the backend with an in-memory implementation and then moved the page to be HomePage.

How to reproduce:

* Open two browsers.
* In browser 1, load the page and create some entries called "2", "3", "4".
* In browser 2, load the page and select "3" in preparation to remove it but don't remove it yet!
* In browser 1, create a fourth entry called "1" (this will move to the top.)
* In browser 2, where you still have "3" selected, hit the button to remove the entry. Entry "2" will have been removed because the table shifted down by one between loading the page and submitting the form.

There is a considerable amount of stubbed out code included which represents my attempt at writing a StatelessDataTable, which shows just how much state DataTable has. :(


> StatelessDataTable (like DefaultDataTable but for use in stateless pages)
> -------------------------------------------------------------------------
>
>                 Key: WICKET-4630
>                 URL: https://issues.apache.org/jira/browse/WICKET-4630
>             Project: Wicket
>          Issue Type: New Feature
>            Reporter: Trejkaz
>         Attachments: brokenstatelesstables.zip
>
>
> (inspired by WICKET-4620)
> We have a StatelessDataTable which is implemented like DefaultDataTable but replacing all links with bookmarkable links.
> Problem is, when there are form fields inside the table, the form doesn't process any of the fields in the table unless you perform a workaround which is apparently the "wrong" way to do it:
>     @Override
>     protected void onInitialize() {
>         super.onInitialize();
>         beforeRender();
>     }
> If there is a "right" way to do it, I think this warrants a stateless table component in Wicket so that people don't implement it from scratch the "wrong" way, which seems to be the only option at present.



--
This message was sent by Atlassian JIRA
(v6.2#6252)