Bootstrap3 in Tiddlywiki?

[Joshua Fontany]

Hi guys,

I'm investigating the features of this awesome JSON Editor plugin: https://github.com/btheado/jsoneditor

One of the neat features (arrange inputs in a grid view) would work well for my RPG Character Database project, to clean up the Character Editor UI.

So far, the author has tried to just copy the CSS out of boostrap and put it in a tiddly, but that did horribly non-euclidean things, apparently: https://github.com/btheado/jsoneditor/issues/1#issuecomment-153214059

I noted that the Boostrap3 package has a *.js component, and that would need to be integrated into TW5. Would this be similar to the FontAwesome stuff? (Still have learning that on my to-do list.)

Best,
Joshua F

[Joshua Fontany]

Hmm, I think I found an answer to this. I'll check the TiddlyWikiDev group to see if there's another way to get the Grid option working...



On Wednesday, September 18, 2013 at 9:13:10 AM UTC-7, Jeremy Ruston wrote:

I did indeed use Bootstrap for an earlier version of TiddlyWiki5. I abandoned it for several reasons:

* Bootstrap markup uses IDs to tie elements together, which doesn't work in dynamic environments like TW5 where it's hard to ensure that IDs remain unique

* As Mario says, the JS code in Bootstrap is useless for TW5 because it doesn't fit into the TW rendering structure

* Bootstrap doesn't (or didn't when I was working with it) permit elements like tabs to be resized

* Bootstrap is incredibly fussy about elements needing to be direct descendants of one another and so doesn't tolerate TW5's additional wrapper elements

* Bootstrap uses Less.css to generate CSS whereas in TW5 it makes more sense to reuse the existing wikitext parsing pipeline

TW5 still uses normalise.css, which is also a part of Bootstrap. It does a great job of smoothing out the differences between browsers

Best wishes

Jeremy

On Wed, Sep 18, 2013 at 1:10 PM, Eskha <khask...@gmail.com> wrote:

Thank you for your nice answer.

In fact, what I had in mind was to be able to create a theme (mainly an alternative page template) using CSS elements like the navbar, the span[n], the dropdown menu, the icons, ... from the Bootstrap CSS.
If I understand correctly your answer, I could still be able to do so by building and including a customize version of Bootsrap [1]  which should not override components created by the wikitext renderers. Is it correct ?

Best regards.

Eskha

[1] http://getbootstrap.com/customize/

Le mardi 17 septembre 2013 13:49:27 UTC+2, PMario a écrit :

On Tuesday, September 17, 2013 9:11:42 AM UTC+2, Eskha wrote:

