Archive of discussion topics on the Brushed Template. See also BrushedTemplateDiscussion for current discussion items.

Questions#


AJAX driven Find Page -- How to get more details by default?#

All AJAX features are really great and work fine! But how do I manage it to get the additional checkbox checked by defaut in order to get more details? --BFT 20-Feb-07
Have a look in FindContent.jsp; and make the 'details' checkbox CHECKED by default. -DF

WikiWizard Errors in IE 6...#

For the fix go to: WikiWizardBugReports and look under the entry: "WikiWizard generates JavaScript error on Windows MSIE" This will fix the following errors:

Preview

  • Line: 13
  • Char: 5
  • Error: 'document.editForm.preview' is null or not an object
  • Code: 0
  • URL: http://localhost:8080/JSPWiki/Edit.jsp?page=page&editor-WikiWizard

or


Minor Bugs#

  • Windows XP Pro, SP 2
  • Apache Tomcat 5.5
  • Running JSPWiki: 2.4.69
  • I deployed all versions of the template ending in: brushed-v2.4.x.zip
  • IE 6.0.2
  • The skin "Brushed" does not display correctly, but all the others appear to match the screen shot.
  • Do you have a zip file of the "standard" pages in the native ".txt" format that can be deployed easily? I was looking through your suggested pages to add after the brushed template and finally broke down and clicked on each individually, then hit edit, and copied them into an edit session on my local pages under the same name.
  • The table of contents appears to float into the far left on loadup for the "Smart" skin. On hover and collape/open it pops into the correct position.

--Kanemojo, 17-Oct-2006

Brushed is still not 100% ok, especially the page title is not rendering fine. Suggestions are welcome
I dont have a zip of the .txt files. CutNPaste should not be to much of a problem cause its only 4 or 5 pages.
I have not seend the issue with the TOC on IE. I need to dig into that one.
--DF


Wysiwig Editor#

I changed the editor to WYSIWIG editor (FCK) but when I click edit the edit window doesn't appear... so I cannot edit the page. tried in FF and IE. In IE the log error was "FCK editor" not defined. Do I need to install it as well? I thought it was included in the template... at least I didn't read that it wasn't in the brushtemplate webpage.

Indeed, missed out in the documentation. You need to install the FCK yourself or it wouldnt work. The installation directories are outside the template directorty, so it is hard to include it in the template. But, yeah, documentation probably is missing -DF

Hi All,

I'm a relative newbie to wiki world. I've been using JSPWiki with Brushed Templates for a few weeks now. Yesterday I discovered the WikiWizard editor, which is almost as cool as Brushed templates. Only I can't get them both working at the same time. WikiWizard works fine with the default templates, but not with the Brushed ones -- it just doesn't come up, and you always just get the plain editor no matter what you do. Has anyone else seen this?

Thanks very much,

Adam

--Adam Ehven, 19-Jul-2006

So far, I didnt do any tests with WikiWizards, so the answer is no. I noticed that a new jsp is added to the template by WikiWizard, so make sure this jsp is copied to the /templates/brushed/editor directory too. --DF
18 Aug 06: use latest download which is compatible with the excellent WikiWizard.
Make sure you also copy the JSP to the templates/brushed/editors directory to make it work.

Change default skin#

I would like to set ExtraVanilla skin for all users, especially because many are new and the menu changes from right to left in some skins.

You can do this in commonheader.jsp
  Change
  String prefSkinName       = "PlainVanilla";
to something else.
  String prefSkinName       = "ExtraVanilla";
--DF, 09 jun 2004
Version of 26jul06 fixed the handling of default preferences. Now it IS ok jst to change the commonheader.jsp to get different skins, date formats, etc. --DF 26 Jul 06

Exception#

I've setup the latest brushed template (Attachment version #3) on JSPWiki 2.1.86 and also 2.1.101 and receive an exception when it trys to render the first page... Any ideas?

I'm using tomcat 5.0.19, java 1.4.2_03. I'm sure this is something simple on my part...

--DF, 22 jun 2004
Reply: this is normal, due to some shortcoming in 2.1.86 release. Look at the bottom of BrushedTemplate to see the solution.

--anon.
<blushing/> Oh damn. I should of RTFM. Sorry. JohnV will never let me hear the end of this.


Support for sortable tables#

Hi Dirk,

Are you planning to add support for sortable tables in a future version - 2.2.y perhaps? ;-)
I found that tablesort.js as part of the the BrushedTemplate distribution but it doesn't seem to be enabled.

Thanks, NascifAbousalhNeto

PS: If you want to have up and down arrows that are not IE specific, you can add the following code to tablesort.js:

function initSortTable() {
  arrowUp = document.createElement("SPAN");
  if (ie5) {
    var tn = document.createTextNode("5");
    arrowUp.appendChild(tn);
  } else {
    arrowUp.innerHTML = '?';
  }
  arrowUp.className = "arrow";

  arrowDown = document.createElement("SPAN");
  if (ie5) {
    var tn = document.createTextNode("6");
    arrowDown.appendChild(tn);
  } else {
    arrowDown.innerHTML = '?';        
  }
  arrowDown.className = "arrow";
}
Aha, the tablesort.js script is some left-over of what I did with TablePlugin. I will include the javascript call in the next update, but it will only function when used together with the tableplugin which automatically generates links to the tablesort stuff if possible. While writing this, I realise this would be useful to make an on-page-load javascript, scanning for tables and injecting the needed tablesort stuff. (or change the wiki-engine of course) New ideas come as we go ;-).
BTW, the proposed code is very useful - although the decision should not happen on (ie5) but on something else like (windows) and (firefox) cause the webdings perfectly do there job in ie. Anyway, I think we better fall back to something portable across all browser types, like the suggested ? and ?. --DF

Would it be possible to indicate which tables should be sortable using a CSS marker instead of a plugin, like you did with text attributes (for super, striked, ...) and collapsable for lists? --NascifAbousalhNeto

It could be done both ways: all tables of a page become sortable or only the ones encapsulated in a %% marker. I would prefer the first solution. --DF

Collapsebox default to closed?#

Hi Dirk,

Is there a way I can create a collapsebox that defaults to closed the first time the user views the wikipage?

Thanks, Ryan Sawatzky

Good suggestion! Unfortunately the answer today is no.
We still need to come up with a good approach. A possibility could be to use a single ! for an open box and a double !! for a closed box -- although I dont like that approach cause you need to change the weight of your headers for this. Another idea is to prefix the header title with a # to indicate a closed box (similar to collapsable lists which uses ordered lists when default closed ). Or we define another JSPWikiStyle, say %%closedcollalapsebox to do the trick. Any preference ? --DF


Hi Dirk,

Thanks for the quick reply. I'm not going to guess at which one would be easiest or best from an implementation pov, but from a user pov, I would prefer using the # character. Just for consistency if for no other reason.

Thanks, Ryan Sawatzky

Version of 26 Jul 06 has a %%collapsebox-closed JSPWikiStyle which does what is mentioned here. See BrushedTemplateCollapseBox--DF 26 Jul 06

Hi Dirk, The table of contents links on the BrushedTemplate page (in this wiki) don't work.
The page layout is getting confusing, after all it has a number of years already... maybe it is time for a clean-up?
Best regards,
--Nascif, 11-Jan-2007
Nascif, the table of contents does work imho, however most links point to hidden sections (in side page-tabs) and so nothing happens when clicking them. If you were running the BrushedTemplate on such a page, you would see it automatically un-hides the related page sections you are clicking to. --DF
I do agree that some clean up of the Discussion page is needed. Most of the stuff is not relevant anymore today, and it's hard to find the things you need.


