I am definitely working on it and will have default.aspx complete this weekend. Moving the javascript out of the .cs files, changing Response.Write to StringBuilder and removing all the <% aspcalls %> so they are executed in the .cs file shows a minimum 50% performance improvement with no caching. Initial page delivery times drop from 3500 ms to under 1500 ms on my dev system.
I also expect to tackle at least some of the Formatter code as the menu javascript stuff is built in there. This may provide other improvements. On 8/2/07, Craig Andera <[EMAIL PROTECTED]> wrote: > > Well, the core doesn't care about the web, so it wouldn't be something I'd > do. Further, for static files you're probably better off *not* caching them, > as IIS is wicked fast at serving them. But if for some reason it made sense > to cache them, then if I was you I'd use the ASP.NET cache. Although I've > abstracted it via the IWikiApplication and IWikiCache interface, when the > core is hosted by the web app, that's where it winds up storing its cached > data. Testing shows you are correct, but it may also be a function of a client side cache in the browser. Times drop to 0 ms to serve up the js when it is in separate files and has been accessed once before by that browser. > > > Cool. What are your goals? I.e. are you going to try to sync up with me for > the 2.0 RTW milestone? For all the pages? Some of them? > > I'd also love to see someone address testing in the web app - our story > sucks there right now. > Testing is where the real problem is with this conversion. I have not yet seen an implementable method for exercising the web portion of an ASP.NET 2.0 web app. Generally I am trying to only touch the presentation, but even that layer has some business logic in it - redirects, config settings, etc., that all impact on how the final topic is rendered? Does anybody have _ANY_ thoughts on how to automate that testing. Right now the only way I can see is to build a wiki with a number of namespaces and test topics that are designed to cover the various cases possible and then have an automated tool run through accessing each topic. Testing is really the major impact on how this syncs with the RTW effort. John Davidson ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Flexwiki-users mailing list Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users