xFieldsPlugin

[Tobias Beer]

Hello everyone,

Reminded by "whatever" [1] of my earlier idea [2] I have set out to
create two new spaces on tiddlyspace, namely:
*xfields [3]
*xfieldsdev [4]

While the former doesn't contain much yet, I started creating the
latter as a kind of drawing board for the general idea of
xFieldsPlugin, which basically will provide the following in the
future...
*Defining Generic Fields
*Relating Generic Fields To Tiddlers
*Auto-Generating Template Elements

I would highly welcome your feedback as users as well as developers
before I actually start coding. So, I invite you to have a look at
[4]. Feel free to "reply to" any of the tiddlers on the drawing board,
to become a member of that space (so you can put some of your ideas
into context) or to simply reply here as to what features and concepts
you would prefer, need, wish for, need clarification for, try to
avoid, etc...

As I think this will be a very useful plugin in the future, I am
looking forward to your feedback.

Cheers, Tobias.

[1] http://groups.google.com/group/tiddlywiki/browse_frm/thread/460b528893a92b24
[2] http://groups.google.com/group/tiddlywiki/msg/24d2b4278c8396e8
[3] http://xfields.tiddlyspace.com
[4] http://xfieldsdev.tiddlyspace.com

[colmjude]

Sounds like a good idea Tobias.
Have you seen Jon's EditFieldsPlugin[1]? It allows a user to easily
define new custom fields to any tiddler whilst in edit mode. It might
be a useful starting point.

Colm

[1] - http://tiddlywikidev.tiddlyspace.com/#EditTemplateFieldsPlugin

[Tobias Beer]

Yes, I'm aware of that handy tool of Jon's called
EditTemplateFieldsPlugin. It even is already referenced at the bottom
section "Alternatives" of my "Welcome" tiddler [1]. :o)

Please let me know of any other alternatives that I might have
missed. I'm keen on what you and others actually expect or hope for
this plugin to provide, esp. in terms of things you keep missing from
existing plugins.

In short, I'd like to get a most comprehensive idea of the undertaking
before actually going down the road of designing and implementing
anything. Eventually, such "field data" might not just be looked at as
the simple text strings they actually are, but instead in combination
with data type qualifiers that would be introduced by this plugin,
designed to be accessible via adequate interfaces to other plugins
wanting to make use of said data.

So an interesting question would be: How far should this plugin go? At
what point would you stop and leave the rest for other stuff possibly
built on top of such a "data driven framework"?

Cheers, Tobias.

[1] http://xfieldsdev.tiddlyspace.com/#Welcome

[tiddlygrp]

On Feb 16, 2:50 pm, Tobias Beer <beertob...@googlemail.com> wrote:
>
> So an interesting question would be: How far should this plugin go? At
> what point would you stop and leave the rest for other stuff possibly
> built on top of such a "data driven framework"?

Hi Tobias,

I think your plugin is a very good idea. When you are going to add
data types, you should think of using json, because that can be easy
and SAFE parsed. Udo (abego) did this also with his data tiddler
plugin. I think this is a good example, although the implementation
is different because the data reside in the tiddler text field.

On the other hand I would think that adding data types is not really
wiki like. Maybe there is a concept of semantic types to use for it.

Vlak

[Tobias Beer]

Hi Vlak,

Thanks for the input!

1) Do you know in what context or for what usecase Udo did add a JSON
data type? Did he use such data later on to generate js objects in an
editable fashion? In general, I'd think something special /
sophisticated like that really begs for being an addon to the plugin.

Although working with indentation in TiddlyWiki's input-textarea is
not such a pleasure, I was wondering if it were good to have the
custom fields definition itself be based on a JSON format, rather than
simple text chunks split by some arbitrary, yet to be defined
separators. But then using an envaluated js object might be more
suitable as it has more lose requirements as for syntax requirements.

2) "On the other hand I would think that adding data types is not
really wiki like."