Install#

Brushed Templates - How to install and edit?#

Q:I just downloaded the JSPWiki (v.2.3.72) 23-Jan-06 - but it did not contain Brushed template directory Where can I download the newest version of Brushed templates and why is it not included? Thanx.els

A: Brushed template is available as .zip in BrushedTemplate. This should be sufficient when you have jspwiki already running. Some of the brushed functionality is included in the default template. Always take the latest version- look at timestamp! This should be sufficient when you have jspwiki already running. As it stands today, the standard JSPWiki has incorporated some stuff of the BrushedTemplate which is considered to be of general interest and stable. Consider templates to be used at own risk -- just contributions of other jspwiki users.

The Brushed Templates zip file does not include a README with installation hints - you find enough input on the BrushedTemplate pages, which are update regularly.

It is installed as follows DF:

  • copy the directory to your templates/brushed directory AND change your jspwiki.properties to point to the correct templates directory; this is what you need to do for any template;
  • changing the default skin can be done through a change in the template/brushed/commonheader.jsp -- somewhere in the beginning of the file the default prefs are initialised;
  • changing background/foreground colors of a skin should not be to hard to do. Look up the skin.css file under the directory /templates/brushed/skin/orderedlist . Change in this CSS the background:xxx; to whatever color you want; the text color will change back to black if you change the color:xxx; to EG color:black;. Of course, first choose the correct block that you want to change.
    • for the leftmenu , lookup the #favorites block and change its style
    • for the body, lookup the body.view block and change its style
When done, why dont you share you new skin with the rest of us ;-))
  • maybe you will may have to clear the cookies of your browser;
  • it looks best with Firefox;
  • if an error with PREF occurs, it is caused by a incompatible change of a tag attribute: plse change 'registerUser' to 'editProfile'; You must change this in all template files. EG: <wiki:Permission permission="editProfile"> . - Is fixed since v2.3.72-25thjan06.
  • You will get more pretty tables with relative width, that do not write over the frames with this little trick (It may not work across all browsers- it does with firefox). Around your table put following wiki markup:
    %%(overflow:auto;) <your table> %%
  • The quicklink "Page Info" fails (brushed templates from 25th jan06 and skin "Ordered List") with Could not find plugin brushed.jspwiki.plugin.ReferredPagesPlugin - this will be fixed soon. You can do 2 things: (1)install the mentioned plugin which will make the ExternalLinks and AttachmentLinks tab in the InfoTab work -- or -- (2) remove these tabs from the InfoTab.jsp.

I am planning an update to v2.3.72 once the version is stable -- any day now? --, but there are no real new things in. Just to keep in line with latest changes which are not always compatible with current template.
Plse feedback on what you like/dont like so we can still make it better ;-)
--DF

Still unclear - more questions reg. Brushed Templates#

  • Which file needs to be edited, so that I supress the "prefs" and "comment" quicklink button and the "This page was last changed..." in the header? (Im am using brushed templates from 6th jan06 andskin "Ordered List"). els
Have a look in PageActionsTop.jsp and PageActionsBottom -- then edit the /skins/<your-skin>/skin.css file to hide the blocks you dont like {display:none;} --DF
no, this did not work- there seem to be some problems with PageActions.obsolete.jsp
I found out, that the "PageActions.jsp" was missing - (it always took the PageActions.jsp automatically from the JSPWiki/template/default dir). So, I finally copied PageActions.jsp from the JSPWiki/template/default directory in templates/BrushedTemplate and edited it - now, I finally managed to change the favorite/quicklinks in the header... :-) els
This is strange - can't find any reference to the PageActions.jsp in the latest brused template. Are you sure you are using the latest download ? --DF
I am using download brushed-v.2.3.72-25jan06.zip and JSPWiki 2.3.72-alpha; and I tested again: it definitively requires a PageActions.jsp . And it takes it from the JSPWiki/template/default dir; so, I moved JSPWiki/template/default in JSPWiki/template/default.old reloaded and got: 'No template file called PageActions.jsp' and no quicklinks (no Edit page, Add comment, ....) were shown; well, I have found a workaround as described above by copying the default PageActions.jsp locally and editing - shall we further investigate into this problem? els
Do you get this problem when viewing a page, or editing, or elsewhere ? So you can check which JSP is still calling the
PageActions.jsp. --DF It happens, when Viewing - actionsTop and actionsbottom seem to require PageAction(I copied the following from "view generated source": <div id="actionsTop">No template file called 'PageActions.jsp') --els

Pls check out your ViewTemplate.jsp. Mine contains following lines:

<div id="wikibody" >
  <wiki:Include page="Header.jsp" />
  <wiki:Include page="PageActionsTop.jsp"/>
  <div id="page"><wiki:Content/></div> 
  <wiki:Include page="Favorites.jsp"/> 
  <wiki:Include page="PageActionsBottom.jsp"/>
  ...
Then check your PageActionsTop.jsp. Mine contains some line saying (different from what you are mentioning ...)
<div id="wikibody" >
  <wiki:Include page="Header.jsp" />
  <wiki:Include page="PageActionsTop.jsp"/>
  <div id="page"><wiki:Content/></div> 
  <wiki:Include page="Favorites.jsp"/> 
  <wiki:Include page="PageActionsBottom.jsp"/>
  ...

Yep, my files contain exactly those lines...- well, no surprise - I am usingyour template- and btw I think it is wonderfull work! I am deeply impressed!
All I am saying is that I was not able to remove the "add comment" and the "my preferences" button from the quicklinks menu (when viewing), until I added the following file PageActions-els.jsp. That does not mean anything, as I am not a JSP/CSS pro. Feel free to have a look at the mentioned file. Maybe youcan give me also a hint, how to position the quicklinks such that they are aligned on the right with the view-frame. Thanks for help! --els

Consider following additions to the jspwiki.css:
<div id="actionsTop" class="pageactions"> 
   ....
</div>
Good luck. --DF Thanx again - talk to you soon els

Hi Dirk, I don't want to forget, to post how I finally solved my strange behaviour problem described above. The problem cause was a "timestamp": When I loaded a new brushed template version I did not clear the generated Java code in the Tomcat dir. The newly copied files were older then the generated Java and hence Tomcat did not use the newly uploded files- instead, Tomcat kept using old classes from PageAction.jsp.... YEP, I learned this lesson.

