Until now I used RichFaces like web-framework to build presentation layer to some applications, now at company I work for has been decided to some project to use vaadin instead of richfaces. With richFaces when I had complex table-based data representations, I often use:
rich:collapsibleSubTable
to get components that looks like at the following
Now I want to ask you how can i get a similar result with vaadin?
Are there some add-on to make it?Otherwise can you give me some suggestion about this?
for the table you can go with the one from vaadin
for the folding you could use a tree on the left side of the table in a horizontal layout or you could go with an accordion or with tabsheet and put the table for each continent there.
accordion + table would come closest to what you have there with least efford.
Related
What is the difference between the Grid and Table components in Vaadin 7?
Which should I use, and when?
Summary
Grid → New & AmazingTable → Venerable & Reliable
Table is a very good data-grid display widget built into the earliest versions of Vaadin.
Grid is grand rewrite from scratch, designed to supplant Table. The Vaadin team is leveraging their wisdom gained from experience, “if we knew then what we know now”, to make the very best data-grid possible given today’s Web technology. Grid is such a big deal that it gets its own vanity page. See this company blog post for a quick overview.
So, generally speaking, I suggest you focus on Grid. Try it out, learn it first, and see if it meets your needs. If you run into bugs or problems, or you have need features lacking in Grid, then fallback to Table. You can mix-and-match both in a project, with the caveat that the different appearance and behavior may confuse your users.
Think of Grid as the precocious adolescent full of promise and eager to make the leap into adulthood, and Table as the mature grownup working hard in its prime years of middle-age while dreaming of a well-earned future retirement sailing into the sunset.
Details
If using Vaadin 6, on a continuing project or you need to support very old browsers, then Table is your only choice. Grid requires Vaadin 7 or later.
Here are some major Table features currently lacking in Grid.
Drag-and-drop features (to be added later).
Resize column by user dragging edge of column header.
Both share many features. They practice lazy-loading to the browser, automatically loading data only as needed from the server-side so as to not overload the web browser. Both allow the user to drag columns to re-order. Both let the user show/hide columns.
Row Selection
Both allow selecting single rows or multiple rows.
Grid also has an automatic feature where it adds a column of checkboxes. The user can select multiple rows by clicking those checkboxes rather than using a mouse or mouse+keyboard. Many, if not most, users are clumsy with mouse-driven multiple row selection. See this screenshot, and notice the very first column.
The programming support for selection is different. Grid does not extend AbstractSelect, instead defines its own selection API. Call addSelectionListener() and define a SelectionListener. See The Book Of Vaadin.
Headers & Footers
Both have headers and footers, but Grid has more options. Grid can place widgets instead of text. Grid can have multiple rows of headers. Grid can join header cells, like spanning in an HTML table.
In-Place Editing
Both provide in-place editing of data, but in different ways. Table allows editing of data in the cell. Grid took a different approach, for editing the entire row by displaying a mini-window, a little data-entry form. This form includes a pair of confirmation & cancellation buttons. This form is much more flexible than Table’s cell-editing.
Filtering
Grid offers user-controlled filtering, where a row of enterable cells appears below the headers. As users type a filter is applied to show only matching rows. See this screenshot. With Table, you need to create some kind of user-interface and apply the filtering.
Backed By Data Container
UPDATE: Vaadin 8 brings a new version of Grid that leverages a newly improved and greatly simplified data model. This is a major reason to use Grid instead of Table. Note that both the original Grid as well as Table are still available in Vaadin 8 via the Vaadin 7 compatibility layer.
The following old info left intact…
Both Table and Grid are a presentation-only widget, backed by a separate data object implementing the Container interface according to the Vaadin Data Model.
The Table class also acts as a Container which always confused me. I’m glad to see Grid maintain a more clear distinct separation.
Like Table, Grid does offer some convenience methods for quick-and-dirty situations where you want to throw some data at the Grid itself without formally producing a Container. But Grid’s convenience methods use row and column terms in contrast to the Container’s item and property terms. These terms make it more clear that your are talking to the Grid but the Grid is acting on its default attached IndexedContainer instance on your behalf.
Cell Content
UPDATE: In Vaadin 8.1, Grid gains the ability to display a Component in a cell. See a live demo of the Component Renderer.
Cell content handling is different. Grid cannot directly display column icons, nor can it place components (widgets) in a cell. Instead used the new Renderer features.
Doc & Demo
Both have a chapter in The Book Of Vaadin, one for Table and one for Grid.
Both have a live demos. One for Table (and TreeTable). And a couple for Grid, one full-window and one with various aspects.
See this brochure page for Grid, including an embedded live demo, with a link to further demos.
Miscellaneous Differences
Grid has a built-in widget for displaying a number as a small thermometer widget. See this screenshot, in the last column.
For more specific differences, see section 5.24.1 Overview – Differences To Table in The Book Of Vaadin.
Esoterica… Grid is the first component in Vaadin Components, a high quality set of Web Components built on Google Polymer that is ready to be used with any framework that supports Web Components. While the Vaadin team has promised to support Table for years in the future, don’t expect it to receive such special attention.
Vaadin 8
In Vaadin 8.0 and 8.1, Grid is getting even better. Major enhancements include:
Works with the simpler sleeker data model new in Vaadin 8
Pass a collection of entities for display
Easily define columns with type-safe lambda syntaxgrid.addColumn( Person::getFirstName ).setCaption( "First Name" );
Easier lazy-loading of data now that Container is gone:grid.setDataProvider( ( sortorder , offset , limit) -> service.findAll( offset , limit) , () -> service.count() );
The ability to display Vaadin components rather than just renderers
Drag-and-drop via the drag-and-drop support defined by HTML5.
Even more speed
The Table component is still available via the Compatibility layer in Vaadin 8 for continuing the use of Vaadin 7 classes.
Future
The Vaadin team has great plans for Grid, so much of what you read on StackOverflow page will change. The team will be eagerly adding features, enhancements, and bug fixes in the coming months and years. Many enhancements have already been made to Grid in its short history, so beware when reading older documents about limitations or lacking features – that may not be so anymore.
Grid is a new more powerful component which is supposed to be the successor of Table (see The Table is dead, long live the Grid). So there should not be any need to favor Table over Grid.
Here is a first in the series of articles by Vaadin aboout migrating from Table to Grid:
https://vaadin.com/blog/-/blogs/mission-rip-table-migrate-to-grid-basic
Actually it's possible to implement everything you want with both of them. But my experience is, that the Grid is more comfortable to use.
The Table is easy to understand and easy to use for simple tables (as you might guess). So if you just want to show a few lines of data visualized nicely - use the Table. It is stable and works well on that.
The Grid looks like a Table but it has some features towards the Table. If you have a whole lot of data to render the Grid might handle it better. Also there is a good practice for "inline editing" your data. There is a way to customise the headers of a grid extensively. If you want to do a lot of customisation and interaction inside a table-like component - use the Grid.
See the features here:
https://vaadin.com/grid
http://demo.vaadin.com/sampler/#ui/grids-and-trees/grid
There is a difference how you can select rows/cells in these two components.
For example the EventListeners for selection are used slightly different concerning the value they return.
Also there's a difference in how you add columns and rows to them, but thats just an implementation thing, so it shouldn't really matter.
In filter table ,if we clicking on the table header,first row will be defaultly highlighted by a method called setSelectable(true); but in grid table there is no such type of action,
I want to apply the same action in grid table. Is there any possibilty for having that nature? Is there any method or code available?
Below is the code I used in my grid table:
private void buildPagedGrid(Class<T> clazz) {
setWidth("100%");
setSelectionMode(SelectionMode.SINGLE);
setImmediate(true);
setSizeFull();
setContainerDataSource(dataSource);
setFooterVisible(true);
}
My target is to display an abbreviation list with two entries per line: the abbreviation and the corresponding long version. For a nice layout I used a GridPane because of the vertical alignment over all entries - it's nice to read.
But I also want to scroll to the clicked abbreviation and set the focus on it like in a ListView version of it.
For example the # on page links in good old HTML. Is there another javafx layout element I miss to achieve this?
I don't believe there is a provided control that will work for the specific scenario you are describing. However, I think one of these options might work for you...
Use the TableView control and add two columns for the information you want to show (one for the abbreviation and another for the long version). TableViews also have the scrollTo and setFocus functionality you're looking for. Here is a good resource to get you started with the Tableview control. You can also style the Tableview with CSS to look less like a table and more like a list if thats what your intention is.
The second option is to set a custom cell factory on your ListView that builds custom cells using HBoxes, VBoxes, Labels, etc. to achieve your desired look. You would also want to use the cell factory to populate each ListView cell with an object that contains both the abbreviated text and long version text. A couple good resources, 1, 2
Although I think both option will work fine, I would suggest option 1 since in option 2 you are sort of building a table type structure anyway. I hope this is helpful!
I am currently developing an Android app that is to be a counterpart to its sister iPhone prototype.
My task is to recreate the screen from a design mockup from the iPhone app in Android, as shown here:
What would be the best layouts / views to use for replicating this screen in an activity?
Thanks.
Your question does not clear some things up. Also, I disagree with Ted Hopp's answer. I believe he is assuming that the medications will be filled statically, or something like that.
By the looks of your app, I assume you will be filling stuff dynamically, probably with many medications at once, or no medication at all. By the arrows in the iPhone mock-up, I also assume you will want to perform actions depending on the medication selected.
All that said, I would use a ListView. My general concept (the one I'd probably use) would be like this:
You have your data source, and use a Loader/LoaderManager/etc. to fill that into a Cursor. I'd feed this cursor to a CursorAdapter (perhaps a SimpleCursorAdapter, which seems likely and easy by looking at that UI concept --- won't need to customize the adapter part itself). Finally, this adapter would be used in the ListView. This is fairly easy and won't take much code (the ListView-SimpleCursorAdapter-Cursor stuff, the data logic is certainly custom).
You can then manage each of your clicks using the proper ListView listeners, IIRC. And act accordingly depending on the item selected. I'm guessing that the user would, for example, startActivity to see a detail about each medication.
However, as I said, if you have a fixed number of medications (here says an experienced former leukemia patient here, so I always assume medications vary widely!), a single TableLayout would do, but I feel that's not the case.
Ah, and about the layout for each component/med, as I said, a simple layout would do. Probably a LinearLayout with horizontal orientation. Again, very simple to implement with a SimpleCursorAdapter.
There's a nice example of how to do this with a custom row view here. This is probably the cleanest way to go.
The closest built-in widget for this is a TableLayout. Take a look at the Hello Views tutorial project for an example of this in action. You might want to wrap it in a ScrollView.
The right approach is highly dependent on the requirements. As I see it, you have (at least) a few options:
TableLayout
ListView
Something custom
As David noted, the TableLayout is most appropriate if you have a fixed set of data, but you can make it work dynamically too simply by adding child views. The benefit of using the TableLayout is mainly a built-in implementation of columns, including dynamic column sizing based on contents. The down-side is the lack of built-in dynamic support, especially when working with large data sets.
A ListView is a better fit for dynamic and large data sets, but comes with the limitation of not supporting columns. Ted's link lets you simulate columns, but unlike TableLayout these columns have a fixed width (in percentage of the parent's width). The columns are not sized based on content. You could potentially try to do something to measure all the children, but it'd be tricky. It can also be mildly annoying to try to deal with headers in a ListView, though with a little searching you'll find plenty of resources to help you with this.
The third option is to roll your own AdapterView or AbsListView. Of course this involves a significant amount more work, but you could take a look at how TableLayout works and resize the columns based on the content. This would also get you support for adapters and all the benefits that come along with that. This is probably quite a bit of work though, especially resizing the columns based on content.
Consider whether your columns must resize to fit their content or not.
I am using JSF 1.1 and I'm looking for a JSF list of values component.
I have a button and when I click that a popup window should open with one text field and buttons, where either I could search for what I am looking for in the text field or select all the values when I click on the buttons and from the available list of values I should be able to select one item.
Is any such type of component available in JSF 1.1 or with the icefaces, richfaces or apache jsf components?
Your question title is a little bit confusing, as you don't seem to ask for just a "list of values"-component, but a bunch of different components. Your situation is too specific to have a single existing component covering it all, but you can rather easily achieve the effect by combining a number of components.
Anyway, RichFaces has a modalPanel that you can use for the popup. Text fields and buttons are in the standard Faces library and the 'available list of values` can be handled by a selectOneMenu component, which is also in the standard library.
One additional hint, if it's in anyway possible try not to use JSF 1.1. This is an extremely old version where the list of problems is nearly endless. If you are somehow stuck on a very servlet container you should at least use JSF 1.2, but much better is to use the latest 2.1 release.
What is the difference betweem the following:
TreeViewer & Tree
TableViewer & Table
TreeViewerColumn & TreeColumn
TableViewerColumn & TableColumn
When to use viewer & regular widget?
PS: It would a great help if you can help me find a good resource for understanding them.Thanks in advance!
You could have titled your question "What does JFace add to SWT ?".
Viewers are from JFace, Widgets are from SWT.
In summary, JFace make Widgets easy to manipulate and insert into a GUI. JFace frees you from all the drudgery of manipulating SWT widget elements to add behaviour to static widgets. SWT just provides listeners, JFace uses these listeners for you to allow you to concentrate on the mapping between the real world model and its SWT representation.
Let's see that on the specific examples you've listed.
If you build a standard SWT widget, you will have to describe the content of a Tree (set one or more top items, hook some TreeItems to each root, possibly add a selection listener) and then manage all its transitions. That Tree will have very little built in logic: just collapse/expand and selection listeners. Period.
That will be a static Tree.
A TreeViewer will allow you to inject many different kinds of behaviours in that Tree: How it is populated, filtered, how the TreeItems are labelled.
You will do that by registering classes satisfying to well specified interfaces (for instance the ILabelProvider will allow you to map a TreeItem label to a file name in a folder).
Without the TreeViewer, building a decent responsive tree would be a lot of hard work. In summary, it makes it easy to map the underlying real world hierarchical model to the SWT Tree representation.
The same holds true for a TableViewer. A TableViewer allows you to add some custom behaviour to your table. How do you edit a cell for instance.
TreeViewerColumn. A long time ago (before 3.3), SWT Trees did not have columns. Trees did not have Columns Tables had columns but they did not expand/colapse. Since 3.3 you can add columns to a Tree. You do this better with by adding a TreeViewerColumn to your TreeViewer rather than by just adding a TreeColumn to a Tree (which you still have to do) for reasons similar to the ones above, you can add support for editing the content of the column cells and you can populate the column (by writing a Label Provider again).
TableViewerColumn. Same thing for TableViewers : adds edition and content management.
For SWT/JFace doc, please have a look at.
Viewers belonging to JFace not to SWT proper, to go forward, look up JFace tutorials on google and you'll find a lot of examples.
Steve Northover's book (the father SWT) "SWT: The Standard Widget Toolkit, Volume 1" (AFAIK there's no second volume yet).
"Eclipse: Building Commercial-Quality Plug-ins" by Eric Clayberg and Dan Rube. Eric is now a Google VP and the father of WindowBuilder Pro
The SWT snippets are also a fast-track to mastering SWT objects.
Other good books include
"The Definitive Guide to SWT and JFace" by Rob Warner and Robert Harris
"Manning's SWT/JFAce in action"