Although I have given up on trying to code Javascript myself, that doesn´t mean I am abandoning you. On the contrary: you have gold in your hands, as I said before, I bear you no ill will, I want this project to succeed as much as you do. Javascipt-handicapped as I am, I am not a beta-tester, I am a burden to you. This said, please allow me to propose some conceptual features, something I know more about, for this or next versions:
On the short term:
- static from dynamic: on slow connections ( a slow provider or a slow, shared access to a router in hotels, bars or airports), Wix Code pages make a lot of trips to different domains (I have seen thing like parastorage, wixcode, amazon, etc) and fetch something. This takes time and resources and thus slows down the end result. Therefore, I propose a per-dynamic-page setting to generate a static page from a dynamic one, to be set by user. This would simply generate a static HTML-page for certain dynamic pages. The idea behind it is that for many pages, they don´t have to be up-to-date every second. A refresh/republish every n hours, like Google sheets or whatever, should be enough. The result would be faster loading pages and a lot less traffic thru your servers.
- make more apps data-bound. I would love to see the HTML-app data-bound, so we could use this app on every dynamic page with a different iframe piece of code, like showing the location on Google Maps, showing Yelp or Tripadvisor reviews, get an average price per house in the neighbourhood you are looking for from the local registry, etc. The time that all data from a page came from one source is long gone, we pull it from different sources.
Other apps, like map apps, restaurant apps, they all have to become data-bound so we would be able to show per Item a map location, an Open Table reservation, etc.
3)team cooperation: been said before, but we need some kind of page-locking mechanism to prevent two-sided editing on the same page
Longer term:
- Repository: I will first start with the problem. If I now want to limit a text field length, or define a field as a URL, I have to do that on interface-level. If I have two pages doing more or less the same, I have to define the field type and field length in two places. If I want to change it, I have to remember where I used it. Thus, I will forget one. But if I go to the admin (database) grid, all these restrictions are unknown: the admin can put in text longer than the max_length specified on interface (page) level, he can mistakenly forget to put https:// in front of a URL, etc.
In short, you will have to define how far you want to go with Wix Code: a beautiful, easy-peasy website with some database functionality, or a good database with a nice website on top.
If last, you will need a repository, a broker between db and interface, where all info is stored in one place and, by going thru the repository, every app behaves the same: the admin grid and the web pages with user interface limitations, they all pull their field settings, allowed chars, drop down content (as a foreign key), checks, help texts and error messages from one and the same resource. As an added advantage, you could construct Wizards to generate input/output pages, fail safe and adhering to the Wix philosophy of ´making things easy’.
If you want some input on a conceptual level, I will help, free of charge.
2)language and currency independency. If you want to make truly international web sites, both the Items Pages and the content from the database should be in several languages.
Example for a site displaying pants:
English:
Description : Leather pants
German:
Beschreibung: Lederhosen
I am not talking about the interface language in the editor: every developer speaks some English. I am talking about the data language, the language a visitor uses on a page. That means field labels, help text, error messages should al be language independent, but also content of dropdowns, text fields and image alt-texts.
Currency independency is more than just displaying another currency abbreviation, but it would take too long to explain here.
3)extendible user class/object/whatever: we need to track an endless amount of data/per user depending on the type of app: language, amount of things bought, air miles, date of last payment, an unpredictable bunch. SO if the concept of ‘user’ could be extended, that would be highly appreciated.
Hope this makes sense, if not, let me know.