What do you mean with "not wiki like"? I would call "wiki like"
whatever can be used in the framework provided by a wiki. I mean,
TiddlyWiki in itself is not as "wiki like" as other wiki frameworks.
What I mean with that is that - due to it being a mostly single user,
javascript implementation - its focus to some extend is shifted
towards dynamic, scripted elements, as opposed to a focus on "mere"
content and content structure alone in an open or multiuser editing
process. However, TiddlySpace (or rather TiddlyWeb) is a big leap
forward in the direction of a multiuser "wiki" environment.

3) "Maybe there is a concept of semantic types to use for it."
Please expand on this as I am not sure where you're headed.

Cheers, Tobias.

[tiddlygrp]

Hi Tobias,

On Feb 16, 5:11 pm, Tobias Beer <beertob...@googlemail.com> wrote:
> 1) Do you know in what context or for what usecase Udo did add a JSON
> data type? Did he use such data later on to generate js objects in an
> editable fashion? In general, I'd think something special /
> sophisticated like that really begs for being an addon to the plugin.

Udo used this for html form templates. You can easily build forms and
prototype tiddlers and use it as a simple db.

>
> Although working with indentation in TiddlyWiki's input-textarea is
> not such a pleasure, I was wondering if it were good to have the
> custom fields definition itself be based on a JSON format, rather than
> simple text chunks split by some arbitrary, yet to be defined
> separators. But then using an envaluated js object might be more
> suitable as it has more lose requirements as for syntax requirements.

JSON is a programming language format and allows you to specify e.g.
string or number as type. For users it is interesting to specify e.g.
in a tiddler about country the type capital city.

> 2) "On the other hand I would think that adding data types is not
> really wiki like."
>
> What do you mean with "not wiki like"? I would call "wiki like"
> whatever can be used in the framework provided by a wiki. I mean,
> TiddlyWiki in itself is not as "wiki like" as other wiki frameworks.
> What I mean with that is that - due to it being a mostly single user,
> javascript implementation - its focus to some extend is shifted
> towards dynamic, scripted elements, as opposed to a focus on "mere"
> content and content structure alone in an open or multiuser editing
> process. However, TiddlySpace (or rather TiddlyWeb) is a big leap
> forward in the direction of a multiuser "wiki" environment.

I meant data types as in programming languages. In a wiki everything
is parsed at view time. Only at this moment data types are created
from strings.

>
> 3) "Maybe there is a concept of semantic types to use for it."
> Please expand on this as I am not sure where you're headed.
>

Have a look at semantic mediawiki. Basically you can attach a type to
some text, e.g. {Paris {capital-of-country France}}. Once you have
this you can reason with the data, but you need (a lot) additional
software.


> Cheers, Tobias.

[Tobias Beer]

Thanks for the feedback, Vlak.

I am aware of what JSON is, which is a serialization format for data,
and as such a direct competitor to xml ...rather than a programming
language.

> Udo used this for html form templates.
> You can easily build forms
> and prototype tiddlers and use it as a simple db.

Could you point to examples that make use of this in the sense of "a
simple db"? Or do you refer to how FormTiddlerPlugin and
DataTiddlerPlugin generally work? I wouldn't know if they do so on the
basis of JSON... I just never have used them as I didn't like the idea
of hidden "data" sections in a tiddler's body... as nowadays there are
fields and slices and sections.

However, I am very inclined to study both plugins as to their inner
workings and the examples Udo provides along with them.

> I meant data types as in programming languages.
> In a wiki everything is parsed at view time.
> Only at this moment data types are created from strings.

In the context of xfields plugin, I am not sure if "data type" is the
correct nomenclature as it is really more of a "field type"... giving
directives as to how to edit or display a given set of field values.

> Have a look at semantic mediawiki.
> Basically you can attach a type to some text,
> e.g. {Paris {capital-of-country France}}.
> Once you have this you can reason with the data,
> but you need (a lot) additional software."

