Closed brendand closed 9 years ago
The tricky part with paste is depending on where you click before you paste, the table of values on the pasteboard might not match the column data types of where you're pasting. And then if you have say 10 rows to paste and there are only 5 rows below the cell you click on, 5 additional rows would have to be added during the paste.
Yes, it'd need some logic to check that each value is compatible -- that the cell type works (e.g. pasting a string into an image cell should fail, and vice versa), and if a text cell with a formatter, that that is compatible. Cells like popups would require the text to match a popup value.
Adding additional rows to fit the pasted values is the right approach, and easy enough.
Maybe should add additional columns if needed too, though could ignore those values. If we did add columns, we'd have to decide how smart to make it -- only add text cells, or look at each value (for the new columns) and add suitable cells, e.g. image. The main determining factor for this will be your use case: does it make sense to add additional columns via paste for Tap Forms?
That would essentially be like adding new fields to the form. It would be quite appropriate for Tap Forms. I would just have to have an array of new columns that need to be added. A value can't be stored in the database without a field being created for it first. The array would need to contain the indexes of the original columns the copied values came from because I would need to look up the proper field types in my own database and essentially duplicate those fields.
But I think that's essentially what any app would need to do and isn't limited to just the way I would use this component.
Done.
I’ve tweaked the controller’s copy method to also put the column classes on the pasteboard, so you can use that to add new fields to the form. It also now uses the column's formatter, if any.
I’ve based the paste methods on the approach of the copy methods, doing most of the work in the controller, which makes sense, since it knows about the data model. The way it’s implemented in the demo controller is like in Numbers: if a single cell is selected, it pastes all of the copied data, adding columns and/or rows as needed. If multiple cells are selected, the paste only replaces those cells.
While implementing support for adding extra rows & columns when needed, I also reduced the code redundancy around those operations, and fixed some issues where it assumed that it’d reload the data after adding every single row or column (which would have had a performance penalty with hundreds or thousands of them, since it did that on loading the table); look though the changes for details.
:+1:
Copying a selection of cells should put the content as text onto the clipboard in a tab/linefeed delimited format. Pasting of tab/linefeed delimited text should be the same as typing the values into the cells. E.g. if the column has a formatter on it, if the content isn't in the right format, it should fail to paste the content into that cell but succeed for the rest where it can.