lmi
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Embed {{MST}} and <html> in product database

From: Vadim Zeitlin
Subject: Re: [lmi] Embed {{MST}} and <html> in product database
Date: Tue, 23 Jul 2019 02:41:13 +0200 
On Mon, 22 Jul 2019 18:19:37 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2019-07-21 12:36, Vadim Zeitlin wrote:
GC> [...]
GC> > On Thu, 18 Jul 2019 18:24:49 +0000 Greg Chicares <address@hidden> wrote:
GC> [...]
GC> > GC> > Is the problem you're trying to solve that it is only supposed to 
contain
GC> > GC> > text, and not HTML, currently, while you'd like to use HTML inside 
it?
GC> > GC> 
GC> > GC> In part, yes. More generally, I'd also like text substitutions
GC> > GC> such as mustache offers.
GC> > 
GC> >  Trying to understand the reasons for my instinctive dislike of your
GC> > initial proposal, I've realized that I don't actually have any objections
GC> > to using text substitutions in the policy files. My main problem is with
GC> > putting HTML inside them, as this just seems like a completely wrong level
GC> > for this: policy files are supposed to contain business logic, not
GC> > presentation-level decorations. I.e. rather than having
GC> > 
GC> >     <br><b>Title:</b><br> Contents
GC> > 
GC> > in the policy file, I'd much prefer to have "Title" and "Contents" as 2
GC> > separate policy fields and then have
GC> > 
GC> >     <br><b>{{Title}}</b><br>{{Contents}}
GC> > 
GC> > in the .mst file. This would preserve the separation between the "model"
GC> > and the "view" parts and would avoid situations where you'd need to
GC> > recreate the policy file just to change bold to italic or change the size
GC> > of a font, instead of simply editing the .mst file directly.
GC> 
GC> We don't need all the flexibility of html in the policy files.

 Unfortunately, chances are that after enough time, we will get it there,
whether we need it or not. I can't really see why would we forbid using <i>
if we allow <b>. Or why would we forbid <span style="color: red;"> if we
allow the other ones. And so on...

GC> All we need is <b>, along with either <br> or <p>. If there were some
GC> easy way to write those in mustache syntax, e.g.:
GC>   {{??The pilcrow makes this a separate paragraph.}}
GC> that would be good enough. Or, instead of devising our own weird mustache
GC> dialect with '{{??' as an atom, we could use special characters to indicate
GC> markup, e.g.:
GC>   "????Some technical term??: its narrative definition."
GC> which would become
GC>   <p><b>Some technical term<b>: its narrative definition.</p>
GC> in PDF output.

 It looks like the real solution would be to allow defining maps in the
policy files. I.e. instead of a single scalar field, I'd like to have a map
with several "Some technical term" -> "its narrative definition" pairs of
keys/values. Would this be something you might consider? It would clearly
require more changes, but would seem to be much cleaner too.

GC> Motivating use case: each illustration includes a "dictionary", somewhat
GC> like this:
GC> 
GC>   <P><B>Do:</B> A deer. A female deer.</P>
GC>   <P><B>Re:</B> A drop of golden sun.</P>
GC>   <P><B>Mi:</B> A name I call myself.</P>
GC>   <P><B>Re:</B> A long, long way to run.</P>

 Just to be clear, all this is to be defined inside a single policy field,
right?

[... snip the explanation ...]

GC> That will bring us back to:
GC>   <P><B>Do:</B> A deer. A female deer.</P>
GC> We really need a simple way to express this. The specification is
GC> not that "Do" exists, and has a name, and has a definition, and it's
GC> definition is to be formatted in a particular way...and that "Re"
GC> exists, and..."Mi"... . Rather, it's that we have a sizable set of
GC> definitions, and they're all to be formatted in a particular style:
GC>  - name in bold, definition not in bold; and
GC>  - each as a separate paragraph; and
GC>  - nothing at all (no empty paragraph) if the definition is empty.
GC> In that context, a good separation of concerns would express this
GC> formatting as some sort of stylesheet, and I'd be glad to approach
GC> it that way if you can think of a way to do it.

 In the worst case, we could hardcode formatting of such "maps" in the C++
code generating PDF. This would already have the advantage of restricting
the HTML features that can be used in the policy files (to none) and of
centralizing all the formatting logic in a single place, and even if this
place is C++ code and not .mst file, this is still advantageous because if
someone suddenly decides that in 2020 the names should be in bold italic
and not just in regular bold, this would be trivial to change.

GC> How can we move forward now, without that much labor?
GC> 
GC> Of the two ideas presented, for strings in '.policy' files:
GC>  (1) allow mustache substitutions
GC>  (2) allow markup for boldface and paragraphing
GC> it seems that:
GC> 
GC>  - You don't strenuously object to (1)...so can we decide now how to
GC> implement it? E.g., invoke a function twice, as in my experimental
GC> patch; or rewrite the function so that it doesn't need to be called
GC> twice?

 It looks like we should use Mustache partials for this: they're exactly
what is used for including strings in Mustache syntax from elsewhere. But
this would make sense only if the string came from the policy file
directly, we could then (easily) implement something like {{<policy:field}}
to get it from there and expand.

 However if we decided to use "maps" suggested above, then I'm not sure if
this would make much sense... So let's first decide if we want to do this
or not.

GC>  - As for (2), is there some simple-enough way to get the boldface
GC> and paragraph separation we need, without using html? Would it be
GC> better to use pilcrows and guillemets as above, or does that just
GC> amount to reinventing html, poorly? Or is there some way to design
GC> a "stylesheet" that does what we need, while keeping presentation
GC> and content separate?

 The fact is that we need to separate the string into its various parts
somehow. The cleanest way to do it would be to define these different parts
in different XML tags, but, again, this would certainly require quite a few
changes.

 If we're not prepared to start doing this right now, perhaps some sort of
a hack with separator characters wouldn't be too bad. Then we could parse
the string into a map in pdf_command_wx.cpp and apply formatting to this
map instead. The exact details of separators don't matter, but it could be
something as simple as Markdown-like section syntax:

        # First definition

        Definition text. More text.
        And even more text.

        And this is still part of the same definition.

        # Second definition

        Less text here because I think I made my point.


GC> If we don't have time to figure out the best solution now, should
GC> we just forge ahead along the lines of my experimental patch, in
GC> the doubtful hope that we'll come back later and redesign it?

 I'm afraid this hope is not just doubtful but forlorn.

GC> Or perhaps I've now been able to persuade you that html isn't such
GC> a bad solution to (2) after all, given the scope of the undertaking;
GC> if so, then should we replace that experimental patch with an
GC> implementation that does the same thing in a less awful way?

 I understand and accept your arguments, but embedding HTML like this still
feels dirty to me and there is just one small step from having only <b> and
<p> tags in there to having 7 levels of nested <table>s for PDF layout. I'd
really like to avoid making this step possible.

 Regards,
VZ

Attachment: pgpV74lG4jibk.pgp
Description: PGP signature

reply via email to
[Prev in Thread] Current Thread [Next in Thread]