On Thu, Jan 19, 2012 at 7:48 AM, HansBKK <[email protected]> wrote:
> 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?
Yes. I explained that the encyclopedia's volumes would be templated.
But there certainly can be all sorts of other things Leo is used for.
What you're concerned about is unclear to me.
>> 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.
My point is that you can distinguish when Leo is being used for
templating from when it isn't.
>> 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.
So you can't tell me whether what I'm saying does that or not.
> 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.
Right. And they aren't templating either.
>> 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)
Different from code maintenance for one file. Putting clones in @file
branches is about putting pieces of other files together to produce a
new hybrid file, or templating.
>> 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?
Could be. I'm trying to see if the use case can be implemented by the
app in a way that doesn't require users to understand clone war
issues, that makes what's going on more transparent. My proposal is
that that might be accomplished by not mixing templating with @file
branches. It may be that the app would implement that and confusion
about clone wars, and requiring users to adhere to disciplined
practices to avoid shooting themselves in the foot, would go away. It
certainly seems to me to be inviting that to have the sort of thing
Edward values clones for, mixed in with templating in @file branches.
> 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.
It would be quite clear that @file isn't for templating if the app
prevented clones in @file branches. Even more so if there's a
separate place for templating that is labeled as such, where you can
put clones.
Seth
>> 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.
--
You received this message because you are subscribed to the Google Groups
"leo-editor" 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/leo-editor?hl=en.
