We are moving more and more to restful resources and have found it a little painful in the data formatting sense. Dates for example come back in nasty full format and then require javascript or other code to do the formatting.
Relationships either aren't included or come back as id's unless you alter the as_json defaults to include the relationships. My initial thought is to flatten the data by duplicating it on the table row but that doesn't work well for has_many.
Are there any articles or podcasts that cover the "right" way to approach this?
Your presentation layer should format values for display - you should store your data in the most neutral format possible. The display of data is a concern of your UI - by formatting the data there you are allowing for multiple different UIs that could format the data different ways.
A good approach for me was to move the format of rendered JSON data to the view layer, using the rabl gem.
It allows to write templates that describe how your JSON data is rendered, selecting which attributes and associations you want to include, along with nice other functions: partials, custom nodes, template inheritance, etc.
Related
I have an interesting situation where I'm working with posts. I don't know how the user will want to structure the posts. It would either be one block of text, or structured in an a-> b -> c structure where a, b, and c are all text blocks, and if represented as a table, there would be an unknown number of columns and unknown number of rows.
Outside of the post data, there is the possibility of adding custom attributes to the post. Most of these would be shorter text strings, but an unknown number of them.
Understanding that a json object would probably be the simplest solution, I have to fit this into a self-serving db. SQLite seems to be the current accepted solution for Redwoodjs, the framework I'm building out of. How would I go about storing this kind of data within Redwoodjs using the prisma.js that it comes with?
Edit: The text blocks need to be separate when displaying the post and able to be referenced separately. There is another part of the project that will link to each text block specifically. The user would be choosing how many columns there are before entering any posts (configured in settings), but the rows would have to be updated dynamically. Closest example I can think of is like a test management software where you have precondition, execution steps, and expected results across the top for columns, and each additional step is a row.
Well, there are two routes that you could take. If possible use a NoSQL database, such as mongoDB, which Prisma has support for. There you would be able to create a JSON like structure with as many or as little paragraphs you would like.
If that is not possible a workaround, since SQLite does not support JSON data, you could store the stringified JSON data in a text field, and then parse it. This is not the optimal solution, so if possible use the first one.
I have a MySQL database and retrieve data using php on a website where I would like to visualize the data in different ways. For this I also need to transform the data (e.g. creating sums, filtering etc.).
My question is now at which step of the data flow this kind of transformation makes most sense, especially regarding performance and flexibility. I am not a very experienced programmer, but I think these are the options I have:
1.) Prepare views in the database which are already providing the desired transformed data.
2.) Use a PHP script that SELECT's the data in the transformed way.
3.) Just have a SELECT * FROM table statement in PHP and load everything in a json, read it in js and transform the data to a desired version.
What is best practice to transform the data?
It all depends in the architectural design of your application.
At this time SOA (Service Oriented Architecture) is a very used approach. If you use It, logic use to be in the services. Database is used as a data repository, and UI manage final data in light weight format, only really needed information.
So in this case, e.g. your option number 2 is most appropriated.
I am getting a list of items in a JSON(through AJAX) and creating the required markup by JS and appending in the view. On the other hand I have seen few examples which do not use this practice, and send the complete or partially complete markup through AJAX and then simply append them to the document. So definitely the markup is being generated on the server.
So I am curious which one is the better approach and why. One thing I can clearly see is that the later approach does not expose the JSON structure to the UI.
You're right about exposing the json structure but perhaps the main thing to consider is loading times, both client side and server side. If the server is dedicated and powerful enough, generating the markup in the server will be fast and will keep the site snappy on the client side.
If not, you'll want the client to do as much of the processing as possible. Generating markup on the client side is not a bad thing. The popukar angularjs framework builds markup on the fly client side and is very effective.
The choice depends on several factors like
what we are trying to achieve - Requirement must be picture clear.
what is the amount of work involved with these choices alone
which choice will have better performance
and in few scenarios which choice will get the job done quick. - where performance is compromised over delivery
Lets take an example to explain better.
1) Create a table to display all the details of employee.
Here since this is a stand alone table we don't have to worry about passing a JSON and then writing logic inside the JS to build the table. This can be done quickly without the need of JS. -- HTML Wins
2) Create a table to display all the details of employee. Also build a dynamic bar graph to display the details of the employee group on click of any row in the table.
Here the scenario is to build a table also on click of any table row get the employee group and generate a bar graph to show total employees in that group or may be any other stuff.
Here if we have built out table with just HTML then to get the data for the bar graph either we need to make another server call OR do a for loop of all tr's and then extract data from each cell by cell which is a pain.
If you use JSON to dynamically build the table structure, We can use the same JSON data and then build the graph and quick without other overhead, As we have the data ready to manipulate. -- JSON wins
This is just a small example. Also this concept is totally debatable, it is choice of the developer and what he is comfortable with, along with few other factors as mentioned above. I think you get the big picture. Hope this is helpful.
I'm trying to make pull XML or Csv data into a HTML file then I want to use math to add up the values and show the result on the page ( I'm basically trying to display invoices on a web browser)
My skill set is HTML/CSS and I understand a little JavaScript
I've managed to pull XML data into HTML using http request and style that information using xslt
Really what I'm asking is what is the best solution to my needs is it using the above method then using xquiry to add up values or would I need to learn a bit of Ajax, Json and calculate the values with JavaScript?
You really should learn AJAX in order to fetch and manipulate data instead of fetching presentation parts. That's the way everyone follows as it allows more responsive interactions with the user and a cleaner architecture in case of complex interactions.
But that doesn't mean you must abandon XML : originally AJAX was built on XML (the X in AJAX) and not JSON.
Personally I prefer JSON, and I think it will be easier to manage in the long term, but if the server side is hard to change, you can fetch the XML (look for example at jquery's ajax function), build javascript objects using it, and then change your screen using those data. If later you decide to use JSON instead of XML, you'll just have to change the "parsing" part of the client code.
"I'm trying to make pull XML or Csv data into a HTML file then I want to use math to add up the values and show the result on the page"
You can do this with either XSLT or javascript. However, with XSLT things can become pretty complicated, depending on what version you're using. XSLT 1.0 has pretty limited set of functions for aggregating results. For all XSLT, you can't reassign variables you'll have to solve many of these things with recursion. In my opinion, not really a comfortable method.
Regardless of the choice between XSLT and Javascript, I would also question the architecture that would put this kind of logic in the presentation layer in the browser. I think it would be better if the server side would perform all the calculations that are required, and limit the browser's tasks to styling the output.
I'm designing an interface to display sets of data. I'm interested in organizing the information in a customized format using DIVs and SPANs to identify where specific data will be (not in the typical row-by-row format tables provide) but still having the flexibility of sorting and organizing the data that most JS libraries provide for tables. Is there a way to get the best of both worlds without rolling my own solution?
I want to sort the data on the fly using JS. I don't want to do crazy sorting... tasks like "group by type", Alphabetize, Sort Date, Ascending/Descending, etc. I know I could presort and display on the backend but I want to reduce server load and wish to keep unnecessary computations off the server. If there's a way to sort and organize on the client side, that would be best. My preference is to work with PHP on the backend and using the jQuery lib on the frontend. I'm also using mySQL if that helps.
It seems like you want the TinySort plugin.
TinySort will sort any nodetype by
it’s text- or attribute value, or by
that of one of it’s children.
Here's the documentation.