Eureka: Adding Reorder/Delete functions to sections (multivalued section)

Created on 4 Oct 2015  路  47Comments  路  Source: xmartlabs/Eureka

In XLForm this functionality was defined by XLFormSectionDescriptor(tag: sectionOptions:), but this feature seems to be missing in Eureka

hard help wanted awaiting response feature request

Most helpful comment

I'm going to have some time off, so I'll try to look into it this week. I'll pull the most recent version from upstream and start trying to implement it. Anyone wants to help let me know and contribute to my pull

All 47 comments

@mathmatrix828
This feature was not implemented yet but we have plans to do it.

Regards

@mtnbarreto any news on when multi valued sections will be available? Or how we could contribute to it?

We have plans to add this feature but not in the short term, this feature is not in the top priorities now.

A good way to approach the feature implementation is taking XLForm code as a guide. I don't want a copy/paste of feature code implementation, what i'm suggesting is to rewrite the feature following swift best practices and using swift capabilities taking as base code XLForm.
i'm really appreciate if you have time to do so.

Regards

@marbetschar I've found a temporary workaround. Use tableView(canEditRowAtIndexPath:) and tableView(editActionsForRowAtIndexPath:). It won't allow you to reorder them, but you will be able to delete them.

One thing I did notice: any time you update the form manually, you must also manually call tableView.reloadData(). I call it in viewDidAppear(animated:) and any updating methods

I have also forked Eureka, and am taking a look at adding reorder/delete natively, without the workaround

@mathmatrix828 that's awesome!!! Keep up!

Any updates on this?

I would also add that the ability to reorder/delete sections and not just rows would be greatly appreciated

I've been busy, kinda dropped the ball on this. @mtnbarreto has there been any progress on your side?

I didn't have time either. I'm gonna address form validation functionality first since a lot of people is asking for it.
Is there anyone who want to help on this? It's already implemented in XLForm so we can look into its implementation ;).

I'm going to have some time off, so I'll try to look into it this week. I'll pull the most recent version from upstream and start trying to implement it. Anyone wants to help let me know and contribute to my pull

almost one year from "Oct 4, 2015".... by the way, Eureka still the best form creation. :)

@mtnbarreto I haven't had a chance to work on it, have any of you?

Any implementation recommendations to take this further and build it into core? Anyone?

I think the only thing I had in mind when I wrote this ticket was doing what XLForm already did

So do we have already something in place to build upon or shall we start from scratch to kick things further?

I don't believe there's anything in place, @mtnbarreto would have to confirm that and I haven't looked at the code. We will probably have to start from scratch

Ok. Let's start from scratch then.

Since this issue seems to evolve into some major work I would be happy to have you guys on board so we can make this happen in a community effort. I'm absolutely willing to invest time on it, but I can't get the whole thing done alone.

Who's in?

Holidays aren't really busy for me so I'm down to contrib a bit

Fantastic! My approach is to achieve the following in order:

1. Adding the reordering functionality to the cells

I think this should be configurable with a reorderable: true/false per cell. Also within a multivalued section, all cells should be reorderable = true by default.

2. Adding the ability to add and remove cells in a multivalued section

My preferred approach for this would be a swipe to the left for deletion and a swipe to the right for adding a new cell. See https://github.com/xmartlabs/Eureka/issues/105 for details.

I mean it shouldn't be terribly hard. Create a public method that receives the cells that can be reordered and pass that to the tableview logic, and to remove just pass them to caneditcellatindexpath and set up the view

However I disagree, I believe the cells should be set to false by default. Reordering should be only in certain circumstances. By default, uitableviewcontroller sets it to false, we should keep to that

I agree on sticking to the default. That's a good idea! I'll create a fork and invite you, so we can start things rollin'

@mathmatrix828 I've just created the fork & invited you: https://github.com/Mandelkind/Eureka
Also I've added a new branch feature-17 for this issue, based upon master.

Perfect, we'll get down to it then

@mathmatrix828

I've just added the ability to use a Condition to define whetere a row should be moveable or not - defaults to false - https://github.com/xmartlabs/Eureka/compare/master...Mandelkind:feature-17

