Charlie, Is it possible the extra traffic is relating to authentication? I know when you do a open window action, the window is opened 'in the same session', but is it possible that when doing a URL call, it's having to communicate with the web server to determine which session is yours, which is taking a bit of time?
On Sun, Apr 13, 2014 at 7:37 PM, Charlie Lotridge <[email protected]>wrote: > ** > Thanks for the suggestion Joe. Unfortunately the solution is not going to > be that simple: I was actually using a request id in the search, so it's > not going to get more optimal than that. > > I actually did a side-by-side comparison earlier. I set up an AL that > would open an entry using OpenWindow, and another that opened the same > entry using a URL, both effectively doing the same exact search (using a > request id). The URL method took a full second more to load (about .6 for > OpenWindow vs. 1.6 seconds for the URL). Using the browser's network > monitor I can see that it's performing some additional network > transactions, though (again) I really don't how to interpret these results > yet. > > -charlie > > > On Sun, Apr 13, 2014 at 1:57 PM, Joe D'Souza <[email protected]> wrote: > >> ** >> >> I won't pretend to know the answer - but have you ruled out some piece of >> search workflow that might be running when you use the application command, >> which might not be running with an optimal search criteria, which might not >> be triggered during the regular Open Window action? I wouldn't have thought >> there would be a difference in the performance when essentially you are >> doing the same thing. >> >> >> >> Joe >> >> >> ------------------------------ >> >> *From:* Action Request System discussion list(ARSList) [mailto: >> [email protected]] *On Behalf Of *Charlie Lotridge >> *Sent:* Sunday, April 13, 2014 1:51 PM >> *To:* [email protected] >> *Subject:* OpenWindow vs. PERFORM-ACTION-OPEN-URL >> >> >> >> ** >> >> Hi, >> >> >> >> Recently I was experimenting using PERFORM-ACTION-OPEN-URL instead of an >> OpenWindow action to open a Modify window on a specific entry (using the >> ?eid=<request id> parameter). It's easy enough to use and I certainly got >> it working, but the performance as compared to OpenWindow was abysmal. >> >> >> >> My guess is that this has something to do with browser caching...maybe >> this method can't use the cache or something. But I'm not sure since I >> don't really know anything about how browser caching works. I opened up >> the Network Monitoring console on Netscape and do see some significant >> differences in the request/response transactions, but I don't quite know >> how to interpret it. >> >> >> >> Does anyone have any thoughts or experience as to why I'm seeing this >> performance difference or how to mitigate it if at all possible? I've >> tried it on each of IE, Chrome, & Netscape with similar results. >> >> >> >> FYI here are my reasons for potentially wanting to use >> PERFORM-ACTION-OPEN-URL: when (in the natural course of navigating through >> my application) the user wishes to modify some entry, I have some >> generalized workflow that causes the app to open a Modify window. If the >> window is opened using OpenWindow, though, and the user subsequently >> attempts to refresh the browser page, it's converted to a Query (Search) >> window and the context is lost. >> >> >> >> Similarly, I was hoping to preserve browser history functionality for the >> user. If a user navigates from one entry to another (on the same for or a >> different one), then the browser's Back and Forward functions should work >> correctly and revisit the appropriate previously visited entries in modify >> mode, but with OpenWindow they don't. >> >> >> >> Using PERFORM-ACTION-OPEN-URL accomplishes both of these goals NICELY and >> I'd switch my generalized workflow to use it except for the performance >> issue. >> >> >> >> Any thoughts? >> >> >> >> Thanks, >> >> Charlie >> _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
