Hi Jeremy, 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.
I already figured that there would be some performance drawbacks or complexity-issues when using ids as a parallel mechanism, however, thanks for explicitly highlighting this point. The bit that you don't have is enforcement of the uniqueness of the ID, > though. That is true, I pray to god that the javascript function never creates the same id twice. 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). That would be a nice solution, similiar to refactoring-dialogs in modern IDEs, however, this is also extremely complicated to program as the issue becomes quite complex. Sorry for labouring the response to your points; I just figured it may be > useful to lay out some of the reasoning. That's ok. :) I regard my original question as answered. Regards Felix Am Dienstag, 3. Juni 2014 11:05:28 UTC+2 schrieb Jeremy Ruston: > > 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></$ >>>>> tiddler> >>>>> \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 <[email protected]> >>>>> 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 [email protected]. >>>>>> To post to this group, send email to [email protected]. >>>>>> >>>>>> Visit this group at http://groups.google.com/group/tiddlywiki. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Jeremy Ruston >>>>> mailto:[email protected] >>>>> >>>> >>> >>> >>> -- >>> Jeremy Ruston >>> mailto:[email protected] >>> >> > > > -- > Jeremy Ruston > mailto:[email protected] <javascript:> > -- 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 post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tiddlywiki. For more options, visit https://groups.google.com/d/optout.
