Multi-edit Duplicates
Support Ticket
+issues
I just realized that we have a potential bug. The use case is that I wan't to include a plus card for viewing in more than one way, and when I edit a card under my updated *structure rule, the plus card shows up twice in the edit form. I haven't tested, but I'm guessing it would only save edits from one of the instances of that card.
I think it should be considered a bug for multi-edit to have more than one input element for the same card.
The rule in question is http://gerry.wagn.org/book+*type+*structure, and a book card that shows the issue on edit: http://gerry.wagn.org/Signs_of_the_Times
Thinking about solutions to this, I realize that it doesn't have to be the case that the same rule is used for viewing and editing. Note that if some cards might then have a *edit_structure (or whatever the edit setting is named) rule, but not a *structure, I can get multi-edit behavior on cards that aren't hard templated.
Tested it quickly. It only takes edits from the second instance of the card. This makes it easy enough to work around, but I think there is something that should be fixed eventually.
it may be even worse: it may not reliably take the second.
I could see how that could be too. Could be dependent on lots of things, browser, for example, but could be lots of things that might change which one gets in. It shouldn't be that hard to fix.
What can be done now to override the view you get in edit mode? That may be a productive area to explore in designing the solution here. The wagneer could then specify the edit view of a particular inclusion in the nest syntax, and that view could be 'none' (we have 'blank' or something,right?).
I'm thinking that there is a more standard way to override rules in the view (say pointer style rules), but here too we have a mode distinction in finding the right view.
All food for thought. If you've thought of solutions and best practices for these things, that's a great starting point too.
Maybe we should have a blueprint for modes? Do we? Is it maybe part of a view blueprint?
I hear that you're concerned about making it so that Decksters (my new favorite name for Wagneers) can do just about anything. I should probably be clear that I don't really think that's the strategic priority right now. I'm much more concerned about making what we have discoverable than about adding new powers. The developer priority is on completeness, the deckster priority is on usability.
For this specific issue, the problem is easy to workaround: just make one of them a virtual card. Then it won't show up in the editor. I don't think we need to do anything else about this for now. But, you might say, creating a virtual card isn't easy enough! Right! That's the problem! How do we make common decko patterns easier?
I think we're getting to a place where there's an impulse to solve every problem by adding a new nest directive. I don't want to go down that route. IMO we want very few directives (probably <10), and we should be thinking of ways to deepen or harmonize existing ones (in this case, perhaps "hide:edit") rather than add more. We need the nest editor to be simple, crisp, and clean, and that means a few, well-thought out options, not a lot of microfunctionality.
fwiw, I do think it's valuable to keep collecting these kinds of use cases so that when we do decide to expand Deckster's capabilities we can figure out how to go the furthest with the fewest "tricks". But we can't easily add directives and change them later, because that involves a bunch of heavy migrations.
looks like we're not handling comments well. I used a less-than sign and lost most of what followed..
Yeah, comment editor is special. You have to save and edit to get WYSIWYG controls. I wish there were a better way the get the formatting controls on demand.
I'm often a little surprised by when a typed character gets entity encoded or not. It's hard because you're not seeing what you will get in a lot of edge cases.
I can agree about priority. On the other hand, I think we are going the direction of making a more subtle distinction re decksters experience and discoverability vs. cardability. What I'm saying is that sometimes we will be providing a card based control for developer use where it might be noticed by decksters. You don't think that type of feature that isn't designed for discoverability needs to be avoided, right? I know it isn't Decko1.0 critical.
I'm not sure I fully understand your 'workaround' in this case, but this ticket is just about fixing a potential bug. We need to make sure we don't target the same card in multiple input elements regardless of any of the rest of my musings here.
if you have +field twice, you can change one of them to +virtual_field and have that virtual card include _left+field. That will keep it out of the form.
I do think we want to avoid putting special developer tricks in the deckster space. As soon as you put code into a nest, you effectively take it out of the deckster space.
Now, I get the work-around. I can use that for now.
So, the design restriction is on nest syntax? I can see that as a clear distinction.
I guess if we wanted to design developer features in the nest syntax, we could restrict it the way we do with Html vs. Basic cards. Well, this is stronger since Html cards is something decksters may have to do for common use cases. Cards with a certain attribute might be read-only except for the system (migrations, events, ?). Internally, it is extended nest syntax, but it isn't deckster visible or usable. (could be encountered reading 'system' cards, but isn't something they would know about or change. In other words, it could be an implementation choice for a feature, but not part of the deckster space because of explicit and implicit restrictions.
Actually, I just stumbled onto a bug that presents an easier workaround.
As things currently work, the automatic form is looking specifically for nests with card names beginning with a "+". If you instead begin the nest with "_+" or "_self+" or even "_1+" or "_left+" or whatever else, you will not get the editor in the form.
I didn't realize it worked that way. Was that always the case?
So, you can't edit any cards included by absolute references either? That is probably the desired behavior for absolute references, but aren't there some other relative references that you might want to edit with the card? I suppose those could be added to the recognizer test for editable inclusions. You could still want a nest parameter way to override the default in either direction, but hopefully that is very much an edge case and not needed.
It's definitely not all we want it to be (that's why I called it a "bug"!). So not a long-term solution, just a workaround.
Let's look into deeper solutions. (But not on this ticket).
Meaning deeper solutions to the reference handling...
In some sense, the distinction is whether a given reference is treated as a link or an inclusion. It might be as simple as some views being considered variant links vs. inclusions. But as you say, that's another discussion.