Project

Profile

Help

Bug #1613

@xsl:result-document@ triggers a re-load of the page?

Added by Manfred Staudinger about 8 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Low
Assignee:
-
Sprint/Milestone:
Start date:
2012-08-27
Due date:
% Done:

100%

Estimated time:

Description

The initial load of the page runs fine. A click on the "Version" link activates a xsl:result-document with method="ixsl:append-content" which inserts successfully a div (green) with a text @span@. But this immediately disappears because of a re-load of the page and re-compile of the stylesheet. The trace shows exactly the same messages as the initial load.

Windows XP, Saxon-CE 1.0, Opera 12.01 1532

Questenberg_Herman_von.xml (957 Bytes) Questenberg_Herman_von.xml Manfred Staudinger, 2012-08-27 07:40
namen.xsl (2.36 KB) namen.xsl Manfred Staudinger, 2012-08-27 07:40
view_names.xsl (4.81 KB) view_names.xsl Manfred Staudinger, 2012-08-27 07:40
Namen_b.css (1.39 KB) Namen_b.css Manfred Staudinger, 2012-08-27 07:40

History

#1 Updated by Philip Fearon about 8 years ago

If I've understood this correctly, I believe this is the same 'prevent default' issue as described in issue #1503 #1590. Clicking on any HTML anchor a element with an href attribute will always result in a page reload unless steps are taken to prevent this default behaviour for browsers.

There's no cross-browser way (the preventDefault method for event won't work in IE), in XSLT, to prevent default actions directly with the current version of Saxon-CE, but there's an easy workaround for this anchor element case which is to use a span element with an identifying class such as class='hlink' and, if required, a @data-href attribute instead of an a element. CSS can be then be used to style the span element to appear the same as an a element - e.g. Click events for the span element can then be handled reliably within your XSLT without the page refreshing.

span.hlink {
   text-decoration:underline;
}
span.hlink:hover {
   cursor:pointer;
}

#2 Updated by Manfred Staudinger about 8 years ago

Thanks for the detailed explanation given in issue #1603! I didn't understand the difficulty with 'prevent default' because in JS I always used the cross-browser @return false@. If the workaround you propose can considered a temporary one it will pose no problem.

#3 Updated by Philip Fearon about 8 years ago

No problem... in my above answer I should have referenced #1590 (now corrected): 'eventProcessing, preventDefault. Yes, in JS returning false should always work - and this is how it is implemented when the ixsl:prevent-default attribute is used in the next Saxon-CE release to ensure cross-browser compatibility - the span workaround can therefore be considered temporary.

#4 Updated by O'Neil Delpratt over 7 years ago

  • Status changed from New to Resolved

Closed as a usability problem, not a bug

#5 Updated by O'Neil Delpratt over 7 years ago

  • Status changed from Resolved to Closed
  • Sprint/Milestone set to Release 1.1
  • % Done changed from 0 to 100
  • Found in version set to 1.0
  • Fixed in version set to 1.1

Bug fixed for Saxon-CE version 1.1 release

Please register to edit this issue

Also available in: Atom PDF