S
smat-consulting
Guest
There are two approaches for frameworks, I find: a) build every screen manually yourself b) have standard screens built for you, and customize 2 or 3 most important ones manually I am tired of spending weeks and weeks of building standard screens manually, so I prefer option b). There is, to my knowledge, no framework for ABL/WebSpeed out there that uses the b) approach, aside of the one I use. It requires your DB to follow certain best-practice standards. At first, you spend time declaring the relationships of the tables. But once that is done, you get the whole application basically for free. The first pronto-type, that is. With that up and running, you can now go and customize the definition of the lists, filters, viewers, and edit-screens according to your preferences, and then regenerate the application. You cand o that s much and often s you want. If you have changes to the data-model? New fields, tables and/or relationships? No problem. Add them using the dictionary, define the relationships, and regenerate. You won't loose your customizations, but get the adjusted/extended application. With this in place, you can spend your valuable time on implementing the business-logic around workflow processes or triggered by various changes to the data, or whatever... The only time you need to do JS or HTM is if you need special behavior or custom screens. Much of the HTML of such screens, in my experience, can be copied and pasted and enhanced/adjusted from default screens. The JS for the interaction with the backend is usually the same as the standard screens, so not much JS is needed - except adding the hooks, maybe. If you don't need a non-standard screen, there's no JS necessary at all. Let me know if this is kind-of what you're looking for and if you need more information, or ideas...
Continue reading...
Continue reading...