Update datatable on return from dialog

UI Components for JSF
Post Reply
jdubicki
Posts: 11
Joined: 17 Jan 2018, 15:19

15 Mar 2018, 22:11

If someone have already solved this please tell me how. Basically I have a datatable and a button to add a row. The data for the table to retrieved from a database based on a dropdown selection. When the user selects an item from the list the UI is blocked and a query is made. The resulting list is used to populate the tale. This part works. What I need help with is when the user clicks the add button, a dialog opens, the user then enters info. When the OK button is clicked I want to block the UI, call the database on populate the table with the most recent data. Is this possible?

This is what I have so far:

This is the add button and return event.

Code: Select all

<p:commandButton id="add-button" value="Add" icon="fa fa-plus fa-fw"
                                                 actionListener="#{lookupTypeBean.addLookupItem()}" disabled="#{lookupTypeBean.addButtonDisabled}">
                                    <p:ajax event="dialogReturn" listener="#{lookupTypeBean.onLookupTypeAdded}" />
                                    </p:commandButton>
This is the method that is called.

Code: Select all

public void onLookupTypeAdded(SelectEvent event) throws SQLException {
        LookupItem lookupItem = (LookupItem) event.getObject();
        System.out.println("====> Code: " + lookupItem.getCode());
        System.out.println("====> Description: " + lookupItem.getName());

        String isCodeViewable = null;
        String tableName = null;
        String orderByColumn = null;
        int id = Integer.parseInt(selectedLookupType);
        for (int i = 0; i < lookupTypeList.size(); i++) {
            if (lookupTypeList.get(i).getLookupItemId() == id) {
                isCodeViewable = lookupTypeList.get(i).getIsCodeViewable();
                tableName = lookupTypeList.get(i).getTableName();
                orderByColumn = lookupTypeList.get(i).getOrderByColumn();
                break;
            }
        }
        lookupTypeItemsList = new ArrayList<>();
        lookupTypeItemsList = LookupManagementDB.getLookupItems(isCodeViewable, tableName, orderByColumn);
        lazyDataModel = new LookupManagementLazyDataModel(lookupTypeItemsList);
        PrimeFaces.current().ajax().update("form-2:code-lookup-data-table");
        FacesContext context = FacesContext.getCurrentInstance();
        context.addMessage(null, new FacesMessage("Success", "Lookup Item has been added."));
        PrimeFaces.current().ajax().update("form-2:growl");
    }
    
This will do everything I want except for blocking the UI. Is it possible for me to block the UI until the request has come back. I have already tried putting onstart and oncomplete callback in the return event with no success.

kukeltje
Expert Member
Posts: 9605
Joined: 17 Jun 2010, 13:34
Location: Netherlands

17 Mar 2018, 10:48

Did you check the showcase and documentation? Components/features for blocking the ui are available.

LarsD
Posts: 69
Joined: 25 Nov 2011, 22:47
Location: Dresden, Germany

19 Mar 2018, 14:54

Hi.
I would choose a totally different solution for this.

1) No Ajax.
2) Use full page requests and update the page by returning null/void from a "action"-Method, not using a action listener.
(you can also you the FacesContext Navigationhandler)

Your solution would look liek this:

Code: Select all

<p:commandButton
	id="add-button"
	value="Add"
	icon="fa fa-plus fa-fw"
	ajax="false"
        action"#{lookupTypeBean.addLookupItem}"
        disabled="#{lookupTypeBean.addButtonDisabled}" />
lookupTypeBean.addLookupItem should be void or return null... this will reload your page.

In the action-method do your stuff. The bean should be session scoped or view access scoped.

The data should be request scoped to be always up-to-date. You can achieve this by getting the data from a request scoped bean or define the getter for the data table content to return the current list.

CDI would be useful, but you also can achive this with plain javax.faces functionallty.


kind regards
Lars

kukeltje
Expert Member
Posts: 9605
Joined: 17 Jun 2010, 13:34
Location: Netherlands

20 Mar 2018, 10:50

