I don't, off-hand, no.

I can build an example app when I get a chance though.

On 03/01/2013, at 8:20 AM, Ramsey Gurley wrote:

You wouldn't have an example you could share, do you? :-)

On Jan 2, 2013, at 1:57 PM, Matthew Ness wrote:

On 03/01/2013, at 2:44 AM, Ramsey Gurley wrote:

I thought about AUC, but I figured the viewport would jump around when the container updated.

I have not seen that behaviour.

Also, do you reload the entire container each time or are you just appending new results?

The fetch results are appended to a collection. The _container_ is loaded again, so, yes it conceivably gets slower to load. I have seen no real degradation in load up to 1000 objects with most of their graph information and a couple of images each. That was my brief so we're happy with that.

You could perhaps load the new results in a new AUC, which itself has a new AUC for the next results, etc, etc. 

I would expect a full reload to become increasingly slow after each batch.

With JC, all the interface is done on the client.

Yes, I have used Java Client before.

Doing this server side, I see potentially tricky issues… mainly the back button and forms.

Not had a problem so far with either of those.


On Jan 1, 2013, at 11:28 PM, Matthew Ness wrote:

Hi Ramsey,

I've built infinite scroll components before using AjaxUpdateContainers, AjaxSubmitButtons, ERXFetchSpecificationBatchIterators, and some JavaScript listening to a couple of view-port/window events.

Not WODisplayGroups, but works really well. :)



On 02/01/2013, at 3:00 PM, David Avendasora wrote:

Hey Ramsey,

I'm not sure if this is what you mean, or exactly how it is done, but a WO Java Client application automatically faults and transfers data to the client while scrolling a list view. The client gets all the initial EOs that are "visible" in the scroll-view area of the window when it is first displayed, and as the user scrolls or makes the window larger, the client-side app automatically requests additional data from the server-side app depending on what was now "visible" in the client-side window. This made for a very quick initial load, but "required" a fast connection to then server to make it smooth.

Of course a WO JavaClient app has it's own EOF stack and could cache EOs in the client-side EOEditingContext so it didn't have to talk to the server to scroll back up to rows it had already loaded. Not sure how you would deal with that efficiently with a HTML client… maybe with a little choco-hazelnut goodness?


On Dec 31, 2012, at 11:43 PM, Ramsey Gurley <ramseygurley@gmail.com> wrote:

Has anyone done infinite scroll using WODisplayGroups?


Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
Wonder-disc mailing list

WebObjects - so easy that even Dave Avendasora can do it!™
David Avendasora
Senior Software Abuser
Kaiten, Inc.

Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
Wonder-disc mailing list