Replies: 5 comments 2 replies
-
Won't this be too fundamental a change for the 2.0 milestone? This is the library that is used throughout the core and the existing modules to build almost any form on the site. |
Beta Was this translation helpful? Give feedback.
-
I think most places now use ipf forms instead (and these forms extends xoops forms). But I'm not sure about modules. So that's why I'm asking about our options. |
Beta Was this translation helpful? Give feedback.
-
In that case, the title isn't 100% correct :-) I think removing xoopsforms would be a good step. But that would mean marking it as deprecated for 2.0 and removing it in 2.1. That spreads out the changes that are needed in time, both for the core development as for people supporting modules (like me, @skenow @jegelstaff and @madfish) |
Beta Was this translation helpful? Give feedback.
-
I think I'll extract XoopsForms with all repo ristory into new composer package and place it in @OldXoopsLibraries and include this library in our core. It's possible that @geekwright and @mambax7 will move that package to @XOOPS. They have a right to do so. What I'm not sure about if we could use any other forms lib too for using in ipf forms part, so that they will not depend on XoopsForm. I think anything that doesn't use GPL license would be better much for us. Here I'm not sure if there are some alternatives. Another possibility - deprecate all forms PHP functionality and use vue-form-generator or similar library. |
Beta Was this translation helpful? Give feedback.
-
Probably we could use symfony/form for something to replace xoopsforms. One issue with this package is that it depends on symfony/event-dispatcher, so for #177 we probably should use this package. Also, there is dependency for symfony/intl |
Beta Was this translation helpful? Give feedback.
-
Maybe we could get rid of XoopsForms than?
Beta Was this translation helpful? Give feedback.
All reactions