[REBOL] Re: Parse refactoring puzzle
From: joel:neely:fedex at: 1-Aug-2003 8:21
Hi again, Sunanda,
I think our mutual goal is to separate logic from presentation.
As you imply, context is everything...
[SunandaDH--aol--com] wrote:
> We're getting into systems design philosophy here, but my particular
> issue is that I want clear-place-holders to be generic; and. in the
> application I'm designing, that seems the best approach:
>
I understand that the intended "use-case" would shape the requirements
of the function; I'm just thinking out loud here (because I find it
interesting to see how different solution strategies compare and
contrast with each other).
I tend to have a "message (block of tag/value pairs, object, etc.) that
represents only the (unformatted) content under construction, with a
step at the end that renders that content appropriately (via the
template, in this case). If the processing is multiple stages, each
stage can concern itself with only the portions of the content that are
its business.
It would, of course, be easy to prefix the entire pipeline with a
factory that reads the template and constructs a default message, which
is then passed along to the first "real" processing stage. This would
also allow multiple factories, so that one default message replaces
unused tags with empty strings, while another (for use during the
development effort) would replace e.g. !!foo!! with **FOO HERE** to
make visible the layout (or accidental processing skips).
I've toyed with the idea (without the time to fully develop it) of
having a "template compiler" that would move as much work out of the
request-response cycle as possible; the TC would read a template file
and create another file containing both the template and REBOL values
for (or expressions to construct) the default message. That second
file could be LOADed by the request-handling code, with the message
being passed down through the pipline before being used to fill in
the template at the end.
> The parse solutions ... decouple the clear-place-holders function from
> anything above it....With the one proviso that it has to trust that
> higher code has substituted "!" for any "!" that the webpage user
> may have typed into a field -- just to make sure we don't do place-holder
> removal when someone's address really happens to be "!!my house!!".
>
> (Your solution has the same problem, though it's less likely to be
> triggered as the webpage user would have to type the text of an actual
> place-holder).
>
Actually, I tend to favor distinct begin-tag/end-tag markers, such as
Dear {{{NAME}}},
Happy birthday number {{{AGE}}} ...
for a couple of reasons:
1) It further minimizes the likelihood of the template accidentally
containing a tag (or worse, half of a tag!),
2) It (IMHO) is more visually distinct and unambiguous,
3) It is at least as easy to code the pattern match, but failures can
be checked perhaps a bit easier (e.g. after finding all {{{...}}}
occurrences, verify that no open or close markers remain in the
template text, nor in the tag strings themselves..
Thanks for stimulating the previous interesting discussion!
-jn-
