[Pmwiki-users] Editing long pages

[Patrick R. Michaud]

On Thu, Oct 28, 2004 at 06:02:04PM +1300, John Rankin wrote:
> >Along with that, be careful with the ?p=n component--you have to be
> >sure to handle the case where someone else has added or removed ____'s
> >from the page while you're editing one of the chunks.  :-)
> >
> Well I had vaguely thought, insofar as I had thought at all, that
> it would go like this:
> - get a page and break it into pre-chunk, chunk, post-chunk
> - author edits chunk and presses post
> - assemble pre-chunk, new chunk, post-chunk
> - [...]
> 
> Do I perhaps hear an 'It's Not That Simple, You Are About To 
> Fall Into Grimpen Mire, Turn Back Before It's Too Late'?

I'm just cautioning about that third step -- you have to make sure
that the pre-chunk and post-chunk PmWiki uses to assemble the text
are the *same* pre-chunk and post-chunk that existed when the author
began editing it.  I.e., knowing "?p=n" by itself at step 3 isn't
sufficient, because another author may have modified the number of
chunks in the page during the time that the current author has been 
performing her edits.  Thus, PmWiki has to be able to know the page 
as it existed at the time that the edit page form was retrieved in 
order to correctly figure out the correct pre- and post-chunks.  
All of this is separate from the other issues of simultaneous edits, 
which the later code will indeed handle.

One "simple" solution to this *might* be to make 'pre-chunk' and 
'post-chunk' into hidden fields of the edit form, so that PmWiki
doesn't have to recompute them when the post occurs, but doing it
this way may be making a strong (and incorrect) assumption about 
browsers' ability to store hidden fields with very long string values.
I need to see what the W3C standards say about this (and if modern
browsers set any limits on this), because this would make it really
easy to implement an "edit section" capability.

Pm