Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

2Re: Site HTML filtering, Phase II

by jeffa (Bishop)
on Feb 12, 2004 at 01:59 UTC ( #328446=note: print w/replies, xml ) Need Help??

in reply to Re: Site HTML filtering, Phase II
in thread Site HTML filtering, Phase II

I have been quiet on this matter, but i have to pipe in and say that replacing [ .. ] with [[ .. ]] is a SPLENDID idea and you hit the nail on the head why it is a better fit for this site. (typing [ is a royal PITA!)

There seems to be two major problems (barring having all pages be W3C compliant (X)HTML)

  1. newcomers not knowing how to format code sections
  2. folks using "unescaped" [ .. ] sequences, inadvertently producing potential Google hits to their array indices.
I think that getting newcomers to use code tags will always be a problem ... but switching [ .. ] to [[ .. ]] should completely alleviate the need for "inline" code tags, such as $this->[$example].

As for using POD ... newbies have a hard enough with programming, let alone Perl. Offer them POD and watch them run screaming ... maybe not a bad idea after all ...

My stock answer for posting with POD is pod2html | perl -pe 'custom filters here' | tidy which has served me quite well for several of my larger, premeditated posts.


(the triplet paradiddle with high-hat)

Replies are listed 'Best First'.
Re^3: Site HTML filtering, Phase II (backcompat)
by tye (Sage) on Feb 12, 2004 at 06:41 UTC

    Now all you have to do is convert a few hundred thousand nodes to this new standard... not a small number of which are nodes used to implement the site and that contain Perl code (sometimes in templates -- BTW, the templates use several flavors of square brackets for designating different types of code) and some of that code emits square brackets because it knows they'll be turned into links... well, and a few other tasks will also be required...

    Having written POD, I'm convinced that the problems with < and > would be worse with POD than the current problems with [ and ]. And I bet the problems with URLs would be worse as well (I've certainly heard several people get frustrated trying to make POD link to URLs). I find it mildly humorous that the problem of using C<...> to surround Perl code (which has lots of uses for < and >) was "improved" by adding support for C<< ... >>, since Perl code also has several uses for " <<" and " >>", and such uses rarely nest. But then I haven't had reason to study the new POD yet. And I'm not trying to bash POD. I like many things about POD.

    I also think PerlMonks should take a few good ideas from POD.

    And [[ ... ]] is a fine idea. We could even add support for it. But that won't do much good since it won't really help until we can remove support for [ ... ], and I doubt that is going to be in the ballpark of either quick or easy.

    I'll continue working on making this site work better. The handling of HTML(ish) and [ ... ] has improved quite a bit over the last few years and several more improvements are already begun. There are certainly still bugs and other room for improvement.

    [ ... ] parsing should probably be merged into the HTML filtering (since some people expect to not have to escape square brackets inside of links even though they have to escape them most other places at PerlMonks) and we already don't have to escape < and > most places, including inside of square brackets. There's a good chance I can do that without increasing the cost of the filtering considerably.

    I think new users should have "[possible link]" displayed as "[possible link]" so the problem of forgetting to encode your brackets is less severe. I think we should support &lsb; and &rsb;.

    I'd rather use [[...]], but I don't currently see a path to it that is worth persuing. This is probably where someone will suggest starting over. Feel free. It's a great idea and I'd love to see it happen. However, I have no interest in working on it myself.

    I'll be watching to see what schemes for solving the backward compatibility problem get posted, and the back of mind will be thinking about it as well.

    - tye        

      I came up with an idea that I might like for moving forward regarding this type of change. I'd add a field to the node table for 'format' and a corresponding user setting.

      All existing nodes would be tagged 'e2'. New users would start at 'pc' (which would be like simplified POD: preserve blank lines and treat paragraphs containing indented lines like code). When you compose a node, it'd default to your selected input format but you could select another.

      But trying to support too many input formats would probably be a mistake, so new formats should probably be added slowly and deliberately.

      Just the start of an idea...

      - tye        

        I also came close to proposing that idea, but held back on it, because that way, we lose the option to store a "clean" version in the database.

        While the "new way" would be much more flexible, it also requires re-rendering of the format into HTML on each load from the database. I don't know how much of the re-rendering is currently done, so maybe there is no additional hit, and maybe the caching is already aggressive enough to allow this.

      &ob; and &cb;, please.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://328446]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (None)
    As of 2021-10-20 02:03 GMT
    Find Nodes?
      Voting Booth?
      My first memorable Perl project was:

      Results (78 votes). Check out past polls.