The idea behind these template engines is to make them as 
simple as possible to prohibit "Turing-complete" operations.
Whereas JHP templates is a general-purpose tool not
restricted to view separation-only.

Moreover, it is even simpler to implement the
engines below: meld is using XML so XSLT, SAX
or DOM fairly straightforward implementation
is possible. The string templates in the paper
may even be possible with regex.

The decision about having a JHP-style templates
or restricted view-templates is not technology
issue, whose goal is to enable the operations,
but a design decision made for particular project.

All these can be possible with J CGI.


--- Terrence Brannon <[EMAIL PROTECTED]> wrote:

> On 3/30/07, Oleg Kobchenko <[EMAIL PROTECTED]> wrote:
> > As far as was able to understand, the idea is to
> > use static HTML with special attributes
> >
> >    <span meld:id=product>product_name</span>
> >
> > Which are then transformed to actual page at run-time.
> >
> > How to deal with loops?
> 
> pretty easy - just clone the sample row, pop in the data, then append
> the clone. You can see an example of table unrolling here:
>    http://www.plope.com/software/meld3
> 
> > In-line server-side code blocks?
> 
> I'm not sure what this would be
> 
> > Generation of data-driven HTML?
> 
> I'm not sure what this is either. But anything useful with an HTML
> tree can be done with tree
> rewriting... and you are less likely to suffer the pitfalls of dealing
> with HTML as a string
> 
> And things are easier to debug because you can study each language by
> itself with the syntax highlighting and editor support of each
> language as opposed to trying to figure out things that can't be
> tested in isolation because they are on foreign turf.
> 
> 
> >
> > Regardless, it would be possible to incorporate it
> > in J CGI (of which JHP is just a thin handler) if
> > there is a design solution of to make it work.
> >
> > Did you think about this?
> 
> no I haven't, right now I need to master J and Henry Rich's "J for C
> Programmers" is the way to go. The best paper on the whole idea is
> Terence Parr's paper:
> http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
> 
> 
> 
> >
> >
> > --- Terrence Brannon <[EMAIL PROTECTED]> wrote:
> >
> > > On 3/30/07, Oleg Kobchenko <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > > >
> > > > So what are the arguments that text-chunks cannot do,
> > > > or that can be done more easily by tree transformation?
> > > >
> > >
> > > * Static validation - with J and HTML mixed, neither can be validated
> > > for syntactic correctness prior to running either.
> > >
> > > * Big webshops require that HTML designers and webapp programmers work
> > > independantly with no interference... HTML designers do not want to
> > > see <:   ... :> all over the place and their design tools dont either
> > > :)
> > >
> > > * meta-level versus object-level. Let's take a navigation bar:
> > >
> > > <DIV>
> > > HOME :: <span meld:id=product>product_name</span>
> > > </DIV>
> > >
> > > now, this span element with attribute value product can be used for
> > > every product... you simply rewrite the contents of the span tag as a
> > > function of which product you are dealing with...
> > >
> > > when using object-level dynamic html generation, you are forced to do
> > > something.. oops! well, I guess the object-level is not so bad in this
> > > case :)
> > >
> > > <DIV>
> > > HOME :: <span meld:id=product>$product_name$</span>
> > > </DIV>
> > >
> > > Ok, a better example is a web form. You have to show the same form for
> > > input and then fill in the form for confirmation. With tree-rewrites,
> > > you can use the same HTML form for both getting user input and
> > > displaying it, you just rewrite the tree based on whether you are
> > > getting the input or displaying it for confirmation:
> > >
> > > <FORM>
> > >
> > > <!-- fill in with user submitted text on confirmation page -->
> > > <input type=text>    </input>
> > >
> > > <!-- must change label to "confirm data" on next page of cgi program -->
> > > <input type=submit label="submit data">
> > > </FORM>
> > >
> > > but with object-level-inline type systems, you would have to use
> > > if-thens or two separate HTML pages for input and confirmation.
> > > ----------------------------------------------------------------------
> > > For information about J forums see http://www.jsoftware.com/forums.htm
> > >
> >
> >
> >
> >
> > ____________________________________________________________________________________
> > Food fight? Enjoy some healthy debate
> > in the Yahoo! Answers Food & Drink Q&A.
> > http://answers.yahoo.com/dir/?link=list&sid=396545367
> > ----------------------------------------------------------------------
> > For information about J forums see http://www.jsoftware.com/forums.htm
> >
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
> 



 
____________________________________________________________________________________
Food fight? Enjoy some healthy debate 
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to