Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

refactor newlistapproved to absorb newmoderatelist

by jdporter (Canon)
on Jul 13, 2012 at 13:31 UTC ( #981619=pmdevtopic: print w/ replies, xml ) Need Help??
jdporter has raised the following topic:

Update: The below has been done. You may disregard. :-)


If you take a look at the code of each of the sections, you'll see a fairly common pattern. SoPW is the canonical case; it looks like this:

[{get_sitedoclet}] [{votehead}] [{newlistapproved:perlquestion,perlquestion approved linktype,User Que +stions,10,navbaron,showunapproved}] [{votefoot}] [{newmoderatelist:perlquestion,perlquestion approved linktype,Unapprov +ed Questions}] [{addnewform:perlquestion,Add your question,Your question:}]

Examining newlistapproved and newmoderatelist, we find that the latter is logically a part of the former, but it seems to have been split out merely in order to "jump over" a call to votefoot.

I propose merging the code of newmoderatelist back into newlistapproved, and add an option parameter which would tell newlistapproved whether to call votefoot at the appropriate point. There is already an option parameter, showunapproved, which controls whether to show the unapproved list.

In order to grasp all the ramifications across the site, I prepared the following table, which summarizes the code of each place newlistapproved is currently used (excluding test nodes and such).

Table is presented in a reply below.

Based on this data, I believe this change would be safe and straightforward to make. The only real oddball we'd have to worry about is Editor Requests, but I think we could handle that.

I think this change will make the code simpler, but perhaps more importantly, more efficient. The overhead cost of calling an htmlcode is substantial. It includes the cost of (a) retrieving the node from the database, and (b) executing a perl eval.

I reckon we are the only monastery ever to have a dungeon stuffed with 16000 zombies.

Comment on refactor newlistapproved to absorb newmoderatelist
Select or Download Code
Re: refactor newlistapproved to absorb newmoderatelist
by Corion (Pope) on Jul 13, 2012 at 16:48 UTC

    I admit that I'm a bit unclear on where the two go together, except in the sequence they are called in. Maybe unifying the caller (by introducing one more level of indirection) would be cleaner? It wouldn't reduce the htmlcode() invocations, that's sure.

    I already find newlistapproved quite unwieldly, so I'm not sure that pushing some more code into it improves it, maintenance-wise...

      well, newmoderatelist is never used except after calling newlistapproved with the showunapproved option. keeping them together reduces the likelihood of bugs. ANd I think it reduces surprise. Understanding that newmoderatelist was a "continuation" of newlistapproved was something of a revelation for me.

      I could see the advantage of doing it that way if it was to "jump over" some large and/or variable chunk of code, but it doesn't. It always only jumps over votefoot. And now that votefoot is gone from there, there is absolutely no reason for the continuation code to be in a separate htmlcode node.

      Merging the code, as in the patches I just submitted, actually reduces code complexity a bit. For one thing, there's no need to shove the "passed" data into %HTMLVARS anymore.

Re: refactor newlistapproved to absorb newmoderatelist
by jdporter (Canon) on Jul 15, 2012 at 00:22 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (6)
As of 2014-12-21 00:27 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (100 votes), past polls