Well, it depends, as always :)
We could allow for .\ and ..\ in our own internal representation, but we
cannot output those directly in our xhtml. If we do, then we are
violating the RFC for URIs.
They would have to be converted to / before the xhtml document is
written out. Supporting both will probably end in a nightmare of strange
bugs, where we always have to make sure they are converted first.
IMO we should not allow it anywhere, as it encourages people to write
malformed URIs.
Lukas Theussl wrote:
Ok, I got it :)
Shouldn't we still allow ".\" and "..\" as well as windows people might
use that for internal links? Or is that illegal also for links between
files?
-Lukas
Dennis Lundberg wrote:
I was caught by this one the other day as well, but didn't have time
then to see what had gone wrong.
Cabasson Denis wrote:
(I know there is a DOXIA list, but I haven't been able to find it in
a short time, so I used the Maven dev one).
My problem is that on Windows, links beginning with "./", such as
"./link" is not interpreted as an external link (because
StructureSink.isExternalLink is seaching for ".\"). Thus, it is
rendered as href="#./link" which is troublesome.
And in most plugin, (like the PMD one), they are just using "./"
instead of bothering with the separatorChar.
Having links that contains the \ character is plain wrong. See RFC2396
section 2.4.3.
http://www.ietf.org/rfc/rfc2396.txt
We should change StructureSink.isExternalLink so that it doesn't use
File.separator. It should be using the / character directly.
Thus, this revision broke a lot of existing reports (at least on
Windows).
I agree with you that DOXIA-47 is correctly fixed by this patch, but
it breaking quite a lot of other things, which is not good.
Anyway, after some research, I have found that ".\link", if
interpreted correctly by DOXIA is not interpreted correctly by web
browsers (at least Opera and Firefox).
Thus I guess a fix to this would be to change the
StructureSink.isExternalLink method to use "/" instead of
separatorChar (and repbulish a SNAPSHOT version).
Denis.
-----Message d'origine-----
De : Lukas Theussl [mailto:[EMAIL PROTECTED] Envoyé : mardi 17
juillet 2007 16:46
À : Maven Developers List
Objet : Re: [DOXIA] Revert doxia revision 555417
(you know there is a doxia list?...)
I don't quite understand your evaluation of the problem.
StructureSink.isExternalLink uses text.indexOf( "." +
File.separatorChar ), so this returns true for "./link" (Unix) and
".\link" (Windows). In any case you should get an external link (no
#) for "./some/path/file.html".
Anyway, DOXIA-47 is fixed correctly IMO, if there is a Locale
problem then this is a separate issue, you should open another JIRA
for that.
Cheers,
-Lukas
Cabasson Denis wrote:
Could you please revert the Doxia revision :
http://svn.apache.org/viewvc?view=rev&revision=555417
And deploy a new snapshot version of doxia since latest version
(doxia-core-1.0-alpha-9-20070714.200033-13) is shipping
with this patch.
This patch is breaking report created by lots of plugin.
Indeed links
beginning with "./some/path/file.html" are no longer considered as
local link on my configuration (Windows with French Locale)
and ends
up as links to anchor : href="#./some/path/file.html".
This can be tracked to the fact that
http://svn.apache.org/viewvc/maven/doxia/doxia/trunk/doxia-core/src/ma
in
/java/org/apache/maven/doxia/sink/StructureSink.java?revision=519803&v
ie w=markup StructureSink#isExternalLink is using File.separator to
search for relative links (which is '\' instead of '/' on windows),
while most of the report plugin are just using the '/' char (for
example, see
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-pmd-plugin/src/
ma
in/java/org/apache/maven/plugin/pmd/AbstractPmdReport.java?revision=51
70 80&view=markup AbstractPmdReport#constructXRefLocation ).
Before revision 555417, everything was fine but with this
revision, a
lots of reports are broken here, with relative links being
now wrongly
considered as links to anchors.
I guess http://jira.codehaus.org/browse/DOXIA-47 should be
reopened,
and another solution found (or maybe StructureSink should be more
lenient on the separator char).
Thanks!
Denis.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For
additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
