On Mar 17, 7:13 pm, Eric Shulman <[email protected]> wrote: > > > > And it seems that Jon's <<list>> template stuff made it to the core. > > > > Which is > > > > cool. > > > Has it? > > > according to the alpha TS core yes > > TBH, ... TBH? and from other post. RFPs/RFCs (YUCK!). I don't know these TLAs [1]
> ... I think the design of this new feature has not been properly > considered before being added to the core. It seems like this was > 'tossed in' as a quick tweak, without proper *public* discussion or > review of the design or usability issues. > > For example, one *minor* issue I have is with the choice of parameter > name. ... There may be a naming conflict. But in my opinion, the <<list>> template mechanism has nothing to do with the TW theme mechanism. Nor with Edit- or ViewTemplate and there derivatives. > ... There is already a well-established "template" mechanism within > TiddlyWiki: a template is a tiddler containing HTML syntax used to > produce formatted output. However, Jon's <<list>> macro "templates" > do NOT build on that functionality... instead, Jon's list macro > "template" is really more like using <<tiddler>> transclusion that > merely renders wiki-formatted syntax, but without the ability to > substitute "with:" parameter values into the output. Right. Are there any existing plugins, that use "template:" as a named parameter and are used in a totally different context? The discussion about parameters and there names may be done at TWdev group. > A more serious issue is the manner in which this addition has > triggered additional core changes in the <<view>> macro. Those core > changes were entirely *reactive*, and were made without much > discussion about appropriate syntax, usability, or even the features > actually desired by the community. If proper discussions had > occurred, then issues like the "case sensitivity problem" for slice > references could have been easily identified and addressed, *before* > the code was checked-in to the core. IMO, it has been checked-in, into a alpha/beta core, which is reachable with special parameters only. As 2.6.2 came out I personally didn't test it prior to it's official release, because I don't want to permanently include a beta core into my "working" TWs. So I had to wait until it's release and found out, that the SystemSettings feature needed some fixing. I deffinitely like the new mechanism, where I have the possibility to test prior to the release, with a "working" TW involved. But easily switching back. > From my point-of-view, there appears to be a double standard at work > here. Proposed core changes developed *outside* Osmosoft get a lot of > resistance, languish for months (or *years*), or are repeatedly re- > scheduled for a later release, effectively forcing them to be > implemented as plugins, even if the proposed core change is minimal, > isolated, and well-tested. I think github can fix this. We'll see. > In contrast, it seems that changes developed *inside* Osmosoft often > get "fast-tracked" straight into the next release of the core, > resulting in follow-up tickets to fix problems (or add even more > functionality) that could have been identified and addressed > beforehand. > > -e ==== I didn't intend a general discussion about the core. But it seems to be necessary. -m [1] Three Letter Acronyms -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
