TitleMove much more template business into wiki pages
Date25-Nov-2005 15:45:50 EET
JSPWiki version2.2.28
SubmitterGregorHagedorn
Idea CategoryGenericIdea
Reference
Idea StatusNewIdea

Enable the content editors rather than the programmers or admins to adjust the wiki to their needs!

Empower them, let them change things into their language!

Example: I have just been able in our template to simplify ConflictContent.jsp to:

<%@ include file="i_SettingsHandler.jsp" %>
<% <wiki:Translate><%=wiki_InsertRawPage("WikiEditingConflictMessage", 
    (String)pageContext.getAttribute("conflicttext",PageContext.REQUEST_SCOPE),
    (String)pageContext.getAttribute("usertext",PageContext.REQUEST_SCOPE), "")%></wiki:Translate>
<p><wiki:EditLink>Click here to edit <wiki:PageName/></wiki:EditLink>.</p>

wiki_InsertRawPage is a self-written insert raw page function, that supports replacing up to three parameters.

If we should get a NewLinkTagSpecification, the cludge with leaving the edit link in the template would be no longer necessary either! (BTW the interwiki edit trick is not good for template authors, since it can not be relied upon being present...).

See the corresponding WikiEditingConflictMessage containing the language and layout parts that currently in JSPWiki are still in the JSP pages!

Gregor Hagedorn -- Nov. 2005


Other functionality could go into special Layout Plugins. Parameters of those plugins could be used for translation. That's our current approach in our internal distribution. For example we removed the AttachmentList from the default template for public wikis and put that functionality into a plugin called AttachmentList. Now if one would like to have an AttachmentList included on one page, he puts this plugin on the bottom of the wiki text.

In the attachment plugins there could be parameters to translate text like this:

[{AttachmentList title='Anhänge'}]

I've attached the code for this plugin: AttachmentList.java(info).

Of course you would like to have certain things always on top and bottom of the page. There should be seperate areas for that. Like with leftMenu and leftMenuFooter, have a pageFooter and a pageHeader you can edit. You then could include a YourTrail Plugin , the PageTitle Plugin and the SearchboxPlugin, and for stuff that should always go to the pageFooter like AttachmentList you edit the pageFooter accordingly.

The only advantage of the current approach over this I see is that you always have a default layout on installation time for first time deployers. To keep that advantage with these Layout Plugins, there should be a mechanism to expand a default page setup for those areas in case the page directory is empty. The wiki pages for this default setup should go into the template directory so that template developers could determine the default content.

--ChristophSauer Nov. 2005


The idea with the plugins is an excellent perspective! The ConfigurableTemplate currently uses already a long list of wiki pages, including heading tools (for actions in the header, similar to the left side menu/favorites), wiki configuration (those property settings wiki managers should be able to modify), wiki-specific CSS, etc. However, it has way too much in the JSP pages, including language specific stuff, and many things just have to go through configuration switches because the current wiki syntax is too limited. The idea to put the rest into plugins is excellent.

I would vote to make attachment list a core plugin...

BTW: could plugins be based on JSP pages? There is so much wrong, e.g., with the index plugin, but you need to modify the deep JSPWiki code to make it work better. It would be much easier for java non-wizards like me if more could be done in JSP pages or wiki pages, rather than digging into engine code. It would be easier, if a template could modify the html generated by the attachment plugin by modifying the JSP page used by that plugin.

-- Gregor Hagedorn

A quick response to the last part: I doubt that will ever happen. JSPWiki plugins need to work even when there is no HTTP Request or JSP context available (like XML-RPC requests, or embedding), so JSP is out.

However, the idea of using Velocity as a "plugin template language" has been rolling around in my head for quite some time... I know that at least one company has deployed this on a large scale, though they claim that Velocity does not really scale.

If there is no templating language available for plugins, moving functionality into plugins would be only compounding the problem: then you would need to change the plugin code and recompile to change the output.

As to doing the entire layout in plugins... I don't think that will work. There is a reason why people moved away from servlets to templating languages - and moving back to the equivalent of servlets (i.e. plugins) would be shooting yourself in the foot.

To the original idea: yes, that is certainly possible. I would personally like to make the Edit.jsp a page based on WikiForms; the same goes for Search.jsp, etc, so that JSP would be limited to templating part only. However, there are quite a few obstacles still on that road, and it's not being a priority right now :-/

-- JanneJalkanen

Add new attachment

Only authorized users are allowed to upload new attachments.

List of attachments

Kind Attachment Name Size Version Date Modified Author Change note
java
AttachmentList.java 2.8 kB 1 29-Nov-2005 12:15 ChristophSauer
java
I3gWikiPlugin.java 3.6 kB 1 29-Nov-2005 12:14 ChristophSauer
« This page (revision-15) was last changed on 12-Oct-2006 11:14 by JanneJalkanen