Is there a way to preserve the contents of a tabbed component when toggling between them? I found #PreserveOnRefresh but that only seems to work when refreshing the browser.
Assuming you mean navigating between Routes/views rendered as tabs, I think what you're looking for is the #SpringComponent and #UIScope annotations. Add these to the relevant classes to preserve any input fields and outputs when toggling. Note that you'll still need #PreserveOnRefresh if you want to retain those fields when refreshing the page itself.
See: Vaadin Component as Spring bean for a breakdown of the specific functions the two annotations serve.
Related
I am creating a project where I need to create a view with search textboxes and a dropdown which would be populated from the server. Same view also have a grid which would be populated based on the search criteria enter/selected by user.
I want to know what would be the design of the page in terms of showing both on same page. Should I create a partial view for the grid or Search panel or add both in the single view?
Note that dropdown list would need to be populated from the ViewModel. So what is the common practice in the situation. I am new to this I have done few pages but with lot of code, session and ViewBags and I think I am not following recommended practice.
Actually, the design for your web application is according to your requirement.
For example, if you want grid to work with other datasource or view, you could build it as a component, then if you want to use it, you could directly use this component to avoid write the same codes for multiple time.
If you want to use same grid to show in some other page, you could build it a partial view, then you could directly call this view to show something.
In Vaadin 8's grid you would see the Save/Cancel button when doubleclicking on a row in GridPro. In Vaadin 14 Grid Pro doesn't seem to have that save save/cancel button by default. Is there a way to enable it?
It seems like it should be possible because we have getEditor().addSaveListener() etc.
As an extra question whenever I do any action in the grid it seems to only call the addCancelListener(). Is there a reason for this? The primary question of course is if it's possible to show the save/cancel buttons in GridPro
GridPro adds another editing functionality to the Grid, which is not using grid.getEditor() at all. So these are not to be mixed.
GridPro is designed for cell-based spreadsheet like editing with improved keyboard navigation, thus save/cancel buttons are not there. Editable columns are added using grid.addEditColumn(..) method and using either built in fields like below, or custom type. In both cases saving of the value is handled in the call back provided.
grid.addEditColumn(Person::getEmail)
.text((item, newValue) ->
item.setEmail(newValue))
.setHeader("Email (editable)");
So save / cancel events from grid's editor are not emitted. Also this functionality does not use Binder by default. You need wire Binder yourself if you need it, see example in Vaadin's cookbook.
Basic Grid has builtin row based editor, which uses also Binder. With that one you can use it Binder and editor in buffered mode, and for example add an additional component column to where you have edit / cancel buttons, what ever you like. There is rather good code example at Vaadin's component pages.
In summary there are two different editing facilities provided and these are not to be mixed.
I have some experience with GWT . In GWT , widget.setVisible() method will add style="display:none" style to widget. But component of vaadin wouldn't . I checked with firebug , I can't see my component while set component's visible to false. Why ?
I think that should be also have hidden style instead of not containing. I reallize that vaadin's codes were server side. But sometimes , if I would like to just hidden (set style display to none) , has there anyway to accomplish this instead of using css ?
I don't understand concept of what different between without adding component and setVisible(false) ?
As you already noticed, an invisible component is not transferred from server to browser, and from browser's point of view the component doesn't exist. This approach has to benefits:
Less data to transfer from server to client
Security: User cannot inspect invisible components' generated HTML with tools like Firebug because those doesn't exist on the browser.
So basically from browser's point of view it's the same thing that you don't add it to the UI at all. But usually it's just easier to toggle component's visibility instead of adding and removing it from its parent.
If you want to hide components with CSS, you can do it by defining your own theme and adding a style for that there. Then just apply the style for the component you want to hide by using the addStyleName method.
SETVISIBLE Sets the visibility of the component.
Visible components are drawn in the user interface, while invisible ones are not. The effect is not merely a cosmetic CSS change - no information about an invisible component will be sent to the client. The effect is thus the same as removing the component from its parent.
So as the documentation says invisible components are not not visible.
I am having some challenges trying to use JQM and MVVM. I am also trying to use knockout.js too.
For example, currently I am trying to implement a navigation similar to the iOS page control(the little dots indicating you can swipe to navigate to the next page):
The data to be displayed is fetched from the server and it needs to be displayed in JQM pages. So the JQM pages need to be created dynamically.
From the UI perspective, I plan to use a fixed footer containing the dots(based on the number of pages).
The problem is with the view-model which needs to persist between the JQM pages, as I do not want to load data from the server by page, data is loaded at once and it is expected that the client will display it in pages.
I could have a view-model holding the data and living through-out the life of the application and just bind each page view to it.
Instead, I want to keep the view-model alive as long as it's really required by the view.
The solution I am thinking is to catch jQueryMobile page navigation events and see if the navigation is between these pages.
If it's not, the view-model should be removed(assigning it to null).
Next time if any of these pages needs to be loaded(for example by navigating back to the last page), the view model is re-created(data is fetched from web-site again).
Is there a better approach?
You should have a look at the Persistent Footers page on the jQueryMobile documentation.
Why don't you try the JQM pagination plugin along with the persistent footer #calavoow mentions?
That would give you dragable JQM pages with a set footer.
i have an html table in my asp.net mvc view an i am running into some real estate issues with screen space.
I think in one area of my view i am going to have a button in a column of an html table that says "Details" which, when clicked, loads up some dialog ui. what i am trying to get my head around is that i want the fields in the dialog to also be part of data binding object in the overall form which i am passing to the controller when i submit the form.
is there anything that i should be worried about or anything that you need to do special if you have a form where inside your form you have a button that create a popup with some more details elements. I am just trying to see from a data binding view if there are any issues.
also any examples of doing anything similar would be great.
EDIT
So i tried doing this an ran into a binding issue. i have a follow up question with the specifics about this binding issue with jquery ui dialog here:
why does jquery ui dialog break asp.net mvc's default model binding .
There shouldn't be any issues if you are binding elements from your popup dialog to corresponding hidden elements in your main view. These hidden elements will bind correctly like any other control in your main form.
Of course, you might be POSTing the form elements from your popup form to its own controller method directly, and that is also a perfectly good approach.