I see. I guess such semantic qualifiers, would probably go in addition
to any of the available configuration parameters that will be
available to extended fields as automated by xfields, see section
"Available field parameters" at...

http://bit.ly/e9uER3

Cheers, Tobias.

[Tobias Beer]

Some additions to the concept, as of today...

* detailed definitions for field types
* a specification for available parameters that can be specified for
any xfield
* a new and handy field type called "group"
* specific examples for associating tiddlers with xfields

Please keep on revising...

http://xfieldsdev.tiddlyspace.com


Cheers, Tobias.

[octw]

Hi Tobias,

Looks great. I'm thinking the possibility of sorting. Sorting the
fields in-tiddler. Something like a simple fET but focus on fields.
For each fields...

Cheers, octw

[Tobias Beer]

Hi octw,

My idea goes more in the direction of providing a means to give
certain types of tiddlers certain additional fields, e.g.:

A tiddler may be tagged "contact". Thus it might do well with the
following xfields:
-> name
-> address
-> email
-> phone
-> website
-> birthday

These are regular extended fields, yet with a definition in some
config tiddler with respect to the xfields plugin.

The general tiddler body would thus be saved for notes or actual
content and there would be no need for any tiddler templates or
possibly misspelling of any slices or sections one later on wants to
use in a fET, for example.

I would not want the edit controls for these fields to be randomly
sorted but rather layed out in a predefined order. I would also not
want to see any other fields that some plugin (or the TiddlySpace
core) might have saved with the tiddler, unless specified.

Besides, EditTemplateFieldPlugin already does provide a means to see
all tiddler fields, the way you suggest. On the other hand, I am
considering implementing something that allows you to see and edit all
other extended fields, those that are not xfields associated with a
tiddler, via...

slider "misc fields" >
field1:textarea1
field1:textarea1

Cheers, Tobias.

[PMario]

Hi Tobias, Hi Folks,

An interesting thread. Dave Gifford is heavily using
DataTiddlerPlugin. And the "backend/lowlevel functions" are invisible
to the novice user. If you have a detailed look at his bibblywiki [1],
and you _really_ analyse it (TiddlerTweaker will be needed, because
most of it is excludeLists ...). It is quite interesting, how things
are done there.

But as you wrote. Most of the data is hidden inside <data></data>
sections. The internal format is JSON. I'd highly recomend to use a
JSON parser instead of eval(). Since jQuery has one built in, there is
no extra file size.

I also don't lilke hidden data. That's why, I am not happy, if
valueable text is stored as custom fields.

=====
Some things I found out using JSON as a configuration format.

I use it with my IconBuilder space. JSON is human readable, and human
editable. But quite errorprone. You have to exactly know, what you are
doing, if you edit it by hand. See myFunctions [2] link below :)
You'll need to read set description [3] and myFunctions description
[4] exactly in that order, to understand (may be) how it works. ... So
I needed to make an IconConfigurator [5] to produce a valid template.
If one is produced, copy paste is easy (At least for me :)

Conclusion:

JSON is easy and secure to parse. It is human readable. But it is
limited human editable, without copy paste errors. Or you need a good
interface, which is a lot of work to do, and most of the time limited
to a special usecase. See [1]
=====

Using Sections and slices as a configuration format:

I use this type of configuration for my FancyBox plugin [6]. One of
the biggest advantages is, that you can put your configuration into
any tiddler, and it will be nicely wikified using TW core. Also the
core has functions to retrieve this information (see technical stuff).
The disadvantage is, that if you want to have some database
functionality you have to make it on your own. eg: adding, deleting,
sorting, reporting ....

