Here we brainstorm and discuss how interactive svg panels might work in wiki.
I feel that where this discussion is going is a bringing together of: * SVG Panels * Wiki Messaging * Transporters
It may therefore be sensible to borrow some lessons learned form MVC and other architectures while we consider how to structure this functionality. We should consider a wiki page as an active piece of code, that uses messaging to communicate with other pages, or the outside world.
# Some thoughts
So maybe panels work like this: * draw a panel in inkscape * superimpose this on a historic image (optional) * bind drawn elements to wiki page Titles * import this into wiki with a transporter
Here we are separating the interface from the code. The panel simply holds a reference to where it hopes the code will lie.
* the svg becomes a Panel plugin * the Panel javascript fetches pages on hover, click, scrub, drop, etc. * if the page includes hover, click, scurb or drop handler then let to its job * open the handler page on double click to learn more about the control
The concept of a Handler Page here is one that is the destination of a link from an interactive element in the SVG Panel. It is where the actual code to be run by the panel would live.
* page handlers can delegate complex modelling to more pages, even precompiled lineups * all this is 'self documenting' through coding that is mostly readable and extra paragraphs where needed.
# Why?
Why do we wish to separate the code that runs the when a user interacts with a panel from the panel widget itself?
One answer is flexibility - the same panel can now easily be used to run completely different code forked in as a new wiki page.
# See also