@tsi: Hmm, I’ll have a look at it tonight. Haven’t tried downloading and testing in a new environment yet. Which platform are you trying this on?
There is no gradle wrapper folder included in this project.
@it_vegard If you have gradle installed, just go to the root folder of the app and type “gradle wrapper” and a wrapper will be created (or updated) for you. Then make sure .gitignore doesn’t remove the generated files.
Nevermind that, I’ve sent it all as a pull request to your repo =) Enjoy!
1 Like
I’ve installed it and played around a bit. This is really impressive. I can tell you put a lot of work into it.
Why is “method” a text input if the only options are GET and POST? Maybe radiobuttons would be better.
Why not use a service to handle form submits? This way you don’t have to manually enter the action URL?
I’m gonna add a pull request with some changes.
- I changed the form display-name-script to use label instead of meta.label, which didn’t work.
- I removed deprecated stuff from content types like
<immutable>and<allow-children> - I removed language: ‘no’ from the saveForm() function.
I could also update it for 6.4
Hi, @mla! Thanks!
Actually, I noticed the “method”-thing last night myself. I’ll change that as soon as possible. No reason why that should be a text field. Basically just something that has been there since I started this project half a year ago… 
I have thought about the service approach, and still might go there. So far, the reason for posting back to the form part, is that way I know exactly which form I am handling, without having to send it in the form. (Don’t know if that has an effect, but I thought it might be a bit safer way to handle responses)
However, with regards to manually entering action URLs:
That one is optional. As long as you’d like to use my post handling, just leave it open. However, I’d like users of the form to use their own form handling, in case they want special validation, store responses in other databases, etc. Then they can enter the URL to their own service, etc.
I just merged your changes. Great that you guys are getting involved!
I also just added a few fixes. The form content-approach didn’t quite work, as it was a bit outdated compared to the form-part-approach.
Also, the bootstrap and default form templates needed some fixes for their submit-handling. (JS broke because of a missing class)
I don’t see why it would be a problem to send it in the form. Could add a hidden fields.
How about adding fields for the service name and app name and then the form creator can fill those in and the part can generate the serviceUrl without any hard-coding. Whatever site is using the form builder could then create custom services in their own app. Your service would be the default. Or maybe even a content-type for services that has fields for serviceName and appName. Then the developer could make those Service contents and a less tech-savy content editor could just pick one from a content selector.
I just added a pull request which updates it for 6.4. 
1 Like
I think it should be possible to post to a service outside of Enonic as well, which wouldn’t work with the service approach.
Right now I am not convinced that storing responses as content is the best option in every case. Basically, I would expect some form of performance hit when using the content tree if you had multiple forms with several thousands of responses each. In those cases, I think it would be good to have the option of storing responses in an external (SQL?) database, and then possibly create your own part which display the responses in Enonic.
However, that might change when I start looking at the new admin tools. If it is possible to keep the whole responses-part out of the content tree, that would be great. Perhaps using the node-API directly might be an option? (I am thinking about moving the whole form handling to an admin tool, and just creating a form content that can be moved around in the content tree)
Using hidden fields sounds good, but I am not sure what extra it gets me. What is the reason you suggest not posting back to the form? I would think keeping the responsibility of the form in one place would be a good idea, and probably why you enabled post handling in parts as well?
Regarding the pull request: Will the app still work with < 6.4 when the files are moved? (I’d like to support at least all 6.x-versions)
I am a bit uncertain how to handle this change, as I would suspect that I would need to have duplicate files in order to handle both 6.4 and < 6.4. Perhaps a gradle script to copy the files during build is the best way to provide backwards compatability?
The re-structure of files will be forced from 7.0, but “old” (pre 6.4 style) will be supported as long as we continue to develop the 6-branch (which will go up to 6.9 as far as we know right now).
So restructuring the files are not needed now, I think we need to make that much more obvious in the documentation. @gri? @tsi?
It’s not a problem to move them now. I am just unsure how to best handle older versions.
I guess most clients using XP has upgraded to 6.x by now, but eventually there are going to be multiple major versions in use at the same time. Apps for general use should (in my mind) have backwards compatibility as well, which is why I ask about the best way to handle this.
From the top of my head, I would think using the most up-to-date approach for the code, and then a copy-job during build to move files to older locations is the best approach? Or will it cause problems to have files where they are not expected to be found?
Another approach is to have branches for each major version, but that would make it more difficult to keep code up-to-date.
it_vegard has a good point here.
If you move your files, you application will be compatible only with >= 6.4 and < 7.0
If you keep the files, your application will be compatible with >= 6.0 and < 7.0
So it is easier to keep the files where they are untill 7.0 in my opinion
2 Likes
We’ve made some changes to the documentation now to make this more obvious.
1 Like
@it_vegard Great work! Just to make it a bit easier to try it out, could you make an initial import like the superhero blog with a sample form and config?
Vegard, no need to worry about unique names for the content, xp will fix this for you. You need to set a name, this should preferably be the name of your form + text string from the first e-mail or text field or similar…
It’s true that not moving the lib and assets folder will keep it compatible with 6.3. But I suggest at least updating your build.gradle and adding the gradle.properties like you see in that pull request. This will keep everything consistent with the way we do things and when it comes time to update the XP version then you can do it in one place for both the repo and and libs.
@mer: I have added import data now. I set up a new site in a hurry, but I think it should work.
@tsi: Right, that was fixed a couple of versions ago, right? I’ll look at that during the weekend.
@mla: Yes, I’ll add the gradle-changes. Getting a bit late now, but I’ll have time tomorrow, I believe.
1 Like