Next step ist the implementation of the actual row move. My suggestion is a simple "tap & hold" gesture on the table cell to start the "row-moving-process". Agreed?

Struggling with the moveRow implementation. Basically keeping Form and tableView in sync - because of the Form KVO bindings is causing me headaches. Feel free to give it a shot.

@mathmatrix828 please have a look at https://github.com/xmartlabs/Eureka/commit/a6322e0d698a3408e2970bcd6d204708f2ec53d0 to see what I'm struggling with.

Also I'd love to implement http://www.b2cloud.com.au/how-to-guides/reordering-a-uitableviewcell-from-any-touch-point/ in order to avoid switching from/to edit mode.

In my opinion the default implementation of Apple of how editable cells are handled is quite ugly :(

I'm going to try and take a walk through the original XLForm and see how they got past that, then try to implement some of it to improve the situation

Ok. So far I've managed to allow for reordering by dragging the whole table cell - not only the reorder control. Also the reorder control is not shown anymore:

simulator screen shot 13 12 2016 21 24 04

Odd thing is, the cell still preserves the width on the right hand side where the reorder control would show up. Also I'd love to trigger reordering of a cell by using the UILongPressGestureRecognizer instead of manually toggling the tableView edit mode - unfortunately I can't get this to work:

I've tried to trigger setEditing(true, animated: false) on the cell where the gesture is recognized on. This indeed enables edit mode on this cell, but does not select it for reordering - what's missing here?

Let's move this to an issue on the fork, I'm sure everyone in this repo doesn't want to get spammed 馃槃

@mtnbarreto please mark this issue as awaiting input

Hi @mathmatrix828 @marbetschar , first of all Keep up the good work! I looked into the code and seems good to me.

I created a branch to merge the changes https://github.com/xmartlabs/Eureka/tree/feature/multivaluedSection and then continue implementing the feature from it.

Just some considerations..

  • [ ] Should be able to reorder rows.
  • [ ] Should be able to delete rows.
  • [ ] Should be able to add rows.
  • [ ] We must stick to the default UIKit user interaction. I mean we should use by default reorder button to reorder cells. This doesn't mean we will not have a way to change default behaviour to customize it.
  • [ ] At first look Movable protocol and row's moveable property look fine. However seems to me that Section is more adequate to hold these properties, we likely want to configure it once despite how many rows we have in the section or if rows were added later on.
  • [ ] LongGestureRecognizer and every code having hardcoded view names must be deleted or refactored, for me is not the most typical implementation.
  • [ ] Should provide a way to specify if we want to insert, delete or reorder rows.

What do you think about these? Any other consideration?

So, couple things

  1. Reorder/delete are obviously on the list
  2. Adding rows dynamically was not in the plan, and I don't recall XLForm supporting it but I could be wrong
  3. Default UIKit interaction is meh. I support using LGR and/or reorder buttons, but it should be on the end user to add the one inside the navigation controller
  4. However, if we were to support a navigation controller button, adding will not be an issue, but there should be a method inside of Section setting canAddToSection: / canReorderSection: / canDeleteFromSection

@mtnbarreto @mathmatrix828 where to put all these thoughts together into one complete proposal we can discuss on? Is there already something in place for Eureka? I'm thinking of a Markdown Gist - but I'm open to better suggestions, since GitHub Gist's seem to be tied to the user who creates one.

@mtnbarretto please elaborate on:

  1. LongGestureRecognizer and every code having hardcoded view names must be deleted or refactored, for me is not the most typical implementation.

@mtnbarreto please have a look at the proposal here: https://github.com/Mandelkind/Eureka/issues/9 in terms of

"At first look Movable protocol and row's moveable property look fine. However seems to me that Section is more adequate to hold these properties, we likely want to configure it once despite how many rows we have in the section or if rows were added later on."

Adding rows dynamically was not in the plan, and I don't recall XLForm supporting it but I could be wrong

@mathmatrix828 Definitely XLForm supports adding rows into a multivalued section through a button at the end of the section, pretty much similar to how we add information to a contact in iOS.

Default UIKit interaction is meh. I support using LGR and/or reorder buttons, but it should be on the end user to add the one inside the navigation controller.

Implementation must provide a standard UIKit way to do so, i mean the way apple apps do it, which is using the reorder button. Then you can customize it if desired.

where to put all these thoughts together into one complete proposal we can discuss on? @marbetschar

What about using this issue and making pull requests over feature/multivaluedSection branch? Seems to me we don't need several issues to discuss multivalued sections functionality.

@mtnbarretto please elaborate on:

LongGestureRecognizer and every code having hardcoded view names must be deleted refactored, for me is not the most typical implementation.

We have been using default UIKit behavior to implement every Eureka feature which means we must stick to the most common UIKit implementation to implement reordering and the other features. This is the direction we have been taken so far and I would like to continue in this way.

So in other words instead of hardcoding LGR to a particular cell/section/table/view, it should be assigned semi-dynamically to the object is modifying or removed?

I think LGR should be deleted completely. Eureka user should be in charge of adding navigator bar button to enter edit mode showing reordering button. I'm open to provide a way to customize it but let's leave customization support to later on and put our focus on implement the most common UIKit support.

Maybe we could create a new section type to support MultivaluedSection, something like

open class MultivaluedSection<Row: MultivaluedRow> : Section, MultivaluedSectionType where Row: BaseRow {

Some things we should define before implementing it...

-[] Where are we going to specify the multivalued section type, I mean the ability to insert, delete or reorder rows. XLForm has a property under section type.

typedef NS_OPTIONS(NSUInteger, XLFormSectionOptions) {
    XLFormSectionOptionNone        = 0,
    XLFormSectionOptionCanInsert   = 1 << 0,
    XLFormSectionOptionCanDelete   = 1 << 1,
    XLFormSectionOptionCanReorder  = 1 << 2
};

I think we can add a swift option property to MultivaluedSection generic type. That doesn't mean we won't be able to customize it per row.

  • [ ] support only one row type inside a multivalued section or many types? XLForm supports only one which should be specified and is used to instantiate a the multivalued section row every time user tap insert button. From my experience and based on contact and other apple apps the multivalued row is always the same. There is a trade of here, more flexible and complex or more standard and easy to use solution.
  • [ ] We need to provide a way to specify the add new row button type, the button that allows the user to add a new multivalued row. This will allow Eureka developer to customize how it looks like, i can't see any other benefit.

@mathmatrix828 @marbetschar Any thoughts on this?

@mtnbarreto

Agreed on:

  • [x] Sticking to the default UIKit implementation as the first step.
  • [x] Introducing a new type for multivalued section
  • [x] Adding an option property to the MultivaluedSection with .none,.insert,.delete,.reorder

My opinion on the other points:

Multiple row types inside a multivalued section

Short answer

Let's stick to the default implementation here first too: One RowType per MultivaluedSection.

Long answer

I'm biased here: Personally I need the ability to add multiple RowTypes - so this would be awesome! I think it should also be quite easy to implement:

  • One row type
    MultivaluedSection<TextRow>
  • Multiple row types
    MultivaluedSection<[TextRow,PostalAddressRow,...]>

In case of multiple types we simply show multiple "add new row buttons" (maybe in a pushed ViewController).

Specify the add new row button type

Isn't a open class InsertButtonRow: ButtonRowOf<String> enough? As far as I can see we can implement the default actions for didSelect etc. there.

Initialization for the section could then look something like:

MultivaluedSection<Row>(header: String? = nil, footer: String? = nil, insert: InsertButtonRow = InsertButtonRow())

If I'm understanding the above correctly, once this is implemented (add/delete + reorder) it will be relatively trivial to make a form that would let users edit an array of strings, correct?

That is correct
Side note, as I was asked about this, I've posted a semi-workaround that should let you do what you need in terms of dynamic adding
https://gist.github.com/mathmatrix828/3ed183c4a73504deafc5f4561e40adc8

Please note this is just a sample, I wrote this code w/out the library and on the fly so there might be errors, but this is the basic idea

Closing in favor of forked issue Mandelkind#2

Guys, I have a issue #1290 related to this one. Some help?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

AAverin picture AAverin  路  14Comments

RSickenberg picture RSickenberg  路  15Comments

nikkau picture nikkau  路  15Comments

johnlietzke picture johnlietzke  路  13Comments

sash picture sash  路  14Comments