[
https://issues.apache.org/jira/browse/TAP5-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17683263#comment-17683263
]
Ben Weidig commented on TAP5-2747:
----------------------------------
Hello [~thiagohp]!
Just as a disclaimer, I haven't thought every edge-case through so far, so my
conclusions/ideas might be wrong.
*Array-Syntax*
The standalone {{[idx]}} is needed for nested arrays, and if you start with a
JSONArray.
The split up variant {{array.[idx]}} was a side-effect of how I implemented it.
Any beginning or intermediate keypath segment needs to be JSONCollection, so it
just works and I didn't need additional checks, like "if intermediate
non-nested array, direct index lookups".
*The ? operator*
The lookup syntax is prop-binding-like, but more akin to how
JSONObject/JSONArray work.
That means that optionality must be treated more explicitly.
As JSONObject explodes if a key is missing when using a get method, and
JSONArray explodes on invalid indices, the {{?}} indicator must be used as
such, too.
{{outer.nonExistant?}} would enforce outer to exist and be a JSONObject, but it
doesn't have to have a key {{nonExistant}}
{{outer?.nonExistant}} doesn't require {{outer}}, but if it exists, it has to
have a key {{nonExistant}}
Most likely I'm overthinking the syntax...
There's a strong argument to be made that it should be consistent with
prop-binding syntax.
Instead of being so strict while navigating the whole keypath, switching to a
more lenient mode if an optional segment was traversed would make sense.
*Next Steps*
As usual, my "that would be nice and small feature" idea morphs into a
complicated blob with lots of edge cases and convoluted feature set.
Nevertheless, I'll keep going and try to trim it down to the essentials.
And of course I'm going to and create a branch if I have anything to share.
Right now, I'm still experimenting.
The proof-of-concept is located in JSONCollection, so it supports both
JSONArray and JSONObject, but I'm not too fond of it to actually need to know
about the two types. I'm pretty sure there aren't any new JSONCollection types
any time soon, but still...
I even tried to create a Lookup helper factory that creates functions for
Optional pipelines, as a non-keypath-based alternative.
> KeyPath-based traversal of JSONCollection
> -----------------------------------------
>
> Key: TAP5-2747
> URL: https://issues.apache.org/jira/browse/TAP5-2747
> Project: Tapestry 5
> Issue Type: New Feature
> Components: tapestry-json
> Affects Versions: 5.8.2
> Reporter: Ben Weidig
> Assignee: Ben Weidig
> Priority: Minor
>
> As navigation nested {{JSONObject}} structures can be tedious, so I propose
> adding a String-based KeyPath traversal system.
> For example:
> {code:java}
> JSONObject json = ...
> // {
> // outer: { inner: "here" },
> // array: [
> // 1,
> // { innerArray: ["A", "B", "C"] },
> // ["Z", "Y", "X"]
> // ]
> // }
> var result = json.getByKeyPath("array[1].innerArray[5]?");
> // Equivalent to
> var result = json.getByKeyPath("array.[1].innerArray.[5]?");{code}
>
> The {{getByKeyPath}} method returns an Object, but the other types are
> available, too.
> The following types of keypaths should be supported:
> * {{JSONObject}} navigation, e.g. {{outer.inner -> "here"}}
> * {{JSONArray}} indices, e.g. {{array[0] -> 1}}
> * {{JSONArray}} indices without key, e.g. {{array.[0] -> 1}}
> * Optionality, e.g, {{outer.nonExistant? -> null}}
> The different types are combinable as needed.
> By default, the KeyPath is delimited by "." but there should also be a
> {{getByKeyPath(String getKeyPath, String delimiter)}} to support "." in JSON
> keys.
> I already have a proof-of-concept working. However, it requires some cleanup
> and a lot of testing before being ready.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
