And how to use the new code structure now for custom DB structure ?
In version prior to v1.13, the URL format is like:
/v1/category/:cid/product/: pid
It was initially a response to a member question that I made it that way.
Then I thought it is making more sense for general usage with the new structure (omitting the category id since the product id is already sufficient to refer to a particular record). Thus, in the new version, the format is just like this:
The DB structure has not changed.
What changed are the
SQL commands to
pass only the product id as parameter instead of both product and category ids.
The
SQL command keys also changed due to the same reason and instead I call it
ADD_XXX now renamed as
INSERT_XXX. Nothing special about this changes.
In this template, I demonstrated how we can build an API Server with 2 tables where a category table can be use to populate to a dropdown list or combo.
You can modify the commands inside
queries-sqlite.ini file with your table structure or schema.
If you don't like to use this setting file approach, you can also choose to create the db from the code module or class in B4X. I plan to use ORM class in my version 2. You can also pre-design your db using tools like SQLite DB Browser, Heidi, PhpMyAdmin, Adminer, SQL Server Management Studio, etc.
What files are to be edited excepting .ini-files ?
Files\*.html also ?
Inside the Objects folder, the only files need to be modified are INI files.
However, you will also find a www folder inside. Inside this folder, you will see an assets folder. Inside this assets folder, you will find css, img, js and webfonts. This folders will be set as public accessible in Main module.
srvr.StaticFilesFolder = File.Combine(File.DirApp, "www")
You may need to add more css or js files if you think required.
For example you want to change from Bootstrap to other Front-ends such as VueJS or MaterialCSS.
Inside the js folder, I have put webapisearch.js and this js is responsible for the search and CRUD functions of index page.
Open the Files folder and you will see 3 html files. You will see at the bottom where the js files are included.
</footer>
<script src="$ROOT_URL$/assets/js/jquery.min.js"></script>
<script src="$ROOT_URL$/assets/js/jquery.validate.min.js"></script>
<script src="$ROOT_URL$/assets/js/bootstrap.bundle.min.js"></script>
<script src="$ROOT_URL$/assets/js/webapisearch.js"></script>
@DOCSCRIPT@
</body>
</html>
In version 1.13, jquery.validate.min.js is added as this is how I validate the Bootstrap modal form.
You may need take time to study these 3 HTML files but I have make this files very minimalist and easy to understand (hopefully).
main.html => the basic structure or master page
index.html => the home page with search and new CRUD functions. So, in version 1.13, you will see added new lines marked with
<!-- Modal -->
help.html => the template with "collapsible" css class for generating the help file. The actual template is inside
HelpHandler class under
GenerateResponseScript sub.
The magic of auto generating the REST verbs is inside
ReadProjectFile sub.
The API logic are written in B4X code modules and handler classes.
For each parameter (that should have a separate table in DB) the separate handler is needed ?
B4J Server utilize Server handler/class which you can think like a Controller class in MVC and the routing is set in Main module.
srvr.AddHandler(ROOT_PATH & "topic/*", "DefaultHandler", False)
srvr.AddHandler(ROOT_PATH & "category/*", "CategoryHandler", False)
srvr.AddHandler(ROOT_PATH & "product/*", "ProductHandler", False)
srvr.AddHandler(ROOT_PATH & "find/*", "FindHandler", False)
You can have as many handler as you like. How you manage the handler class will determine how organize your code will be. Like in MVC, usually we use
Controller with common name as the
Model.
There is no rules.
In my template, I can follow the conventions. The URL like "
category/*" maps to the
CategoryHandler.
I purposely add a
DefaultHandler, which mapped by the path "
topic/*". This show, we can use whatever name we like.
in previous version, this is the case:
srvr.AddHandler(ROOT_PATH & "category/*", "ProductHandler", False)
Both category and product business logic and
model were handled in a
single handler class name
ProductHandler.
I believe we can map 2 or more paths to the same handler class but isn't this unorganized and make the single file so big and difficult to read or maintain?
Don' forget, sometimes we work with
joining multiple tables. This is demonstrated in FindHandler.
Not exactly. The SQL commands are actually loaded from the INI file. But what I want to say is, there is no rules saying that a handler must be use for only one db table. However it is a good practice to separate a "Model" into it's own handler. Just make your Handler name more meaningful.
Futhermore, the
DefaultHandler is not bind to any database table or model.
It just a very simple "Hello World" handler.
There are too many things I may not able to share in one post. Just ask if you have any further question.
I don't get it. Something related to "Migration"?
