On Thursday, January 19, 2012 6:37:49 PM UTC+7, Differance wrote:
> My point is to distinguish the templating function that's currently
accomplished with "cross-file clones" -- clones within @file branches --
from the code maintenance function.
I appreciate your attempting to clarify the distinction; my point was that
the wide range of Leo use cases doesn't fit IMO to only those two
categories (code maintenance vs templating). I gave another example use
case - does that fit within the domain of "templating" AFAYC?
> I recommend doing that by keeping clones out of @file branches, and
adding @template branches
where clones can be put. Then the user would explicitly choose between 1)
feeding Leo from an external file by use of @file, letting Leo keep the
structure of that external file while letting you create views on it; and
2) creating new external files out of pieces of other files by use of
@template.
IMO the various @ <file> directives give several options for doing these
and many other possibilities already. As long as you're only importing
("feeding") within a single branch (including @shadow as well as @file),
you're free to create as many mashups as you like via @nosent or @asis
without any danger of clone-war data loss.
> This also separates the two use cases explicitly with distinct @ branch
types, making it easier to manage eternal files. It might also, though I'm
not sure, mitigate "clone wars" because @template-created external files
are separate from @file-maintained external files, and @template branches
might also let you select from a number of different
priority/reconciliation algorithms.
I'm simply questioning whether the idea/discussion of "templating" should
necessarily be confabulated with reducing inadvertent data-loss due to
clone-war issues.
On Thursday, January 19, 2012 6:53:45 PM UTC+7, Differance wrote:
>> Is that templating?
> For an encyclopedia where articles are to be placed in more than one
external file (approximately one file per letter of the alphabet), the
model would be to put all articles for all volumes into one big
@file-managed external file, and then make each volume of the
encyclopedia a @template-produced external file.
My current solution is to keep everything (snippets for later use, full
articles in-process or ready-to-publish) in Leo itself, but to only have
published content pushed out to @ <files>. Each article (in my example,
"Deer" and "Bangladesh") is a separate file, with the "spotted deer" node
cloned to be included in both, but via @nosent, with all edits to such
files to be made within Leo only.
To accommodate community editing, I'd have an "Animals" @shadow file, and
the spotted deer node could be edited by me within Leo or by others in the
external file, without danger of clone-war damage.
I would of course need to ensure sufficiently frequent "sync'ing" between
the two to reduce the chances of conflicts needing to be resolved, or
perhaps move to a more granular node-grouping ("deer" or "Asian mammals").
> . . . or in regular views, grouped under regular headers.
At least AFAIK, regular views don't involve any clone-war issues at all.
> Putting clones in @file branches is actually something fundamentally
different.
Sorry, I don't follow - different from what? This is the only area where
clone wars are an issue (AFAIK)
====================
> And there's no reason you couldn't have several @file-managed "article
source" files, if one is too big. The @template-produced encyclopedia
volumes are created from cloned pieces of the @file-managed files.
> no bullets nor dangerous weapons, since clones aren't in @file branches,
and are only
in @template branches.
So far, substitude your "@file" for my "either @file or @shadow", and your
@template for @nosent and I reckon we're both talking about pretty similar
things?
IMO the idea of "templating" within Leo should be discussed independently
of the specific issue of reducing clone-war dangers, as it seems even more
complex to me and the connection between the two issues unclear.
> I'm not saying take away any functions from Leo, just distinguish the
function of templating to produce external files derived from other
external files, from the function of maintaining an external file that
isn't built from other files.
As a general concept, I would be very much in favor of a more explicit
"controlling" directive. As I recently pointed out, Ed had at one point
posited something along the lines of an "@master" possibility, but I
believe his further consideration eliminates that particular train of
thought.
I've been thinking that Leo could check for nodes being cloned under more
than one importing @ <file> branch (@nosents or @asis being no problem) and
warning the user, but I believe Ed doesn't want to go there.
to be continued, time to put my babes to bed. . .
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/leo-editor/-/NH0uCaBW2QwJ.
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/leo-editor?hl=en.
