in reply to node info in title bar

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.


---
demerphq

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

Replies are listed 'Best First'.
Re^2: node info in title bar
by ysth (Canon) on Jun 29, 2004 at 00:17 UTC
    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.

[reply]

      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
[reply]

      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
[reply]

In Section Perl Monks Discussion