This is with reference to this question where I got one tabular report format.
I need to update the user entered values correctly back to the same table rows. I am in the process of doing this by using general form post data methods by using some logics which I think will not be easy to maintain. So, just out of curiosity, Is there a front end creator javascript libraries or frameworks which can create the front end for any query's resultset and updates the corresponding rows when the user updates them from front end. This need not have all the full functionality, any one usable, customizable thing will reduce the code maintenance problems. I have googled for some javascript libraris for this but not able to get which will be suitable. Please suggest any useful tools. My environment is Mysql, PHP, JQuery, XAMPP server on Windows. Is JQuery provides one.
Thanks in advance.
"...from any query's resultset..." I suspect there is no tool that can do that. Imagine a resultset of data from a table with one (or more) columns which has a foreign key to another table(s). A tool would need to find the relationship between the tables, update the "lookup table", and then update the dependent table. Now imagine a more complicated resultset from a variety of tables - maybe some of those tables are views. Tall order...
I use phpMyAdmin to update tables in my schema, but I perform these updates as an admin rather than a user.
I dont know the nature of the app nor do i know of any JS libraries with this type of functionality. I think i would look at PHP libraries/components as opposed to JS. For example Symfony could lend you this functionality through the use of its admin generator features. While converting something youre well along on to Symfony for the sake of admin generation probably isnt the best idea, i think youre bound to find alo tmore resources on the server side than the client side. :-)
Related
I have to display products which are stored in an ERP on a webpage. The ERP can produce an XML or JSON file which would include all products. The webpage needs functions like pagination, sorting or filtering by attributes. At the moment I think the easiest way would be to just load the entire file in AngularJS and then iterate over all items and work with that. The number of products is limited to ~500. The reason why I think this is the easiest is because the client changes the information on a daily basis in this way I don't have to write an import / synchronization process for a database.
But I am a bit worried about performance. Sorting, filtering, pagination etc. are all things that would be very fast with a database (probably MongoDB since the datastructure is quite simple).
Can I expect serious performance problems? Is this doable? Or should I put a database between ERP and frontend that does the heavy lifting?
The only way to be sure is to test it out yourself, that is what I would do. The answer is very often, "it depends.. ". You say its around ~500 products, if each product only has a product name, then a database would be overkill. Angular is perfectly comfortable with that amount. But if each product got tons of properties and nested data, the file itself could be very large to even load on every pageload. So, it depends..
I would to this:
Export the file from the ERP as JSON
Create a boilerplate angular app
Put the JSON file as a resource file
Create a simple repeater and throw those objects out into the DOM
Now you can easily experiment with filtering, sorting, pagination and so on. Test if the browser perfomance and load time is what you are looking for.
I think there will be no performance problem on data transfer since there are only 500 elements in the JSON file. But maybe you'll experiment performance problems in showing those 500 elements with AngularJS.
Instead of pagination, you can checkout 'Infinite Scroll' with AngularJS, a good solution for result showing performance. Check this article: http://www.williambrownstreet.net/blog/2013/07/angularjs-my-solution-to-the-ng-repeat-performance-problem/
And no, I don't agree having a database in the middle. You are trying to use it as a cache, but you'll have more problems than solutions, because since you have only 500 elements, you would not gain performance at all. And another added problem: database maintenance ;)
Cheers
I don't know much about databases, I've been asking a few questions about them lately to get a better understanding but I'm still a bit confused about what does and doesn't need one.
I'm making a simple application using HTML/CSS/JavaScript, it has a few quizzes and "tutorials" targeted towards children. I don't want the next tutorial/quiz to be unlocked until the previous one is completed.
So for that would I need a database so that it "saves" when one is completed? I don't need to save scores or anything like that, they just get to move on once they get a passing score.
Any other requirements such as saving to a profile or needing to persist between sessions (e.g. changing of device)?
Browsers have localStorage APIs now which allow you to save a lot of the data (and keep it for a set duration of time). There are also good'ol'fashioned cookies which allow you save pieces of information as well.
Keep in mind that both of the above mandate the user use the same browser and allow these mechanisms. Obviously using "private"/"incognito" browsing would also affect saving status.
It's up to what you feel the requirements are.
EDIT Just saw your mention of a mobile app. If you're planning on allowing the experience to transcend devices, you'll need a database. otherwise, you'll be relying heavily on if they use cross-device sync (like Chrome and Firefox do with bookmarks, passwords, etc.)
If you don't mind that people can do a "view source" on the webpage or use every browsers' developer tools to find out the answers or move on to the next tutorial or quiz, then you can use cookies to store the user's status. Or you can use the preferable Web Storage API.
You might want to look at Firebase. Using just simple JavaScript on the web browser, you can have users with logins (or just allow them to login via Facebook or other services) very easily. And then you can store and retrieve data very easily as well, like quizzes, tutorials and results. This way nobody can see the answers even if they're adept at analyzing the webpage.
When you don't use database, before any check, you have to load all data in your static page.
So My sloution: store students situation in a cookie. On each page check cookie status and then use Jquery remove() to remove (Client-side) those parts of page that he/she can not access.
EDIT
This wont work when JavaScript is disabled.
There seems to be a lot of ideas but no clarifying on the database subject.
TL;DR is: No.
Now for the specifics. A database is nothing more than a way to store information. While traditional "SQL" databases (it is pronounced "Sequel" as in "My Sequel" for MySQL) have concepts of tables, where you define columns with items to store and saves each row with its value, much like an Excel file, some databases like Redis store key-value pairs and others lide MongoDB store JavaScript Objects.
You can store information in the source code (As Variables possibly) or in a file. A database is a way to organize that information.
With that said, in your case, you probably need a backend or an API. An API is basically a means of communication with a server through AJAX (JavaScript in the browser asks for stuff). That would be your way to retrieve information from the server as needed, so that users wouldn't see the answers before they answer.
With that out of the way, there are some options. FireBase (As noted on other answer) and AppBase are easy ways to integrate this concept with little effort. But they tie you and your information to their system, and they are mostly targeting more resource intensive apps.
Since you are using JS and seem to be enjoying your learning experience, I would suggest you consider suing NodeJS and defining the data as either a JSON file or a variable in JS. You keep working on your problem but add options and get to learn some stuff.
If you decide to integrate a database and possibly do some neat stuff, you have most of the groundwork done already.
If NodeJS picks your interest, Mean.IO and KrakenJS are, in my opinion, the best places to start, though they may both seem overkill in your specific case.
Do consider though: A database is just a small possible piece in a puzzle, and it's mostly a horrible way to name some of the software that tries to organize your information. Consider first if you need to organize information, and what and how do you need to organize, then start thinking if databases are the best way to organize it.
I've googled this loads and am sure there is an obvious way that I'm missing, but..does anyone know how to approach rendering example source code that is kept in a noSql database?
I am writing a javaScript blog site and want to show example code rendered from backbone templates whose models are populated from a mongoDB database.
Most of the google results offer a variety of syntax highlighting pulg-ins, but how would I format the code to preserve indentation etc as the code will be flat in a JSON object.
I'm thinking tables may be a key but I'm unsure if I'm reinventing the wheel here.
As always, any help would be greatly appreciated. Thanks in advance.
Strings in MongoDB can store any special characters like line-breaks, tabs or multiple spaces. When you store some program sourcecode as a string in a document, it should look the same when you retrieve the document.
Well you'll need something to access the database and returns back that to the backbone.js client.
You can use a Node.JS server with the MongoDB Driver if you prefer javascript.
You may want to try some node.js packages such as Express and Mongoose.
If this is a small project, just to learn how everything works, that's ok. Otherwise you might want to consider looking into how to display only the Blog Text by backbone.js, and separating the View from the Data. So if you want to change the CSS or they style of the blog you don't need to update (every single blog post document on mongo)
I apologize if this question is not specific enough, but I do need some help understanding this concept. I've been researching many Javascript libraries including JQuery, MooTools, Backbone, Underscore, Handlebars, Mustache, etc - also Node.js and Meteor (I know all those serve different purposes). I have a basic idea of what each does, but my question is mainly focused on the templating libraries.
I think the general idea is that the template will be filled by a JSON object that's retrieved from the server. However, i'm confused by how that JSON object is formed, and if it can go the other way to the backend to update the database. Please correct me if this is incorrect.
For a more solid example, let's say I have Apache running on Linux, and am using MongoDB as the database and python as my primary language. How do all these components interact with the templating library and each other?
For example, if I have an HTML file with a form in it and the action will be set to some python script; will that script have to retrieve the fields, validate them, and then update them in the DB? If it's MySQL I'd have to write a SQL statement to update it, but with Mongo wouldn't it be different/easier since it's BSON/JSON based?
And for the other example, let's say I have a view-account.html page that will need to pull up user information from the DB, in what form will it pull the information out and how will it fill it into the template? I'm guessing i'd have to have a python script that pulls the information from the DB, create a JSON object, and use it to populate the fields in the html template.
I am aware there are web frameworks that will ease this process, and please suggest any that you would recommend; however, I'm really interested in understanding the concepts of how these components interact.
Thanks!!
There are obviously many ways this can all work together, but it sounds like you have the (a) right idea. Generally the frontend deals with JSON, and the server provides JSON. What's consuming or providing those responses is irrelevant; you shouldn't need to worry that Mongo is your database, or that underscore is handling your templates.
Think of your frontend and backend as two totally separate applications (this is pretty much true). Ignore the fact that your frontend code and templates are probably delivered from the same machine that's handling the backend. Your backend is in the business of persisting data, and your frontend in the business of displaying it.
RE: Mongo using JSON/BSON; The fact it uses the same language as your frontend to communicate is a red herring. Your DB layer should abstract this away anyway, so you're just using Python dicts/tuples/etc to talk to the database.
I'm guessing i'd have to have a python script that pulls the information from the DB, create a JSON object, and use it to populate the fields in the html template.
Spot on :)
I'm working on a project and there is some battle between how some JS filtering should be implemented and I would like to ask you guys some input on this.
Today we have this site that displays a long list of repeated entries of data and some JS filtering would be nice for the users to navigate through. The usual stuff: keyword, order, date, price, etc. The question is not the use of JS, which is obvious, but the origin of the data. One person defends that the HTML itself should be used and that the JS should parse through it making the user's desired filtering. Another person defends that we should use a JSON generated in the server, and that JSON should be the data's origin.
What you guys think on this? What are the pros and cons?
As a final request, I would like you to be the most informative as possible since your answers will be used and referenced for all us in the company. (Yes, that is how we trust you!:)
The right action is matter of taste and system architecture as well as utility.
I would go with dynamically generated pages with JS and JSON -- These days I think you can safely assume that most browsers has Javascript enabled -- however you may need to make provisions for crawler (GoogleBot, Bing, Ask etc) as they may not fully execute all JS and hence may not index the page if you do figure out some kind of exception for supporting those.
Using JS+JSON also means that you make your code work so that support for mobile diveces is done client side, without the webserver having to create anything special.
Doing DOM manipulation as the alternative would not be my best friend, as the logic of the page control and layout is split-up in two places -- partly in the View controller on the webserver, and partly in the JavaScript -- it is in my opinion better to have it in one place and have the view controller only generate JSON and server the root pages etc.
However this is a matter of taste, and im not sure that I would be able to say that there is one correct and best solution.
I think it's a lot cleaner if the data is delivered in JSON and then the presentation HTML or view of that data is generated from that JSON with javascript.
This fits the more classic style of keeping core data structures separate from views. In this manner you can generate all types of views without having to constantly munge/revise the way you store, access and manipulate the data. You can even build classes and methods to develop a clean interface on your data that is entirely independent of how that data is displayed.
The only issue I see with that is if the browser doesn't support javascript and that browser is a desired viewer. In that case, you have to include a default HTML version from the server that will obviously not be manipulated and the JSON will be ignored.
The middle ground is that you include both JSON and the "default", initial HTML view of that data in rendered HTML. The view comes up quickly and non-JS browsers can see something useful. But, then any future manipulation of the view (sorting, for example) uses the JSON data and generates a new clean view from the JSON data. No data is then ever "parsed" from the HTML view.
In larger projects, this also can facilitate the separation of presentation from data manipulation so different people may work on creating HTML views vs. manipulate the data (like sorting).
I would make the multiple ajax calls to the server and have it return the sorted/filtered data. If you server backend is fast than it won't be very taxing and you could even cache the data between requests.
If you only have 50-100 items than it would be reasonable to send it all to the client and have javascript sort and filter it.
Some considerations to help make the decision
Is the information sensitive and unique? (this voids and benefit to caching in my first point)
What is the most common request that will happen and are you optimizing for that?
How much data is there? (tens of rows, hundreds, thousands, millions)?
Does you site have to work with JavaScript turned off? (supporting older browsers?)
Is your development team more comfortable doing this in the front-end or back-end?
The answer is that it depends on your situation.