>
> This is very a very cool idea!
>
I think it's certainly worth exploring and not too complex after all.
However, I the whole append/prepend concept is obviously physically linear.
>
Every templating engine is linear. The only thing you have to keep in mind
is that there is some nesting going on.
However, if something eventually turns out to be rows or columns or boxes
or columns in rows or rows in columns or boxes in boxes or inline in block
is entirely for the css to decide! It's not for the templating enginge to
have some preconceived notion.
I'm thinking, would it be possible to insert... I don't know what to call
> it - place holders or markers in the definitions of the templates so that
> one could refer to specific physical places?
>
The template itself IS the placeholder. The described method simply adds
stuff around its content.
Obviously, if you desire to place content somewhere in the middle of a
template and that template doesn't make use of further subtemplates, the
only choice you're left with is to modify the template and either put your
content in there directly or otherwise transclude yet another subtemplate.
If you want this functionality without modifying a template, then the *only*
chance you literally have is querying the DOM, with a library such as
jQuery... and then tell it how to place your custom content.
> Maybe even pre-filled transclusion or "transclusion holders"
>
> {{LeftOfTiddlerTitle}}
> {{BelowTagsField}}
>
This is precisely what my method does!
One could theoretically use different, but generic pointers, e.g.
- $:/core/ui/ViewTemplate/tags/BEFORE
- $:/core/ui/ViewTemplate/tags/AFTER
- $:/core/ui/ViewTemplate/tags/APPEND
- $:/core/ui/ViewTemplate/tags/PREPEND
The core itself should perhaps not make use of this mechanism as this is
what would provide the customizability.
And those serving as the type of template tags we already know.
To have this translated into left or below is counter-productive as it is
entirely up for the designer to decide if things get rendered left to
right, top to bottom, inside - out, inline or block, floating or not,
whatever.
So, wanting to "simplyfy" things like that comes at a major cost... of
impinging on flexibility. You should *not* stick to the idea that tags are
always "below" the title, or even that they're in a row. That's an entirely
arbitrary convention by virtue of a default layout. If you do templating
right, you can define a layout as freely as possible. *{{BelowTagsField}}*
really has no place in that, unless you specifically declare this very
thing for the very layout you want to create. But then it would be entirely
superfluous as you simply provide a shortcut to the generic under-the-hood
mechanism... and, it wouldn't be a transclusion, but at tag like
*$:/tags/ViewTemplate*.
Creating a tiddler named such and putting content in it puts it in that
> place. I figure there are only a limited number of templates and only a
> limited number of places within those that are relevant.
>
Leave it up to template designers. There is no general place for things, in
my mind... only what's obvious, e.g. that tags of a tiddler. There only is
a before, after, and inside of. You see, theoretically, the tags of a
tiddler could be rendered somewhere in the page-layout independent of those
tiddlers in the story and then some script could do the magic of placing
and showing it where the tiddler is, via mouseover or whatever, you really
don't know.
And an area such as "BelowTiddlerTitle" could be CSS-refined with
> right/center/middle etc.
>
You will have to know how to style things to properly align them... which
is why "BelowTiddlerTitle" is the wrong approach as it gives the illusion
of some intrinsic, default css. I would not do that. All I want is stuff
rendered in the flow the way I want it and then apply the desired css
myself. This should not come with automated guessing that I need to
overrule. I am already in customizing-land, so please don't try to predict
my customizations.
> They could be coordinates, like this which would cover most needs:
>
Please, no coordinates, don't think in tables, it's the web of the 90ies
and before. Today's layouts are fluid, respect mobile, that's why I am
saying there only is BEFORE (outside), AFTER (outside), APPEND (inside),
PREPEND (inside)... the visual implications of all of this are entirely up
to the css to decide.
Now, you can sure try and make use of grids, but you'll only know where a
box ends up when you know how many boxes are before it and how much space
they take and if they're in a row or a column or whatever... these things
are only predefined in the standard template, but even there they should
provide flexibility to changing things, correctly.
For example, up until a few days ago, the topleftbar and toprightbar were
rendered after the story. Now think of going onto a mobile device and
rendering them differently. They place they end up is after all tiddlers.
Surely not what one would have in mind. So, those are the basics the core
needs to cover in the least intrusive manner, with meaningful defaults.
Or, perhaps stating Up/Right/Down/Left of any field - {{TagsDown}}
>
I can understand that you want to make things "simple". The fact is, it is
not and never will be using plain css. So, first, let's start with a
generic "fits all" method... and once that works we can see if there is
room for "simplification". But then, you don't want to go about it with
cryptic names like those that imply way too much. What an end-user
eventually wants is some drag-and-drop ui that puts things at the right
place, defining how it should behave via layout-options.
Maybe transclusions with predefined tiddler titles is to strange so another
> idea would be predefined fields like:
> titleleft:NiceStar.png
> textright:{{EditorsNote}}
> textbottom:- by {{Creator}}
>
In general, it's not a good idea, to try and think ahead like that. Leave
it up for everyone to flexibly add what they want and where... and provide
simple instructions how that's done. Chances are, your preconceived
placeholder is not it.
It maybe that filed values cannot contain transclusions etc (too tired to
> investigate at the moment) but I think the point should be clear.
>
I think your point is: "Have TiddlyWiki automagically intuit what I
desire." ...and its not a good idea. The idea should be, have TiddlyWiki
allow me what I have in mind, not what it had in mind for me.
> And within such areas one could do some CSS to floatright etc.
>
So, this is what you always declare, bit by bit, by yourself... don't
overload with preconceived notions. It's somehting I never liked with TWc
as it did put you in a very straight corsett of what people expected the
layout to be... also in terms of plugins, e.g. "toggle that right
sidebar"... which would break if that sidebar wasn't quite what the
standard tightly defined.
In my mind, a layout in TiddlyWiki is and should be whatever you want,
upside down, inside out... no preconceived notions of "but the toolbar is
up top to the right"... and then there's that place "LeftOfToolbar", but
not "AboveToolbar".
Keep things generic... is what the code should do, imho. Even if that comes
with, at first, ctyptic tiddler or tag titles with a functional purpose.
Best wishes, Tobias.
--
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 http://groups.google.com/group/tiddlywikidev.
For more options, visit https://groups.google.com/d/optout.
