From: Nuno O. <nun...@te...> - 2015-08-13 13:41:05
|
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 > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel |