(Note: the page name may be misleading: this is a list documenting some changes we made while developing Configurable Template. Some are bugs, some are cosmetic issues. They are documented here to contribute to the development of the default template after 2.2.28)


One task in developing the Configurable Template was to fix xhtml problems remaining in the default 2.2.28 template. The following list tried to keep a log of changes to that they may be applied to the default templates. The list is slightly incomplete because the intial expectation was to only fix the default template and then submit it as a fix. Over time, the changes got more and more complex, so that a comparison was no longer possible.

Please excuse submitting this like this instead of using the bug submission system, the list is just too long for my time.

Fixed 2.2.28 template issues#

  • html element must contain the namespace to make files xhtml compatible: <html xmlns="http://www.w3.org/1999/xhtml">
  • Several templates use : <p><hr /></p> which seems to be improper xhtml, at least tidy does not like it. Replaced with <hr />
  • "pre" must be in parallel to p, not embedded in p (as currently in FindContent.jsp.
  • Conversely, in ConflictContent.jsp the inline formatting element tt is used as a block level element, it is best exchanged for pre there.
  • In UploadTemplate.jsp a closing tr element seems to be missing. Also <meta name="robots" content="noindex"> is not closed.
  • Several minor problems fixed in commonheader.jsp, unfortunately before starting this log...
  • To all tables the "summary=" attribute has been added (for people with disabilities, required (or recommended?) for xhtml)
  • In xhtml "a name=" is deprecated and should be accompanied by "id=" (only place is <a name="Top" id="Top">)
  • An minor but undesirable effect of the wiki engine seems to be that it starts any li element with a blank before the text, e.g. "<li> <a class="wikipage" href="Wiki.jsp?page=About">About this Wiki</a>.</li>". Tidy removes these blanks as they are not expected to be displayed by browsers.
  • On InfoContent.jsp and UploadTemplate.jsp "img" elements are not closed. Change to <img src="<wiki:BaseURL/>images/xml.png" border="0" alt="[RSS]" /> and <img src="<wiki:BaseURL/>images/attachment_big.png" border="0" alt="Info on <%=att.getFileName()%>" />
  • On InfoContent.jsp: <script language="javascript"> is obsolete and should be supplemented to: <script language="javascript" type="text/javascript">
  • InfoContent.Jsp: Although the current version 2.2.28 only allows to delete entire pages (and not individual history revisions), the page-delete functionality is not available for newly create pages, only after a history is being displayed (starting with version 2). I believe the likelihood of immediately deciding that a page shall be deleted is actually higher than the likelihood of deleting and old page with many versions...
  • Error in CSS:
    h2 { border-bottom: 2px grey solid }
    h3 { border-bottom: 1px grey solid }
    should be:
    h2 { border-bottom: 2px solid grey }
    h3 { border-bottom: 1px solid grey }
  • The empty "<span class="error"></span>" might better not be displayed at all, i.e. they should be enclosed in an "If-Error" construct (which I believe is not avaible in the wiki tags).
  • Another related fix worth noting: The javascript for opening the attachment window worked only with javascript enabled. Change this to: <a href="<wiki:UploadLink format="url" />" target="_blank" onclick="window.open('<wiki:UploadLink format="url" />','Upload', 'width=640,height=480,toolbar=1,menubar=1,scrollbars=1,resizable=1,' ).focus();return false;" title="attach images or documents">Attach</a> The functionality remains the same, but it now also works with javascript disabled and also when user opens in new window (shift-clicks).
  • A usability issue: On the edit preview edit page, the semantics of the cancel button are unclear to users (cancel preview or cancel edit? - the latter is the case). Label changed to "Cancel all changes" to clarify.
  • Not a bug, rather a question of taste, but... We also removed use of wiki:Include in favor of the more transparent (at least we were confused what wiki:Include actually does...) standard jsp construct <%@ include file="i_LeftMenu.jsp" %>. In the java source code for the Include tag Janne noted ("// FIXME: Perhaps unnecessary?"). A least for the default template, the answer is: unnecessary.
    • Not so. <wiki:Include> is MANDATORY in the current template system. It fetches files from the "default" template, if they're not available in the current template.
  • I also found the phrasing of several messages in the template not ideal, but I am not a native speaker either. I tried to modify them in the Configurable Template. We welcome any remarks and improvements!
  • A particular message problem is contained in the upload form. It is not possible to cite the label of the "browse" button, because that label is supplied by the local browser, not by the page. As such, the label differs in many locales, leaving users confused that they do not see the button mentioned.

Other changes in Configurable Template:#

  • Removed hr markup where it was used for lines on top and bottom of page/edit content. The lines are now defined in css-styles, allowing more options for CSS designers. This makes the template much more flexible, requiring changes only to css to change the layout.
  • Consolidated LeftMenu parts, making it much easier to have the flexible layout proposed above. Previously left menu was constructed using different methods in the view and edit templates. Now from the other templates it is just a single call. The full functionality, including the use of the two wiki pages was preserved.
  • Some refactoring has taken place. For example, in 2.2.28 the header table (displaying page and SearchBox.jsp) is for viewing in the template (ViewTemplate.jsp), for editing/commenting in the content: EditContent.jsp and CommentContent.jsp. This has been changed so that the header is always in the template. This required only one wiki:Context check to achieve the same result and results in less code duplications.
  • Similarly, the new i_LeftMenu.jsp is a refactoring of LeftMenu.jsp, LeftMenuFooter.jsp together with duplicate code from ViewTemplate.jsp and EditTemplate.jsp.
  • Not a bug but confusing: cssinclude.js is included in the template files, but the actual file used is in scripts.
  • Perhaps even more confusing: the file is named ".js" but is a jsp page, not javascript. It mostly contains js, but due to the use of wiki tags, it needs to be included in a jsp page to work. Functionally this is the case, as I say it is just confusing.

-- Gregor Hagedorn, 2005-09-07


Please note that while all of these are good ideas, you should file separate bug reports on them. Otherwise they're likely to be forgotten on my next "what unfixed bugs I have -run"...

Or, please send me patches in the standard format :-)

