Hi Felix That said, I apologize for bothering you with my newbie-opinions or > questions, but from my understanding > it is possible to have more than one unique-field that identifies a > tiddler. Similar to SQL > where I can have several unique attributes in a table that each could be > used to identify a row. > If a new tiddler is created, the system only needs to ensure that the > title AND the id is unique. >
To have two unique tiddler fields in JavaScript would mean using a separate hashmap for each field that we want to enforce uniqueness. It would considerably complicate all the low level operations involving tiddlers. Right now, TW can be fast because the tiddler store is a very thin wrapper around JavaScript's native storage mechanisms. > From this point on, it is the decision of the user to reference the > tiddler by id or by title. > As written above, I have introduced this mechanism in my wiki and it works > well. > The bit that you don't have is enforcement of the uniqueness of the ID, though. One could imagine adding tools that prompt you if you've got an ID clash, and that wouldn't be ridiculously expensive. But making it a properly enforced constraint is expensive. > Providing a build-in alternative to a reference-by-title concept for those > who want it would be a nice > feature because links wouldn't break. Maybe it's not a common issue but I > found a threat on stackexchange > where a user had the same problem: > > http://webapps.stackexchange.com/questions/22850/changing-the-name-of-a-tiddler-in-tiddlywiki-and-retain-the-references-pointing > Link breakage is definitely a common problem. As I said at the top, I'm keen to support the ID way of working as an option (using the title field as the ID), but I don't think it's practical to enforce multiple unique fields on the tiddler store. My preferred solution to the breaking links problem is also a solution to wider problems of wikitext authorship: a decent search and replace operation that is syntactically aware; it can reliably find and replace all the references to a tiddler (without being confused by plain text references to the same text). > In any case, I fully support your choice to use the title as unique > identifier and if TW internals > do not allow the introduction of such a parallel-concept then it is > totally fine. I think TW is > great and offers much flexibility either way! > > So thank you for your work and your previous answers. > Sorry for labouring the response to your points; I just figured it may be useful to lay out some of the reasoning. Best wishes Jeremy > > Greetings > Felix > > > On Monday, June 2, 2014 6:46:26 PM UTC+2, Jeremy Ruston wrote: > >> Hi Felix >> >>> >>> By the way, is there any reason, why the tiddlers do not get a unique id >>> on creation time as a field value per default? >>> This would support people to create unbreakable references via ids, >>> without the previous effort to give each tiddler a unique id or creating a >>> custom button. >>> >> >> That's the unavoidable, perennial question referred to above. A simple >> formulation is: do we use the "title" field as the identifier for a tiddler >> the "title" field, or do we use a separate "ID" field. The two options >> can't co-exist, we need to choose one. TiddlyWiki chooses the former on the >> basis that is a more human formulation, and that it can trivially emulate >> the ID approach. But that is done by using the title field as an ID, not by >> introducing a new ID field. The reason is because of the need to enforce >> uniqueness: we guarantee the uniqueness of titles, but not of other fields. >> >> Best wishes >> >> Jeremy. >> >> >> >> >> >>> Regards >>> Felix >>> >>> >>> >>> >>> On Monday, June 2, 2014 5:02:33 PM UTC+2, Jeremy Ruston wrote: >>> >>>> This question of whether tiddlers should be identified by title or by >>>> an abstract GUID is a perennial one. >>>> >>>> My aim is that users should be able to use GUIDs for tiddler titles if >>>> it suits their use case. The missing piece is a way of linking to a tiddler >>>> by it's GUID/title, but having a specified field displayed as the text of >>>> the link. Here's an example of a macro to do that: >>>> >>>> \define link(guid) >>>> <$tiddler tiddler="$guid$"><$link><$view field="name"/></$link></$tiddl >>>> er> >>>> \end >>>> >>>> This is a link by guid <<link qqu99yie1>> >>>> >>>> Of course, it would be more useful if one could arrange for that macro >>>> to be automatically substituted for links. >>>> >>>> Best wishes >>>> >>>> Jeremy. >>>> >>>> >>>> >>>> >>>> On Mon, Jun 2, 2014 at 2:57 PM, Felix Küppers <felixk...@hotmail.de> >>>> wrote: >>>> >>>>> Well, I know linking via ids is not readable in edit mode, however in >>>>> a non-edit mode, the id translates to a name, so that is ok for me. >>>>> >>>>> As for semantic-alias (i.e. a real second title) vs. ids, I rather >>>>> chose ids as their purpose is only to allow exact references. same as in >>>>> SQL autoincrement primary keys... >>>>> And I rather place them inside a field because I like them to be more >>>>> "invisible" as they have no semantic meaning. >>>>> >>>>> However I took a closer look at you example in your space and it is a >>>>> really nice workaround you are using, I mean exploiting the masking-title >>>>> of the link as a variable to use it in a local macro. >>>>> >>>>> This way I could do something like >>>>> >>>>> {{ 415241 | id }} >>>>> >>>>> and put the filter in the macro instead of directly writing >>>>> >>>>> {{{ [field:id[]!has[draft.of]first[]] }}} >>>>> >>>>> that will make a nice shortcut... >>>>> >>>>> >>>>> >>>>> On Monday, June 2, 2014 3:30:38 PM UTC+2, Stephan Hradek wrote: >>>>>> >>>>>> I can't see a fundamental difference between my alias approach and >>>>>> using IDs. Except that ID's tend to be unreadable. >>>>>> >>>>> -- >>>>> 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. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> Jeremy Ruston >>>> mailto:jeremy...@gmail.com >>>> >>> >> >> >> -- >> Jeremy Ruston >> mailto:jeremy...@gmail.com >> > -- Jeremy Ruston mailto:jeremy.rus...@gmail.com -- 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+unsubscr...@googlegroups.com. To post to this group, send email to tiddlywiki@googlegroups.com. Visit this group at http://groups.google.com/group/tiddlywiki. For more options, visit https://groups.google.com/d/optout.
