How to fetch remote data when no count() is available? - doby-grid

How can i use the remote fetching functionality of DobyGrid when it is not possible to provide a valid value for the count() method?
There are some situations where this is not possible, i.e. when counting all the rows would be way to expensive in a performance point of view.

At the moment, it is not possible. The count() is required to determine the height of the viewport's scrollbar which is used for pagination. Without the count, the current pagination technique would not work.
In order to support count-less remote fetching functionality, we would need to add an alternate form of pagination. Either via infinite scrolling which only fetches the next page when you're near the bottom of the grid, or more traditional, with page selections buttons in a toolbar area. We can probably add support for both.
The feature is being tracked on our Github page at:


setAutoScroll with QTreeView and custom model does not work

I have made a QTreeView to display a very large and continuous data set. Since the data set is continuous, I delete initial rows when the total number of rows is greater than a specified amount.
I have used a custom model for this purpose
The whole system is working correctly and displaying data.
But I want it to autoscroll to the bottom to display latest data. If i use scrollToBottom at row addition it completely slows down the entire view-model. But If i use m_pTreeView->setAutoScroll at the start, it has not effect.
Moreover if i click on the view, it completely slows down.
I am using Qt 4.7.1
How should I auto scroll to the bottom without compromising on performance?
And show I remove the lag/drastic performance hit when I click on the view?
the whole code is available at this repo:

Strange behaviour in dojo filtering select

I have a problem in an xpages application where I use dojo filtering select. When I use type ahead and the result returned is restricted to one occurrence, I have the behavior shown below. How can I increase the height of the results listing. Is there any way to do this?

How do native apps handle a large number of nodes in the view?

I am a web developer and one of the current issues is the migration towards single page applications (SPA) and the challenges this brings about. For example, if we implement the infinite scroll, we can easily find ourselves with hundreds of document object model (DOM) nodes rendered in the browser.
Subsequently, if we need to make some changes that will propagate through all of them, this can take a huge bite off our performance. That is partially a reason why libraries like React gained popularity - virtual DOM.
Virtual DOM creates a virtual representation of the whole DOM tree and whenever any changes are made, it compares the old and new state, and updates only those nodes that have changed. Ionic, a hybrid app framework, has its own solution for infinite scroll that hides those nodes that are not in the view to speed up the performance.
So I was wondering, how do native apps cope with a large number of nodes in the view? Any social app with a feed can reach that number after a few seconds of scrolling. Is it handled by the OS? Is it an issue at all?
It is an issue if you don't adhere to some best practices. Like loading variable images asynchronously or keeping the layout as flat as possible. For list views its the ViewHolder technique.
The List implementations on Android usually don't instantiate as many views as there is content in the provided dataset but only as many (and some extra) as could fit on the screen. When a view goes off screen the ListView caches that instance and provides it back to you when a new entry from the dataset should be shown. You then simply put the values from the model in the provided view (or better in the associated ViewHolder) and its done.
Other issues might arise if the dataset is changed frequently or is simply to huge. If an entry in the dataset changes, then you probably don't want to redraw the whole ListView but only the view that changed. Older List implementations cannot handle this. If something changes, every visible view in the list is redrawn. Modern List implementations like the RecyclerView don't have this limitation. Not only does it enforce the ViewHolder technique it also provides methods to tell the RecyclerView what item changed so it can pull of some efficient redraw magic.
If the dataset is to large, then the best way to avoid memory or performance limitations is to only load the latest items from the dataset and ask the user to load more. Or paging.
So yeah, the framework does help you is most cases. But there is enough room to mess things up.

What is the best way to display list items (thousand+) in AIR Mobile app?

I'm working on an app right now displaying a contact list. The app is for Android and iOS, developed in AS3. That contact list contains on a basic usage 1000 items and that could go to 10 000.
Now a displayList with that many items does not work of course.
So I tried using BitmapData (the same item is updated, moved, and "stamped" on the BitmapData) before rendering but again, that's too big for a bitmapData.
I am now thinking about calculating the position of the scroll in the contact list and render on the displayList only what's on screen but I'm not sure how to handle this.
What are the best practices for that kind of issue?
I am now thinking about calculating the position of the scroll in the
contact list and render on the displayList only what's on screen but
I'm not sure how to handle this.
That's the correct way to do it, it's a form of object pooling and I think it's also known as layout virtualization. I don't know how to do it in classic AS, but I've been using the Starling framework (gpu rendered display list), and the components lib there (known as Feathers), has such a list, you may wish to check its implementation. Here's a demo (check the List), I've tested this with thousands of items and it works perfectly:
Feathers Component Explorer
But in short the idea is to create visual components equal to the maximum that can be seen at the same time. Then, whenever the list moves you must check which are the visible indexes. When they change, which happens when an item becomes invisible - for example going off the top, you move it to the bottom and reuse it with new data, corresponding to its index.
It's best to use some framework for that - search for UI tools. If you are using Starling - there is Feathers. Also you can use MadComponents which is pretty nice. For simple cases you can use MinimalComponents.
They all have built in lists. If you don't like them, you should build one by yourself.
The best practice is to show only the visible items, and have others removed from stage. So you have to calculate the current position of the list that is being scrolled, calculate the items that are visible, and then add them and display them. Everything else should be removed and hidden.
But again, I think some of those I mentioned should fit your needs.

Sorting nodes visually in Drupal

I have created a photo gallery for several web sites using CCK. I created a new content type and added a numeric select list field that allows the client to change the order of the photos in the gallery (views with a jquery lightbox).
The problem is that there are now too many photos to manage the sort easily. The only way for the client to change the sort order is to edit each photo node individually.
Is there some sort of drag and drop sorting that I utilize to give my clients a GUI interface to sort these nodes?
I had considered Nodequeue, but I thought there might be a better solution.
A nodequeue is probably your best bet (remember that you can also do a view over a nodequeue, which makes them a little easier to use).
If your gallery is a content type, and a photo is a content type, then you can have your gallery noderef the photos. Set it up so that the noderef uses autocomplete text fields, and you can then drag-and-drop the ordering on the gallery edit page.
This sounds like a prime case scenario for Draggable Views. It takes a little bit of setting up, you have to make a new page (in your current view) that is used only for administrative sorting, but once done it should work perfectly as you are describing.