It's now time to analyze the solution. We do not yet know very well (joke), but when I see a code or an architecture, I used to have a critical eye over. I confess that it is the same for the code I produce. So, here are my thoughts about the developed solution:
-
Deploying MySQL ODBC driver may be acceptable for an small intranet solution but is not acceptable for a full web compliant environment.
-
The direct use of a database from a Web Plugin may be dangerous for the database server since it forces administrators to openthe firewall for a specific port. That's unsecure and it's not the state of the art even if we place the database server in a DMZ. So we should use secured Web Services or Rest Services, i.e. on a standard protocol (http or https). this is what is called a Service-Oriented Architecture (SOA).
-
It will be better to only store the url of the services layer on http instead of a connection string. Url that can be set by the http server that manages the Web Page including the web plugin tag object.
-
I use the root account to access the catalog that I use to store my information. It's dangerous from a security point of view. We should use a dedicated account with less privileges.
-
You'll notice in my script, I hard stored the culture to format the price. On the other hand, we should not make this as a dynamic part since in my database I store Euros and not Dollars. And with the price of the dollar right now, it won't be interesting, except if we manage changes according to the user culture.
-
If you take a look at the database schema, you will notice it is simplistic. Indeed, products may have more data such as categories, keywords, etc. and we should use an integer as a primary key to perform powerful tables joins.
-
The last thing is the way to load once all data from database. What happens if data change in the database after web Plugin loading? Well, nothing in fact because data are not collected when the user interaction is executed.
-
Last but not least, the Web Plugin had to be updated to reference the missing "System.Data.dll" assembly to access "System.Data.Odbc" namespace. This update will be available soon with Nova Explorer auto-update.
Well, you are going to tell me that I coded with my feets ;-). In fact I responded directly to a need that I have been asked for. Moreover, any script may always be improved with time. I develop this solution in a couple of hours (in fact 3 hours). This partly explains it... Now I will attach myself to do things in the rules of art, anyway, as I believe they should be :-)
So in my next post I will show you how to develop a REST Architecture to expose my data and to consume it in a Nova script.
See you soon!