Hi,
Glad I could help :)
About your doubts, the dash-array use case is different from the one
solved by the parseCssParameter method.
We actually want a list of expressions, so no need for the concat
function or other function.
In my opinion the implementation of the parsing of the dash-array
property should look like this:
private List<Expression> parseDashArray(Node root) {
NodeList children = root.getChildNodes();
List<Expression> expressions = new ArrayList<>();
for (int i = 0; i < children.getLength(); i++) {
Node child = children.item(i);
if (child == null) continue;
switch (child.getNodeType()) {
case Node.TEXT_NODE:
handleDashArrayText(child.getNodeValue(), expressions);
case Node.ELEMENT_NODE:
handleDashArrayNode(child, expressions);
case Node.CDATA_SECTION_NODE:
handleDashArrayText(child.getNodeValue(), expressions);
}
}
return expressions;
}
private void handleDashArrayText(String text, List<Expression> expressions) {
if (text == null || text.isEmpty()) return;
for (String textPart : text.split("\\s+")) {
expressions.add(ff.literal(Float.valueOf(textPart)));
}
}
private void handleDashArrayNode(Node child, List<Expression> expressions) {
Expression expression = ExpressionDOMParser.parseExpression(child);
if (expression instanceof Literal) {
handleDashArrayLiteral((Literal) expression, expressions);
} else {
expressions.add(expression);
}
}
private void handleDashArrayLiteral(Literal literal, List<Expression>
expressions) {
Object value = literal.getValue();
if (value instanceof String) {
handleDashArrayText((String) value, expressions);
} else {
expressions.add(literal);
}
}
Best regards,
Nuno Oliveira
Le jeudi 13 août 2015 à 08:45 +0100, Igor Volkov a écrit :
> Thank you Nuno! Through your doubts I continued my search and found a nice
> solution, which is a symbiosis of my idea to use the argument of a function
> for storing expressions for dash array (list) and your desire to do without
> superfluous functions similar to that of the Label concatenation in SLD. I
> have found, that SLDParser while parsing value of Label creats internally
> the strConcat function. This is just what I need! Test showed, that it is
> working for stroke-dasharray CssParameter.
> I am ready to commit new implementation of dashArray expression list. But l
> have some doubts.
> If implementation of expression concatenation for Label will be changed in
> future (for example the strConcat will be replaced by Concatenate which is
> more convenient) then my code will not work correctly and this will be
> difficult to discover. Also some strange person may wish to use strConcat
> for dasharray implicitly, but if he will nest strConcat's in second argument
> and not in the first as SLDParser does, then my code will faild again. I
> have tried to write universal processing of strConcat and Concatenate (it
> was my fist approch to the problem of dasharray) but I am not shure that it
> is necessary to be so paranoid.
> So I am waiting for advice befor commiting of new implementation of
> dashArray.
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/SLD-Stroke-Dasharray-Property-tp5083512p5219634.html
> Sent from the geotools-devel mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
------------------------------------------------------------------------------
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
