Hmm, some way of 'recycling' node_ids would be useful, but that sounds like a huge project.

Anyway, Any thoughts, objections, notes on this?

C.

In case you don't have a clue what I'm on about, tye started some changes to the Approval system a while back, which mostly involve internal changes, namely getting rid of using the link table to 'link' nodes to sections and/or the frontpage. (tye, feel free to add anything/correct me). I've picked this up and have been adjusting/adding to/improving it (hopefully) to a point where we can start using it in production.

I'm inviting anyone with a login on the test server to have a look, and test out the functionality. In theory, the overall result should work as before, on the surface. What needs testing:

• Moderation Nodelet - replaces the Approval Nodelet, also the 'removelinks' part of the editors nodelet
• Node Status - nodelet, check that it reflects the correct status
• The Monastery Gates - should show nodes frontpages by the moderation nodelet
• Seekers of Perl Wisdom - and other sections, show approved nodes (or all if showunapproved is on), approve nodes if level > 5

• moderation nodelet - make work, mostly
• node status - nodelet, use isapprove
• newapprove - make work, adapt
• isapprove - ..
• approvalhistory - table that holds the history of all approval actions
• approvalstatus - table that holds the current/last status of each approved/fp'd node (no entry means unapproved)
• newcachedlistapproved - complete rewrite of cachedlistapproved, to use new tables etc
• Monastery Gates/Section pages - use newcachedlistapproved
• moderatelist default outer container - use newapprove opcode
• cachedinfo table - made key unique
• listapproved settings - added daysOnFrontPage, updateInterval

I'd appreciate if people would point out any other areas that are using the 'listapproved'/'approval' type code, that I've otherwise missed. (I've already noted that several section-similar pages, such as Editor Requests, SQL Query list, need another htmlcode, which doesnt use approval (since their entries arent/cant be approved.)

Many thanks to tye for starting this in the first place.

C.

PS: Note that this is by no means the end of the changes coming, once this has proven itself, I'll get on to the showing of history, and similar for considerations..

I'd like to create a FullPage Chat Lite and want some feed back. It's an easy thing as I can quickly duplicate and modify existing node code. The difference between Lite and the normal one is that we don't need the other monks or the private messages.

The look I'm imagining for it can be seen on my scratchpad (Some browsers are too smart to override the servers text/plain so you'll just see the source). The top frame should just contain the ad and the bottom should just have the talk bar.

It seems though that I need a few new nodes and I'm not sure how to go about getting them created:

• I need a superdoc that will just load basichead .. that gives the ad at the top of the page.
• I need a superdoc that will just load talkbar .. that gives the text input area at the bottom of the page
• And finally I need a fullpage to put the frameset HTML in.

The Everything Bible says that I need to be a God, then I go to the non existant node. The search results come up and I can click on something to create a node. Does PM have anything for non-gods? Or do I need to convince a god of the need for such a page? (Hey, it's less work for the database as there's no need to reload the ad, users or PM frames!)

Hi guys. I think it would be nice to have a patch for colorblend and User Settings so that the user can specify the start/end colors themselves and override the theme specifc ones I configured. Shouldnt be a big deal to do, but I've got my hands full with other features and would really appreciate it if someone felt like helping out with this.

1. copy the ?etVars code into patch display/edit pages, adjusted to use code instead of vars
2. make settings patches a new nodetype that uses the setting table instead of (or in addition to) htmlcode.
3. Change Everything.pm something like: (Updated to factor out packVars/unpackVars:)(Updated to de-indent:)

--- Everything.pm.orig    2004-09-13 15:29:13.318740800 -0700
+++ Everything.pm    2004-09-14 09:23:15.763673600 -0700
@@ -258,16 +258,13 @@
 
 
 #####################################################################
