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: Sun, 21 Jul 2019 14:36:21 +0200 
 Sorry for the delay with reply, I decided to let this stew a little in the
hope that I'll have some better ideas later, but after waiting for 2+ days
and still not being any more inspired than before, I'll just write what I
can, even if it's not very helpful.

On Thu, 18 Jul 2019 18:24:49 +0000 Greg Chicares <address@hidden> wrote:

GC> Most generally, I want there to be more than one way to code
GC> variations.

 Generally speaking, and as much as I like Perl, this would seem like a
step in the wrong direction, but I'll just have to trust you that in this
particular case the benefits of being able to choose outweigh the drawbacks
of having to choose.

GC> > Is the problem you're trying to solve that it is only supposed to contain
GC> > text, and not HTML, currently, while you'd like to use HTML inside it?
GC> 
GC> In part, yes. More generally, I'd also like text substitutions
GC> such as mustache offers.

 Trying to understand the reasons for my instinctive dislike of your
initial proposal, I've realized that I don't actually have any objections
to using text substitutions in the policy files. My main problem is with
putting HTML inside them, as this just seems like a completely wrong level
for this: policy files are supposed to contain business logic, not
presentation-level decorations. I.e. rather than having

          <br><b>Title:</b><br> Contents

in the policy file, I'd much prefer to have "Title" and "Contents" as 2
separate policy fields and then have

          <br><b>{{Title}}</b><br>{{Contents}}

in the .mst file. This would preserve the separation between the "model"
and the "view" parts and would avoid situations where you'd need to
recreate the policy file just to change bold to italic or change the size
of a font, instead of simply editing the .mst file directly.


 But -- just in case you thought I was unusually accommodating by
explaining why I strongly dislike just one half of your proposal instead of
all of it -- even though I don't have any objections to supporting text
substitutions in the policy files, I still have some reservations about
using Mustache for them, because it seems to do too much. Do we really need
support for Mustache sections (i.e. conditionals)? I'm almost sure we don't
need support for partials (inclusions) and I don't really know what could
we possibly do if we encountered one inside a policy file field. And even
though they're harmless, supporting comments here doesn't seem useful
neither. So I wonder if we shouldn't use something simpler, like just
"$FIELD" shell-like expansions in the policy fields?


GC> If we had the flexibility to use html and mustache markup
GC> in '.policy' strings, as well as in '.mst' templates, then
GC> we could reduce overall complexity.

 Would using HTML really help that much? At least in example you present,
the gains come purely from being able to use text substitutions, which is,
I agree, definitely useful (whether we use Mustache syntax for them or not
being a secondary question).


 To summarize, thanks to your patient explanations, I think I do understand
the problem now, but I still very much dislike the idea of putting HTML
inside the policy files because of the violation of separation of layers
concerns and also, to be honest, because it's just plain ugly to use quoted
HTML inside XML (and using CDATA wouldn't be much less uglier). So my
question is whether we could get all, or most of, the gains you envision by
just allowing text substitutions in them or if per-product alterations that
you've mentioned may really require you to make an extra word bold instead
of just changing the wording?

 Sorry again if this is not particularly useful, I understand that you were
probably looking for an advice about how to better implement what you had
in mind rather than an advice about how to do something completely
different, but mixing HTML into the product file fields is so unappealing
to me, that I'd really like to at least explore the alternatives before
committing to it.

 Regards,
VZ

Attachment: pgpxg1GOmeBEA.pgp
Description: PGP signature

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