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? > 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. Starting to feel like I might still be a developer after all! -- - Shane https://www.apache.org/foundation/marks/resources