YOU WERE RIGHT. All I had to do was

  • edit /skins/<your-skin>/skin.css (BUT: at the very beginning of the file!!!)
  • edit /templates/brushed/PageActionsTop.jsp (and PageActionsBottom.jsp)
  • AND CLEAR THE OLD JAVA CODE UNDER THE TOMCAT DIR (rm -r ..../jakarta-tomcat/work/Catalina/localhost/<myWiki>/org/apache/jsp/templates/brushed/*) :-)
  • since then, we are using Bruhshed template daily in our intranetWiki and are very happy. Thanks again.
---els

Odd Behavior on the editing screen #

Hi Dirk, First thanks for the template it really brings out the usability of JSPWiki. I am noticing an odd behavior when editing pages (standard editor). I am running JSPWiki 2.3.72-alpha and the 25Jan06 version of the Template. My primary browser is Firefox 1.5.01. I have no idea yet which of these is the source of my problem

Sometimes when I am working in the editor, usually when I am going back and forth from preview to edit several times, the save, preview, and cancel buttons stop working for me. Clicking on them them does nothing and when I use the tab key to try and get to the button so that I can manually press it (space bar) the tab steps right over it as if it is not a valid option. Clicking the replace button, or moving between tabs on the top of the editing screen works fine, but I cannot save, preview, or cancel. Usually I copy the text for the page into a clipboard and leave the editor using back on my browser. Then I go back to "edit this page" and paste the clipboard at which time save works fine.

Any thought?

csh -- 15Feb06 --

This behaviour is normal. In order to prevent double-save clicks, I added some stuff to deactivate all buttons after the first button click. Of course this implies you can not use the back button anymore to go to edit and do a new save. Instead, you should always use the buttons in the PREVIEW page to go back to editing mode.
You can still use the browser BACK as long as you didnt press SAVE, PREVIEW or CANCEL.--DF

v2.2 Install issue#

Hi, I've installed the 2.2 version of BrushedTemplate on my 2.2.33 JspWiki, and I'm getting the following whenever I try to view a page:
  /* +++ 470 PageActions.jsp +++ */
  .actionComment      { []; }
  .actionPrefs             {  display: none; }
What did I do wrong?\ Thanks,\ Stephen Cooper 2006-03-26
I've not seen this error before. Are you sure the jspwiki.properties are correctly pointing to the brushed templates directory ? I seems to be a basic servlet JSP error - not something related to a template jsp error. --DF


Opening External Links By Default In A New Window#

Hi Dirk, I am having trouble opening a new window for urls. I am using JSPWiki2.3 and brushed (e.g.OrderedList) brushed-v.2.3.72-25jan06 and the code from OpeningExternelLinksByDefaultInANewWindow

I added the following to JSPWiki.properties

2006-03-24 14:09:20 ApplicationDispatcher[/portalwiki] Servlet.service() for servlet jsp threw exception
java.lang.NullPointerException
        at org.apache.jasper.runtime.JspRuntimeLibrary.getContextRelativePath(JspRuntimeLibrary.java:908)

On my test Wiki page I am trying to open two new links in two new windows:

#  For the NewHttp reference
jspwiki.interWikiRef.NewHttp=http://%s" TARGET="_blank
jspwiki.interWikiRef.New = Wiki.jsp?page=%s" target="_blank 

But the google link cannot be clicked, and the second link creates a new page called [NewHttp:www.google.com] \\ [New:News]
Obviously, the quotes are not processed correctly - as you see on the HTML page source.

http://localhost:8080/testWiki/Wiki.jsp?page=News%22%20target=%22_blank 
Is there a workaround?b Thanks.

--Eva Lippert-Stephan, 04-Apr-2006

I don't see an easy workaround. Apparently, JSPWiki v2.3.x is escaping all special characters in the interWikiRef property string, such that the suggested hack doesnt work anymore. Eventually you can report this as a bug and ask JanneJalkanen to fall back to the v2.2.x approach.
--DF

Yah, it was disabled due to a possible XSS attack. I haven't yet figured out a satisfactory way to deal with this yet.

-- JanneJalkanen


Editing Wiki Sample Page Fails #

We are happily running JSPWiki2.3.72-alpha with tomcat 5.5.51 and brushed-v2.3.72. But the Wiki_Sample_Pages (e.g., RecentChanges, WikiVariables, EditPageHelp) can not be edited. Viewing is fine, when trying to edit, I get the following error.
<p><a class="interwiki" href="http://www.google.com&quot; TARGET=&quot;_blank">NewHttp:www.google.com</a><img class="outlink" src="images/out.png" alt="" /><br />
<a class="interwiki" href="Wiki.jsp?page=News&quot; target=&quot;_blank">New:News</a>
I deleted the "$/work/Catalina/*" and restarted tomcat, but still fails. Any Idea would be appreciated.

--Eva, 11-Apr-2006

I've seen a problem in the past in case you edit the first version of a page. Allthough that problem doesnt render a JSP exception. So far, this jsp code is working properly at my side. --DF

I finally have found a workaround for this problem: I first add an empty comment to EditPageHelp ("add Comment link" with Comment.jsp works fine) and after that I can run "Edit page" (Edit.jsp?page=EditPageHelp) without error ... strange isn't it? --Eva, 24-Apr-2006


I love this template and think its great that you have kept it up to date. Just having one small problem (and im sure its user error). I've downloaded the latest zip and extracted and everything. However when I try to go to the login page or the prefs page im getting errors. The login page gets a "Tag failed, check logs: null" error. The Prefs page error is a Null pointer exception thrown from the UserManager.getUserProfile method. Im assuming that is because im not logged in. Any thoughts. I really would like to use this template and the 2.4 JSPWiki

Thanks

--Chris Rohr, 07-Jun-2006

Chris, I've not seen these issues before. What version of JSPWiki are you running? --DF

Version 2.4.6 but I think it may be because I don't have the security setup correctly. It seems that it is logging in automatically as Guest user and I don't have that user defined anywhere. Like I said earlier, probably user error. I will try to get security working correctly and see if that fixes it. Thank you --Chris

Maybe while the AAA code is still evolving it would be better if the template is coded to expect occasional failures. I would add null checks on every security-related API call... - NascifAbousalhNeto

Got it working... Seems that my jspwiki.properties file had the jspwiki.security set to container and I didn't have any container security stuff set up so it couldn't get the user information etc. I just took that line out and everything started working. Thank you for your help --Chris

Hi All I have been using jspwiki for few weeks now. I just downloaded 2.4.* and Brushed template to go with it. I have trouble running WikiWizard plugin when i use brushed template? Anybody on same boat? Thanks
I have not yet looked at WikiWizard plugin so far. Plse share your experiences if you ge tit working. --DF 26 Jul 06
Fixed in v2.4.x. 18 Aug 06.

Don't really know if this is wiki code or template code, however I noticed a weird bug yesterday. Attachments were added to one page through a plugin. As I navigated through other pages, the attachments were duplicated on those other pages. Thinking that it was just a reference I checked the storage directory and it actually copied the attachments to each page. (Using wiki 2.4.6 and the latest template) Just wondering if any one had come across this or if you think it may be the plugin that is doing it.

--Chris Rohr, 09-Jun-2006

Found the problem... just an FYI for anyone who may do this. Adding a plugin that generates attachments to the help page will create the attachments on any page when you edit it. Don't really think that this is a bug, because I guess it is technically doing what it should be, it was just something hard to find.
--Chris


Sorry one more weird thing I noticed. When I click on the Info tab to see the history, it seems that each version is loaded and parsed. The reason I have noticed this is in version 1 I had a plugin that creates an attachment. By version 5 I had removed the code for the plugin. When I try to delete the attachments, they go away until the next time I view the history and then they come back. In the InfoTab.jsp I found this snippet of code:

JSPWiki has detected an error
Error Message 
Tag failed, check logs: Could not find plugin brushed.jspwiki.plugin.ReferredPagesPlugin
Exception 
javax.servlet.jsp.JspException 
Place where detected 
com.ecyrd.jspwiki.tags.IncludeTag.doEndTag(), line 90 

This column in the history never displays anything (always blank), but I think that is causing the page to be loaded. Am I correct?

Thanks --Chris

--Chris Rohr, 10-Jun-2006

Chris, this is very true. I am using the variable versionLabel to put comments on certain versions of a page. The only way to view them in the version history is with the trick indicated in the code snippet. You can easily remove it from the JSP. Probably I need to add some documentation to highlight this special behaviour. Tx for pointing out the side-effect of the trick ! We definitely need better built-in support in JSPWiki for metadata -- these tricks always bite you ;-) --DF


