Why tour HTML-to-DB II?
Welcome back to the tour and this is the part II.
E-shop Tour Example 1 (html) -- visit the page
E-shop Tour Example 2 (json) -- visit the page
E-shop Tour Example 4 (db) -- visit the page
E-shop Tour Example 5 (Fields4Entry) -- visit the page
If you followed the Part I of the tour (Movie Examples), there is not much to elaborate here, other than us pointing out that last three examples (Pagination, DB, Fields4Entry) look exactly identical purposely. We need to move on the technical and practical aspects of utilizing JSON, DB or Fields4Entry in order to conclude the tour.
Fields4Entry Practice: Entering Catalog -- visit the page
Instead of explaining Fields4Entry further, let's touch it first. Here you see a practice session for Fields4Entry bulk data entry. This is a "bulk" data entry screen for the busy (or impatient) business persons. Go there, hit the large "+" button many times. It will create as many new records as you want. Then, in any order, you type in the data which your users eventually get to see from your HTML pages. Probably you won't like the initial order of the records showing up. Hit "Up" arrow or "Down" Arrow to re-arrange them to your satisfaction.
Then there are buttons for your transferring the entered data back and forth between DocuComm, your computer and your server (i.e save, export, import). Why? We will explain two sections below.
Fields4Entry Practice: Entering Bookmarks -- visit the page
The second practice. Your are entering custom bookmarks for your utmost personalized web navigation experiences. All the bookmarks used by ohmyabc.com and docucomm.com were entered this way also.
Fields4Entry Daily: Entering Custom Data -- visit the page
Several topics to touch upon.
First day - Too long But Need To Read
Fields4Entry can be an extremely efficient solution for creating custom data bases without back-end developers' help. But users need to be aware, since Field4Entry is different from following Custom Fields/Custom Form Solutions
Different from CMS-based Custom Fields
"Custom Fields" is a powerful concept which allows CMS users of Drupal and WordPress to define, create and modify their custom data bases without getting back-end DB programmers. But the learning curves (specially for Drupal's Custom Fields) are famously steep.
Different from Cloud-based Custom Form/Custom Application Builders
While bypassing the steep learning curves of Custom Fields, many DP/DB projects can be downsized or completely replaced by cloud based "Custom Form" services. Examples include Zoho-creator, Knack, Quickbase and Filemaker. They are truly wonderful/cost-saving solutions. But you need to be prepared to pay per each transaction.
Yes finally, Fields4Entry
You are accessing our data base services at no cost for building your custom data bases. However, you need to export your data into your computer/server for processing them via AJAX calls instead of data base APIs, which can significantly downsize your development effort. Probably you won't need a programmer after the initial stage.
Fields4Entry .. Everyday Usage & Checkout Procedures
These are the procedures needed to connect your HTML programs to the resulting JSON files.
You need a Token or Tokens, Why?
Instead of requiring you to register with us or pay us, we will provide you a token or tokens. One token per one of your custom data bases. If you have multiple data bases to manage, you need one unique token for each one. A token has usually 6 case-sensitive characters or less.
You need to export your JSON file after data entry
When you finish the data entry periodically, you need to move your data into your computer or server or hosting services. There are no automatic connections between our server and your server(s). If you desire such tight/automatic coupling, we recommend you to use the above-listed "Custom Form" services and pay for each transaction.
Make sure your HTML programs can handle AJAX calls
This is a fairly simple procedure for you or your helper. Still if you need an assistance, there are many free-lancing developers whom you can locate via Fiverr, Craiglist or Yelp.
Sometimes you need to import back JSON files
Once you export JSON files and use them daily, you have already backed-up them safely! If you lose your token or lose your data in your browser cache, no sweat, you need to import back your JSON file(s) into your working area and restart.
Why tour HTML-to-DB? Why did we do it?
We are near the end of the tour. But not 100% yet. We gave the tour to the non-programming audiences, but to important decision-maker types. We were intending to drive home the following points. If they were not made clear, our apologies.
Typical web project size is mostly determined by where your store your contents and user data. The project size grows exponentially just based on "where".
HTML is the great starting point, where initial excitements, final magics, on-going pains and eventual choking points will co-habit.
In-house DB is the most natural no-compromise destination for large projects and larger firms.
In-between, there are numerous compromises. If you are a blogger or small publisher, you would use WordPress to store your posts.
If you are larger than the typical WordPress users and have more diverse custom contents, you would use Drupal, for which I will assume you will hire programming staff. You will store posts, articles, corporate news, product news, merchandises, administrative records and so-called custom contents there. Drupal's usage of custom fields make this possible. You can even run a presidential campaign with Drupal.
If you have to do without programming staff, you need to figure out how WordPress customer fields work. Google with "custom fields" and see what happens. It should work also.
You have a substantial budget but you are risk-averse, you would use ever-becoming-popular and wonderful cloud services like Zoho creator, Knack, Quickbase and Filemaker. Google with "Zoho creator vs" and see what happens. But be prepared to pay per transaction.
Build like us or Build with us?
There is no need to hire us for custom programming. We hope here are sufficient reading materials and content entry screens for readers' benefit.
Knowing how time-consuming a typical DB programming project would be, we will not ask you to hire us for back-end programming tasks. The greatest premise of initial "Custom Fields" concept is to define, create and maintain custom data bases via front-end-driven solutions. A lot of companies believe in this premise and came out with their solutions, as listed above.
Still if you think Field4Entry is the only and most-fitting interim solution until you hire your first DB programmer, we will either modify our screens, create custom screens, or manage data entry tasks for you by accepting only the narrowly-defined service requests sent to firstname.lastname@example.org. Remember there is never a charge for programming. Our fees are based on pre-agreed-upon results and management guidance.
Referenced Sources for Right-sizing E-Commerce or Content-Entry Projects