On Thu, Apr 27, 2017 at 9:54 PM, Shane Curcuru <[email protected]> wrote: > Sam Ruby wrote on 4/27/17 9:37 PM: >> On Thu, Apr 27, 2017 at 8:28 PM, Shane Curcuru <[email protected]> wrote: > ...snip... >> What that means is that your script will have to look at the URL to >> decide what to output. Look for "request" in members/watch.cgi for an >> example. > > Fascinating. Question: when does Wunderbar send data to the browser? > When I load members/watch/appstatus, it *seems* that the browser renders > the header and two panels first, then pauses briefly, then renders the > table. > > Which makes me think: shouldn't the txt = File.read(... and txt.scan > lines be moved after the rendering of the panels, so the user experience > is better if the server's being slow?
Wunderbar buffers everything up, computes the value of a few header (etag, for example) and then sends the data all at once. >> Duplicating sounds bad, but you have plenty of changes, for example >> linking to the phonebook instead of the roster tool. There will be >> some common code, such as parsing the orgchart... that can be factored >> out to lib/whimsy/asf. > > Ah - because while the display of /orgchart and /duties is very similar > to how it works in roster, much of the rest of the connections to groups > and roster/committer pages would be completely different than the > private version. > > Yes, separately I wonder sometimes why some code is in this model, vs. > moving back to whimsy/asf. Some differences absolutely make sense, but > on first inspection it feels like there are some other parts that could > get factored back. I suppose that's 1) how things got built > organically, and 2) only has a purpose if some other tool needs those > functions as well. Pretty much. > Starting to feel like I might still be a developer after all! I've been impressed by how fast you've come on board. > -- > > - Shane > https://www.apache.org/foundation/marks/resources - Sam Ruby
