Item11969: Add default value for parameters passed to STARTSECTION macro.
Priority: Enhancement
Current State: Closed
Released In: 2.0.0
Target Release: major
Applies To: Engine
Component: INCLUDE
Branches: trunk
see
AddDefaultValueToSTARTSECTION
diff --git a/core/lib/Foswiki/Macros/INCLUDE.pm b/core/lib/Foswiki/Macros/INCLUDE.pm
index ad0366a..e483ffb 100644
--- a/core/lib/Foswiki/Macros/INCLUDE.pm
+++ b/core/lib/Foswiki/Macros/INCLUDE.pm
@@ -227,6 +227,12 @@ sub _includeTopic {
# Rebuild the text from the interesting sections
$text = '';
foreach my $s (@$sections) {
+
+ $this->{prefs}
+ ->pushTopicContext( $this->{webName}, $this->{topicName} );
+ $this->{prefs}->setSessionPreferences(%$s);
+ $this->{prefs}->setSessionPreferences(%$params);
+
if ( $control->{section}
&& $s->{type} eq 'section'
&& $s->{name} eq $control->{section} )
@@ -241,6 +247,8 @@ sub _includeTopic {
substr( $ntext, $s->{start}, $s->{end} - $s->{start} );
$interesting = 1;
}
+
+ $this->{prefs}->popTopicContext();
}
}
giggle.
yes, this will not cut it in reality - at minimum i need to remove the section hash's internal use keys, otherwise their use in
INCLUDE would change (
type
,
name
,
start
and
end
are a bit too generally useful to suddenly default to non-'')
--
SvenDowideit - 25 Jun 2012
Michael noticed and fixed: Breaks things in some strange combinations, because there's a "last" that doesn't clean up the stack. Happened to me
when deleting the wrong topic.
--
SvenDowideit - 26 Jun 2012
I've implemented a more wholesome solution, with unit tests, but need to see what that does to Michael's issue, and if anyone sees anything else interesting.
--
SvenDowideit - 26 Jun 2012
Going to check it out.
The prev error was only ocurring randomly, making it very hard to reproduce. There was something manipulating the value of
%WEB%
and
%TOPIC%
so that the respective wiki apps produced a totally wrong delete-topic form. The url was correct - alas it was pointing to some topic once %INCLUDEd in the head of the skin, and nowhere else.
So there might have been some error with regards to the topic context stack not being pushed/popped symetrically. There should be an ASSERT comparing the number of pushes and pops at the end of the request. Not sure how to do that...
--
MichaelDaum - 26 Jun 2012