When XWiki renders a document, the interactions between the Groovy,
Velocity, and Wiki (Radeox?) syntax processing can lead to unexpected and
undesirable behavior. There have been posts on this list in the past where
this issue has been discussed. However, I'm not aware that any consensus has
emerged as to how to deal with these problems.
To summarize, here are a few of the issues that I'm aware of:
* Getting XWiki to render a bit of text without doing any syntax processing
on it can be difficult. For example, the {pre} ... {/pre} markup turns off
XWiki syntax processing, but not Groovy processing.
* The # symbol is used both to do numbered lists and is also used for Groovy
processing. If a user wants to create a numbered list and forgets to put a
space after the #, he can run into trouble. The following example will cause
a stack dump:
#bring coffee
#include doughnuts
* Code samples on a Wiki page sometimes don't render correctly, due to
conflicts with Velocity syntax processing. The following C/C++ code sample
results in a runtime stack dump:
{code}
#include <stdio.h>
...
{code}
* Groovy and Velocity both use $varname syntax. I think I've read some posts
in the past where this was an issue -- although I can't come up with any
examples at the moment.
* A usability issue: Most XWiki tags ({table}, {code}, etc.) come in pairs.
The closing tag has no slash. For example: {table} ... {table}. However,
the {pre} tag does have a closing slash: {pre} ... {/pre}. This
inconsistency is annoying and causes difficulties for new users.
* A significant usability issue for Windows users: Pathnames contain
backslashes (\). XWiki uses the backslash as an escape character. So
attempting to put a UNC path like \\myserver\myshare\mydoc.txt in an XWiki
document triggers an XWiki runtime exception. Boy, is that frustrating for
new XWiki users. The solution is to wrap the path in {pre} .. {/pre}, but
the error message gives the user no clue what the problem was, much less how
to correct it.
Here are some proposals for discussion:
1. {pre} ... {/pre} should turn off ALL syntax processing of its contents.
2. {code} ... {code} should turn off ALL syntax processing, except for
syntax coloring.
3. {pre} should allow {pre} as a closing tag.
4. Consider requiring users to explicitly enable Groovy/Velocity processing
for selected Wiki documents as needed. In the page editor, provide two
checkboxes: "Perform Groovy Processing" and "Perform Velocity Processing".
The user could separately enable either Groovy or Velocity processing, or
both. People who enable them would presumably be in a better position to
deal with the kinds of syntax conflicts that would occur.
5. Provide more user-friendly error messages when a Groovy or Velocity
processing exception occurs. Show the Wiki source line that caused the
problem.
I haven't opened a JIRA issue for this yet, because I'm not sure how best to
word it. But I think this is a high-priority issue that should be carefully
addressed before the 1.0 release. This may be an issue that warrants a page
on the xwiki.org developer site. I'll be glad to start one if the developers
desire it -- perhaps here:
http://www.xwiki.org/xwiki/bin/view/Dev/Discussions
Stephen
Thought you might enjoy this.
------- Forwarded message -------
From: "Karl Dubost" <karl(a)w3.org>
To: "'public-evangelist(a)w3.org' w3. org" <public-evangelist(a)w3.org>
Subject: HOWTO Spot a Wannabe Web Standards Advocate
Date: Thu, 10 Nov 2005 20:10:30 -0000
Evangelistas,
[[[
HOWTO Spot a Wannabe Web Standards Advocate
If there is a match, you have spotted a wannabe.
* Talks about the importance of the alt tag.
* Claims <b> and <i> are deprecated.
* And spells it %u201Cdepreciated%u201D.
* Uses <span style="font-style: italic;">, because <i> is
presentational.
* Wants software to use <em> and <strong> when the UI says
italic and bold.
* Marks up quoted text as <cite>.
* Complains about upper-case tags in HTML.
* Claims XHTML 1.0 is more semantic than HTML 4.01.
* Claims XHTML 1.0 is more structured than HTML 4.01.
* Claims XHTML 1.0 is less presentational than HTML 4.01.
* Claims browsers parse XHTML served as text/html faster than
they parse HTML.
* Refers to %u201Cthe benefits of XHTML%u201D without specifying
what the benefits are.
* Uses large XHTML 1.0 Transitional documents with table layouts
while claiming enhanced compatibility with handheld devices thanks to
XHTML.
* %u201CFuture proofs%u201D a site by migrating from HTML 4.01
Transitional to XHTML 1.0 Transitional and keeps serving it as text/
html with all the old JavaScript scripts in place.
* Uses the XML empty element notation on pages that are supposed
to be HTML pages.
* Complains about doctypeless application/xhtml+xml or SVG
documents and smugly points to validator.w3.org.
* Claims all tables are evil.
* Advocates pixel-based absolute CSS positioning as the
righteous replacement for evil tables.
* Changes //EN at the end of the public identifier in the
doctype to the language code of the language the page is written in.
* Omits the namespace declaration in XHTML or SVG and claims it
is OK, because it validates.
* Serves documents written using a home-grown XML vocabulary
along with an XSLT transformation to HTML to browsers instead of
serving HTML, because XML is more semantic.
]]]
-- HOWTO Spot a Wannabe Web Standards Advocate
http://hsivonen.iki.fi/wannabe/
Wed, 27 Jul 2005 17:06:31 GMT
--
Jim Stuttard
Hi,
As tempus fugit towards release 1.0 I have a bit of a basic architecture
problem with the current DB schema.
Why does XWiki's DB schema depend on a number of proxy primary keys - eg.
ID: bigint? XWikiListClasses has a primary key of id, and name;
XWikiClasses has only a numeric id and name doesn't seem to matter. Is
this just me missing some basic idea?
Doesn't this hide the cardinalities, semantic connections and
non-transitive dependencies captured by primary keys in a fully-normalised
relational schema?
Currently this information would have to be inferred from the existing
schema, taking some time to do. And so I can't tell whether the schema is
normalised or not.
An example might be a Document. If memory serves me, Documents are
frequently uniquely identified by the minimal primary key of {title,
author, publication date}. If you ask "What are the chances of 2 different
documents having the same author name, title and publication timestamp?"
then this satisfices most conditions. An XWikiDoc however has a large set
of required fields and a single key.
Neither MySql nor any other RDBMS I know of uses single-field primary
keys. They are only required in the binary relational model.
I have always thought that good OODB design demanded *explicit*
de-normalisation if needed?
Cheers
Jim
--
Jim Stuttard
Hi
I'd like to propose a patch for com.xpn.xwiki.doc.XWikiDocument in order to
add a function that can allow user to create attachments.
Regards
--
Xavier MOGHRABI - Consortium ObjectWeb
Email: xavier.moghrabi at objectweb.org
Phone: +33 4 76 61 52 35