What do you think about implementing a "assist" bar kind of like the small piece template did with javascript controls to input some basic wiki syntax for the wiki-novices? The only reason I suggest is because I currently have some individuals who have never even heard of a wiki before.

--Chris Rohr, 13-Jun-2006

Sounds like an interesting idea. However, is this toolbar compatible across browser? As far as I know, these text-area related functions are not always well supported on all browsers. If you have some JSP/JS code snippet, I am willing to take it in. --DF
See BrushedTemplateToolbar for a fancy javascript driven toolbar. --DF 26 Jul 06

Graphbar#

I created an entry for IdeaTableDecorators that could be implemented as an extension to BrushedTemplate. I will try my hand at some of them as well - but I won't mind not being the first to implement them :-)
--Nascif Abousalh-Neto, 14-Jun-2006

:-) Have a look at BrushedTemplateGraphBars and download version of 26 Jul 06. It looks great on Firefox and Safari ! --DF 26 Jul 06

Hi Dirk, you are the man!!! Thanks for looking into my suggestions. The new graph bars are not working on Firefox 1.5.0.4 on Windows XP, JSPWiki 2.4.24. The page editor has some problem as well - it always starts empty. When I switch the rendering engine to IE (using the IE Tab extension) things work nicely though. The new features are awesome! --Nascif Abousalh-Neto, 27-Jul-2006

Tx, Nascif. Could you provide some more info on why Firefox is not working -- the firefox javascript logs are very extensive. --DF

Hmm, I don't know why, but I can give more detail on what is not working. I am using the ExtraVanilla skin, and just upgraded to Firefox 1.5.0.5 (BTW, there is a big difference in the skin rendering under IE - the "left menu" is on the right in Firefox, and on the left in IE).

Testcase Firefox IE (using IE Tab, inside Firefox)
Default behavior (no decoration on the %%graphBars markup) works fine works fine
"Date and Time" example shows only the first numbers (days) - so the graph bars are actually showing 27, 1, 15 and 1 Dates are converted and bar lengths are displayed correctly (in orange over a black background)
"Bar Length" Tab no bars at all works as expected
"Bar Colors" Tab no bars at all works as expected
"Vertical Bars " Tab no bars at all works as expected
"Progress Bars" Tab no bars at all works as expected
"Gauge Bars" Tab no bars at all works as expected

My guess is that the new parsing of arguments is not working properly in Firefox.

Tx for the info! Concerning the Date problem, I has some difficulty too in Firefox with the parsing of the Date. Apparently Firefox doesn't accept as many time-formats as you would expect - so try playing around with other date formats. (I am using a / or a - as delimiter; year should consist of 4 digits, and so on) The same problem occurs when sorting a table with date information. May-be I should consider a custom-build date parser iso the out-of-the-box js Date.parse() function.
If the ExtraVanilla skin is not showing its left-menu on the right; something is seriouly wrong. Can you check the Javascript logs of the browser ? (Tools - Javascript Console) --DF

Here is the Firefox log (for the graphBar problem). When I switch to the IE engine I don't get any logs, sorry. And I don't know how to get Javascript logs from IE.

Favorites.jsp:49:37: This attribute is not recognized.
  <wiki:Calendar pageformat="<%="'"+pagename+"_blogentry_'ddMMyy'_1'"%>"
                                    ^------^
Favorites.jsp:49:47: This attribute is not recognized.
  <wiki:Calendar pageformat="<%="'"+pagename+"_blogentry_'ddMMyy'_1'"%>"
                                              ^---------^
Favorites.jsp:49:59: This attribute is not recognized.
  <wiki:Calendar pageformat="<%="'"+pagename+"_blogentry_'ddMMyy'_1'"%>"
                                                          ^----^
Favorites.jsp:49:66: This attribute is not recognized.
  <wiki:Calendar pageformat="<%="'"+pagename+"_blogentry_'ddMMyy'_1'"%>"
                                                              ^^
These are css errors from the skins/ExtraVanilla/skin.css. Nothing to worry about. Apparently you dont have any functional js errors. Do you have these problems to with PlainVanillan skin or Smart skin ? So only problems on Firefox; IE runs correctly ? (strange -- most of the time it's just the opposited - hehe )

Do you have any idea on how to handle two different sets of graphBar configurations (say a deadline tracker using dates and a progress bar) on different columns of the same table?

For the time being this is not possible: one gbar at the time ;-) Possilbly we could extend the gbar tags with a number or so, say gBar1 and gBar2. But I think this will get very complicated.

How about extending the graphBar marku instead, perhaps creating one specific for tables? You could add column names to the enclosing markup, and then use something similar to Zebra Tables where you traverse the DOM structure assigning CSS styles to each row - but in this case, to each cell in one of the named columns.

Another big advantage of supporting that would be completely removing presentation aspects from inside the table. This would allow tables to be just pure "data" and keep presentation details in the current page. Which is useful for tables that are either produced by a plugin (like JSPlugin or TasksQuery) or inserted from an attachment or from another page.

Hi Nascif, what about following approach? The suggested markup is completely decoupled from the inner data structure. It would eg also be feasible to have a table with 2 vertical graphBars styles in 2 different rows. The suffix to graphBar and gBar could be a number or some readable name. (such as graphBarsPlanning, graphBarsDefects etc.)
Error: Error in parsing value for property 'color'.  Declaration dropped.
Source File: http://d15695.na.sas.com:8080/MyWiki/templates/brushed/skins/ExtraVanilla/skin.css
Line: 41
Error: Error in parsing value for property 'height'.  Declaration dropped.
Source File: http://d15695.na.sas.com:8080/MyWiki/templates/brushed/skins/ExtraVanilla/skin.css
Line: 41
--DF

Hi Dirk (we should be using a weblog for tracking those threads?),
This is nice, and surely a step in the right direction. I see two minor problems though - and please forgive my focus on tables, but I use them a lot in my wiki-based activities. But anyway:

  • 1. It is very redundant - every row in a column has to have the same markup;
  • 2. It doesn't allow the same data to be used with different presentation in different pages/contexts (and the same data could be re-used if you use InsertPage or InsertAttachment to retrieve it, or TasksQuery to generate it).
  • 3. It forces the application (plugin) generating the data to be aware of a presentation concern. I am working on an extension of TasksQuery that would support that, but every plugin that generates data (OK, table data) would have to do the same.

I have been working on ways to "chain" plugins so this last one is particularly critical - it would allow one plugin to generate data without having to worry about how it would be used. Consider the following pattern, which I already use a lot:

%%graphBars1-<some-parms>
%%graphBars2-<some-other-parms>

  here comes your data
  %%gBar1 someValule %%
  %%gBar2 someValule %%
  ...
  %%gBar1 someValule %%
  %%gBar2 someValule %%

%%
%%

This works really well; but I wouldn't be able to, say, use the new date-based graph bar to display the date without changing the plugin to wrap every column cell with the same gBar markup.

