Item843: INCLUDE pattern appears to require matching for the entire text
Priority: Normal
Current State: No Action Required
Released In: 1.1.3
Target Release: patch
Applies To: Engine
Component:
Branches:
but
VarINCLUDE reads as though the
^
etc are optional, not required
section called 'hello'
%STARTSECTION{"hello"}%hello there this is a section%ENDSECTION{"hello"}%
a sectional include that uses a pattern to try to get just one character
- INCLUDE{"Item843" section="hello" warn="off" pattern="[a-zA-Z]"}%
there being no (), should I be expecting this result?, and isn't respecting warn="off"
-
INCLUDE{"Item843" section="hello" warn="off" pattern="([a-zA-Z])"}%
doesn't seem to be to be getting on character either, and isn't respecting warn="off"
-
INCLUDE{"Item843" section="hello" warn="off" pattern=".*([a-zA-Z]).*"}%
seems to work.
this requires alot of unit tests to be written, as the functionality is poorly defined.
and the code is um, shocking really
=begin TML
---++ StaticMethod applyPatternToIncludedText( $text, $pattern ) -> $text
Apply a pattern on included text to extract a subset
=cut
sub applyPatternToIncludedText {
my ( $text, $pattern ) = @_;
$pattern = Foswiki::Sandbox::untaint($pattern, \&validatePattern);
try {
$text =~ s/$pattern/$1/is;
} catch Error::Simple with {
$text = '';
};
return $text;
}
whereas the docco says
pattern="..." |
Include a subset of a topic or a web page. Specify a RegularExpression that scans from start ('^' ) to end and contains the text you want to keep in parenthesis, e.g., pattern="^.*?(from here.*?to here).*" . IncludeTopicsAndWebPages has more information and example. |
none |
quite a different thing
this bizzaroland code is duplicated in Foswiki::Search - these 'filters' need to be extracted and fixed
interestingly, Search.pm has the following comment:
# FIXME: Allow all regex characters but escape them
# Note: The RE requires a .* at the end of a pattern to avoid false positives
# in pattern matching
$out =~
s/\$pattern\((.*?\s*\.\*)\)/_extractPattern( $text, $1 )/ges;
--
SvenDowideit - 23 Jan 2009
This one - when fixed - must not make applications that used current behaviour not work anymore. It seems highly risky rushing a fix through for 1.0.1 with no time before release to test it.
I am deferring this and downgrading to normal.
--
KennethLavrsen - 12 Feb 2009
This seems to be fixed in 1.1.3. Unit tests also exist for various pattern matches.
--
GeorgeClark - 14 Mar 2011