Brandon said: "It is claimed that you plus two cards together to get a third, which isn't really the case. Plus cards allow us to have subcards. In "Card+How To", Card is a card but "How To" is not a card; it's just a naming scheme that gives it recognition and the possibility of an *rform."
Actually, "How To" is a card. It gets created even if it wasn't there before. It's true that it's a naming scheme, but a card is also created. And if I add "+how to" to another type, it's connecting that other thing to the same HowTo card (despite the name variance).
I do think we want to make the relationship tracking easier than it currrently is, though. I'm not yet sold on your solution in the example, perhaps because I don't quite get it. It looks like the relationship itself has a complicated name, which wagn works hard to avoid. And I'm not clear on the gain. Even as things currently are, you do see the relationship in the related tab, no?
But Brandon's underlying point is one that I have named as well. I understand that the real existence of the tag card is important to tracking references, but the point that it is just a naming convention stands, and it is even moreso that way when we get patterns. It also creates conflicts between different contextual usage of a card key. It takes the canonical card name from the initial creation, which is understandable but confusing in operation.
--Gerry Gleason.....Fri Nov 06 11:51:02 -0800 2009
Note the problem we just had with Topic+discussion+other. The fact that Topic+discussion now exists fixes the problem, but now "Topic" has a discussion card and I have to try to limit the searches not to see it. There is no reason that Topic+discussion has to actually exist as a real card that can be found in typical searches, but it does have to exist for Topic+discussion+other to be computed.
--Gerry Gleason.....Fri Nov 06 11:55:26 -0800 2009
If I may interpret Brandon's example a little ...
Currently, you can use student+*rform, but that would apply to a +student to any card, so if I also put in say an "Activity" cardtype and wanted to have + cards, I have to use the same +*rform.
Isn't this one of the prime use cases for using patterns to find templates? So that the +student could get a different template conditioned on "left".
--Gerry Gleason.....Fri Dec 04 05:33:04 -0800 2009
yes, patterns would address having different meanings for form settings applied to different "sets" of cards, while preserving the often desirable use case of plus formatting that applies to everything.
I'm not sure that's related to Brandon's initial point, which seemed to me to be more about bidirectionality.
--Ethan McCutchen.....Mon Dec 07 12:51:33 -0800 2009
changing to idea, as I feel like this could handle more discussion, but I'm not sure there's support to do right now.
--Ethan McCutchen.....Mon Dec 07 12:52:16 -0800 2009
this is one approach to support bidirectionality
--Ethan McCutchen.....2013-04-05 17:47:03 +0000
I think this is actually similar to my symmetric method of linking cards. He's sort-of asking for *type_plus_type patterns, which we have, but not as a standard pattern. Not sure how relevant this ticket is now. We have even talked about taking back the + join for what is more like the original usage and using / for the naming case that it has morphed to.
Yeah, very similar. For others' reference, Gerry's join comment refers to the see "Transitive Plusses" section in DeckoSystems+names .
--Ethan McCutchen.....2015-05-04 20:07:24 +0000