[pmwiki-users] Nested Blocks (tables, divs, etc)

Ed W lists at wildgooses.com
Wed Feb 25 07:01:32 CST 2009


Patrick R. Michaud wrote:
>
>> I appreciate that you are being flippant, but your suggestion requires
>> "forking" a fairly major piece of core code which will obviously 
>> now have to be maintained from version to version and also it breaks 
>> any further recipes trying to do the same thing
>>     
>
> I think I'm being less flippant than you think.  To me it's not a 
> "fork" -- 

You are arguing against common terminology.  A "fork" is where someone
is maintaining a parallel branch of code independently to the upstream
maintainer

> PmWiki fully recognizes that people may want to customize 
> markups, and it's been designed with that in mind.

PmWiki implements what is typically called "monkey patching" in dynamic
programming language circles.  It's got a mixed following, but clearly
it's a very powerful feature when used carefully.  The main issues are
that the patched code "rots" and falls out of sync with upstream (I have
this very issue with some Rails patches where I have patched some core
functionality...)

As you might remember I have been using pmwiki for around 5 years, so I
obviously like the very "meta" approach that it implements.  However, as
I do mostly Ruby stuff these days my comments are that the core could
sometimes benefit from some of the functions being broken up a bit
smaller so that it's simpler to patch only a small piece of
functionality rather than forking a whole chunk of code...

Anyway, back to the current question - I had considered that this might
break some small amount of automatic closing of tags when I proposed the
change, however, as I am upgrading from a couple of years back
installation where it wasn't even possible to have nested div tags it
seemed completely moot given that I never even had that feature before...

If we must have named blocks then can we discuss making the names
meaningful:

- You mentioned nested tables - last time I had a look at the markup
this wasn't obviously yet implemented? Can we please have (:table1:) etc
syntax implemented?  Better yet (:table_inner:) which adds a
class="inner" to the table...?

- Why not lets make the nested syntax useful? Perhaps >>blah<< could
mean the same as (:div_blah:) and so the div class or ID is specified
automatically?


My preferred idea would still be:

- How about one class of div tags nests automatically and another
doesn't? eg (:div1:) doesn't nest and closes automatically when it meets
another (:div1:).  However, (:div:) implements automatic nesting? (or
(:div_pick_a_nest_level_for_me_automatically:) or whatever...). 

- This could be an option enabled at the site config level.  I *think*
it could be implemented simply by having the Cells function generate
numbered tags automatically (ie fairly non intrusive).  The tags used
would be in a slightly different format to the current numbers so that
they can't overlap.  I need a bit of help understanding how the
CloseMarkup function works before I can properly propose the code change?



Some other thoughts:

- It would be desirable to support <TH> in the (:table:) markup.  Can
this please be considered?  (The web is moving fast towards semantic
markups and CSS).  Right now it would appear that I have to "fork" the
whole Cells() function in order to add this once cell type - I can't
personally see how to simplify the function to avoid that though, hence
request it becoming part of core?

- Consider adding some counters to the nesting levels.  This could be
very interesting for table cells/rows.  With the addition of being able
to do "MOD()" arithmetic then you can do zebra stripes, etc using only
core functions and some maths to read the $Row/$Col variable).  This
seems to be a fairly low impact change?

Some of this stuff is in a cookbook recipe, but it seems like several of
the main bits could actually be added into core without being too
intrusive? (hence easier to maintain going forward)


I still think on any non trivial sized page it's no easier to use the
autoclosing tags than it is to manually close tags.  Just before I wrote
this email I messed up a test page which took some time to realise it's
because I didn't close a div tag...  Have you got some real examples of
how the autoclose is actually useful?  Seems to me that you still need
to manually close the outer div and you need to track the nested div
level in order to make use of the autoclose syntax so it's no easier
than just closing the thing manually on anything other than really small
paragraphs?

Thanks for listening...

Ed W






More information about the pmwiki-users mailing list