Renames on Type Change+discussion
Are there any events specific to set membership changes? Might be a good thing to have internally.
for any event def, you can do :changed=>:name, or :changed=>:type. You may be able to give it both in an array. Those are the two changes that involve set membership changes. I suppose we could make :changed=>:set as a shortcut, which would also presumably ignore name changes within the same keyspace.
"When a the Cardtype is changed on a card, I want some things to happen on the rename based on the old and new type". If all you're doing is changing a type, there is no rename. The title of this ticket has the same weirdness.
Plus card idea is a good one. I think we may have an 8ish-year-old ticket about that, actually.
Wouldn't need a full workflow system, but the *Ticket types here are great for extended use cases. As it is, the editor has to know what type transition or ok and which not. I just realized that I couldn't have entered data in to +solution on that other ticket because I created it as a Support TIcket without that field, and then when you made it a Ticket you moved my solution (in the issue part) to that 'new' field.
Say I have a type inheriting from Basic and I've added content. Then I want it to transition to a new type that has virtual content (*structure rule) and I still want the original content as Original card+description (or +whatever). Another case might be changing to a different virtual content where the attribute (plus name) is different.
But I can see how the title isn't best, feel free to make it comprehensible to you.
So, the mechanism is there for specific set changes. That's probably what we want anyway (at dev/module level). Just exposed in common cases to Wagneering.
Oh, I definitely need to rename this. I realize that my first analysis of this is all wrong. There are two related use cases, but they aren't related by a type change, or not all that directly.
It is when you change the content rule between *default and *structure, so the triggering events are actually (content rule) card creation and deletion.
So, I want to come up with the right thing to call it. Roughly, 'moving content on content rule change' which typically would be moving _self content to _self+some_tag or vice versa. Seems like it would have to be something supported by a mod change whether appropriate for common use or not.
The other use case is where I got it confused with changing a type. When you change the type, and the two types have a different kinds of content rules (i.e. one has virtual content, the other real), you might want to make the equivalent change to the above. That is have the buffer that was on current card content (real card, _self.content) be on a particular field of a multi-edit (for +some_tag, assuming it is included into the virtual content).
Common case for me now is changing a URI typed thing to a virtual content type with +reference containing that URI.
Support tickets don't have solutions, because they're for people asking for help with problems. if you're discussing solutions, it should typically be an Idea or a Ticket (we often change support tickets into those once we have a solution in mind). Even in those, we want to make sure the issue is clearly articulated.
Here the issue is sometimes a change means a card's existing content is overridden by *structure rule, and we want better routes for keeping that content available.
Here is John Abbe's name from January 2008 (7.5 years ago -- I was close!): Migrate existing data when formatting existing cards. I might rename it to Migrate existing content when overriding with structure rule and move this discussion there.
Re triggers, it's not super easy to describe where this happens concisely, but there are two main cases:
1. A *structure rule is newly applied to a set, either by creating or renaming the rule. Whether or not a *default rule was involved is irrelevant.
2. A change is made to an unstructured card that means it newly joins a structured set.
(This is a common pattern, actually. Sometimes you change the set's rule, sometimes a card joins the set.)
Basically you would probably want events to detect each of the above, and then each of those would call a third event (on ruled cards in the first case and self in the second) that would actually handle the migration.
But to be honest, the implementation is the easy part. I don't think anyone's really designed a solution as to what should happen. What does the stuff get renamed to. Is there a prompt? Is there a rule?
Personally, I don't think we've offered an implementation-ready ux/data design, so the event conversation is probably premature (though perhaps helpful in understanding the situations where it would come up)
Yeah, that's about right. I guess it has been thought about a bit. Should we give this one a better name or use the old one you referenced?
I think it is rules, but not sure how they would be coded. The oddity is it could depend on the original type/set as well as the new one. When we have to encode this sort of complexity in a rule, it probably calls for a JSON description of some sort.
Maybe something like "moving structured content on content rule change" or "automatically re-structuring content".
I'm thinking we need to map one or more context relative cards into different content relative cards. In my URI - Quote example, you would be mapping _self and _self+reference.
We could put a new rule on the destination set (using URI -> Quote as the change), so Quote+*type+*migrate might have {URI+*type : {_self : +reference}}