Here is an idea: what if we took a page from data binding libraries that use "configuration by naming convention"? For example, let's say we do this:

%%sortable
%%filter-table
[{TasksQuery select='Name,Title,Date' from='Defects' where='status = open'}]
%%
%%

So it would follow your idea of using names to denote specific graphBar configurations (I really like that BTW, much more scalable) but would trigger a special behavior when processing tables; column names would be matched against the named graph bar contexts and matches would indicate that every cell on that column should be decorated using the given style.

--Nascif Abousalh-Neto, 30-Jul-2006

Good point. It is indeed a cramp to stuff all those %%gBar on every cell of the table. Unfortunately, your approach would only work for table-columns;; not for table-rows. Moreover, there is a problem in your example : the graphBarsAge is supposed to be working on date-values in the table and on decimal values outside. As a simplification I would suggest that we either process data inside gBar elements or data inside the table; not both. (see updated example below) BTW, seems like graphBar is growing so hard that it would be better of as a plugin ? --DF
%%graphBarsProgress-<some-parms>
%%graphBarsAge-<some-other-parms>
||Title || Owner || Priority || Progress || Age
| blah blah | John Doe | A | 0.80 | 23-Jul-2006
| bleh bleh | JaneDoe  | B | 0.90 | 26-Jun-2006

Average Progress: %%gBarAge 0.85 %%
%%
%%

The mix of dates and decimals in my example was a mistake, it was not done on purpose. The use case could be made to work with table rows if you assume the convention that the content of the first cell in each row acts as the row "title" for the purposes of matching:

%%graphBarsProgress-<some-parms>
%%graphBarsAge-<some-other-parms>
||Title || Owner || Priority || Progress || Age
| blah blah | John Doe | A | 0.80 | 23-Jul-2006
| bleh bleh | JaneDoe  | B | 0.90 | 26-Jun-2006
%%
%%
%%graphBarsAge-<some-other-parms>
Average Progress: %%gBarAge 0.85 %%
%%

As for it being better as a plugin, I don't know; markup/Javascript seems to have the upper hand when acting directly on the DOM, which is what you want with this particular feature. You probably would have to use the wiki engine to convert the body to HTML (to handle embedded plugins), parse the result in a DOM, manipulate it, then emit it again, right? I don't know how much easier/harder it would be in Java. On the other hand, you would be less browser-vulnerable when dealing with data transformation (like dates), would have more control over parametrization, and so on. Pros and cons either way - as always :-) --Nascif Abousalh-Neto

Check out v2.4.13-3aug06 and BrushedTemplateGraphBars : the js is now smart enough to select the rigth table column or row. --DF

The new Graph Bar support for tables is just awesome. I tested and it is working fine for both rows and columns. Thanks for another useful feature! --Nascif Abousalh-Neto, 8-Aug-2006


More food for thought: IdeaTableSummaryMarkup
--Nascif Abousalh-Neto, 18-Jul-2006


Calendar #

Just upgraded to JSPWiki version 2.4.15 beta with the 2.4.13-28jun06 versions of the Brushed Templates - and the last column of my Calendar is getting truncated. My setting is for Monday - Sunday and the brushed template showing the Calendar does not show Sun (Sunday). I can see the html but that column does not appear and no horizontal scrollbar appears. The calendar does appear correctly in some of the other templates like ExtraVanilla.

--Mike Miller, 25-Jul-2006

Tweaked the skin.css of the brushed skin to make the Calendar look better. Used download of 26 Jul 06. --DF 26 Jul 06

I18N#

Hi, I would like to provide an easy-to-upgrade German translation of the template, I think I'd do this by adding a “language” setting to the Preferences menu (update: bummer, that already exists, but without any function, as it seems ;-) ). I will try to move all language-specific output into one JSP file that creates a simple Hashtable. I thought of a new languages/ directory which contains the language files.

I think it might be useful to integrate this in future versions that you will publish here, I will upload my version of the template here. I don't know if you are already working on support for multiple languages, if so, it would be nice if you contacted me via e-mail. (I won't wait for your response because it's holidays and I've got plenty of time... ;-) )

--Candid Dauth, 27-Aug-2006

Candid, I recommend that you check the JANNE_BRANCH from JSPWiki CVS; it's got a localized version of the default template. It should give you some ideas on how we're planning to do things in future.

-- JanneJalkanen, 28-Aug-2006

Brushed will implement I18N aligned with the default JSPWiki template. As you can see from the javascript file, already some i18n hooks are foreseen. This is additional to the JSP internationalisation. --DF, 28-Aug-2006

Hm, so a general internationalisation management is already being implemented. I think I'll rather try to write a more current version of BrushedTemplateInGerman. --Candid Dauth, 28-Aug-2006


Deleting of attachments works fine in default template but throws a http 404 error in brushed#

Hi,

I'm using the brushed template version of the 15th of Oct 2006

It keep's on doing the following when trying to delete an attachment

HTTP Status 404 - /mywiki/undefined

type Status report

message /mywiki/undefined

description The requested resource (/mywiki/undefined) is not available.
Apache Tomcat/5.5.20

This work fine with the default template....

Before I delve any further, does anyone have any ideas?

Thanks

-- GregP

Part 2 of delete attachments mystery

Okay, this works on I.E 6(XP SP2), but not on Firefox 1.5.0.7... that's very strange. Also upgraded JSPWiki from 2.4.64 to 2.4.72 to no avail...

Please help... ;)

-- GregP

Hi Greg, apparently Firefox chokes on a wrong html attribute (url) of the delete button. Safari or IE do not complain. Here is a fix in AttachmentTab.jsp. I'll include the fix in the next upload. --DF 24 Oct 06

Current code in AttachmentTab.jsp , line 140-144:

          <input type="button" 
                value="Delete"
                  url="<wiki:Link format='url' context='<%=WikiContext.DELETE%>' />"
              onclick="AttachTable.remove(this.url);" />
should be changed to
          <input type="button" 
                value="Delete"
                  src="<wiki:Link format='url' context='<%=WikiContext.DELETE%>' />"
              onclick="AttachTable.remove(this.src);" />
Thanks Dirk it works on all 3 now (IE, Firefox & Opera)... I thought I was going nuts ;) Even posted to the mail list because I though it might be related to the Auth I had setup...

One more thing: In IE the toc lies over the leftmenu then when you minimise and maximise the window it corrects itself. I have also noticed something similiar with tables.

Thanks for your fast response; I really apprecaite it. Thanks also to all the hard work you put into this template ...it's gr8

-- GregP

Greg, need to check this out on IE. I haven't noticed it myself yet. Does this occur with a specific skin, or is this a general issues ? --DF

Creating New Group doesn't work in IE 6#

I am using JspWiki 2.4.71 and Brushed 2.4.x. When I enter new group name and click on "Save New Group" Nothing Happens. It is working on FireFox. Any Help is appreciated.

Thx Vamsi


Hello, I am using this template with the lates stable version of JSPWiki(2.4.82) and I am getting some problems with managing the groups. I don't see anywhere a way to edit/delete groups or even view the members of each group except the manual old way via EditGroup.jsp. Is this part of the template unfinnished? All the time when I click on some wiki group page I get page to create a wiki group not to list/edit/remove the group members. Regards vlatko --02-12-2006

