I need to display a big amount(1000+) of similar widgets (each widget
contains photo + descrption - about 400*400 px total) in a table -
say, 10 rows and 2 columns per page. I don't need option to select,
drag, highlight or do smth else with these widgets - just display
them.
It seems that FlexTable doesn't support paging. CellTable does, but it
seems to be too complicated and best suited for displaying different
data in different columns while I need just to place similar widgets
in each cell.
So, I'm a bit confused about what table to use and need some help
about this.
Thanks in advance!
Celltable and family are definitely the way to go. From the docs :
Cell widgets (data presentation widgets) are high-performance,
lightweight widgets composed of Cells for displaying data. Examples
are lists, tables, trees and browsers. These widgets are designed to
handle and display very large sets of data quickly.
https://developers.google.com/web-toolkit/doc/latest/DevGuideUiCellWidgets
And they support server side paging...
Your case from what I read.
Related
I've been trying to understand the difference between these two widget constructors (not sure if that's the right term, I'm new to Flutter).
The way you use them seems to be pretty similar. I'm working through a tutorial and ListView.builder seems to be the way to build long lists efficiently since it only builds what needs to be displayed on screen. Does ListView.custom do this too?
This docs for ListView.builder state:
https://api.flutter.dev/flutter/widgets/ListView/ListView.builder.html
Creates a scrollable, linear array of widgets that are created on demand.
This constructor is appropriate for list views with a large (or infinite) number of children because the builder is called only for those children that are actually visible.
For ListView.custom it says:
https://api.flutter.dev/flutter/widgets/ListView/ListView.custom.html
Creates a scrollable, linear array of widgets with a custom child model.
For example, a custom child model can control the algorithm used to estimate the size of children that are not actually visible.
It's not quite clear what the difference is, when to use which, etc. Can anyone give some more insight into these two features?
I am trying to create a table in a PDF document with itext7. But, if the content before the table is too big, the table gets split up between current page and next page. I want to insert a -
document.Add(new AreaBreak())
if there is not enough space left in the current page for the table to be inserted completely. However, I have no idea on how to calculate the available space.
Any help or pointers will be highly appreciated.
From your requirement to avoid page-break inside the table, I assume Table#setKeepTogether(boolean) is exactly what you need.
This property ensures that, if it's possible, elements with this property are pushed to the next area if they are split between areas.
This is not exactly what you have asked, however it seems it's what you want to achieve. Manually checking for this use case might be tricky. You would need to have a look at renderers mechanism and inner processing of iText layout in order to get available space left and space needed for the table. You would also need to take care of the cases like if table is to big to be fit on single page. Also #setKeepTogether(boolean) works when elements are nested inside each other.
I have a case where my DataGrid might contain thousands of rows of data. My page size is only 50. So I want to get only so much data onto the client from server and load rows of data as and when required. Is there a default support from GWT to do that?
I tried using PageSizePager but then realized that the data is already sent to the client and that defeats what am trying to achieve.
Thanks.
Indeed. The aim (among others) of DataGrid, as well as of any other cell widget, is to display large data sets as fast as possible by using pagination and cells.
I suggest you to start with the official docs about CellTable (same applies to DataGrid), and pagination/data retrieval.
You'll probably need an AsyncDataProvider to asynchronously fetch data and an AbstractPager (say, SimplePager) to force retrieval of more data.
You can also decide to extend the current range of rows (say, infinite scroll), instead having multiple pages (by using KeyboardPagingPolicy.INCREASE_RANGE).
In general, the question is too general and can be hardly answered in few lines (or without specify more). The bits are all in the links above, and don't forget to have a look at the cell widgets samples in the showcase, as they cover almost everything you will need.
Hope to get you started.
I would like to make celltable to behave like smartgwt's table
http://www.smartclient.com/smartgwt/showcase/#grid_memo_rows
but i do not want to use smartgwt library
For the time being, you'd have to resort to some kind of composite cell rendering the whole row, which can be quite tricky.
This feature should come in GWT by this summer though: https://groups.google.com/d/msg/google-web-toolkit-contributors/tKim48mKwGE/P4wj0t-Om5AJ
We are attempting to create an editable grid using CellTable. The use
case is fairly high volume data entry for accountants who are used to
10-key entry into spreadsheets. We are trying to replicate spreadsheet-
style keyboard navigation as closely as possible.
Is there any way to avoid having to hit Enter to get into edit mode
for a TextInputCell? I have tried overriding
TextInputCell.onBrowserEvent() to call onEnterKeyDown() when a focus
event is received, but that didn't work.
Is there any way to use Tab and Shift-Tab to navigate between
columns instead of LEFT-ARROW and RIGHT-ARROW? CellTable seems to be
hardcoded to use left and right arrows and difficult to extend.
After quite a bit of work trying, we determined that CellTable was not extensible enough to do what we needed. We ended up extending GWT's Grid class, taking design cues from CellTable to make it perform well enough for our needs.
In our use case, 80% of page views will display less than 10 rows and we will never have more than 600 rows by 10 columns (< 0.5% of cases have more than 500 rows). Instead of a full-fledged flyweight pattern, we used a lazy loading pattern. When the Grid is initially populated, display-only widgets are used to show the data from the underlying value objects. A FocusHandler is attached to each display-only widget. When a user clicks or tabs into a display widget, the FocusHander swaps out the display-only widgets for that row with the editable widgets.
Display-only widgets are restricted to lightweight widgets such as TextBox and CheckBox, so rendering time is acceptable. 100 rows x 5 columns render in less than 2 seconds. SuggestBoxes, DateBoxes, and other Composites are limited to only being used as editable widgets.
Advantages
Flexibility to use any of the
standard widgets
Extensibility - we're not limited by
the implementation choices made in
CellTable
Ease of development - prototyped in
less than 3 days of development
Performs well enough to fit our
needs
Tabs work out of the box as you would expect
Disadvantages
Not as scalable as CellTable. This
implementation is not going to render
thousands of rows
We have to maintain it ourselves