Tony,
I'm unsure if what your last post describe is as things currently are or as
you'd want them to be.
But it seems your vision is not to have fields be separate entities like I
envision them. But if you're happy to always see them integrated in
tiddlers, then what do you mean by first class citizens? You can access a
field value from anywhere with {{tiddler!!field}} and you can set fields
and remove them.
Warning:
In the following I hope it is OK that I also rant a bit and clarify my
thoughts/opinions, not as an attempt to hijack your thread but rather to
bounce ideas:
Like in a standard database, a field is really just a column title, and the
> instances of it are the values associated with a key. Tiddlers are
> addressable by there unique name (a key), even if a field-name is used
> once, to access its its instance we needs to identify the tiddler title to
> which it belongs. To me this makes the tiddler remain the "atom" of
> tiddlywiki, fields are the sub-atomic particles.
>
I did not know this. Very interesting view of it, or maybe it is not even a
view of it but how it actually is implemented. Either way, very
interesting.
*My* vision is then to rather make the cells be the atomic unit, with the
row+column ID equivalent to tiddlertitle+fieldname. I.e an instance of such
a unit could be something like "MyCar.Color:blue", where "MyCar.Color" is
the unique ID. This unit should be independent - for example it should be
exportable to other TWs.
I'll here refer to these cells as *fids* ("field tiddlers") from lack of a
better name. Tiddlers would still have an important role but they are
complex entities consisting of fids, but they would probably differ in
implementation depending on context/need. (Tiddlers in a notebook TW are
probably different from tiddlers in a spreadsheet type TW.)
..but really, the tiddler.fieldname as ID is just a special case. It is two
dimensional. The ID could consist of any number of parameters that would
also serve as fid kinship (categorization/belongness). For example
MyCar.Color.MyWifesCar:blue I intentionally did not use a hierarchical
example here, like Vehicle.MyCar.Color:blue because I do not mean a
hierarcy. The ID would be more comparable to tags! (OK, probably throw in a
unique hash number also.)
So another fid might be Foobar.Color.MyWifesCar:whatever and the ID shows
clearly shows the partial kinship with the previous fid.
The point is that, just like tiddlers, these would be independent units
that are still linked to one another. They would be as targetable as cells
in a speadsheet but in no way locked in like they are in spreadsheets. IMO
this is *pure* tiddler philosophy. Not that we should be dogmatic about
"tiddler philosophy" - I think just think "*minimal* chunks of meaningful
content to create bigger narratives" is a brilliant strongly practical
ideal.)
Likely, the most popular use of such fids would be to group tids into
tiddlers as they are currently expressed. But not always. :-)
If there is a field anywhere (and everywhere) in the wiki called
> "fieldname" then it is fine to have a single tiddler that describes it. If
> someone chooses to use fieldname in one set of tiddlers to mean X and in
> another to mean Y then they are free to do so. They could even note in the
> fieldname tiddler that fieldname has two or more uses. Extending the Info
> page to tell you in which tiddlers the field is used and or has a value
> will help.
>
> In keeping with the field concept I think data tiddlers can be considered
> external fields,
>
Very interesting!!!
IMO, while data tiddlers are pretty concise they are still complex in that
they list several more or less independent entries. IMO it would be truer
to tiddler philosophy if data tiddlers really were *lists* of fids,
comparable to lists of tiddlers.
Side note: it would be pretty cool to create fids by manually typing a data
tiddler type of list, e.g like so:
tiddlertitle:Foo
text:
foo1:bar1
foo2:bar2
foo3:bar3
...and, on tiddler save, these fids are *created* (because they're fully
defined). E.g number 2 fid would be Foo.foo2:bar2 ...or whatever the syntax
would be - the main point is that this mini-thing defines the entire fid.
Recreating the list would be even simpler with something like {{{
[fid[Foo]] }}} ...or with focus on any of the
other.identifying.kinship.attributes.that.it.may.have.
...but that was a digress.
Back to your thoughts.
> they define a field, its instances(index name is the key not the tiddler
> name) and values all in a single tiddler, they are more like a global field
> not to be confused with others such as Text/Title/Tags so by thinking of
> them as external fields (for want of a better name) could help. Actually it
> could be helpful if we (users) could define a global field like text and
> Tags in a tiddlywiki that exists in every tiddler like changecount (from
> TWC).
>
What role/purpose would this serve in your vision? (I can, however, see it
as part of 'fids' to serve as a part of the ID)
However there is a good argument that maintaining a SINGLE tiddler for each
> fieldname, and each field name for a documented purpose, is a way of
> supporting a good naming standard, avoid unexpected results, support self
> documentation practices and more.
>
> Never the less a Tiddler can be a tiddler with content, including
> containing text/code (macro) or references to other tiddlers, be a tag and
> a Field definition all at once. And as in the discussion you linked to,
> also a variable or container for a variable. It is with this possibility in
> mind that perhaps a state tiddler should not populate the "text" field but
> a "value" field in the state tiddler. Although using text should remain
> valid.
>
Not quite sure what the problem is here. I must assume both the text fild
and other fields are "just fields" even if with different properties. It
may be aesthetically unpleasing to use the text field for states... but
other than that, I don't know.
...
> If we are to simplify the syntax I think we may need to start
> differentiating here because there are constants that can change, things
> that vary and things that vary within the tree. In someways
> "currentTiddler" causes a problem because there is a current tiddler
> "Displayed" and a changing "currentTiddler" as a result of a filter/list.
> Sometimes the current tiddler is not even a tiddler, or only a potential
> tiddler. Because I am keen for tiddlywiki to undergo reform not revolution
> if we keep currenttiddler and introduce a value "displayTiddler" for the
> parent that is static in the tree below, a templateTiddler when specified
> for the displayTiddler it would have helped me learn and do things sooner.
>
There is much consideration for backward compatibility. Pros/cons with that
approach. I'd spontaneously guess that it is not possible to introduce a
"displayTiddler" other than perhaps as some alias to currentTiddler. I also
think that revolutions (to use your term...by which I assume you mean a
total rework, or perhaps a fork) comes when there is enough tension between
current status and identified/solvable improvement that it feels justified.
The aforementioned backward compatibility approach, probably hastens this
process. (Obviously it also takes super skills to be able to pull it off...)
> Perhaps the whole widget tree idea needs to be made clearer, perhaps by
> providing tools to navigate it, not through understanding the code but
> tools provided that help people visualise and tap into it, perhaps even a
> debug mode so we can see its value changing, Inheritance is is a good
> example. It is all fine having a many to many quine but a lot in tiddlywiki
> and the real world uses hierarchies and these should be more available,
> visible, understandable and reusable.
>
Considering that I barely know anything about how the widget tree works,
I'd like this... but maybe it is more a js matter?
<:-)
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywikidev/82990c03-0e3d-4bcb-9228-e5f64ba0587a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
