Is there a way to force wikification of text?

[c pa]

What is the internal function that wikifies text?

I want to build a javascript macro to force wikification of text. (because I'm running into situations where no matter how many macro levels I call into I can't get the string wikified)

I searched the code for the string "wikify" and there is no available function to call.

The help text has this:

Despite the term "variable", each snippet is a constant string. The apparent variability is actually the result of the presence of multiple variables with the same name in different parts of the widget tree.

Macros are a special form of variable whose value can contain placeholders that get filled in with parameters whenever the macro is used.

By themselves, the snippets are not parsed as WikiText. However, a variable reference will transclude a snippet into a context where WikiText parsing may be occurring.

may may may. Arrrgh I'm going nuts. I need to force the wikification of the text

[Jed Carty]

A macro to force wikification would be awesome.

I had some similar questions that got answered over on the dev forum here and here.

You can look at the code for the calendar widget here (line 163 to line 167 should be the relevant part), and for the trigger actions plugin here (the evaluateExpression function should be the relevant part) as examples. The calendar widget is probably the more helpful of the two.

Hopefully that is helpful.

[PMario]

Can you provide an example text, that is not wikified, so we can actually test it.
It would make the possibility to help much easier.
-m

[c pa]

PMario

What I want to do is build a macro that will evaluate and return the results of an expression such as {{!!fieldname}} within the current context. That would solve so many of my macro problems. I've wasted too many days working out the context differences between <<variableName>>, $variableName$, $(variableName)$, <$macrocall $name="variableName"> etc. etc. etc. Because macro strings are not evaluated within the macro, only after they have been returned into the calling tiddler context.

Here's the actual use case:
We are migrating data from one application to another

1. I have a type="application/json" tiddler containing name/value pairs where name translates into value. It is tagged "xlate"
2. I have 2 fields in that tiddler from = "sourcetablename" and to = "targettablename"
3. I have 2 other tiddlers "sourcetablename" and "targettablename" (for example except I have 100+ tables)
.   a. The sourcetablename tiddler has a list field listing the target tables into which the data is going to be moved
.   b. The targettablename tiddler has a set of fields (select, from, where, orderby, screenname) that list the fields that are being displayed on the screen
4. I have a viewtemplate that constructs a set of sql statements that are going to allow an analyst to query the source tables, query the target tables, look at the screens and make sure that the data has been migrated correctly

Yay. That works. Total pain to make work but it works and its saving me tons of pain managing a thousand or so test cases

Now I want to display that same text in another tiddler and all of the macro statements I worked so hard to develop for the one use case don't work in this new context because the snippets are not parsed as WikiText. Instead they are returned unevaluated through the macro tree and only evaluated in the calling context.

And you can't have a statement <$macrocall $name="macroname" variablename="<$macrocall $name="anothermacro"/>" />

I think there's a whole github discussion about this.

[PMario]

On Saturday, April 18, 2015 at 1:48:39 AM UTC+2, c pa wrote:

What I want to do is build a macro that will evaluate and return the results of an expression such as {{!!fieldname}} within the current context. That would solve so many of my macro problems. I've wasted too many days working out the context differences between <<variableName>>, $variableName$, $(variableName)$, <$macrocall $name="variableName"> etc. etc. etc. Because macro strings are not evaluated within the macro, only after they have been returned into the calling tiddler context.

I think the problem here is, that the TW definition of the "current context", is different to what you expect. (mainly for performance reasons) ... But the currentTiddler context is just a definition and can be changed / extended by the user using core widgets.

.. Reading your 1,2,3 description, I think there is no new macro needed. ....

but I'm still not sure, what TW does and, how your data / dataflow looks like.

Let me explain, what I understand:

There are 2 different types of json config tiddlers.
 - one defines a "from", "to" relation
 - second ... I can't construct in my mind, but it is different because it is tagged "xlate"

 - There are 100+ sourcetablename and targettablename tiddlers that contain the a data to create an "anlyst view".
 - sourcetablename uses the "list" field to point to target tables
 - targettablename uses fields to define, what should be shown to the analyst.
 - That  "view" can be used by an analyst to see if data table export / import mechanism was done right.

The data "migration" is done outside of TW but the data migration mechanism created the tiddlers, that are used to create the views.

... is that right?

And you can't have a statement <$macrocall $name="macroname" variablename="<$macrocall $name="anothermacro"/>" />

I think there's a whole github discussion about this.

Yes, you can, but it looks different.

-------------

Can you provide a small example tiddlywiki, that contains some tiddlers with real data, that allows us to follow your data flow.

 - I think of the 2 JSON tiddlers (one standard and one tagged xlate)
 - eg: 3 sourcetablename, 3 targettablename containing minimal data.
 - We probably may need the views and viewtemplates too.

I think, there is a conceptual problem. ... eg: {{!!fieldname}} is a very high level abstraction for the <$transclude> and / or <$view> widget. So imo {{}} shouldn't be used in your macros. IMO we need to find the right widgets for your macros.

TW has a very powerful iteration tool. The <$list> widgets. .. By default it sets its context to the "currentTiddler" variable. But its also possible to use a different variable name here. So you can nest 2 or more list widgets without loosing the parents context. ...

but since I can't really grasp your data structure, it's very hard to tell, how an easy to use and working configuration can look like.

-mario

[c pa]

PMario,

I have set up my public wiki with the elements I'm working on. here http://cpashow.tiddlyspot.com/

With comments

[Stephan Hradek]

I couldn't follow that. Maybe you can set up a static tiddler there whcich describes your workflow and what you're trying to achieve?

[Jeremy Ruston]

Hi c pa

> I have set up my public wiki with the elements I'm working on. here http://cpashow.tiddlyspot.com/

If I'm understanding correctly, what you're trying to do is pretty cool: to be able to document a source and destination SQL schema and have TW generate the necessary SQL statements to migrate the data.

> I want to build a javascript macro to force wikification of text. (because I'm running into situations where no matter how many macro levels I call into I can't get the string wikified)

JavaScript macros return a string of text; they cannot control how or whether what they return is later wikified.

I don't quite understand the underlying problem. Can you point to the part that doesn't work?

Best wishes

Jeremy.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at http://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/16863eb4-156a-446c-88de-40bc196e8e88%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Jeremy Ruston
mailto:jeremy...@gmail.com

[c pa]

Jeremy,

I'm pretty sure that there's no problem that can't ultimately be solved with clever macros and cleverly formatted tiddlers. I've been trying to find a problem I can't solve on my own. Unfortunately I pick a problem, spend 2 hours on it and then figure out the solution. So I'm working through the code one problem at a time, rewriting my code, separating it into global macros, all the stuff that well written code should do.

But, given that I realize all problems can be solved eventually, many problems could be solved in 5 minutes instead of 2 hours if I could force the evaluation of some text string during the execution of a macro rather than after it has been returned to the base context.