On 12/6/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
It's hard to tell which problem you are trying to solve through your comments.
Well, I've got a lot of pages that just plain take a while (1-2 secs, with a max at maybe 5 seconds for one particularly nasty page that will eventually get some custom schema to alleviate the mess of joins) to collect all of the data necessary to render them, even without a form submission. I've also got an enterprise app where the data center is in Munich, but half the users are in the US and other distant locations, so I've got two problems to solve - general transfer latency of rich pages and compute latency. I need to nail both with a single solution. In most cases, I don't have the ability to render an empty page and then fill it in with ajax because tap just doesn't appear to be flexible enough in that regard, unfortunately. Rewind cycle strikes again. Trying to load up an 'empty' page which can then be populated with ajax is difficult because any form component that uses a complex model (table, property selection, etc) must at least have enough data in the model to be successfully rewound during the ajax request unless I want to store all the submitted values via persistence to the client or session so that I can render the page without any form fields at all, initially. That probably means a special version of the model which contains only the values I know will be submitted during the ajax request. To me, that's just architecturally ugly, since every page that needs a please wait notice must have custom engineering to support it, and the engineering required is different for every instance. That'll be both bug prone and time consuming. What I am looking for is something that can be applied at the framework or base class level (or added as a component, but I know that isn't going to work), so I don't have to go back and re-engineer a couple hundred fairly sophisticated pages just to get processing notices added to them all. The only solution I see, and one which appears to work quite nicely, is to use a servlet filter to provide a fake request to render a progress notifier and then replace that with the original request via a javascript redirect after the "please wait" notice is displayed. It handles all non-ajax cases except file upload form submissions and it can be easily enabled and disabled on a per-page basis declaratively through a number of methods - custom params in the request, special headers, path identification, and probably others. The only thing I don't like is that it is 'outside the application' since it lives in a servlet filter, but I can live with that. Sure, it will suffer a little for users on high latency connections (especially the folks down under), but so long as the processing notice is very small, it shouldn't be too bad, since the bytes transferred should fit within a single packet, if I'm careful. And the notice will be visible and remain visible whether the lag is due to network or server i/o. I'm just posting this so others can use the idea. I've already determined that the concept is sound. --sam
The mention of a File upload area being a good place to have a wait indicator would be a perfect scenario for the suggestion of throwing up some sort of shared "wait" dialog via javascript. (as was outlined in more detail previously) For data intensive things with potentially many nodes there are other options. For instance, you will notice that the tacos tree demo does exactly this. It renders the page out initially and displays a wait cursor after that is completed while it fetched all of the data to display all of the tree nodes, http://opencomponentry.com:8080/tacos/ajax/TreeExample.html . I don't think you are going to find a solution that fits all scenarios. (at least not one that works well from a user/developer perspective) You may have to just treat each page on a case by case basis. Probably more work but definitely a better experience for your users. On 12/6/06, Sam Gendler <[EMAIL PROTECTED]> wrote: > I think that functions by loading the page entirely without data and > then firing off an ajax request to get the data. I'm seriously > considering reworkgin my pages in a manner that alows this. By > default, the page renders a page that does no work, including > populating models and such. The content area gets wrapped in a great > big div that can be replaced by an ajax request. When the ajax > request fires, I can then populate the models, knowing that a please > wait dialog is visible. The trick will be in ensuring that all the > models are instantiated with at least enough data to rewind correctly > during the ajax request - I'm concerned that doing that will be very > labour intensive and may well require lots of custom code on every > page, to take into account that page's particular requirements. > > I'm thinking I need to get really sneaky and do something with a > servlet filter, such as intercepting all incoming requests, > instantiating a new Request object which tells tapestry to render a > page that does nothing but display a please wait dialog before sending > an ajax request with a particular identifier in it. When the filter > sees that identifier, it can replace the incoming Request object with > the original Request object, allowing the page to render correctly. I > have no idea whether this is truly feasible, but I suspect it is the > only truly viable solution that works in all cases (except file > upload, I imagine, which is a shame, cause that'd be a real handy > place to have a pleae wait dialog). > > --sam > > <snipped> -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