+########
-sub getVars
+sub unpackVars
 {
-    my ($NODE) = @_;
-    getRef $NODE;
-
-    return if ($NODE == -1);
+    my ($vars) = @_;
 
-    return {} unless $NODE->{vars};
+    return {} unless $vars;
 
-    my %vars = map { split /=/ } split (/&/, $$NODE{vars});
+    my %vars = map { split /=/ } split (/&/, $vars);
     foreach (keys %vars) {
         unescape $vars{$_};
         if ($vars{$_} eq ' ') { $vars{$_} = ""; }
@@ -277,46 +274,69 @@
 }
 
 #####################################################################
+########
+sub getVars
+{
+    my ($NODE, $field) = @_;
+    getRef $NODE;
+
+    return if ($NODE == -1);
+
+    $field ||= "vars";
+
+    return unpackVars( $NODE->{$field} );
+}
+
+#####################################################################
+########
+sub packVars
+{
+    my ($varsref) = @_;
+
+    # Clean out the keys that have do not have a value.
+    foreach (sort keys %$varsref) {
+        $$varsref{$_} = " " unless $$varsref{$_};
+    }
+
+    return join("&", map( $_."=".escape($$varsref{$_}), keys %$varsre
+f) );
+}
+
+#####################################################################
+########
 #   Sub
 #       setVars
 #
 #   Purpose
-#       This takes a hash of variables and assigns it to the 'vars' o
+f the
-#       given node.  If the new vars are different, we will update th
+e
-#       node.
+#       This takes a hash of variables and assigns it to a field of t
+he
+#       given node.  If the field is changed, we will update the node
+.
 #
 #   Parameters
-#       $NODE - a node id or hash of a node that joins on the
+#       $NODE - a node id or hash of a node, usually one that joins o
+n the
 #       "settings" table which has a "vars" field to assign the vars 
+to.
 #       $varsref - the hashref to get the vars from
+#       $field - the field in which to put the vars; defaults to "var
+s"
 #
 #   Returns
 #       Nothing
 #
 sub setVars
 {
-    my ($NODE, $varsref) = @_;
-    my $str;
+    my ($NODE, $varsref, $field) = @_;
+    $field ||= "vars";
 
     getRef($NODE);
 
-    unless (exists $$NODE{vars}) {
-        warn ("setVars:\t'vars' field does not exist for node ".getId
+($NODE)."
-        perhaps it doesn't join on the settings table?\n");
-    }
-
-    # Clean out the keys that have do not have a value.
-    foreach (keys %$varsref) {
-        $$varsref{$_} = " " unless $$varsref{$_};
+    unless (exists $$NODE{$field}) {
+        warn ("setVars:\t'$field' field does not exist for node "
+            . getId($NODE) . "\n");
+        warn ("\t\tperhaps it doesn't join on the settings table?\n")
+            if $field eq "vars";
     }
 
-    $str = join("&", map( $_."=".escape($$varsref{$_}), keys %$varsre
+f) );
+    my $str = packVars( $varsref );
 
-    return unless ($str ne $$NODE{vars}); #we don't need to update...
+    return unless ($str ne $$NODE{$field}); #we don't need to update.
+..
 
     # The new vars are different from what this user node contains, f
+orce
     # an update on the user info.
-    $$NODE{vars} = $str;
+    $$NODE{$field} = $str;
     my $superuser = -1;
     $DB->updateNode($NODE, $superuser);
 }
[download]

Once that's resolved, the rest is pretty easy; it will work differently from other patches in a couple of ways. First, there will be just a "Create Patch" button on the setting display page, not a form (since I don't see an easy way to feed op=new an editvars form). Second, it will just display the new settings, not a diff, at least until I figure out diff_strings enough to hack it to the purpose.

IMO, with the arrival of this new section (Scriptorium), some management must be done to the Monastery title bar and/or the front page to help Monks comenting there.

Thanks to demerphq, all has been (well) done for the cabalists to get here through their dedicated nodelet. But, as stated by the specific policy of the section, every monks should be able to comments. This will certainly be difficult with the lack of more "generalistic" entry points.

This is perhaps also the time for the man with a q to exhaust his Titlebar Settings bunch of patches, to handle this gracefully, no ?

Subsidiary question: should a writeup here be taken into account as the ones in other sections or not (as it seems for now) ?