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
Allow the Dynamic XML DS to support JSON #695
Comments
Personal opinions are listed:
Some other thoughts: While we're at it, could we add a 'Local File Datasource' too? Thinking on those lines, we should have just two datasource types, JSON or XML (and maybe CSV, the import/export extension is cool, but what about regularly changing files? It has been questioned on the forum recently) and then under these be able to choose the method of aquisition, being External, Local or Direct Input. |
Functionally, fetching from XML or JSON have two key differences: XML requires namespace declaration. JSON requires conversion to XML. Aside from that, the method in which data is fetched, cached and delivered to the frontend XML are the same. We could look at something similar to JIT recipes in which fetched data goes through a 'pipe' i.e. XML adds namespace declaration. JSON adds XML conversion. This way more 'pipes' can be added in the future should the need arise.
|
Thinking about it some more, I worry adding a piping mechanism is complicating things a little. Event has filters, JIT has recipes. Adding Remote DS with pipes seem like we've got too many different tertiary hooks to keep track of. I'm okay with the idea of having two separate DS types, |
I like the idea of two Datasource types as well, it's more explicit, makes instant sense to a user ('ah ha, JSON, I'll click that ') and it will be easier to manage, test and debug. While the ping and cache functionality is shared (or will be), I think there could be a neat way to make the code reusable instead of duplicating it. |
If this is planned for 2.3 (I really like the idea of having "Remote Datasources" that are capable to fetch JSON as well), shouldn't we have a more general look at the data source editor? There are already a few other issues posted regarding the DS editor and maybe 2.3 could really push a few things forward? |
Superb! I also like the concept of "Remote DS" :) Question: will there be a Static JSON DS type? |
I think there should be. XML and JSON are both widely available data format, and should be equally represented now and in the future for us. |
What would the use case be for static JSON DS though?
If a user needs a convenient or on-they-fly way to convert JSON to XML, then The |
Having two different DS types in the DS editor sounds good to me, too. How it's handled code-wise is another question. And "Remote DS" feels like a very good name. |
Ok. |
I thought that was the point of the Realign :) I plan to start work on this ASAP in another branch, at least sorting out the technical side of things anyway |
Well, we started on the premise "Only cosmetics!" ... When we start working on JSON integration we should also have a look at negation and filter options in general ("Field |
Am I missing something? I thought it was only cosmetics, as Nils said. ;) |
Changing the UI of the Datasource Editor is cosmetic, adding something like negation is not IMO. That's more a field's responsibility to implement the filtering, unless your taking about having a better selector instead of 'mode: {value}' in which I guess it's related. I should clarify what I meant too, I see the realign not as just a 'skin', but a collaborative effort to improve the UI and workflow in general, things like breadcrumbs, active navigation states, save and return, implementing something like EDUI etc. Applying a new skin only seems superfluous to me as users can do that already with the Admin Override CSS extension, and I feel we need to push Symphony forward to be more intuitive so it's users will love it even more :D That said, we've gotta be careful not to put too much work on ourselves, we are spread pretty thin as it is and 2.3 must ship before Christmas, so careful planning and scope is the key! |
http://goessner.net/articles/JsonPath/ interesting, wonder if we try to support this instead of converting to XML? edit: looks meh on closer inspection |
Not sure how supporting JSON selectors could work, but see also JSONSelect if you're interested. |
Just the idea of not converting the JSON to XML from the get go. The jsonpath would allow the dev to set the included elements, then the result of that would be converted. You're right though, it doesn't add a whole lot. |
I don't think something like this should be added until it's really standadised or at least has become an inofficial standard throughout the business. |
Summary of where we are at:
Few things to note:
Or if you'd prefer to see it for yourself, this gist shows a sample Twitter feed being consumed. |
@brendo: The json2xml class seems rather advanced, so I will test it in an extension I am building. That's why I thought it might be good idea to put this class in Symphony's toolkit folder (so extensions are "invited" to use it). What do you think? |
Maybe one might even build two new helper classes, |
The above commit:
|
Aha! The code is moved from the core to an extension. God I hate to be on the cutting edge.. |
:o) |
A lot, a lot, of API's these days expose their API as JSON, not XML (or in addition too). Symphony needs to keep with the times, so it should be able to read JSON just as it was XML. JSON, thankfully, has a strict syntax and there is a couple of classes floating around the forums (and the net) about transforming JSON to XML, so I don't think this would be too difficult to implement.
To be clear, the JSON would be read in and transformed to XML for use in XSLT.
Things to that need to be decided:
/cc @nickdunn @allen @rowan-lewis @creativedutchmen @eKoEs @nilshoerrmann @czheng
The text was updated successfully, but these errors were encountered: