10-06-2016, 01:22 PM
I think the forms discussion is something that needs to be addressed in a discussion about where UserSpice 5 is going (this is the right thread name, but I think warrants a much more detailed discussion to figure out where it is going. I do have a form builder that includes validation and can hold the values through the form display and submission, but at the moment the implementation is a solution to something, but I'm not exactly sure what. In the end, I think we want a UserSpice package that can be updated without worry of overwriting someones code during a semi-automatic update, people want to customize existing forms, and people want to extend existing forms as well as potentially supply their own forms.
If we limit the scope of UserSpice intervening only during sign up, sign in, sign out, and general permission handling, then we don't need to go too much farther, and we will limit the front end exposure of UserSpice. The simplest solution to that could be what I suggested before which was having a multi-step form, but that hurts the user experience. To this then, we need to address what aspects of the user experience we want UserSpice to be a part of.
Regarding redirects, in US5, the variables $abs_us_root, and $us_url_root are still present, but have been replaced throughout the code with the constants ABS_US_ROOT and US_URL_ROOT. I personally think that the method of using US_URL_ROOT with the redirect URL is the right way to go, rather than including US_URL_ROOT within the function itself. This would match the use of US_URL_ROOT in links, or other url access. In this manner, the redirects will work no matter where the page is located, as long as the link is supplied with the path between the website root and the file itself (which I think is prudent anyway). That said, I'm open to a specific discussion on how it *should* work, given some potential or likely use cases.
If we limit the scope of UserSpice intervening only during sign up, sign in, sign out, and general permission handling, then we don't need to go too much farther, and we will limit the front end exposure of UserSpice. The simplest solution to that could be what I suggested before which was having a multi-step form, but that hurts the user experience. To this then, we need to address what aspects of the user experience we want UserSpice to be a part of.
Regarding redirects, in US5, the variables $abs_us_root, and $us_url_root are still present, but have been replaced throughout the code with the constants ABS_US_ROOT and US_URL_ROOT. I personally think that the method of using US_URL_ROOT with the redirect URL is the right way to go, rather than including US_URL_ROOT within the function itself. This would match the use of US_URL_ROOT in links, or other url access. In this manner, the redirects will work no matter where the page is located, as long as the link is supplied with the path between the website root and the file itself (which I think is prudent anyway). That said, I'm open to a specific discussion on how it *should* work, given some potential or likely use cases.