One of the design principles of JHP/CGI and other J libraries is that it is (1) practical and (2) efficient.
1) To justify a particular feature this there need to be a broad range of compelling use cases, which do not contradict with each other. 2) Design and implemenetation of a feature need to be nice and simple and fit nicely with other features and J libraries. In order to have quality discussion about the design we need to designate scope, goals and use cases. --- June Kim <[EMAIL PROTECTED]> wrote: > > For the provided use case, here's how it's done: > > > > require 'web/jhp' > > > > v=: 3 : 0 > > r=: '' > > print=: 3 : 'r=: r,padj y' > > 3 : (hrep y)'' > > r > > ) > > > > name=: 'JHP' > > v 'Hello <%=name%>!' > > Hello JHP! > > > > v 'Hello <%=i.3 4%>!' > > Hello 0 1 2 3 > > 4 5 6 7 > > 8 9 10 11! > > > > v is "destructive". It has a couple of (global) side effects. Firstly, > the use of v changes the behaviour of jhp's original print afterwards. It is delibrately so for two reasons: (1) to provide an easy to follow example showing the idea of precision overriding of granular methods without changing the bulk of the processing and (2) to show how lack of usecases would limit the functionality. It was not in the requirements to provide any other features. > (maybe we should reset the meaning of print before returning back). Note: the overriding in 'base' does not change the original definition in 'z'. If you need to protect visibility of original "print" in 'base', override in another locale. But that again is outside of the scope of original usecases. For "v" to be re-entrant, other facilities would be used in real life like read/writer streaming as in xml/sax addon. > Secondly, and more importantly, it isn't possible to do nested > templating, which is crucial in modular templating[1]. (which you use > in phrview example; btw, your maketable example doesn't use template > facility but suppose it uses) Before we say that module X does not do Y we need to understand what is Y, is it good, or maybe X already does the same but avoiding the complexities of Y. For nested "unrestricted" template examples see again Phrase DB. How would other design of nested templates work and be better? > [1] http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf The ideas in this paper carefully camouflaged with big academic wording, essentially describe a mechanism that is called "binding". http://www.jsoftware.com/pipermail/general/2007-April/029397.html Word "binding" is not even used in the paper, because it would reveal that the author does not have much new to say. That is in terms of practicing GUI development and web applications in particular; notwithstanding the credit of ingenuity of ANTLR author taking his parser design experience with generative grammars and reversing into template productions. I would expect that this is not his final installment, because now his generator generates text output, whereas the next logical step would be to produce a tree further amenable to transformation and substitutions. The same way as his parser has a pattern-based tree transformer. However, again the real world is ahead of him: there's been first ASP.NET which produces a server-side DOM structure of controls, then Java Server Faces picked up the pace (JSF 1.0, 2004-03-11). They provide a few advantages over flat templates: dynamically modifiable; separate view controls; binding etc. DOM templates have more appeal than the restristed templates, which in addition put a burden of representing input data in certain format, that may in the end turn out to be couter-productive. > > --- June Kim <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > > > > I've been playing with JHP recently. While it does well what it > > > originally attempts to do, I'd like to extend and generalize its use. > > > I want to use it for general templating. > > > > > > The first step could be letting JHP return a result string. However, > > > the code isn't particularly designed for extension. (I have to copy > > > and modify the code directly) > > > > > > template=: 'hello Mr./Mrs. <%= name %>' > > > name=:'Jane' > > > hrep template > > > print 'hello Mr./Mrs. ' > > > print name > > > 0!:0 hrep template NB. since this session is from J window print > > > is smoutput > > > hello Mr./Mrs. > > > Jane > > > > > > What I want is a verb v that does: > > > > > > 'hello Mr./Mr.s Jane' -: v template > > > > > > I could modify the code directly myself, but that doesn't seem like a > > > proper way of extending a code. Code should be closed for modification > > > but open for extension[1]. > > > > > > Obviously, next step would be handing over a key, value pairs(maybe > > > the name of a locale that contains those variables) to the templating > > > verb. > > > > > > > > > [1] Open-Closed principle > > > http://www.objectmentor.com/resources/articles/ocp.pdf ____________________________________________________________________________________ Need Mail bonding? Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users. http://answers.yahoo.com/dir/?link=list&sid=396546091 ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
