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
patch
JSPWiki_lucene.patch 4.6 kB 1 27-Oct-2004 16:14 80.126.27.148

This page (revision-116) was last changed on 20-Feb-2011 19:54 by Harry Metske  

This page was created on 27-Sep-2003 11:56 by JanneJalkanen

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 1 changed one line
Nice site <a href=http://google.com>....)</a>
The JSPWiki 2.2 release is at the stage where all major functionality has been added, and now we're interested in mostly tweaking the functionality for a full release. This page is meant for discussion, ideas and bug reports for the 2.1 alpha releases, so please don't suggest any new, big functionality here. Those should go to [Ideas]. Also, bug reports on the stable version should go to [BugReports].
The focus on this release has been with the [authentication system|AuthorizationAndAuthenticationHOWTO], so we expect most problems to occur in it.
;:Would like to see more separation of the authentication, authorization, and user account management functions. My chief concern is that these are all mixed together now, making it impossible to integrate container-managed security the way it "should" be. It's too late for 2.2 I suspect, but I'd like to put this on the roadmap for 2.3. -- [Andrew Jaquith]
Also, if there are any pet [BugReports] that you really think should be fixed in this release, please make a mention of them here (just a one-two line reminder is enough; no need to make the page very big. :-) Please also add any items from the documentation that are missing, or link to pages on this site that you think should be included with the distribution.
----
Why don't we standardize on some decent date format like yyyy-mm-dd (for use in WebLogs, in the calendar etc.)? It's more logical than any other scheme, better for sorting, better readable (than i.e. 121104, easily confused as 12. Nov or 11. Dec), and been adopted by many standards organizations (see [W3C - Date and Time Formats|http://www.w3.org/TR/NOTE-datetime] or [A Summary of the International Standard Date and Time Notation|http://www.cl.cam.ac.uk/~mgk25/iso-time.html]). -- ReinhardEngel
----
Things that are probably still going to happen are:
* New setup system for [PageFilters]; probably XML-based, since the current system does not allow multiple filters by the same name.
* Documentation update and cleanup (yes, we're sorry, some of the features are still on the [RTFS] -stage.
* Cleanup and bug fixes on the TemplateManager (which I accidentally checked in but was too lazy to remove :-)
* rss.jsp to work better on individual files.
* Redesign ~DefaultPermissions system for the ~PageAuthorizer; the current system has some glitches.
* Make deleting pages possible.
* XHTML compliance - for some really strange reason the W3 validator thinks that we are not valid HTML - it complains about META tag being non-valid in a HEAD element, and I just simply cannot figure out why this is so, because the spec clearly says it's okay. __Please help me out on this__, if you're a HTML guru.
;XHTML:AFAIK in XHTML all official tags and attribute names have to be in __lower case__. -- ReinhardEngel
;XHTML/HTML compliance:You just need to decide which code you are outputting. It cannot be both XHTML and HTML compliant at once (though it may appear that way). Although most browsers handle it (IE, Mozilla, etc), mixing <...> with the same tagname <.../> for self-closing elements like ''meta'', ''link'', ''img'', etc., it is not compliant with either standard. Since the doctype states ''...HTML 4.01...'' you don't have "/>" at the end of any tag, that is an XHTML (i.e. XML) feature. BTW, the validator is really telling you that the previous tag is in error, rather than the one which it is pointing at (just like hunting through the output of any complier you may have used in the past, you find previous errors have all sorts of fun side-effects downhill :) ). The renderer thing you have introduced in 2.1.x, once used for everything, will likely help with this task. My simple advice is this: clean, clean, clean. Best strategy for fixing unsolvable bugs. You may never find the cause, but it doesn't matter, your code will be in good shape and behaving well. --MurrayG
----
First, let's not mix up browser behaviour with markup standards; they're two different things.
JSPWiki uses XHTML, not HTML. And yes, all XHTML element type names ("tag names"), attribute names and fixed values __must__ be in lowercase. Whereas HTML was SGML-based, XHTML is XML-based. One of SGML's numerous features that XML doesn't have (i.e., permit) is wrapping of case. Another is called ''tag minimization'' (i.e., not requiring end tags), and then there's how empty elements are handled. In HTML, {{&lt;meta&gt;}}, {{&lt;img&gt;}} and the other elements whose declared content model is {{EMPTY}} could simply be represented as a single tag, with their end tags inferred. There is no such feature in XML. The W3C's XML Working Group managed to find a relatively elegant solution for empty XML elements that actually worked in existing Web browsers: by adding "{{ />}}" (note that the space preceding the slash is __required__) here was something that worked and was SGML-legal, via a minor change to the SGML declaration for XML (the machine-readable declaration for the profile).
! Invalid (in XHTML):
{{{
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8"> [uppercase]
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> [no empty tag markup]
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/> [missing space]
}}}
! Valid (in XHTML):
{{{
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
}}}
So what this comes down to, as it always has been, is ''declaring'' the markup language you're using and then sticking to it. If you've declared you're using XHTML you should also precede an appropriate DOCTYPE declaration with the XML declaration ({{<?xml version="1.0" encoding="UTF-8"?>}}). That's not strictly necessary but is good practice and gives validation tools a clue that you're using XML.
-- MurrayAltheim, 13-Apr-2007
----
You can download the current alpha on [JSPWikiDownload].
''I'll try to keep the discussion on this page relatively tight, so I will remove things that have already been taken care of. You can do that too =).''
[{TableOfContents}]
----
!!!Documentation
* [Authorization And Authentication HOWTO]
----
!!!Open Bug Reports
!!2004/12/06 - Make JSPWiki JDK1.5-compatible
Not necessarily make use of new JDK1.5 features, merely avoid identifier names like "enum" which are now reserved words.
-- [Ramon Casha]
!!2004/10/26 - Lucene cache is not updated if page is changed "underneath JSPWiki"
|JSPWiki version | JSPWiki v2.1.115-alpha
|Java version | 1.4.x
|Operating system| Linux
|Web server and servlet container | Tomcat 4.3.1
|Page provider | FileSystem, AntCvs (modified to work)
|Browser | n/a
Hi all,
I hope that someone sees this one ;-)\\
Anyway, the problem that I have is pretty simple, when using the CVS provider, the Lucene cache is never updated when the file is imported through CVS, even though the new file is shown on the Wiki. [This patch|Release2.2Discussion/JSPWiki_lucene.patch] fixes that problem, as well as a crashing bug when a file is deleted.
;:''Fixed in 2.1.117''
----
!!2004/08/26 - Java2Html Plugin: Neverending loop in attachemnt loading
|JSPWiki version | JSPWiki v2.1.103-alpha from current download, Java2Html Plugin 4.1
|Java version | 1.4.x
|Operating system| WinXP, Linux
|Web server and servlet container | JBoss 3.X - Jetty 4.X
|Page provider | FileSystem, RCS
|Browser | n/a
Hi,
I'm not sure if this is the right place here to ask but will try it.
I'm using the Java2Html plugin to display an attachment. Therefore in the plugin's execute method, the attachement is loaded and parsed. But in this case, the default authenticator asks the current page, if this attachement exists and its readable by the current user. Then all plugins on this page were executed, also the Java2Html plugin and loading of the attachement starts again. And again. And again.
No I'm not sure if this is a bug of the plugin or the authentication handling. The critical problem on this loop, is that in each call a new HTTP-Request is fired to the webserver, which ends up with something like 'no more threads available'. Server reboot is the only solution on this.
Regards
-- [SteffenStundzig]
----
!!2004/07/27 - jspwiki.tld: HistoryIteratorTag still defines a page attribute
|JSPWiki version | JSPWiki v2.1.103-alpha from Nightly Build 2004.07.15
|Java version | 1.4.x
|Operating system| Win2K
|Web server and servlet container | Weblogic 8.1
|Page provider | n/a
|Browser | n/a
|Fixed in | v2.1.118
Weblogic server is moaning that there is no setter defined for attribute page. Simply removing
{{{
<attribute>
<name>page</name>
</attribute>
}}}
as suggested in [JSPWikiServletCompatibility] resolved the issue. -- [Christian Buchegger]
----
!!2004/07/15 - New lines in preformatted block not preserved when preceded by spaces
|JSPWiki version | JSPWiki v2.1.103-alpha from Nightly Build 2004.07.15
|Java version | 1.4.x
|Operating system| Red Hat 9
|Web server and servlet container | Resin Server 3.0.6
|Page provider | VersioningFileProvider
|Browser | Internet Explorer 6.0
I'm not sure if this is a bug or a new feature.
It appears that new lines are disappearing when the preformatted block tags are preceded by spaces in v2.1.103-alpha. This tag combination behaved differently (and as I preferred for use inside numbered lists) in v2.0.52. Take a look at the following examples.
* [JSPWiki v2.0.52|http://www.dirkschreckmann.com/wiki/Wiki.jsp?page=PossibleBug] - preferred behavior
* [JSPWiki v2.1.103-alpha|http://www.dirkschreckmann.com/wiki-test/Wiki.jsp?page=PossibleBug] - not preferred behavior
-- DirkSchreckmann
!!2004/05/19 - CamelCase causing exception
Using v2.1.98-CVS
Apache 2.0.49
Tomcat 5.0.19
Just moved existing Wiki pages from JSPWiki 2.0.36 to 2.1.98-CVS. With the CamelCase property set to true JSPWiki fails to start with the following exception.
{{{
2004-05-19 20:44:24,171 [TP-Processor3] ERROR com.ecyrd.jspwiki.WikiEngine - Failed to start managers.
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.StringBuffer.replace(StringBuffer.java:711)
}}}
If the CamelCase property is set to false then JSPWiki starts up perfectly. I am not sure yet if its a single page that is causing the problem. I need to investigate further. This [zip|http://tarasis.net/wiki-pages.zip] contains the pages.
-- RobertMcGovern
----
!!2004/05/11 - Renaming the Start Page seems to be broken
Using v2.1.94CVS.
I didn't know whether to post this here or in the general bug reports section. Sorry if it should have gone there. Here goes: When I change the value of the jspwiki.frontpage property in jspwiki.properties, the wiki:Include tag breaks (fails to load the page). Having checked the logs, I see that the wiki knows the name of the new page, but somehow can't load it. The exception is thrown in Include's doEndTag() handler. This happens no matter what page I choose to be the front page. It only happens when I use the application name directory as the last part of the URL - no page specified. If I then click on a link or manually put in the full URL to any page, including the one that failed to load, it loads properly. I have checked my jspwiki.properties file. Any clues?\\
-- RayBaco
----
!!2004/03/16 - InsertPagePlugin does not check permissions from included page
Using v2.1.86-alpha.
The InsertPagePlugin does not check permission of included page.
This is a security problem, because this way you can create a new page an include protected page.
As a result, you have access to the protected page.
* Create a page with ACL info which included no view permission (~InvisiblePage).
* Create another new page with InsertPagePlugin like this as content: {{{
[{InsertPage page='InvisiblePage'}]
}}}
* As a result you will see the content of ~InvisiblePage, even if you don't have view
permission.
-- [Guido]
----
!!2004/02/19 - Page suddenly empty
I'm testing 2.1.86-alpha and sometimes JSPWiki displays a page as empty. \\
If I check the txt-file there is text in the file. Why does this happen? I am doing some bulk updates on the pages (like changing a common filedirectory in all wiki-pages linking there). Could that be the reason? If so how do I work around that? I'm running JSPWiki on JBoss on WinXp \\
-- MichaelWiller
----
!!2004/01/20 - Attachments arn't accessable
Using v2.1.86-alpha.
An attachment can be added successfully, but when attempting to retrieve the attachment the browser reports that the site cannot be opened. The stdout log in Tomcat shows:
Latest version=-1
But the file is in the dataset and the properties seem correct. This only occurs when using ssl (by setting the security constraint in the web deployment to confidential and protected)
i.e.
<security-constraint>\\
<web-resource-collection>\\
<web-resource-name>Protected</web-resource-name>\\
<url-pattern>/*</url-pattern>\\
</web-resource-collection>\\
<user-data-constraint>\\
<transport-guarantee>CONFIDENTIAL</transport-guarantee>\\
</user-data-constraint>\\
</security-constraint>
----
!!2003/12/01 - Quotes & WikiName in Id or Name attribute causes page errors
Using v2.1.86-alpha.
If the Id or Name attribute in embedded HTML is a WikiName enclosed in quotes there are anomalies in the page display. E.g.
{{{
Where is that <font id="Darkblue" color=DarkBlue>rascally</font> rabbit?
Where is that <font id="Dark Blue" color="DarkBlue">rascally</font> rabbit?
Where is that <font id="DarkBlue" color="DarkBlue">rascally</font> rabbit?
}}}
. . . displays as -
{{{
Where is that rascally rabbit?
Where is that rascally rabbit?
Where is that ?" color="DarkBlue">rascally rabbit?
}}}
I have not done extensive testing, this may occur with other attributes as well, but does not occur with all.
-- [PaulDownes]
----
Hi, I'm testing the upgrade and I'm getting javascript errors on setting the form focus in __~EditTemplate.jsp__. Would it be possible to put some sort of null check in the 'onload' as below?
{{{
<wiki:CheckRequestContext context="edit">
<body class="edit" bgcolor="#D9E8FF"
onLoad="if( document.forms[1].text != null ) {document.forms[1].text.focus();}">
</wiki:CheckRequestContext>
<wiki:CheckRequestContext context="comment">
<body class="comment" bgcolor="#EEEEEE"
onLoad="if( document.forms[1].text != null ) {document.forms[1].text.focus();}">
</wiki:CheckRequestContext>
}}}
-- ScottHurlbert
Ah, I see, the real problem is that you have probably removed the Search box... Really what we should do is to refer to the textarea via a name instead of its # on the web page.
-- JanneJalkanen
----
I'm testing v2.1.89 alpha, and on the UserPreferences page, i cant set the editor width and hieght. no matter what i do, it always reverts back to 80 & 25. --DaSamon
''I haven't been keeping up with the 2.x releases much, but the 80x25 dimensions sound suspiciously like what I have in my [contributed template|ContributedTemplatesMrg]. If you are using that template, make sure you are using the most recent version, which does allow you to set the width and height (assuming you have cookies enabled). -- MichaelGentry''
----
!!!Suggestions
!!Auto-inc topic number support, like in SnipSnap: #.#.#
It's very useful to add support for topic numbering.
-- [Bin Sun | mailto:sun2bin@163.com]
\\
eg:
\\
# topic1
\\
#.# subtopic1
\\
turns into:
\\
1 topic1
\\
1.1 subtopic1
!AutoBackEditPatch
* Hmmm, have you tried the AutoBackEditPatch? I personally hate hating the edit forms in my browser history. We use it just fine on our wiki at work and it seems like it is harmless. --JohnV
----
!!~PrintFriendly
I would like to suggest that the ~PrintFriendly feature in [MichaelGentry]'s MRG template is added to the JSPWiki core, and a ~PrintFriendly option is added to the default template's page footer menu.
-- [PaulDownes]
Actually, it's already there, but it's in the form of a special CSS stylesheet. You can either change into a print -stylesheet from the View-menu of your browser (if it is supported), but printing a page should automatically remove things like LeftMenu.
-- JanneJalkanen
To which CSS stylesheet are you referring? The only stylesheets that appear to be distributed with the 2.0.52 version of JSPWiki are the jspwiki*.css files, none of which seem to address printing per se.
In at least the Internet Explorer browser, printing a page does not automatically remove the LeftMenu.
I'd like to second the motion of adding the MRG template's ~PrintFriendly.jsp and an accompanying link to execute that JSP (whether on the left menu or in the list of links at the bottom of each page) to the JSPWiki core.
-- [Theosophe74]
No, it's in 2.1. branch - there's a print stylesheet called jspwiki_print.css. It's actually rather trivial to add to 2.0, if you want to.
I don't actually want to add ~PrintFriendly.jsp, because I don't want to add any new top-level JSP pages unless absolutely necessary (and with the new WikiForm -plugin, after a bit of polishing, we can probably start getting rid of a bunch of the old ones as well).
If you don't want to have a CSS-based solution, I'll probably be adding a "plain" template to the next release.
-- JanneJalkanen
I couldn't disagree with this approach more. I am very frustrated with this
at the moment and the whole non configurability of the left menu thing is the
only downside to jspwiki that i have. IE definitely prints the left menu.
I don't know how to print with the CSS solution. Adding a plain template
doesn't do any good because i want to do it within my current template.
I haven't been able to get PrintFriendly or HideMenu to work with the
default template.
In general i think worrying about how many top level jsps there are is
a developer worry that i as a user could care less about. I would like all
the goodies tossed in so i don't have to try to add things to the wiki,
which usually isn't that easy because somethng wierd always happens.
-- Anonymous
Out of curiosity, how would one re-style a page to use jspwiki_print.css without having a browser that supports the "print -stylesheet" behavior that you described? I can move this to StupidQuestions if that's appropriate. :-)
Are there any plans to release a ''non''-alpha 2.1.x version of JSPWiki in 2003? :-) Thanks.
-- [Theosophe74]
Javascript. It even has an added bonus that you don't have to necessarily reload the page.
2.2 will be out "when it's ready", to follow the general Linux release schedule =). It all depends on available time.
Having said that, many people are using 2.1 alpha successfully for production work...
-- JanneJalkanen
----
!!Page authorization
It would be nice if a page's permission could apply to a scope of pages instead of just the current page.
For example instead of [[{ALLOW view somegroup}] you would write [[{ALLOW* view somegroup}] and all pages that start with the current page's title would be affected. Having to specify the permission for each individual page as soon as they deviate from the DefaultPermission is quite cumbersome. Alternatively the DefaultPermission handling might be modified, e.g. by using PrefixDefaultPermission to apply to all pages starting with Prefix.
;:''I don't think that's a very good idea. It would easily lead into a "now exactly where this thing is configured" -nightmare. I'd rather go with proper SubPages. --JanneJalkanen''
----
!!!Questions
!!Page Rename Patch
* By chance did a page rename feature make it into 2.1? I recall mention that the matchEnglishPlurals issues had been addressed, and that was one of the last holes in the RenamePagePatch. --JohnV
* No, not yet. I'll see if it can be integrated. All known issues with matchEnglishPlurals have been solved. --JanneJalkanen
* You mention that "Make deleting pages possible." is still going to happen, might I suggest that implementing the RenamePagePatch is one means to accomplish it? Hint-hint, nidge-nudge. (I really like being able to rename pages, and hate having to patch source.) --JohnV
* Well, it kinda works in the same area, and the biggest reason that I haven't included it is that we needed a working auth before allowing something like this which is potentially NOT reversible :-). --JanneJalkanen
----
!!Chinese prompt message under UTF-8
* Hi, JanneJalkanen. My name is Jin Zeng and I live in Beijing of China. Thanks for your great work, I am using your JSPWiki v2.0.52. It works well.In order to input Chinese, I set JSPWiki to use UTF-8. It also does well.Further more, I want the prompt message displayed in Chinese. So I think I need to do some change in the JSP source file.For example, I edited a file named ~FindContent.jsp. However, the characters I input was displayed in irregular character can not be read.How do I fix this problem then? -- Jin Zeng
Which prompt message? You will need to make a Chinese template. See [WikiTemplates]. Unfortunately, not all of JSPWiki is yet localizable... --JanneJalkanen
----
!!Error: 'document.forms.1.text' is null or not an object
* I get this error whenever I try to edit a page at www.jspwiki.org. (IE5.5)
* I also get it if I try to run 2.1.103-alpha at my site
* A stable version is what I would really like, but I would like to have the fix for nested numeric bullets. Any suggestions?
Thanks, --KirkWolf
IE 5.5 and 6 do not like {{document.forms[1].text}}, because they use another Document Object Model (I suppose IE6 can be made to like it by changing the DOCTYPE of the page, but I haven't tried that yet). Simple solution: edit {{default/~EditTemplate.jsp}} by deleting the {{onload}} instruction on lines 14 and 18. Better solution (if you want to keep the functionality): add an ID to the main FORM of the editing page, and replace {{document.forms[1].text.focus()}} using the {{getElementByID()}} function... [Wouter]
----
!!!Closed Bugs
!!2003/11/05 - Quotes cause Preview page errors
Using quotes in text causes anomalies in display on the preview page, and if the Save button is selected, the text following the first quote is deleted.
-- [PaulDownes]
Thanks, this is already fixed in 2.1.84.
-- JanneJalkanen
----
Version Date Modified Size Author Changes ... Change note
116 20-Feb-2011 19:54 22.68 kB Harry Metske to previous
115 18-Feb-2011 06:50 0.047 kB noipApoximb to previous | to last
114 14-Apr-2008 10:44 22.68 kB 121.15.13.195 to previous | to last
113 14-Apr-2008 10:43 22.681 kB 121.15.13.195 to previous | to last
112 19-Mar-2008 17:36 22.68 kB JanneJalkanen to previous | to last
111 19-Mar-2008 17:02 22.692 kB Giraffe to previous | to last
110 26-Sep-2007 23:41 22.68 kB JanneJalkanen to previous | to last
109 26-Sep-2007 02:48 22.691 kB 81.180.65.2 to previous | to last
108 06-Jun-2007 01:59 22.68 kB MurrayAltheim to previous | to last disabled unintentional links
107 13-Apr-2007 14:26 22.676 kB MurrayAltheim to previous | to last clarified some XHTML issues
106 13-Apr-2007 14:24 22.685 kB MurrayAltheim to previous | to last clarified some XHTML issues
105 13-Apr-2007 13:19 22.078 kB MurrayAltheim to previous | to last clarified some XHTML issues
104 13-Apr-2007 13:00 20.724 kB gblasko to previous | to last
103 13-Apr-2007 13:00 20.754 kB gblasko to previous | to last Comment by gblasko
102 10-Sep-2006 20:47 20.714 kB JanneJalkanen to previous | to last
101 10-Sep-2006 20:03 21.815 kB Bush to previous | to last
« This page (revision-116) was last changed on 20-Feb-2011 19:54 by Harry Metske