As far as styles are concerned would it be possible to use twitter bootstrap CSS and derived themes inside TW5 or are there some technical difficulties doing so ?
(btw I think it was an option you mention when you have started TW5, wasn't it ?)

It was part of TW5, but imo it clashed with the structure created by the wikitext renderers. ... For my taste twitter bootstrap is way to bloated allready and it defines a concept, that is very different to TW5. eg: It contains javascript, that handles sliders and tabs. But the TW tab and slider handling is defined in a totally different way. Tabs and sliders will be wikitext not html. 

-m

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

[Tobias Beer]

Hi Joshua,

 

Hmm, I think I found an answer to this. I'll check the TiddlyWikiDev group to see if there's another way to get the Grid option working...

My first question would be: Why JSON? ...as currently JSON support in TW is limited.

The cleanest most TiddlyWiki approach here would be using tiddler fields, imho.

Best wishes,

Tobias.

[Joshua Fontany]

Hi Tobias,

Good question. Maybe I'm not approaching this project quite the right way.

(As a quick aside, I'm probably going to use Array objects for those elements that the Grid view would be useful for. So I've got a workaround for this specific Grid issue, but let me explain my intended data-design a bit better.)

This JSON Editor widget was very appealing because of the JSON-Schema functionality, where I can plan out how the various bits of character data are stored, save these schema as separate tiddlers, and then display editors-widgets to quickly edit "parts" of characters on the fly. I may have to write my own widgets for the "display view" of the data instead of the "edit view" of the data

Here's my data-structure plan so far:

• Each "characterName" tiddler in my wiki will have an accompanying "characterName/gamesystem/data" tiddler.
  
• The dataTiddler's text field will be the character's "Long Description".
• The dataTiddler will have other fields to store more character data as JSON objects, such as !!attributes, !!health, !!inventory, !!factions, !!relationships, etc.
• The main Character tiddler will then use a skeleton tiddler to transclude the data into a "Character Sheet" with tabs for sections, character-picture & descriptions, stats, etc.
• The "Character Sheet" skeleton will have buttons to enable or disable a JSONEditor widget to edit just there sub-sections independently. For example, we dont' want to mistakenly edit the Character's attributes when we add/remove things from their Inventory.
• There will be another set of Tiddlers that the user will step through to initialize a new character and data tiddler for a new character, where I can re-use these schemas or extend them.

On Thu, Nov 5, 2015 at 12:34 PM, Tobias Beer <beert...@gmail.com> wrote:

Hi Joshua,

 

Hmm, I think I found an answer to this. I'll check the TiddlyWikiDev group to see if there's another way to get the Grid option working...

My first question would be: Why JSON? ...as currently JSON support in TW is limited.

The cleanest most TiddlywWiki approach here would be using tiddler fields, imho.

Best wishes,

Tobias.

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/uZUsq7dgJ3E/unsubscribe.
To unsubscribe from this group and all its topics, 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/c32e3e27-511f-49d2-a3f3-3a414cee741c%40googlegroups.com.

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

[Tobias Beer]

Hi Joshua, 

• The dataTiddler will have other fields to store more character data as JSON objects, such as !!attributes, !!health, !!inventory, !!factions, !!relationships, etc.

I see, that's the crucial bit I didn't get the first time around... making me think that you really don't need any data tiddler, it's just how you chose to design it. You could as well have stuck the long-description into a field as well.

Now to the real question: What makes bootstrap any of your concern? What do you need it for? Why would you need any of its css?

Musings:

Yes, being able to define an editor for a sophisticated fields containing json while specifying the schema defining whatever it is to contain is great. On top it would be great if TiddlyWiki can actually read / parse / address even write any such field-content-json via TextReferences or perhaps some macro that does so, e.g. <<json SomeTiddler some-json-field ".type">>. The problematic bit is that you can structure that json anyway you want but eventually you really don't want that. You want well-defined objects that respect a schema that some viewer know how to handle or some editor or other respects. Not having studied all that in detail, it appears, jsoneditor is one such interface.

Best wishes,

Tobias.

[Joshua Fontany]

Thanks for the help and the comments, Tobias.

I had originally wanted to access the "grid" layout feature of the Json Editor to clean up complex editors for the character data. The "grid" feature requires a separate CSS module to work (bootstrap or foundation). I think at this point that investigating bootstrap was a bad choice/distraction. The Array object in the Editor can serve to group and manage more complex data editors in TiddlyWiki.

I'll consider this topic closed. If I have any other questions (such as about my "Character Sheet" view-mode widget to accompany the Json Editor edit-mode widget) I'll start a new thread.

Thanks!

[Tobias Beer]

Hi Joshua,

 

I'll consider this topic closed.

Not so fast. :D

The "grid" feature requires a separate CSS module to work (bootstrap or foundation).

What happens without such a "module"?

...and then what is that "module" to provide so that you can use either this or that "framework", e.g. bootstrap or some other?

Best wishes,

Tobias.

[Joshua Fontany]

 

I'll consider this topic closed.

Not so fast. :D 

Cool. I had been digging around the original Json Editor stand-alone code, maybe I can point to something useful.

Warning: Code Blocks coming up. :D

 

The "grid" feature requires a separate CSS module to work (bootstrap or foundation).

What happens without such a "module"?

...and then what is that "module" to provide so that you can use either this or that "framework", e.g. bootstrap or some other?

When I tried @btheado's method (below), I also got overlapping elements (& I think he's right about conflicting CSS definitions...). See attached jpeg for a screenshot.

1. Open http://netdna.bootstrapcdn.com/bootstrap/3.0.3/css/bootstrap.min.css in your browser and select all and copy to clipboard
2. Open https://btheado.github.io/jsoneditor.html in your browser
3. Create new tiddler titled "bootstrap" or whatever.
4. Paste clipboard contents into the body of the tiddler
5. Add the $:/tags/Stylesheet tag to the tiddler
6. Save the tiddler