Make sure you are properly logged in. Then go Prefs, and select the Group tab. You should now be able to create/view/edit/delete groups. --DF

I have allready tried that, so Dirk please be my guest and try working with groups on the jspwiki here --vlatko 03-12-2006
Apparently, you are not working with the latest version of the brushed template. Plse first upgrade, so you have support to the v2.4.xx group editing features. --DF

Apparently I was thinking that I was working with the latest version of the brushed template. :) Sorry for waisting your time on stupid things and big thanks for the help. Regards vlatko

Users reporting Edit tab sporadically missing#

Barry Beveridge: 11 Dec 06

We are running JSPWiki V2.4.56 and Brushed Templates v2.4.13-3aug06. Other users can see the Edit tab. The pages don't have any write/read protection set. We are suing a mix of non-login and login profiles.

Barry, plse checkout the PageActionsTop.jsp. It contains a <wiki:Permission> tag which makes sure that the EDIT tab is not visible when no permission. It the tab is still visible, it probably means your users have edit permission. Thus, no template problem. Plse checkout the JSPWiki's security implementation for more info. --DF
; Dirk, This was not a brushed templates problem, see Bug Page Permissions Changing Randomly instead. --Barry

Closed Bugs#

Editor "locked" in brushed-v2.4.13-28jun06 version#

There seems to be a problem with the last update (that introduces the metadata editor). When opening a page in edit mode, the edit text area was empty. Also, new content entered by the user is not saved.

I had to roll back to the previous Brushed version, which works fine. Using JSPWiki 2.4.18, Tomcat 5.5.17, Windows XP, Firefox. --Nascif Abousalh-Neto, 7-Jul-2006

Should now be ok with latest version. --DF

Reading pages with large RCS history is very slow#

More of a performance bug: We have a JSPWiki with 2 years of history, some pages have dozens of revisions in RCS. It seems that Brushed template is very very slow on such pages, due to the fact that it loads the full RCS info even when only looking at the page (so that you can switch to the info tab without waiting). While this is very convenient, it is not so convenient that reading any page, even if you need the info tab only rarely, takes a long time because of it. Would it be possible to make the info tab optinal, and add a usual "page info" link instead? --Peter Mutsaers, 12.07.2006
Strange. The latest versions of BrushedTemplate only show in the info tab information about the last 10 versions. This shouldn't be much of a performance hit, even if your page has long history sections.
Anyway, it shouldn't be difficult to change PageInfoTab.jsp so that it only shows the page-history information when the context is equal to INFO. --DF
Besides the performance hit of recreating versioned content, rendering the old pages will also trigger the execution of embedded plugins (check recent messages on the mailing list). Is it really necessary to render the HTML of the previous versions? If so, isn't there a way to reset the environment when doing that so that Form Handler plugins won't be activated? -- NascifAbousalhNeto
Need to dig into that further. Janne, is there a way to retrieve, let's sy, only the text version of an older page without doing the full plugin expansion ? --DF 21 Jul 06
Added 'Hiden Feature section to BrushedTemplate. The last update (dd. 26 jul) has the feature commented out, so you should not see the performance hit. --DF 26 Jul 06

Using Full Name (with spaces) to locate Favorites#

In my installation, the code in Favorites.jsp appears to be looking in username to build the Favorites path and if a user enters a Full Name with spaces, then the path to Favorites includes an invalid space as well.
  // MIKEW String myFav = username + "Favorites";
  String myFav= wikiContext.getEngine().getUserManager().
    getUserProfile(wikiContext.getWikiSession()).getWikiName()+"Favorites";
The above seems to work, but I expect there is a better way to get the wikiname. --MikeW

A few fixes for upload and edit problems#

The following 3 files are missing the > at the end of the </select></select></select></select></wiki:PageType> on line 21 of InfoContent.jsp

Still think this is awesome :-). BTW, we already use the word "section" for things separated with horizontal lines. Maybe we should use some other name for them? Paragraphs?

-- JanneJalkanen

Paragraphs are perhaps still something else. I propose to use the term fragment instead. --DF
Fragment's cool by me. On the other hand, it would make sense to call anything separated by a header a "section" and anything separated by horizontal lines "fragments"... Maybe it would make sense to do just a simple rename? Not a lot would break, I assume. -- Janne

Hi,

Just a quick note to say I fixed a bug in the section handling code. If the sub-section textarea did not end with a newline, you would get the next section appended to the visible textarea on blur/unfocus. Hope it helps! -- KieronWilkinson

function sectionTextAreaChanged( )
{
  var section = new SectionHelper();
  
  // START NEW CODE BLOCK
  // Check text area ends with a newline
  var str = section.textArea.value;
  if (str.lastIndexOf("\n") + 1 != str.length) {
     section.textArea.value += "\n";
  }
  // END NEW CODE BLOCK

  var s = section.mainTextArea.value;
  s = s.substring( 0, section.start) + section.textArea.value + s.substring( section.end ) ; 
  section.mainTextArea.value = s;
  updateSectionSelector( );  
  section = null;
}
Tx for the suggestion! Indeed the current approach is somewhat inconvenient; it is better to insert the \n. I will take it along in the next upload. --DF

Help Request...#

I am using the most recent version of the BrushedTemplate (downloaded on Nov 10th, 2005) with JSPWiki 2.2.33. On the PageInfo page, there is a "Rename" button that links to Rename.jsp. However, this page doesn't exist. The only information I can find about renaming pages in JSPWiki is this page.

So, is there any way to get the "Rename.jsp" page and the Rename functionality other than by downloading the "patch" file, modifying the Wiki source code and compiling it? If possible, I would like to not have to compile the source code. Thanks. --MFred

;Why not move to v2.3.x. ? It's pretty stable and rename is included. --DF

tewr 21-Nov-2005
The 19-Nov-2005 version gives me the following error:
/templates/brushed/PageActions.jsp(149): Non-matching extension tags //[ null; Line: 149]
probably occurred due to an error in /templates/brushed/PageActions.jsp line 149:
Indeed, line 149 should be removed. The line contains </wiki:DiffLink> . --DF
tewr 21-Nov-2005
The 19-Nov-2005 version also has layout problems in IE on JSPWiki 2.2.33.
The default skin's layout is screwy, as is brushed skin, "Extra Vanilla" seems OK.
Also the preferences bug seems to have returned, if I change the prefs they do not take.
Mmm, I ran it on a 2.2.8 and seems all ok. You may have to cleanup your cookies before you start. --DF
tewr 21-Nov-2005
Preferences: After manually removing all my cached files and cookies the preferences now save fine.
Skins: Are you sure the skins work under 2.2.33? They are still hosed for me in IE.
Thanks for your help.
I need to check out IE again, but I dont have it available right now ;-) Could you plse try it out on a Firefox ? --DF
Here is a fix for IE lovers: in the file skins/PlainVanilla/skin.css you need to add left:2.5%; inside the definition of the #favorites block. This is also applicable to the Brushed skin since it uses the same basic look with leftmenu at the left. Thus, in your skin css, it should now read :
#favorites  { position:absolute; left: 2.5%; width: 18%; top: 64px; /* make place for the logo */ } 
There is still a problem with the way IE renders the logo: only the left half of it is visible ;-). Some further css hacking is needed to find a solution also acceptable for IE. It works fine on FireFox. --DF

