There have been rumblings along this line from others as well. What has been discussed is to modify it to do section links ala Super Search. Ive been thinking about this for a while and i lean actually towards a "Node Links Nodelet" and not putting it in either Node Status or Approval. Id like to see a single nodelet that shows the node_id, the type, section, and plain text of the link and author (for easier cut and pastiing for linking and messaging) in one place. That way we can remove it from the other nodelets and then its available regardless of users group membership or level or what have you.

At bare minimum if we are going to see this information duplicated in multiple nodelets I'd like to see it refactored out into an htmlcode node so that we can reuse it and not have slight variations of the same code in each nodelet.

It had sounded like there was overwhelming agreement that the Approval Nodelet should have a superset of the info in Node Status. If so, yes, the node status stuff should be refactored.

But why not have the id and type there? It sounds like what you want is an expanded Node Status without the approved by/fp'd by. That would be taking a different approach; then I'd expect the Approval Nodelet to have nothing but the approval/frontpage/consideration stuff.

All the talk ive heard is to put identical data in multiple nodeletss. My preference is to remove said data from both nodelets and put it in its own place. I dont think a slim nodelet with this data is a bad idea. Especially if it reduces the complexity of other nodes. Consider that corion posted the base link text patch only to one of the nodelets, wheras it would be useful for both. But there isnt much call for non developers/gods from having both enabled at the same time. Thus we have at minimum a serious target for refactoring.

As for type, i believe this could be easily triggered by such things as membership in SDC or PMDev (both which have good reason to know the type of a node). But to be honest i dont think its a bad thing to expose the common user to this information. After all we are a learning site, and learning about PM represents some form of education. Even if in the worse case its a lesson in how not to do things. (Something I obviously dont believe, but im taking the worst case perspective here.)



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

Just to follow up while im suffering insomnia, if you look at the code for Super Search the text block at the top (in the q()) has 4 columns. the 2nd through 4th columns represnt nodetype, section abbreviation, and section name. (The section name is optional and is only needed if the abbreviation!=section name). We should turn this info into a Setting and expand it to cover all nodetypes. (Its a pity nodetypes don't have a way to store this...) Then this can be used for whatever it is we end up doing.

As for id and type, i want the Id for the same reasons Bart outlines. I want the type because for a pmdever such information is very useful. I want the id and author in a raw form because for various things such information is useful in a n "un-urled" form. Eg, making a nodepin you need the id, currently its a bit of a pain to do.

And yes ultimately i think much of the redundant info would be better off in a single nodelet. Even if folks want it the other way I still want that nodelet. So I think the best thing is to make a htmlcode node that is used to provide this info. It should adjust itself appropriately based on parameters so it can be tailored for reuse in other nodelets if thats what people want, but it should also handle various logic like group memembership and $VARS determining what people see. Essentially the nodelet i want would have all the special links at the top of the pmdev nodelet, and the stuff at the top of each node, along with assorted related bits from the other nodelets. Presumaby this nodelet would just a be a special case of the htmlcode node i have in mind.

Pesky time keeps disappearing though so I havent got a prototype put together though.



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

1. Safe reloading, bookmarking, and being able to safely get an actual URL for the node, irrespective of what you've been doing, be it voting, a consideration, or talk in the CB
2. Having a handy way to copy the node id to link to in nodes and in the CB.

I do not think the link actually should have to be that "loud". It might blend in more with the other links you mentioned: "print, w/replies, xml". Perhaps "plain"? As in:

plain, print, w/ replies, xml

For the record, I neither need nor use the ID or nodetype in the node headers, Id also prefer barts suggestion, and add a 'displaycode' or something to it. (which I would like at least for scratchpads, where the link looks kinda out of place, but I couldnt think of a better way to do it).

Although, I have occasionally needed to know the nodetype, and scrolled to the bottom to find it. I'd still prefer both ID and nodetype in the editors nodelet, which is where I use them.

I can see the argument that it would be nicer code-wise to have the stuff in one place, but I just dont think its practical usage-wise. Editors need them near editing tools/links, pmdevs near pmdev stuff etc. pp. Having them in Node Status is nice, but thats not on every page, whereas editor/pmdev nodelets are..

Just to recap on the Node Status Nodelet. Its point was (and still is, IIRC), to show users < level 5 the information that the approval nodelet had, such as if their node had been considered/approved and so on. Removing this nodelet should not be an option.

Adding another nodelet just adds to the clutter, IMO. I already have so many that I cant have them all within sensible reachable range or proximity of each other (even with CB and other users turned off now)

Hmm, someone should implement the 'rollup' nodelet feature properly. (For those not in the know, its possible to make the nodelet content 'disappear' and just show its title, saving space when not in use.. Except this 'feature' has no usable GUI..)

C.

options++

As i said the way that we all get pretty much what we want is to put all of this stuff in a single htmlcode that handles the various cases and then call through from the various nodelets as necessary.

Regading another nodelet, I find it much more annoying trying to find the information I want that relates to such matters scattered through the various nodelets I have. As such I would put the Node Links Nodelet at the top and then the other nodelets would be purely for their individual function and not also for displaying various attributes.

But I have a feeling that if a nodelet like I mention was available a lot of folks would prefer it over the approach we currently have. And for those folks that didnt, well a User Setting or two and the appropriate Nodelet Setting would put that to rest pretty quick. :-)



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

Do you remember my '"Nodelet Nodelet" nodelet requests' post? Please re-read last sentence/question, and imagine this coupled with castaway proposal...

(I knew I could help PM to improve... ;-)

____
HTH, Dominique
My two favorites:
If the only tool you have is a hammer, you will see every problem as a nail. --Abraham Maslow
Bien faire, et le faire savoir...

Er, I wasn't aware that you can copy/and paste from the titlebar...



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi