We've talked about using this before and decided against it because it convolutes things for wagneers. Every card should have one and only one content.
{{_self}} already refers to the (formatted) content
--Ethan McCutchen.....Thu Oct 29 13:05:27 -0700 2009
Oh, ok, maybe this is not an issue then.
You can't put view/render options on it?
Maybe there is still a useful idea on this card. The idea of other transclusion processors and syntax.
For that, I am not saying more than one content, but that if the content is structured you could specify parts of it with this extended transclusion syntax.
--Gerry Gleason.....Thu Oct 29 15:20:15 -0700 2009
yeah, I've been thinking about something that may be related: making all parts addressible via inclusion syntax. (we're trying to nix using the word "transclusion" for anything user level -- it scares people)
For example, say you had a card named "A+B+C+D+E". We could reference parts this way:
_ = A+B+C+D+E (now _self)
_R = E (now _right)
_L = A+B+C+D (now _left)
_LR = D (now inaccessible)
_LL = A+B+C (now inaccessible)
_LLR = C (now inaccessible)
_LLL = A+B (now inaccessible)
_LLLR = B (now inaccessible)
_LLLL = A (now inaccessible)
--Ethan McCutchen.....Fri Oct 30 12:49:54 -0700 2009
This was implemented, see contextual names
You call it just "inclusion", then?
Now that's yet another dimension. That's cool. I'm thinking of an example of XML content in a card, and maybe something like
--Gerry Gleason.....Sat Oct 31 06:53:04 -0700 2009
looks to me like putting developer syntax into the wagneer space. I'd much prefer that be accomplished within a view. I think we should put a premium on keeping inclusion syntax simple. In fact, I'm hoping we'll have good GUI's for it eventually, though there are definitely tricky bits there.
--Ethan McCutchen.....Fri Nov 06 10:49:45 -0800 2009
Maybe, but why is that a bad thing? You seem to be under the illusion that wagneering is not development. It is. Proto-developers can take patterns from real wagneers and do a lot in the pure content parts of the space, but I really don't think non-developers will ever really grok the programming aspects of wagneering.
--Gerry Gleason.....Fri Nov 06 11:59:38 -0800 2009
wagneering is meant to empower people who aren't traditional developers. That's a huge part of the point. It's key to our mission and strategy. If something is too hard for them now, we have to make it easier. GUI searches, link and inclusion editors, etc.
--Ethan McCutchen.....Fri Nov 06 14:23:34 -0800 2009
I see your point, but I also think you need to consider the structures necessary to provide good wagneering interfaces. In other words asking "How can I provide that in cards and patterns", which is the way it is more or less now. Then we build the tools to sling around hands or cards under control of a wagneered GUI. It's all wagneering in a sense, but there is a place for wagneering for the wagneers. Advanced stuff that you can't use long before you can modify and extend.
--Gerry Gleason.....Fri Nov 06 18:06:21 -0800 2009
I can't get {{_self}} to work. This should work in a hard template (+*tform), right? I was trying to see if I could use it with the Forum Topic cardtype here: http://wiki.flowplace.org/wagn/Topic I thought at first that the form wouldn't update, but changing it temporarily to a soft template, I could see the updated conent, but {{_self}} seems to keep expanding to the template over and over when it should get the real card content. [ that was odd, I got a transclude recursion problem with my comment ]
--Gerry Gleason.....Sat Nov 07 09:03:13 -0800 2009
re the last comment: Gerry, that's exactly what I'd expect. One card has one content. When you refer to its content within its content, you get recursion. You could now use "raw", however, if you want what's in the database. But you won't have a way to access that...
--Ethan McCutchen.....Fri Apr 30 08:02:02 -0700 2010
Broadly, the more powerful Wagn becomes, the more that developers are going to want to use it as a development environment, and I think that's a good thing. Integrated and non-integrated development environments are one of my inspirations for all this stuff.
--John Abbe.....Mon Feb 21 11:19:43 -0800 2011
Hmm, maybe the Blueprint card I just added, Data Cards is obliquely related to this idea. It might be nice to be able to put little bits of ruby into card content for validations or triggering events, etc.
Remember that with cloud deploys, the process of actually extending Wagn as a developer has a bit more friction to it. We may want to distinguish some things you can do in cards as "developer" level with a distinct role to permission it.