inclusions as link targets
http://democracyinnovations.wagn.org/wagn/Asset-Based_Community_Development%2BOrganization+card_in_me looks okay, but http://democracyinnovations.wagn.org/wagn/Asset-Based_Community_Development+Organization+summary_link_to_resource returns a mess.
http://democracyinnovations.wagn.org/wagn/summary_link_to_resource%2B*right%2B*content :
• [[\{{_left+card in me}}|{{_2|name}}]]
http://democracyinnovations.wagn.org/wagn/card_in_me+*right+*content
{"referred_to_by": "_self",
"view": "name"
}
Some of the links generated on http://democracyinnovations.wagn.org/wagn/the_big_list are red, which I think is the same problem I ran into the other day, but can't find the support or dev ticket now.
--John Abbe.....Mon Feb 21 03:03:12 -0800 2011
See inclusions as link targets
it's the same problem as using the content url -- putting an inclusion in as the link target. Issue is in http://democracyinnovations.wagn.org/wagn/summary_link_to_resource+*right+*content:
I think it will work if you just do this:
--Ethan McCutchen.....Mon Feb 21 09:31:18 -0800 2011
Okay, the trick is there was a dereferencing left to do. http://democracyinnovations.wagn.org/wagn/summary_link_to_resource+*right+*content now uses http://democracyinnovations.wagn.org/wagn/card_in_me+*right+*content and http://democracyinnovations.wagn.org/wagn/Asset-Based_Community_Development%2BOrganization+card_in_me looks ok, but on the big list it seems as if it's giving back brackets around it?
--John Abbe.....Mon Feb 21 09:54:30 -0800 2011
If that's a pointer in view raw, the items already have brackets around them.
There are like 5 steps between that configuration and the big list.
It's clearly already f'ed up here: http://democracyinnovations.wagn.org/wagn/Asset-Based_Community_Development+summary_link_to_resource
Basically, I don't think wagn supports inclusions as link targets. It treats them all as unknown cards and goes nuts if there's any html tags around them. If you're committed to this approach, best case scenario is a red link at this point. What you'll need to do is try to find a way to view the card without any html tags around it. I'm not sure we currently have a way to do that for searches or pointers, but *that* is definitely something worth figuring out.
--Ethan McCutchen.....Mon Feb 21 10:05:50 -0800 2011
http://democracyinnovations.wagn.org/wagn/Asset-Based_Community_Development+summary_link_to_resource shouldn't be getting called, it should be http://democracyinnovations.wagn.org/wagn/Asset-Based_Community_Development+Organization+summary_link_to_resource
(sigh, which is also f'ed up)
--John Abbe.....Mon Feb 21 10:35:57 -0800 2011
I've put the two low layers where the problem shows up and doesn't in +example.
If we get the content to show up right, I can CSS the red links to green (probably a slightly lighter shade, so that in other places we can still distinguish non-existent cards).
I'm not committed to this approach, open to alternatives within the general approach one Resource type using +type for Innovation, Book, etc. Also open to doing separate cardtypes for Innovation, Book, etc., but that requires +*cardtype.
--John Abbe.....Mon Feb 21 10:49:13 -0800 2011
My current best idea about how to do this would be to be able to specify a format as part of inclusion syntax. So you could do and that inclusion would be processed as you would process a textual page. I'm a little hesitant to ticket it without thinking through the ramifications a bit more, but we could add an idea to add syntax to specify format
--Ethan McCutchen.....Mon Feb 21 11:03:23 -0800 2011
The two closest solutions are well-laid-out now at http://test.dwagn.org/wagn/Earth
I appreciate the time you're putting into this, which I know is not core to Wagn's high pri next steps.
--John Abbe.....Mon Feb 21 12:24:25 -0800 2011
There is another avenue for addressing these issues that we could consider (and that we talked about long long ago. maybe there's even a ticket?). It's being able to add a "title" in the inclusion syntax. That would be handled differently by different views, (link text in links, obvious in open, closed, titled...). For this to work for the present case, you'd need to be able to make titles relative. Even then, it would be pretty heavy duty....
--Ethan McCutchen.....Mon Feb 21 12:47:24 -0800 2011
Didn't find, so added a ticket for add inclusion syntax to customize title
Yeah, heavy duty. I like add syntax to specify format (in its own right much more than custom title), but that also may be more heavy duty than necessary for this. I can't think of any use cases for the layout that add syntax to specify format would need here - such a layout only makes sense for delinking card(s) in a Pointer or Search. This is a very specific problem and although it's obviously possible to come up with general solutions that address it, I'm back to thinking a narrow solution might be the way to go.
--John Abbe.....Mon Feb 21 14:20:08 -0800 2011
by "heavy duty" I meant the wagneering, not the code. neither of those tickets are particularly horrendous given the current architecture.
The issue is rendering without the per-item html, maybe just separating each item with a line break. I don't like adding new views, but that one seems pretty generally useful. And it's certainly come up a bunch.
--Ethan McCutchen.....Mon Feb 21 14:36:04 -0800 2011
Personally I abhor underscores, finding them ugly and hard to type. Ticketed interpret spaces in view names as underscores.
--John Abbe.....Thu Feb 24 14:14:05 -0800 2011
So...bare_items solves the use case above, but not the case where what's wanted is to use the content of a card as a URL. See the first part of http://test.dwagn.org/wagn/inclusions_as_link_targets
--John Abbe.....Mon Mar 14 22:21:41 -0700 2011
There are use cases, e.g. http://yi-tan.wagn.org/wagn/Prefab_Green+podcast_links_and_playback will show long, ugly URLs until this is handled better. If I recall correctly, this isn't an easy or even necessarily clear fix, having to do with the order things are done in. Do we want a general Idea like handle inclusions as link targets to explore all related issues together, and/or is there a narrower thing we could ticket to stop the prepending of a Wagn's bas URL?
--John Abbe.....Fri Mar 18 22:40:46 -0700 2011
? I don't think wagn is actively prepending base urls anywhere is it?
--Ethan McCutchen.....Mon Mar 21 08:56:21 -0700 2011
Oh, it's prepending /wagn/, right. There's a ticket about that already, make urls in content work within link syntax. I think that can probably be the placeholder for solution discussions for now.
--Ethan McCutchen.....Mon Mar 21 09:27:55 -0700 2011