The stylesheet should now be applied and the json form becames misaligned and unreadable :-(. Not sure if it is due to some conflict the the tiddlywiki styles or if it is some other problem.

The easiest way to trigger this layout option is to include "format": "grid" in the object's schema.

 So, I dug into @jdorn/json-editor's source looking for references to the "grid" option. There is one reference in the "object.js" sub-file of the "jsoneditor.js" (distribution package) in the "layoutEditors: function()":

if (this.format === 'grid'){ do stuff to make grid }
// Normal layout

else { do other stuff to make normal layout}

Withing the If statement, there is are this.theme.getGridRow() calls (which I think is where the bootstrap or foundation *.js files are referenced):

// Layout the form for Grid format

container = document.createElement('div');

for(i=0; i<rows.length; i++) {

var row = this.theme.getGridRow();

container.appendChild(row);

for(j=0; j<rows[i].editors.length; j++) {

  var key = rows[i].editors[j].key;

  var editor = this.editors[key];

  

  if(editor.options.hidden) editor.container.style.display = 'none';

  else this.theme.setGridColumnSize(editor.container,rows[i].editors[j].width);

  row.appendChild(editor.container);

  }

}

While the else{} block had this:

ontainer = document.createElement('div');

      $each(this.property_order, function(i,key) {

        var editor = self.editors[key];

        if(editor.property_removed) return;

        var row = self.theme.getGridRow();

        container.appendChild(row);

        

        if(editor.options.hidden) editor.container.style.display = 'none';

        else self.theme.setGridColumnSize(editor.container,12);

        row.appendChild(editor.container);

      });

Looking in the included theme.js sub-file, we have this:

getGridRow: function() {
    var el = document.createElement('div');
    el.className = 'row';
    return el;
  }

To test the differences, I simplified the schema in @jdorn's sample (http://jeremydorn.com/json-editor/), and inspected the source code with and without the Grid option set.

Without "format" : "grid" set:

<div class="well well-sm" style="padding-bottom: 0px;">

<div>

<div>

<div class="row">

<div data-schematype="string" data-schemapath="root.name" class="col-md-12">

<div class=" form-group">

<label class=" control-label">name</label>

<input type="text" class="form-control" pattern=".{4,}" name="root[name]">

<p class="help-block">First and Last name</p>

</div>

<div/>

</div>

</div>

<div class="row">

<div data-schematype="integer" data-schemapath="root.age" class="col-md-12">

<div class=" form-group">

<label class=" control-label">age</label>

<input type="text" class="form-control" name="root[age]">

</div>

<div/>

</div>

</div>

<div class="row">

<div data-schematype="string" data-schemapath="root.favorite_color" class="col-md-12">

<div class=" form-group">

<label class=" control-label">favorite color</label>

<input type="color" class="form-control" data-schemaformat="color" name="root[favorite_color]">

</div>

<div/>

</div>

</div>

<div class="row">

<div data-schematype="string" data-schemapath="root.gender" class="col-md-12">

<div class=" form-group">

<label class=" control-label">gender</label>

<select class="form-control" name="root[gender]">

<option value="undefined"> </option>

<option value="male">male</option>

<option value="female">female</option>

</select>

</div>

<div/>

</div>

</div>

</div>

</div>

</div>

With "format" : "grid" applied:

<div class="well well-sm" style="padding-bottom: 0px;">

<div>

<div>

<div class="row">

<div data-schematype="string" data-schemapath="root.name" class="col-md-5">

<div class=" form-group">

<label class=" control-label">name</label>

<input type="text" class="form-control" pattern=".{4,}" name="root[name]">

<p class="help-block">First and Last name</p>

</div>

<div/>

</div>

<div data-schematype="integer" data-schemapath="root.age" class="col-md-2">

<div class=" form-group">

<label class=" control-label">age</label>

<input type="text" class="form-control" name="root[age]">

</div>

<div/>

</div>

<div data-schematype="string" data-schemapath="root.favorite_color" class="col-md-3">

<div class=" form-group">

<label class=" control-label">favorite color</label>

<input type="color" class="form-control" data-schemaformat="color" name="root[favorite_color]">

</div>

<div/>

</div>

<div data-schematype="string" data-schemapath="root.gender" class="col-md-2">

<div class=" form-group">

<label class=" control-label">gender</label>

<select class="form-control" name="root[gender]">

<option value="undefined"> </option>

<option value="male">male</option>

<option value="female">female</option>

</select>

</div>

<div/>

</div>

</div>

</div>

</div>

</div>

So it seems to change how these Row elements are nested, and applies a CSS class to define how many columns this element takes up (out of the 12 column max used in the layout logic).

Hope that helps to understand this issue.

[Joshua Fontany]

Ok, I've tried the same test with @btheado's TiddlyWiki JsonEditor, and am not getting the different Row element layout, and not getting the class tags.... hmm. This points to those function not existing or not getting called appropriately in his version (those sub-files may not have been included in the TiddlyWiki version).

--

You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/uZUsq7dgJ3E/unsubscribe.
To unsubscribe from this group and all its topics, 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/e8bf275c-d8ce-43f8-9c9d-a6f8e3c77f14%40googlegroups.com.

[Joshua Fontany]

Oooops, correction: I _am_ getting the Row nesting behavior. I _am_not_ getting the CSS class tags applied.

[Tobias Beer]

Hi Joshua,

I have also commented here: https://github.com/btheado/jsoneditor/issues/1

Perhaps discuss technicalities over there to keep the tech-talk low in this group, or move it to TiddlyWikiDev.

I would assume the problem lies in how json-editor detects what framework/version is being used and to assign the corresponding css classes accordingly. I believe you need to:

1. declare that manually
   
2. extract / import all the required row / column css from whichever framework you chose as your favourite

This issue suggests that you do, in fact, declare that manually via the theme property.

Looking at the code of the widget for TiddlyWiki, I am thinking that this function is problematic / incomplete:

JSONEditorWidget.prototype.getOptionsFromAttributes = function() { ... }

1. first of all, it should possibly not interpret options as text-references
• but use the default way of declaring them via option:{{!!foo}} not option:"!!foo"
2. it doesn't seem to handle any options other than schema and jsonOutput
• instead, it should read any arbitrary attributes not specifically declared upfront
• e.g. also theme: "bootstrap3" iconlib: "fontawesome4"
• if needed, btheado could iterate over an array of supported (tested) options, e.g
• params = ["schema","jsonOutput","theme","iconlib"]
• and then perhaps use switch to handle cases, if necessary
• however, the current widget architecture does allow to read / catch undeclared attributes within the widget
• without them being predefined as actual widget properties
• e.g.: $:/core/modules/widgets/action-setfield.js#L60
• see the each loop where any field not prefixed $ is interpreted as a tiddler-field-name
• compare: ActionSetFieldWidget (last "parameter)
• json-editor should do the same thing
• use attributes prefixed with $ for any that need special handling
• for now, I don't think there should be any, except maybe $json instead of jsonOutput
• the special handling for schema and jsonOutput should be removed, imho
• schema could be initialized as "{}" and then overwritten with any declared attribute
• just use any attributes not prefixed $ as options for the json-editor

Tobias.

[Joshua Fontany]

Awesome, I was on the right track then. Just started looking at the JSONEditorWidget.prototype.getOptionsFromAttributes function as the problem area when trying to figure out where to set the theme. If that can be set and the appropriate CSS can be extracted from bootstrap it should probably work. :D

[Brian Theado]

Tobias and Joshua,

Thanks for all the analysis and feedback. You've done all the work to identify the issue and show the way toward a fix. Nice work. I will take a look maybe this weekend.

> but use the default way of declaring them via option:{{!!foo}} not option:"!!foo"

[...]

> the special handling for schema and jsonOutput should be removed, imho

The {{!!foo}} style would work for the schema attribute because that one is readonly and only needs a value. The jsonOutput attribute however is read-write. The form is populated from some initial json and as the user makes changes via the form, the resulting json is updated and saved back to the tiddler. So I thought I would need a pointer to where the json should be stored and a value wouldn't work there.

I guess I could make it more like an edit widget (since it is really about editing json) and associate it with certain tiddler types (any application/json which also had a schema referenced?). If that would work, it would probably be more consistent with the rest of TiddlyWiki.

Brian

[Tobias Beer]

The jsonOutput attribute however is read-write. The form is populated from some initial json and as the user makes changes via the form, the resulting json is updated and saved back to the tiddler. So I thought I would need a pointer to where the json should be stored and a value wouldn't work there.

Makes sense and using a TextReference to encode this also does. So, of course, I'd keep it. Perhaps double check that it supports full TextReferences. Eventually you don't want to parse this text reference ever, but just "write some text" to it, no matter what tiddler or field or data index.

I guess I could make it more like an edit widget (since it is really about editing json) and associate it with certain tiddler types (any application/json which also had a schema referenced?). If that would work, it would probably be more consistent with the rest of TiddlyWiki.

Sounds reasonable. Again, perhaps there's a (better) way to implement some core interfac in terms of "read text from reference" and then "write text to reference"... rather than you or any other plugin author having to write that code. I'd presume this stuff exists. Perhaps ask @JEREMY as to where to find it, e.g. @ mention him on that GitHub issue.

At second thought, I guess $tw.wiki.getTextReference() and $tw.wiki.setTextReference() in wiki.js provide the above interfaces.

Best wishes, Tobias.