search

getodk / build

ODK Build is a drag-and-drop form designer for ODK XForms. Thousands of users around the world depend on it for their data collection campaigns. Contribute and make the world a better place! ✨📝✨
https://build.getodk.org/
Other
110 stars 82 forks source link

add delete form in menu #59

Closed getodk-bot closed 7 years ago

getodk-bot commented 7 years ago

Issue by mitchellsundt Thursday Jul 09, 2015 at 17:57 GMT Originally opened as https://github.com/opendatakit/opendatakit/issues/240 (1 comment(s))

Originally reported on Google Code with ID 239

deleting forms by going to open forms isn't intuitive...

Reported by yanokwa on 2011-06-24 19:21:02

getodk-bot commented 7 years ago

Comment by mitchellsundt Thursday Jul 09, 2015 at 17:57 GMT

add build label

Reported by mitchellsundt on 2011-07-01 20:45:29

issa-tseng commented 7 years ago

Simple fix may be to rename "Open Form" to "My Forms" and push the lost data warning for the current form back to when the user attempts to open rather than when the dialog appears.

hd719 commented 7 years ago

Hello I am new to open source is this still open?

rockydcoder commented 7 years ago

It has been a while since anyone responded. Can I take this up?

rockydcoder commented 7 years ago

push the lost data warning for the current form back to when the user attempts to open rather than when the dialog appears.

This is done by the destructive class, right? I added this class to the Open button, but the message to save the form does not appear. Can you give me any ideas? @clint-tseng

issa-tseng commented 7 years ago

Hmm. So, the destructive class is one cheap way of triggering the warning, but I'm not sure it accounts for anything besides the action of opening a Modal.

But even if you change destructive to a more modern jQuery style of delegation (ie $(document).on('click', '.destructive', …), the Open button's own handler will still fire before that event bubbles up to the point where the generic destructive handler will actually try to do anything.

My recommendation is to look at this block of code, and genericize it into the odkmaker.application namespace for many places to call. It could go next to the confirm function and have a very similar signature (ie confirmDestruction(callback)), internally check the clean flag, ask the user if they're sure they want to proceed, and if they say yes then perform the action in the callback.

Make sense?

issa-tseng commented 7 years ago

And: sorry about the delayed reply; had my hands full all weekend with something else.

rockydcoder commented 7 years ago

Yes, thanks for the suggestion. I have raised a PR. Please review.

rockydcoder commented 7 years ago

Just a concern. Now, the UI looks like this: image

Is this fine or do we need to change the way it looks? (One dialog on top of another, without completely hiding it)

issa-tseng commented 7 years ago

Yeah, that's okay. I'm not too concerned about it. Thanks, though.

rockydcoder commented 7 years ago

@clint-tseng , this issue can be closed now, I guess.