For sure, Stan. I've got to iron out some kinks, and figure out how a user
could upgrade from one version of Tifoist to the next (i.e. never need to
re-enter or fix anything in an upgrade.)
Once I can get the basic functionality working, I will throw myself into
figuring out how to build a Tifoist plugin.
I'm thinking, very much on the fly:
- Testing of basic functionality first. Iron kinks.
- Well, once I finish "basic functionality", (the scope is a moving
target right now.)
- Setup Tifoist as a plugin, then test that and iron out kinks.
- Then work on Tifoist upgrading. Test and iron out kinks.
- At some point, test TiddlyWiki upgrade of a TiddlyWiki with Tifoist
plugin.
- At some point, and in logical chunks, add more functionality, while
making sure none of the above get broken.
I've spent *the last few days hyperfocused on GUI design* (i.e. making the
TiddlyWiki look like an an application for domain "modeling" and database
engineering, maybe even software engineering).
Also a little sidetracked by naming paralysis by analysis.
Anyhoo, latest incarnation for your viewing pleasure and scrutinizing:
Tifoist-TW5
Prototype 2 <https://tifoist.neocities.org/CJ_TIFOIST_BIS_PROTOTYPE_V2.html>
(continuing
to model a domain I know well: the business domain of New Brunswick's
Buildings Group, related information about 2/3rds of the way down this page
<https://www2.gnb.ca/content/gnb/en/contacts/dept_renderer.149.1699.html#mandates>
.)
On Saturday, February 27, 2021 at 8:50:23 AM UTC-4 [email protected] wrote:
> This looks really nice, Charlie. Let me know when you are ready for some
> beta testing. I have a couple of nice book projects where I could use
> Tifoist.
> Stan
>
> On Tuesday, February 23, 2021 at 10:05:14 PM UTC-5 [email protected]
> wrote:
>
>> "ORM-ish à la TiddlyWiki" is now "*The Tifoist Project*"
>>
>> - *T*ifoist *I*s a *F*act-*O*riented *I*nformation-*S*emanticization
>> *T*ool
>>
>>
>> The previous work I now call "prototype 1."
>>
>> I am now labouring on "prototype 2", involving some GUI design and
>> overhauling/refactoring what I did in prototype 1. Much of what I did in
>> prototype 1 is now broken in prototype 2.
>>
>> Much work to do before prototype 2 can be released into the wild for some
>> scrutiny. For now, I share a few screenshots (attached).
>>
>> Cheers !
>>
>> On Tuesday, December 1, 2020 at 4:49:31 PM UTC-4 Charlie Veniot wrote:
>>
>>> Project TiddlyWiki: ORM-ish à la TiddlyWiki
>>> <https://intertwingularityslicendice.neocities.org/CJ_ORM.html>
>>>
>>> *BTW: My announcement for this project has turned into an awesome
>>> thread of discussion. Please check out Using TiddlyWiki for fact-based
>>> information modelling and database engineering ???
>>> <https://groups.google.com/g/tiddlywiki/c/57_eiPadjCo> for some
>>> ridiculously excellent buffet of food for thought about, um, thought
>>> (cognitive processing). Things like (I can't do it all justice):*
>>>
>>> - *managing complexity*
>>> - *information/knowledge design/navigation*
>>> - *PhD-related stuff about context and keeping stuff understandable*
>>> - *in short: A LOT OF WOW GOODNESS !!!*
>>>
>>> *Latest Updates*
>>> *(The following pretty much sums up changes/additions since November
>>> 23rd.)*
>>>
>>> *Text Rotation Testing*
>>>
>>> - I took a little side trip trying to figure out a generic mechanism
>>> from creating tables like in the "Entity Relationship Matrix" tiddler.
>>> Although I gave up after a few hours (much too big and messy of a job),
>>> I
>>> left the following two tiddlers in the TiddlyWiki in case I ever want to
>>> try again: "Research Macros" and "Text Rotation Tester"
>>>
>>> *Coded Form of Facts*
>>>
>>> - I last had coded form of facts setup as one field for each fact,
>>> containing the entire coding line (for example: coded field = "BUILDING
>>> 1:1 BLDG_NAME").
>>> - That was making all of my scripting more complicated (having to
>>> split that coded field into the three parts: BUILDING, 1:1, and
>>> BLDG_NAME
>>> for whatever kind of processing.) MORE IMPORTANTLY: that was making it
>>> much more difficult for me to setup "data entry" of a fact's coded form
>>> via
>>> select widgets.
>>> - Now, a fact's coded form is split into three fields: c1, c2, and
>>> c3. (for example: c1 field = "BUILDING", c2 field = "1:1", and c3
>>> field =
>>> "BLDG_NAME".)
>>> - This change from one field to three required some rejigging of
>>> various tiddlers, including (among others): "Entity Relationship
>>> Matrix",
>>> "oEs" (a transclusion template to generate conceptual representations of
>>> entities; see "BLDG_SPACE_UNIT" tiddler for an example)
>>>
>>> *Early start (experimentation) of widgets for data entry*
>>>
>>> - Using "select widgets" to help with creating coded form of facts.
>>> I'm very new to the use of widgets for this purpose, so this will take
>>> me a
>>> while to get right. For a starting example, see the "A Building has
>>> exactly one Name / A Name is unique to a Building" fact
>>>
>>> *Entity Relationship Matrix tiddler*
>>>
>>> - For the slanted column titles, I removed the little links for the
>>> related tiddlers, because the slanting of titles often causes the
>>> tiddler
>>> links to not be clickable (they wind up at the bottom of "z-order", and
>>> it
>>> just isn't a fun thing to try and fix at the moment.)
>>> - Pure CSS for tooltips on the check marks is wonky sometimes
>>> because of tooltip positioning (which can only be auto-adjusted nicely
>>> to
>>> show the tooltip, in a guaranteed viewable spot, with javascript.) That
>>> is
>>> not a fun thing to try and fix at the moment.
>>> - Scrolling the table columns towards the left: modified so that
>>> when columns get slid over to the left, the cells don't show on top of
>>> the
>>> row headers on the far left (that remain in fixed position.)
>>> - I haven't figured out how to do the same for column headers, but
>>> I'm on the fence: not sure I want to hide column headers when columns
>>> are
>>> scrolled to the left.
>>>
>>> *Primary Keys for entities*
>>>
>>> - I was setting up all primary keys as "value_type" tiddlers, but
>>> I've modified so that primary keys are now specified as a simple field
>>> on
>>> each related entity tiddler.
>>> - Seeing as I'm a big believer in using Sequence Numbers (as per
>>> Oracle Database products; whatever is equivalent in other database
>>> products), it doesn't make much sense for each primary key having a
>>> dedicated tiddler.
>>> - Instead, every entity has a sequence number name specified in a
>>> field, and each sequence number follows the exact same standard (data
>>> type,
>>> max length .... all of which are currently hard-coded in scripts; I
>>> plan to
>>> move those "standard sequence number details" in a data tiddler).
>>> - BTW: Related oEs template tiddler (for conceptualisation of
>>> entities) modified accordingly.
>>>
>>> *Conceptualisation of Entities*
>>>
>>> - For each attribute, the table now shows the related fact in a new
>>> column on the far right side. (Just nice extra information about each
>>> attribute).
>>> - TODO: setup some mechanism to specify an order for the attributes
>>> (likely up/down buttons with saving position in related fact tiddlers;
>>> still thinking about it.)
>>>
>>> *Task Tracking*
>>>
>>> - Renamed "Facts - Coded Form Pending" to "Facts - Incomplete Coded
>>> Form".
>>> - Got rid of "Entities/Attributes Pending Creation" tracking because
>>> "Facts - Incomplete Coded Form" handles that.
>>> - Added "Entities - Incomplete Primary Key" tracking.
>>>
>>> *Entity "... to Many" relationships with value types or with other
>>> entities*
>>> *(getting into some heavy-ish relational database design stuff here ...)*
>>>
>>> - In simple "... to 1" relationships, this would translate into one
>>> table for the one entity (for an entity relationship to a value type),
>>> or a
>>> table each for the two entities (for an entity relationship to an
>>> entity).
>>> Easy peasy.
>>> - However, for a case of "... to many", that introduces an
>>> additional table for both scenarios (1. relationship to many value type
>>> instances 2. relationship to many entity instances.)
>>> - That's something I need to ponder on: i.e. how to handle
>>> writing facts, coding those facts, and conceptualisation entities
>>> (i.e. the
>>> related scripts)
>>>
>>>
>>>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/60559437-eaa3-4123-be6f-1755b0a0e370n%40googlegroups.com.
