4 ms·

This looks like a well thought-out project, but I am unsure how it would realistically fit into an actual project. It claims that "it does not tie you to a web

This looks like a well thought-out project, but I am unsure how it would realistically fit into an actual project. It claims that "it does not tie you to a web framework", which I guess is technically true... but the amount of setup involved on the server basically makes this thing its own framework (in terms of having to manage it on the back-end). And if you're already using a framework then it most likely includes its own form generation/processing system. Seems to me that a more practical "framework-agnostic" form library would be one that is completely on the front-end, and assumes a REST-like API exists on the backend that it can communicate with.

adamw1pl 12y ago
We would be fine using existing frameworks and their form handling systems, but all of them feel very heavyweight. Either the backing objects need to be of some specific form, or the communication protocol between the server and the client is weird, or the generated markup is a mess. With Supler, we want to make it easy to customise the form, the form's markup and associated Javascript (to add any dynamic behaviour), so that you don't have to hack the framework, but instead so that you can use our library to generate the base and then customise further. One of the main points of Supler is that it takes care of both the frontend and the backend, so I don't think it would be possible to keep it entirely on the frontend. E.g. you define the form once, and you have partial validation on the frontend, and the same full validation on the backend (without having to repeat yourself).