-
-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FXP Rewrite #682
FXP Rewrite #682
Conversation
@KaiVolland , since you are rewriting the SLD parser, would it make sense to extract the SLD version from the XML if a user has not provided the value explicitly? The reason that I'm asking is because when we use the SLD parser in our code, we now 'manually' extract it with using the following (also using
We then feed that version value as option in the constructor of the SLD parser. It seems that automatically extracting it from the SLD would be a logical next step. If this added functionality does not fit within this PR, I'll happily wait for your work here to be completed and I can then propose that functionality in a separate PR. |
+1 from my side. Personally, I would prefer to have it in a separate PR though. |
and adds documentation
adaption of 872cc9d
Can you please change the commit message of 385ca38? |
I'm going to squash this PR so the message will be gone. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a thorough review, some remarks. Take what you agree with. Thanks.
Co-authored-by: Marc Jansen <[email protected]>
Co-authored-by: Marc Jansen <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice @KaiVolland!
Co-authored-by: dnlkoch <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Way too much to properly review. Anyhow, made a few remarks.
Is there a reason that parsing Expressions is not included in this PR?
I wanted to keep this PR only for the rewrite. The Expression parsing will be completly diffrent then the one before as the geostyler-style v6 and v7 changed a lot there. But there is already an issue for this: #697 |
e7ded40
to
7de79cb
Compare
Co-authored-by: jansule <[email protected]>
7de79cb
to
47f5f78
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for addressing the remarks! Nice work @KaiVolland
Just a few minor points left
* @param tagName The tagname to get. | ||
* @returns An array of object as created by the fast-xml-parser | ||
*/ | ||
export function getChildren(elements: any[], tagName: string): any[] { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's unfortunate. But doesn't above line work anyways? It's the same as writing any
except that with this notation, we highlight that the output type equals the input type.
This replaces xml2js parser with fast-xml-parser.
Parsing of functions and expressions is not yet supported.