Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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-