A technical look on building a democracy

Here comes the Plugins

Up until now, the getMainPage function, which was part of the topicProcess made internal invocation to get the user data and the tags and put it all together to create the page’s data before it was return to the WebApplication to be rendered into XSLT and then HTML. I decided that TopicProcess shouldn’t know nor care about the tags and user info, and I can actually put into use the plugins mechanism which didn’t do anything yet.

How is a plugin work? well, after identifying the call, the WebApplication prepares a list of all relevant plugins, which are methods, much like the handlers we had until now and runs all the plugins in a recursive manner:

a plugin get the input,

may alter it,

if there’s another plugin in queue, runs the next one

if not, it runs the handler (i.e. main application), which returns a JSON object as output

the plugin may alter the output and return the call to its caller

so we end up back in the WebApplication after all plugins and the handler went over the input and the output

TagProcess now knows that whenever the url “/” is called, it should run the pGetTags plugin (the prefix “p” is for plugin, as the function is slightly different the getTags handler). It was extremely easy and it works like a charm.

The next step, which I will do sometime in the future is more challenging: currently, the XSLT knows nothing about the plugins and their additions to the page. If future plugins should be available for anyone to add – the XSLT shouldn’t know about the plugins either. At most, it should know it should run a plugin-XSLT that will create an HTML snippet with an attribute stating where the snippet should be placed (e.g. “inside-sidebar”). But who will do the actual placing? can I trust the server-side code to do it effectively? nothing like a good challenge to call it a night 😉