-- JanneJalkanen

I have submitted all bugs and ideas against the wiki engine I came across, which already took much time. With regard to "standard format": Sorry, I cannot. Much of the language talked on this Wiki is "Chinese" to me, and that includes such phrases. I am not a system developer, I am a content developer. I try to contribute from my perspective, but I do not know the tools you often talk of on this wiki.

Well, but you do need to understand that I have limited time to work on this stuff. I have a day job, too, and I would like to spend some time with my friends and family. So, the less work I have to do on something, the more probable it is that it ends up in the system. I'm not saying I'm excluding things, but I'm asking to share the burden in this case. Could someone who's a bit more dev-savvy help Gregor here?

For example: We really need the Rename facility, but it seems you have to be a UNIX system developer to apply the method described how to implement it (using a "patch")...

Or any developer. Eclipse does patches wonderfully. "patch" runs fine on Windows, too. The rename patch is already in 2.3, BTW.

Trying to submit the Configurable Template is an attempt to solve the problem that we can not report on the default template, because we can not use it. In our multi-wiki setup there is no purpose and space for a left menu, the system already runs a left menu that is to integrate multiple wikis and other tools.

But there are things that would benefit JSPWiki. While the whole thing might not be useful, some parts of it would be. And I just don't have the time to take huge contributions and extract small things out of them that might be useful... It's sad, but it's true :-(

So either we make our own, and nobody cares, and JSPWiki does not profit, and we do not profit from other users reports or improvements. Or several people start to collaborate on ConfigurableTemplate (or of course, something similarly flexible that we can use it).

-- Gregor Hagedorn, 2005-09-07


I fully understand your problem, Janne. We are really grateful for all the effort that already went into JSPWiki! And many thanks for all the direct of wiki responses to questions!

My vision would be: rather than trying to port small bits from the new template into the current default template (which I believe can only be done in some places, because of the rather monolithic nature and the fixed set of assumptions driving the current template), keep the current template, perhaps even simplify it further to make it a bare-bone template, and add the configurable one as an alternative branch in the next distribution.

  • The new template is fully based on the default template of 2.2, so nothing is missing that was present there (even if we do not need it for our setup).
  • I believe the new template would be a much better basis for further contributed templates that only change the settings file and the css. Great style could be developed.
  • In fact I am thinking about adding a setting to make the table layout completely optional, so if desired, the template layout could be fully CSS driven even with left menu (as shown by some contributed templates). So this could be a common platform for those who want to have browser-safe operation and those relying on advanced CSS.

Can other template developers take a look at the new template and critisize it? That would be a good start. The new template is carefully designed and tested, but certainly problematic in places. As said, my main incentive is my feeling it would be the better collaboration platform. But without collaboration, if the template goes the way of other templates (i.e. down the drain over time because JSPWiki itself matures) I would not like to invest further time.

-- Gregor Hagedorn, 2005-09-09


Return to Configurable Template

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-16) was last changed on 09-Sep-2005 12:58 by GregorHagedorn