Test report for Windows XP, with the latest BrushedTemplate and JSPWiki JSPWiki v2.2.33 on Tomcat 5.5.11.
I found the same skin layout problem in IE. "Qute" seems to be the only one working in this browser. It works fine for Firefox though.

Different problem: sorting tables. Completely broken in IE (the rows disappear) and semi-broken in Firefox (works the first click then freezes; you have to reload the page to sort again).

-- NascifAbousalhNeto

Good feedback. Will investigate. Seems also to fail under Firefox in os-x. --DF
Bugfix is avail in BrushedTemplateSortableTables and latest download of BrushedTemplate--DF
Bugfix for sorting tables was verified and confirmed to work on Firefox and IE. Thanks! -- NascifAbousalhNeto

Hi Dirk,

I flagged my implementation of idea Search Edit and GoTo buttons to Janne, and he said to contact you. I don't have your email-- hope you're watching here. It replaces the single "Find" button in the upper-right corner with 3 buttons (search, edit and goto) that are great if you're a power-user of jspwiki.

Janne hoped that you would have the time to look at it. It is a simple change: it just replaces the bit of HTML/JSP which drives the SearchBox. It is all Javascript-- no change to the java code at all.

I am loving having this on the two wikis that I run, and hope to see it on JSPWiki.org someday!

-- DanHoward. Nov 27, 2005

Hi Dan, it is a great suggestion indeed! The new JSPWiki template (as well as the BrushedTemplate) have a dropdown box coupled with the search-input-field. It would be nice to include the suggested GOTO, EDIT, SEARCH buttons in it. And it's already js driven. --DF
Hi Dirk, A slight refinement: The "Search" button would be better as a "Find" button. It's (1) shorter, (2) more elegant (4 letters, like the other two buttons), and (3) a less-disruptive change (same word as users are used to seeing on the search button). I'll concoct one and attach it to the idea page. --DH


GP Nov 28, 2005

I have been using the MediaWiki Template for a while, but would like to start a personal wiki with the Brushed template ('cause it's so much cooler)....

