This doesn't seem like something a module should be needed for. -- I've thought a module would be more like "render the following block of text using LaTeX", or "turn the following list of data into a graph". i.e. things that would require something outside what could be accomplished with built-in application languages (WQL, etc)
This is an example of a feature that would require something outside of Wagn's built in application languages, unless I'm mistaken. Perhaps I didn't describe the story in enough detail? I meant to refer to a scenario where one may click a card link and be immediately shown the contents of that card, but in the *sidebar.*
--Marcus Estes.....Thu Oct 08 17:04:53 -0700 2009
I understand that you can't currently do this with built-in languages, but my argument is that you should be able to, and adding a module instead of enhancing the built in capabilites will lead us down the path of having lots of small modules that will make installing and managing a Wagn installation more difficult.
--James Thompson.....Fri Oct 09 11:11:42 -0700 2009
I'm going to respond elsewhere (with an effort to be fairly thorough) to James' architectural questions, which go to the center of questions like "what's core" and "what's a module". For the moment I want to dig into representing this kind of situation.
My first reaction is that we probably want some way of defining a link "target", which is to say, what changes when you click on a link. Normally, of course, it's the whole page, but it could also be a little spot in the sidebar somewhere. You might want to specify a precise place in the middle of a card where this should happen, for example. I'd be tempted to make this a special inclusion, like
The syntax for the link itself might be something like example annotation, which would look for the first target marker inside the card named *sidebar.
As we move to custom layouts (coming out in 1.2 very soon now), there won't really be anything special about the card named *sidebar, so I'd want to leave this functionality open to other layout representations.
Downside of this rep is that there's only one target per card. may or may not be an issue. Another similar approach might be to make it possible to replace the content of any card through ajax.
there are a number of other situations coming up where it would be nice to be able to influence one part of a page from another part, so we should look for commonalities to find a strong general solution. For example, some have wanted to be able to manipulate maps on a page by clicking links and/or checkboxes....
--Ethan McCutchen.....Tue Oct 13 10:02:35 -0700 2009