After creating some collection entries in Squarespace (like Blogs, Events, Products and so on..), is it possible to access the single databases with a MySql management application?
Or is it possible to create a private MySql database and force Squarespace to use it for the collection?
I would be easier to add/edit large data..
Squarespace is very much a "design-first" platform, and the data structure (or at least, the data structure as we can access it) is heavily abstracted away in the name of a simple design process. Getting data in can indeed be difficult, and getting it out even more so. It's just not a platform friendly to data management or portability.
Furthermore, you cannot run server-side code. So unless you fetch, parse and display your date entirely client-side using JavaScript (bypassing Squrespace's collections/layout entirely), the only way to serve the data to users is to first enter it via Squarespace's back-end editing UI. Custom tools have been created that, for example, add a button in the backend editing UI that allows you to manually sync collection items/data with an external source. It basically reads your source, maps the data to the collection item creation API that the backend UI itself uses, then executes until all collection items have been added in the back-end. However, this process must be manually trigered, and continually done as needed by logging into the backend, running the syncing function, then waiting for it to finish.
Related
this is probably something i could have googled; however i thought id start getting more active on chat forums so basically...
I'm almost done with making a family members business website, on the website is an enquiry form; i want to know how i go making that form store the data its given and how i would then retrieve that data?
still doing final touches to the design then im going to start learning the process of deploying it live which is why im posting here to see how to go about it.
It is very vast question, You will need an API to pass the data from Forms to API Server and a Database, that will store the data. It is also called client-server architecture.
Web Forms -> API Server -> Database
You can use either node express, java, python or any language to create API.
You can install the database on the server where you will run the API or you can use any from the cloud like AWS or Heroku, that way you will skip some setups and it will be ready to be used directly in the API.
To store data from an HTML form, you will need a server-side language and a database to save the data to. Some popular options for the server-side language include PHP, Java, and Python.
Once you have chosen a server-side language, you can use it to write code that will process the form data when the form is submitted. This typically involves connecting to a database, creating a table to store the data in, and then inserting the form data into the table.
To retrieve the data from the database, you will need to use a SQL query to fetch the data from the table. You can then use the server-side language to display the data on the website as needed.
It's a good idea to also consider security when handling form data. Make sure to validate and sanitize the form data to prevent any potential security vulnerabilities.
Can someone explain to me why you can't connect to a MySQL DB directly through dart from a security point of view?
There is no hard guideline on whether to connect frontend directly to backend or not. It is just a design practice that has been widely accepted and evolved over many years.
Typical app structure consists of
FRONTEND -> SOME MIDDLE LAYER -> BACKEND
Where your middle layer handles all the interactions/processing with the database and the frontend uses this functionality with some sort of API structure. Having this layer is extremely helpful when the application goes to scale, it gives an added abstraction to the frontend.
It is not advisable to directly fuse your frontend(your flutter app), to the DB(MySQL) because any efficient hacker might use basic man-in-middle attack to know your DB structure/connections/queries(There are some pretty effective decompilers present out there), and alter your data and you might not even get to know what caused the data to update unless you've applied some checks on DB layer.
Also, your frontend logic needs to be more of end-user centric than to handle the data of the user. Any backend system(java, node, etc) gives you added functionality & freedom to parse and present the data from either side.
You can use the sqlite package available to store basic data, like your session tokens, your app configurations etc, but it is advisable to keep the main user data like the logins, etc in a separate place, or better yet, you can use the firebase plugin to store data in document structure in the cloud.
Basically I need to connect a MySql database to an IOS application and save a local copy to the device but i'm confused about which path I should take to do this.
Here is a basic description of the application:
The application is used to replace multiple paper based forms, allowing the user to complete a desired form on an iPad. Once the user has completed the form, the forms data is uploaded to a server.
Some forms have fields where the user is required to 'select' an option (drop down list). These options need to be pulled from a database because the options will be changed regularly.
The application still needs to work if there is no internet connection!
This means that whenever there is a connection the application needs to save a copy of the current database so that any required information to fill out forms is still available even if there is no connection.
In short my question is: What is my best option to save a local copy of a database (or just a few tables) to an IOS application?
You should look into Core Data. If you're trying to keep an updated copy of a couple tables, I would create a Core Data database that contains the information you need for your app and, every time the user uses your app, check to see if there's an internet connection. If there is, use NSURLSession to download the necessary data from the web server, after which you can compare the downloaded data to that which is in your Core Data database. If there are any discrepancies between the two, you can update your Core Data database as needed. This way you will always have a relatively up-to-date copy of your MySQL database.
This is a good tutorial for getting a feel for NSURLSession in case you haven't used it much.
Hope it helps!
So I have this fileMakerPro7 database. As my senior project, I supposed to migrate the database to a MySQL database and than give it a PHP Based interface in 3N form...
Company allow us $200 tops to spend on the project, but if I pay for something, it has to work. However, I am having trouble finding a way of migrating the database. Any suggestions?
I have found "file maker pro migrator" (http://www.fmpromigrator.com), would the trial version be enough for us? In worst case, we will start from the beginning with throwing away the whole database that company has.
I can also download fileMakerPro12 and use it for a month with trial version for free. Would I be able to convert the db by using FMP12?
I am totally lost...open to any free suggestions...
+this is a non-profit-making company I'm doing the project for
If I had to do it, I'd look at the design of the FileMaker db and create something similar in mysql. Then I would export the Filemaker data to text and import it somehow. The details depend on foreign key values and such.
The PHP interface would be done separately.
MySQL Data Conversion:
Yes, if your database is small enough, the demo version of FmPro Migrator will convert the database and also build you a PHP web application - at no cost.
Here are the limitations of the demo version:
5 fields
5 scripts
5 layouts
PHP Web Application:
Most people don't realize it, but there is a wealth of FileMaker metadata available in XML format for performing these types of conversions. This XML info is available either thru copying the layout via the clipboard or reading it from the Database Design Report XML file. I have found the clipboard data to be the most reliable source of this info.
FmPro Migrator is able to parse in the XML and convert it into the PHP web application.
Each object on a layout is represented in XML, along with style and position info. This info can be used to create form files representing the same look as the original layout. In fact, it can be difficult to see the difference between the web application and the original database if you get all of the object properties implemented. This can be helpful for situations in which companies don't want to have to retrain their employees. They want the web application to look and work the same as the original desktop application.
I have done a few of these conversions recently into the CakePHP framework. Here a few techniques I used:
Auto-Enter Calculation Fields - Stored calculation fields are calculated and stored within the model saves a record to the database.
Unstored Calculation Fields - Unstored Calculation fields are calculated in real-time within the form controller - but only for fields actually displayed on the form. This prevents unnecessarily calculating these values if they aren't being used on a form, improving performance.
Global Fields - A Global field in FileMaker is used like a global variable in programming languages. It is important to know that each FileMaker user gets there own private copy of global field data. There is no equivalent feature MySQL or other SQL database servers, but this functionality can easily be simulated using SESSION variables. Therefore each web user will still get their own private SESSION data, simulating the same functionality originally present in the FileMaker database. I structure these globals in the model data array as if they were retrieved from the model, meaning that converted scripts and fields on forms can reference them easily. Just before the record gets written into the database, the results are saved into SESSION variables for persistence.
Global Variables in Scripts - Global variables within FileMaker scripts match up very well with the use of PHP SESSION variables, if you want to implement the same functionality.
Vector Graphic Objects - FileMaker layouts frequently include rectangles, ovals and line objects. These objects can be replaced with the RafaelJS library, providing high quality resolution independent graphics.
Value Lists - Custom and Field based value lists are implemented in a centralized location within the AppController.php file. Therefore making a change to the definition of the value list within the AppController, succeeds in changing the menu automatically throughout the whole application.
I'm currently in the planning phase of a rather large project that I'll develop in the Zend Framework. One of the problems I'm facing is that the customers will want to translate not only the content but also the interface. I'm currently using gettext and poedit to manage my language files but this is not an option for the customer as they, for one, wont have FTP access to the site.
Hence, I'm thinking of a mysql back end with an interface in the front end for the customer to manage his own translations of the interface. There is however still no mysql adapater for Zend_Translate.
So, does anybody now of an adapter script for Zend_Translate so it can work with a mysql table? Or any arguments against using mysql and possible other solutions for this problem?
You could solve this problem on different ways:
Extend Zend_Translate_Adapter to create your own. All new adapters are only responsible from getting the translations out from the source. That is, you would need only to fetch the translations from the database. Look at other adapters and see how they are implemented.
Fetch the data from the database and pass it to Zend_Translate_Adapter_Array
Use Zend_Translate_Adapter_Csv or Ini. As there would be more reading the writing on the translations, this solution would cut down the number of queries to the database. When the client adds a new language or changes an existing one, simply write it to a file, not the database.
If you decide to go with the database adapter, maybe you could "tag" somehow the translations, so that on the home page you fetch only the translations for the home page, on the contact page only the translations for the contact page...
HTH!
Default Zend adapters handle caching well, so I'd stick to them, unless you really need database.
Instead storing the translation data in the database, you may directly operate on the translation files (e.g. po templates). This would be the best choice if you just needed to add (append to file) new translation strings.
You may use Zend_Translate's option to log untranslated messages (to file or any log adapter, including database),
and then handle the logs, or even create listener translating the saved strings.
Here's how: http://cloetensbrecht.be/zend_translate_mysql.html