Did you try the syntax suggested in the documentation you copied? Eg:
{{+some information|type: Pointer;item:link}}
Actually the more concise syntax is this:
{{+some information | type: Pointer | link}}
Each pipe ("|") indicates a deeper level of nesting.
Great! Believe it or not it never crossed my mind when I read that part. Something like {{+some information | type: Pointer | view: titled}} does work as expected and is quite intuitive.
I find multiple pipe to be more intuitive, as per http://wagn.org/Inclusion_Syntax
item any valid view name to be deprecated in favor of multiple-pipe syntax above
Also I was thinking about using the *default rule for cards and apparently it's already on someone's mind
type any valid Cardtype name may be deprecated?; set type via rules with *default setting
One more thing though, doing a {{+some information | view: titled}} brings in the title and everything.... is there a view that brings in the content of a card starting on the same line as the card, titled puts a line break plus the titled and then another line break and the content.... I just want the content which is one line on the same line as the position where I put the transclusion.
Yeah, the multiple pipe is a really cool extension of the original inclusion syntax. Very elegant in use and implementation.
Is there a view that brings in the content of a card starting on the same line as the card, titled puts a line break plus the titled and then another line break and the content?
"labeled". it's not a well advertised view yet because it's a bit new. Looks like we're going to keep it, but there may be some slight HTML and/or default CSS tweaks before we start to trumpet about it.
note that labeled uses "closed content" (another view), which means the content gets truncated at some point.
I see... Ended up using {{some card | view: content}}...
My main use scenario would me like this, taking a letter as an example:
"Dear {{+first name}},
I was nice meeting you {{+date of visit | type: Date}}. I hope you like the {{+gift}} I got for you.
Thanks,
{{my first name}}"
When using wagn like this it is very important for the transclusions to come in on the same line and not have a line break after them, for example in forms, invoices and general text related scenarios. Is this scenario supported?
The closest I could get is using {{+first name | view: link}} to get that on one line.
One note on this sort of thing. Views will often use div tags to logically separate parts of the view, and often the default view styles for divs are for blocks that start new 'lines'. The point of all this is that because it is based on styles, it can be changed with styles. Wagn adds classes to card divs to make it relatively easy to change the style for particular cards or sets of cards.
I think even the 'content' view wraps the content in a div, but maybe there is styling in the standard style cards that makes this an inline block.
Perhaps "core" view will work for you here?
Note that core views are static - you can't click on them to edit in place. To expand upon what Gerry was saying, dynamic views are wrapped in a special div that we call a "card slot". The "core" view has no slot.
So the options for this kind of use case are:
A. static views, or
B. custom CSS to make the slot display inline.
I see. I was looking through code and concluded the same. So it's the browser that really does this by default. Some time ago I encountered a situation and we converted to using span instead of divs... they provided all the stuff and didn't have this behavior. I can't tell is this is possible in wagn.
Later edit: sadly I checked out the "core" option and the output is the same... for Basic cards.
Also tried to convert the {{+first name}} card to PlainText and used "core" and now it replaces on the same line.
When it used to be a "Basic" card it automatically wrapped everything around a P and /P paragraph html tag and it got shifted to the next line. So it was the behavior of card that impeded this. I then converted it to the HTML card.
Conclusion: Because of the Basic card behavior (or TinyMCE for that matter) of wrapping everything in P /P markup you are essentially locked out of using Basic cards (interpreted HTML) and stuck to using HTML cards directly or PlainText. I think this is a TinyMCE problem... it would be nice to have it wrap everythin in a SPAN or something else that does not do carrige return the first time. Or have a default option in TinyMCE drop down menu of selecting Heading 1,2 and Paragraph to have "Unformatted" to the list... or one would have to edit HTML cards directly or click the Html button in TinyMCE to take out the P /P wrapping.
Conclusion 2: Apparently the above is only part of the problem, using anything other than "core" totally wraps everything in a div which by default means a new line. So even if I manage to deal with TinyMCE, WAGN itself has this behaviour built in and looking at the div you seem to be using it for a lot more than just formatting. Hmmmm... this is interesting... I was using this with a combination of Pointers and other cards to see if the system can get information deep from other cards transparently... this div thing is an issue. Time will tell I suppose. I'll continue digging.
The p tags stuff is due to tiny_mce. We haven't figured out a solution or replacement for that. I hate it, except that it is better than having users deal with all the html tags manually. A Phrase card is a lot like a Basic card, but no tiny_mce and no p tags.
Those tags are really a bad fit for wagn because when you include {{some card}}, and it has p tags in it, they are now nested inside other p tags and it isn't even valid html.
Hmm... can't really tell since I haven't used tinyMCE at all but it seems to be a general problem. Do these help:
http://stackoverflow.com/questions/13841986/tinymce-adding-p-tags-automatically
http://stackoverflow.com/questions/17058644/remove-the-extra-p-tag-in-tinymce
http://stackoverflow.com/questions/5211687/tinymce-problem-extra-paragraphs
Any luck?
PS. Can one replace tinyMCE? Is it a card, if you opt to use another editor...
Yes, it is a general problem. You could replace it, but with what? That's the crux of the problem, even though many people hate it for things like this, there haven't been any good enough replacements. Maybe there is one, but it isn't that well known yet, or not working well enough yet.
I would like to recommend http://www.wymeditor.org as I’ve used it before, it was created to generate perfectly structured XHTML strict code. There is also (yahoo) YUI which has evolved into a full-blown library that yahoo actually uses, but one can use only the editor http://yuilibrary.com/yui/docs/editor/
These are the best I think, an honorable mention goes to CKEditor but I found it rather heavy.
Check out this list for other alternatives: https://github.com/cheeaun/mooeditable/wiki/Alternative-Javascript-WYSIWYG-editors
Forgot that Mercury at the bottom of the list... it's a gem, a Ruby gem that is... :)
http://jejacks0n.github.io/mercury/
Mercury allows you to edit a section of HTML directly in the web browser through a WYSIWYG editor.
cool. sounds like we should reopen the discussion on editors. Perhaps we should put this in an Idea card?
I'm personally pretty open to changing editors, and it could even happen relatively quickly so long as it doesn't break existing sites. I'm curious as to whether they also use the editable divs built into the browsers and have similar p tag issues, but it sounds like you're hopeful they don't.
Fwiw, it would be straightforward to implement a cardtype for one of these and then edit *all+*default and change it to that. There are actually very few places in the code where "Basic" is referred to; almost everything comes from that *all+*default rule. Cardtype and User do both have "include Basic", but that should only take effect on unstructured Cardtype and User cards.
I will say that I edited *all+*default, and the "Something" behavior that Mircea described in the other ticket still happened, but I think that might be a caching issue?
I would also note that we may consider having different default editors for *structure rules, since it's even more important there than elsewhere that we get rid of the p's.
Added an idea card here: Changing text editors
awesome. thanks!
I would also note that we may consider having different default editors for *structure rules, since it's even more important there than elsewhere that we get rid of the p's.
--Ethan McCutchen.....2014-09-19 16:21:54 +0000
Wow exactly... I bumped into this exact issue and wanted to change the "CardType" to inherit from HTML instead of Basic to check for that. Not possible for now...
I've pasted some technical details into the Changing text editors idea card.