In terms of tables I do the following
-- some.template.html --
<HTML><BODY>
<TABLE ...>
$table$
</TABLE>
</BODY></HTML>
When my template processor processes this page it finds $table$. Then it
calls a method called procMacro_table (using some reflection stuff in
here). This method has some templat line to (loaded from properties file
on startup), and it looks like this
<TR><TD>$col1$</TD><TD>$col2$</TD>...</TR>
now we process THIS macro string (a copule of times for rows) setting for
each row its own macro Properties table. That's it. Everything is outside
the code.
-- Misha
On Mon, 17 May 1999, George Svedloff wrote:
> I quite agree - the proliferatoin of proprietary solutions is a little
> annoying.
>
> In my opinion, tempaltes offer a very clean solution. They have one
> problem - it is hard to deal with dynamic elements like talbes or lists
> when you use templates.
>
> The solution we are currently trying for this is the following:
>
> Use tempaltes, and when you need to use a dynamic element like table,
> insert some "placeholeder" into your HTML instead of the table that will be
> substituted later. Then use something to dynamically generate the table
> (we currently use the W3C DOM library). After the table is generated,
> replace the "placeholeder" with the generated table.
>
> Any comments on this approach?
>
> George Svedloff
> Informix Software, Inc.
>
>
> At 04:22 PM 5/17/99 +0200, Carlos Amengual wrote:
> >Danny Ayers wrote:
> >>
> >> Hi,
> >> I'm sure most programmers would agree that hardcoding and templates each
> >> have their place. One thing that does irritate me though is how systems
> >> for templates (not just for Java/HTML) keep appearing that require the
> >> user to learn proprietary techniques, usually scripting languages. All
> >> are offered as timesavers, 'no hardcoding required' being the selling
> >> point. Well, I wouldn't have to do any Java hardcoding if I'd bothered
> >> to learn Perl & PHP scripting...
> >
> >I agree with you. My approach has been to even avoid proprietary tags in
> >the HTML, and do all the programmatic manipulation from Java. This
> >leaves many unsolved problems, however, as in HTML you don't have an
> >universal way to locate by name individual tags, and relative addressing
> >workarounds -as I did- are easily broken. And if you want to insert, for
> >example, a table into the document, you must put the formatting of the
> >individual cells into the Java program.
> >
> >My solution to this was to use XML instead of HTML, and use style sheets
> >to do the final graphic rendering. The problem is that these style
> >sheets are still too obscure for the graphic designers to work with. I'd
> >like to hear other people's experience with the deployment of XML as an
> >HTML substitute.
> >
> >
> >Carlos
> >
> >___________________________________________________________________________
> >To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> >of the message "signoff SERVLET-INTEREST".
> >
> >Archives: http://archives.java.sun.com/archives/servlet-interest.html
> >Resources: http://java.sun.com/products/servlet/external-resources.html
> >LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
> >
> >
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
