No announcement yet.
  • Filter
  • Time
Clear All
new posts

    Configuration of AutoChildProperties for BatchUploader ListGrid

    Hi Isomorphic,

    we are using a BatchUploader to import Data. I would like to check the data according to our business logic before the data gets shown in the BatchUploaders ListGrid, and mark rows, that match a specific needing without having a vaidation error. What I was thinking about is either
    1. add a ClickHandler on the uploadButton and then check the data or
    2. add a DataArrivedHandler on the ListGrid or
    3. make it as a validator, but as far as I know there is nothing like a "warning" validator, that would allow to commit the data anyway, right?
    1. :
    I was able to add a ClickHandler to the upload button via
            ButtonItem uploadButtonTemplate = new ButtonItem();
             uploadButtonTemplate.addClickHandler(new {
             public void onClick( event) {
             // TODO Auto-generated method stub
            BatchUploader.changeAutoChildDefaults("uploadButton", uploadButtonTemplate);
    That works, but what is the best practice then to get the data, before it arrives in the grid?

    I was not able to add a DataArrivedHandler to the ListGrid, what i tried is:

           ListGrid grid = new ListGrid() {
                    addDataArrivedHandler(new DataArrivedHandler() {
                        public void onDataArrived(DataArrivedEvent event) {
            BatchUploader.changeAutoChildDefaults("grid", grid);
    The data is shown in the grid without hitting the Handler. According to the docs
    it says it should be possible. Please let me know if I did not use this right.

    What I generally wanna do is check each row, if it meets some criteria. so when Im in the Handler I need to make a fetch for this row and either mark it or not. Could You please give some advice, how to establish that in a good way.

    Thanks in Advance,
    Kind Regards

    In the internal workings of the BatchUploader, setData() is used rather than fetchData(), so DataArrived is not expected to fire. However there is a dedicated notification for this (BatchUploader.previewShown()) so that's what you should be using anyway.


      Note further that there's no need to get the *data* before it goes to the grid. You could achieve what you want by, for example, implementing getBaseStyle() or getCellCSSText() to style cells that have warnings differently. Then you wouldn't really even need previewShown as everything is just done on demand, as cells are rendered.


        Thank You very much! That was what I needed. Now I have another question. Its not relevant for us at the moment, but it would be interesting to know anyway. When I click the commit button, is it possible to catch the response from the server? Like, if I want to customize the CommitConfirmation depending on the response. Is that possible, and how could I get it?


          When you have a concrete scenario in mind where you want to do this, let us know what the response is that you need to respond to, and what you need to able to do, and we can comment.


            Hi Isomorphic,

            the plan here is the following:
            • With your fix from here we return data for a ListGridField with canHide: true, hidden: true.
            • With Hilites we mark/warn whole rows depending on this field (if they are a duplicate to an existing entry in the system, which we decide server side in the "validator")
            • These two bug reports are also related
            Now, on "Commit"-click we would like to do the following:
            • If there are no warnings (=Hidden field doesn't have data in any row), we would call
            • If there are warnings, we show a "Do you really want..."-Popup and on OK we would call
            • After that, in the CallBack of, we show some popup or would call super.showDefaultPopup()
            Does this make sense to you? Do you have a better idea?

            Best regards


              You could do this if you used the native "confirm" function. Otherwise, showing a SmartGWT-based dialog is asynchronous so you would not be able to call per se. But you could initiate the commit again.