Technical Stuff:
=====
TiddlyWiki.prototype.calcAllSlices(title) gives you all slices a
"title"d tiddler contains.
The disadvantage there is:
chkSomething: true .. gives you slices.chkSomething = "true" which is
a string not a boolean :(

I needed to change it a little bit: see. FancyBoxPlugin
calcTextSlices: function (text) {} which gives you slices.chSomething
= true; (the boolean) and it needs tiddler.text instead of
tiddler.title

Conclusion:
*Many users allready know, Sections and Slices.
**For those who don't know, it is quite easy to tell them. Most of
them will need it anyway, if they really want to work with TW.
*Configuration values, can go together with documentation text (I like
this very much)
*It is as flexible as using JSON for configuration, but less error
prone if human edited.
*It needs a little bit more parsing. But parsing is still simple (see
technical stuff).
*There are no automatically created forms yet. But tiddlytools may be
a source here. Especially PasteUpPlugin

=====
Using someone elses stuff and resources.

eg: Baggr [7] it uses DataTiddlerPlugin
[7] http://baggr.tiddlyspot.com/#TwitterUsage

Have a look at the
"∈ .. Query View" which gives you a list of content.
"Δ .. Form View" gives you a automatically created form specified by:
"Ψ .. Shema View" lets you specify the database "elements"
"ξ .. Tools" some export import tools
"? .. Help" .. help

@Tobias. I think this is very close allready to what you want to have,
except the data content is hidden.

The advantage is, that everything can be freely defined. The
disadvantage is, that it needs a tought learning curve. And you have
to know a little bit about databases.

Accessing the database content you'll need more plugins [8]

Conclusion:
Very flexible, but tough learning curve. All the data is hidden. Not
human editable without any specialized forms.

I had a closer look at it, as I wanted to use it for IconBuilder. But
since I can't manually edit the content I didn't use it. Using copy/
paste with the TW built in text edit functions is way faster. Export,
import would have been an option.

There are some more ideas, but they are confidential :))

Just some thoughts.
have fun!
mario

[1] http://www.giffmex.org/bibblywiki.html#VanhoozerMeaningText
[2] http://iconbuilder.tiddlyspace.com/#myFunctions
[3] http://iconbuilder.tiddlyspace.com/#[[set.xx%20description]]
[4] http://iconbuilder.tiddlyspace.com/#[[myFunctions%20description]]
[5] http://iconbuilder.tiddlyspace.com/#IconConfigurator

[6] http://fancybox.tiddlyspace.com/#Example_ThumblistSlideShow

[7] http://baggr.tiddlyspot.com/#TwitterUsage
[8] http://baggr.tiddlyspot.com/#DataListPlugin

[Alex Hough]

I've used dataPlugin with html forms as per Udo's methods. What I
thought would be good was if the data from the forms were stored to a
custom field. In the end, I made custom fields and put text in them,
text that should have been in the tiddler.

Tobias re-factored the whole lot into a single plugin - very fast.
For me the public editing of the TW in a small was important. So
readable tiddler based data a preference to JSON

ALex
[1] https://dl.dropbox.com/u/1316865/AlexHough/SCiO/OMM.beta/ommDirector.html

> --
> You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
> To post to this group, send email to tiddl...@googlegroups.com.
> To unsubscribe from this group, send email to tiddlywiki+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
>
>

[Tobias Beer]

Hi Mario & Alex,

About readability... one basic design goal of xFieldsPlugin is to make
extended fields more accessible. Thus, the important bit (to me) is
NOT that tiddler data are always best when contained in the tiddlers
main text. In fact, I find that approach to be somewhat distracting
and error prone.

The only thing required to make use of the enhanced accessibility
xfield is to provide is a meaningful configuration defining which
xfields will be displayed at what kind of tiddler.

In that regard, using extended fields to store structured data of
tiddlers and to make unified input methods available, I fail to see at
this point where xfields would benefit from making use of JSON...
other than the config itself, perhaps. On the other hand, I strongly
tend to prefer the configuration tiddler to be structured via somewhat
readable Wiki Markup.

Cheers, Tobias.