@LarsD: Why no ajax. Sounds like working around the problem or is there a real advantage of doing it without ajax in this case (I do it with ajax all the time, nothing special about it)

LarsD
Posts: 69
Joined: 25 Nov 2011, 22:47
Location: Dresden, Germany

20 Mar 2018, 12:59

In general, not using so much Ajax is my personal preference.

In this particular case (meaning add/remove/update data of a dataTable in a popup) it would normally end in a persistence operation which means a server call. It makes no sense to me using Ajax then because you have to run server code and have to update a lot in the client content anyway. This is much easier in a full page request especially for non-expert users. Of course everything is possible with both solutions.

One advantage is less coding and independence from page structure, so you don't have to care about something like .update("form-2:someComponent");. So if the page structure changes, your function is likely to break too which means a higher amount of maintenance and refactoring at a long term perspective in your software project. Also you cannot use the function in a CompositeComponent beacuse you always need to known somthing about the xhtml structure to make it work or use @Form which, at the end, brings you back to what I said before.

As I said, this is valid when we talk about service calls or peristence operations. I prefer to use Ajax for "fire-and-forget" calls or to load some lazy stuff to the UI.

Lars

kukeltje
Expert Member
Posts: 9605
Joined: 17 Jun 2010, 13:34
Location: Netherlands

20 Mar 2018, 22:09

Hmmmm I read some things that I like to comment on although all this is sort of off-topic. And in my opinion there seems to be a contradiction.

[/quote]
LarsD wrote:
20 Mar 2018, 12:59
In general, not using so much Ajax is my personal preference.
For me it is the opposite (mainly for a better user experience (less delay, less flickering and less processing on the server)
LarsD wrote:
20 Mar 2018, 12:59
In this particular case (meaning add/remove/update data of a dataTable in a popup) it would normally end in a persistence operation which means a server call. It makes no sense to me using Ajax then because you have to run server code and have to update a lot in the client content anyway. This is much easier in a full page request especially for non-expert users. Of course everything is possible with both solutions.
Update a 'lot'? Just the datatable... or a container. Can still be waaaay less than a full page refresh. And for non-expert users it is better to become one that to keep living in the dark-ages (yes exaggerated)
LarsD wrote:
20 Mar 2018, 12:59
One advantage is less coding and independence from page structure, so you don't have to care about something like .update("form-2:someComponent");.
It's just a little less coding (the 'update' part) since the server side stuff is still needed. And sometimes not using ajax results in more code (Adding error messages if a button is pressed that cannot do anything since e.g. no row in a datatable is selected and similar things). Disabling that button when no row is selected is easier.
LarsD wrote:
20 Mar 2018, 12:59
So if the page structure changes, your function is likely to break too which means a higher amount of maintenance and refactoring at a long term perspective in your software project.
For small changes this often is very little effort. And for big changes, the amount of effort that needs to be put in the big changes is waaay more than the ajax stuff. And even then, if the basic functionality of your app does not change, just lots of ui changes, the ajax often can stay the same, assuming you assigned meaningful id's to things.
LarsD wrote:
20 Mar 2018, 12:59
Also you cannot use the function in a CompositeComponent beacuse you always need to known somthing about the xhtml structure to make it work
You **can** use it there and if you need to know what is **inside** a CompositeComponent, the composite component should maybe not be a composite component or the thing outside the composite component that needs to know about things inside it should also be inside it (encapsulation) And PrimeFaces search expressions facilitate some of these things
LarsD wrote:
20 Mar 2018, 12:59
or use @Form which, at the end, brings you back to what I said before.
Updating 'large parts'? Things are not black and updating a form is very often much quicker than a full page refresh. And with complex forms for business apps, the user experience when doing full page requests is bad, very bad. Unless you develop lots and lots of client-side javascript to counter this (PF CSV is only part of the solution)

Cheers

Post Reply

Return to “PrimeFaces”

  • Information
  • Who is online

    Users browsing this forum: No registered users and 37 guests