Downloaded the latest for 2.2.x (I'm running 2.2.33) and I'm experiencing the following funnies:

  • Whenever a page loads a msgbox pops up with null as the text?
  • If using the brushed skin everything on the browser seems mashed up
I'm running the following
  • IE version 6.0.2900.2180....
  • Tomcat version 5.5.12
  • SUN JDK 1.5.05
Any ideas?

--Greg--

Seems I left some test code in the upload - sorry. And made a small fix to the brushed skin.css. Plse try the new upload of today. --DF

GP still seems to be doing it...

GP Version 7 is ok (no null), but the brushed skin still mashes together


RAF Has anyone seen this problem:

Error Message /templates/brushed/PageActions.jsp(40,4) No tag "UserProfile" defined in tag library imported with prefix "wiki" Exception javax.servlet.jsp.JspException Place where detected com.ecyrd.jspwiki.tags.IncludeTag.doEndTag(), line 74

Are you running the template on the latest v2.3.45 or later? v2.3.x of BrushedTemplate does not run on v2.2.xx of JSPWiki. --DF

RAF Sorry, my fault - another case of RTFM. Having said that, I have it up and running under 2.2.33 and it looks great!


As long as I use this cool template (for 3 month now) saving Userpreferences does not work for me. Looking at the HTML Source after saving:
<script src="templates/brushed/scripts/brushed.js" 
        type="text/javascript"></script>
<script src="templates/brushed/skins/ExtraVanilla?d/MM?Europe/Berlin?24?yes?no/skin.js" 
        type="text/javascript"></script>
</head>
That reports Firefox about the cookie:
Name	JSPWikiUserPrefs
Value	ExtraVanilla%C2%A4d%2FMM%C2%A4Europe%2FBerlin%C2%A424%C2%A4yes%C2%A4no
Browser: Safari, Camino, Firefox
Server: Jetty and JSPWiki 2.2.33 / 2.3.48

Any hints how to fix this?

--Alexander

Plse clear your cookies once. It should then all be ok. --DF

Unfortunately no - and I tried this before. But now I changed Wiki.DELIM in ./scripts/brushed.js and ./commonheader.jsp from "\u00A4" to "|", reseted the browser and it's all okay !!!

--Alexander

Jetty has a problem with the cookie Tokenizer in commongheader.jsp. I refactored that part in version 26 Jul 06 and made it more robust. However, I was not yet able to retest on Jetty. I hope this is now fixed. --DF 26 Jul 06

Editors do not work in brushed template for JSPWiki 2.3 (Servlet Exception). To fix this, you may change
<%@ page import="com.ecyrd.jspwiki.editor.EditorManager" %>
into
<%@ page import="com.ecyrd.jspwiki.ui.EditorManager" %>

in ./editor/*.jsp and PreviewContent.jsp.

--Alexander

Tx for reporting this. There is a mistake in the version I uploaded yesterday ! Plse download the version of (today) 4 Dec 05. --DF


Bug report: multiple table-filter instances on the same page do not work. Only the first one will have the filter widget. I had the same problem with sortable as well but it has been fixed in the latest JSPWiki from CVS. I wonder if the technique can be applied to table-filter?
--Nascif Abousalh-Neto, 28-Jul-2006

This is a bug. I fixed the one on sortable in sync with JSPWiki from CVS. The same cut-n-paste err is in the table-filter. Fixed in v2.4.13-3aug06. --DF

Brushed Template causing exception in ContentTag#

The page that created the problem had the weblog plugins

Error Message:
    Exception in JSP: /templates/brushed/editors/plain.jsp:129 126: 
    String thisAuthor = context.getWikiSession().getUserPrincipal().getName(); 
    127: %> 128: 129: <% if( lastAuthor.equals(thisAuthor) ) { /* should be 
    the same author */ %> 130: <% if( lastChangeTime > anHourAgo ) { /*changes 
    within one hour */ %> 131:          132: Overwrite version: Stacktrace:
Exception:
    javax.servlet.jsp.JspException
Place where detected:
    com.ecyrd.jspwiki.tags.IncludeTag.doEndTag(), line 84 

The exception trace:

!~IrpWiki PLog
Project Weblog (''PLog'' for short) for general discussion and annoucements related to the IRP project.\\
PLogs and how they can be used for project management are discussed at length [here|http://bipsvr19.pc.sas.com:8080/wiki/Wiki.jsp?page=WebLogsAndProjectLogsExplained].

----
Create a [{INSERT WeblogEntryPlugin WHERE entrytext='new entry'}], or check the [archives|PLog#Archives].

----
[{INSERT WeblogPlugin}]

----
! Archives
[{INSERT WeblogArchivePlugin}]

Latest JSPWiki and Brushed Template. --NascifAbousalhNeto, 01-Jun-2006


Similar problem, when trying to edit a page:

SEVERE: Servlet.service() for servlet jsp threw exception
javax.servlet.jsp.JspException
	at com.ecyrd.jspwiki.tags.ContentTag.doEndTag(ContentTag.java:156)
	at org.apache.jsp.templates.brushed.EditTemplate_jsp._jspx_meth_wiki_Content_0(EditTemplate_jsp.java:316)
	at org.apache.jsp.templates.brushed.EditTemplate_jsp._jspService(EditTemplate_jsp.java:127)
	at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
...
	at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:876)
	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
	at java.lang.Thread.run(Unknown Source)

I added some simple null checking and it worked:

JSPWiki has detected an error
Error Message 
Exception in JSP: /templates/brushed/editors/plain.jsp:147 
javax.servlet.jsp.JspException: Exception in JSP: /templates/brushed/editors/plain.jsp:147

144:        String thisAuthor = context.getWikiSession().getUserPrincipal().getName();                           
145:      %>
146:      <wiki:UserCheck status="authenticated">
147:        <% if( lastAuthor.equals(thisAuthor) ) { /* should be the same author */ %>
148:          <% if( lastChangeTime > anHourAgo ) { /*changes within one hour */ %>
149:            &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
150:            Overwrite version: <input type="checkbox" name="overwrite" checked="checked" />

Exception 
javax.servlet.jsp.JspException 
Place where detected 
com.ecyrd.jspwiki.tags.IncludeTag.doEndTag(), line 90 

--Nascif Abousalh-Neto, 01-Jun-2006

Tx for pointing out. Will be fixed in next upload --DF
Fixed in last v2.4 version - upload of 6 Jun 06

Small bug on InfoTab.jsp:

       String lastAuthor = context.getPage().getAuthor();
       String thisAuthor = null;
       if (context.getWikiSession().getUserPrincipal() != null) {
         thisAuthor = context.getWikiSession().getUserPrincipal().getName();
       }
     %>
     <wiki:UserCheck status="authenticated">
       <% if( lastAuthor != null && lastAuthor.equals(thisAuthor) ) { /* should be the same author */ %>
         <% if( lastChangeTime > anHourAgo ) { /*changes within one hour */ %>

Some context: this bug showed up after I added the "Admin" role to my userid using the jspwiki.policy file. After that, loading a page was triggering the IE script debugger due to the syntax error.

I noticed similar problems in the PageContent.jsp and PreferencesContent.jsp. Seems ok in TOMCAT, WebLogic hangs on this. Next upload --DF
Thanks. BTW I am using Tomcat 5.5.17 on Windows. --NascifAbousalhNeto
Fixed in last v2.4 version - upload of 6 Jun 06

After I fixed it, I can load the page and I can see the "delete" and "rename" forms - but when I click on the "More info" link I get

  <wiki:Permission permission="delete"> 
  <p>
    <form action="<wiki:Link format='url' context='<%=WikiContext.DELETE%>' />" 
            name="deleteForm"
          method="post" accept-charset="<wiki:ContentEncoding />" 
        onsubmit="return( confirm( 'Please confirm that you want to delete content permanently!' )
                       && WikiForm.submitOnce( this ) );">
      <input type="submit" value="Delete" name="delete-all" style="display:none;"/>
      <input type="button" value="Delete" name="proxy2"
          onclick="this.form.elements["delete-all"].click();" />  <<<< nested double quotes
    </form>
  </p>
  </wiki:Permission>

--Nascif Abousalh-Neto, 01-Jun-2006

I know. The jspwiki ReferredPagesPlugin removed the functionality for showing external links or attachment links. Plse comment that part out in the jsp. I will do the same in the next upload. Unless you like the functionality -- in that case install the original contriubted plugin. --DF
OK. Better to have something that works with no surprises out of the box and a note on the documentation explaining how to add the extra functionality. --NascifAbousalhNeto
Added a HIDDEN FEATURE section to BrushedTemplate. Hope you find it useful. --DF 26 Jul 06

Weblogic problem#

I get the error below from Favorites.jsp when runing the latest 2.4 version of the brushed template under JSPWiki 2.4.13 (and 2.4.6) under Weblogic 910, it appears as soon as I access the main page.

       <td>
        <%
          try 
          { 
            WikiContext cc = (WikiContext)wikiContext.clone();
            cc.setPage ( (WikiPage)currentPage) ;
            String pagedata = cc.getEngine().getPureText(currentPage);
            cc.getEngine().textToHTML(cc, pagedata);
          } 
          catch( Exception  e )  { /* dont care */ }     
        %>
        <wiki:Variable var='versionLabel' default="&nbsp;"/> 
        </td>

--tewr, 14-Jun-2006. --I assume all nesting quote problems, which seem to hand weblogic, have been removed. --DF 26 Jul 06

MSIE PNG Alpha Hack causes wrong image size#

Somehow, the MSIE PNG Alpha hack causes all images to be resized to a square here. I figured out that this was because the hack only defines a width for the blank image, so the height is calculated automatically, which produces a square. I fixed this by changing this line (twice)

   if (currentStyle.width == 'auto' && currentStyle.height == 'auto')
    style.width = offsetWidth + 'px';
to
   if (currentStyle.width == 'auto' && currentStyle.height == 'auto')
   {
    style.width = offsetWidth + 'px';
    style.height = offsetHeight + 'px';
   }

But, on pages with many images, this hack really slows down the page loading progress in MSIE, I would rather use palette-indexed colour for the logo for being displayed correctly in MSIE.

Fixed in upload of 23 Aug 06. Couln't validate on IE yet --DF

Image attachment preview is not shown in attachment version history#

I think line 401 of InfoTab.jsp should be WikiAttach.showImage instead of Attach.showImage.

Indeed. Fixed in upload of 23 Aug 06 --DF

Open Bugs#

Zebra in IE#

Hi, zebra tables seem to work only in Firefox. I would like to use zebra-tabels also with IE - any ideas? --Eva Lippert-Stephan, 21-Mar-2006

The color settings for a specific wiki-page - e.g. %%zebra-red <mytable>%% on a particular wikipage" - only works with Firefox, but not with IE. However, if general zebra-table-color-settings are specified within the skin.css, zebra tables also work with IE.

Apparently the current JSPWiki has implemented the zebra-tables at server-side (the .odd class is part of the html rendered by jspwiki) -- thus every table automatically gets zebra stripes. This also means that the zebra-table implementation does not function as expected: the specific color settings are overwritten by the .css settings in wiki.
( could it be that firefox and ie are taking a different default behaviour ? ) I need to tweek the implementation a bit to overwrite this behaviour and remove the .odd class of JSPWiki. Txs for flagging this site-effect. I will take it along in a next upload of the brushed-template. (look for a fix in BrushedTemplateZebraTable) --DF
I confirm zebra-tables are not working in IE. Need to dig into that --DF

Hi, the edit box for comments is not positioned correctly in IE 6.0 with skin "Smart, OrderedList and PlainVanilla", i.e.., it is squashed under the left menu! (JSPWIKI2.4.53 and "brushed2.4.x dated 5thSept06") -- els

--Eva Lippert-Stephan, 26-Sep-2006

Tx! Indeed, there is a badly closed <div> in the CommentContent.jsp. It will be fixed in the next upload. --DF

Missing Password Field#

Hi,

I am having problems with my login/logout using the brushedTemplate. The following symptoms are present:

  1. password field does not appear eventhough container managed authentication is not used
  2. login does not check the userdatabase.xml eventhough it is set in jspwiki.properties
  3. if cookie contains authenticated user, logout does option does not appear

Additional info:

  • no realms are set
  • container managed authentication is not used
  • JSPWiki Version: 2.5
  • BrushedTemplate: v3.x Sep-Nov 05
  • Security setting all okay according to SecurityConfig.jsp
  • Source of Error (I assume):Some where in BrushedTemplate it is flagged container management is being used eventhough it is not, switch to default template everything is fine

--Regards, DH

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-29) was last changed on 16-Mar-2011 21:26 by Janne Jalkanen