Sorry for jumping in so late.  I don't get to read this list on a daily
(or rather minute by minute) basis, so I didn't read the rest of the
thread before replying.  As I read through, it seemed there came a
consensus to using Widgets.  However, I can now offer some real world
experience where we use this approach in a Java webapp for an Organ
Transplantation tracking and information system.  We use the
Widget/Screen/Document approach for generating all of our HTML and PDF.
We have a Human Interaction Team (affectionately known as the HIT Squad)
that gives us mock-ups of the UI.  We have been using this system and
adapting it for nearly two years.  It has really helped us a lot in the
presentation layer and I would have only traded it out for the same
thing written in Smalltalk.

The hierarchy of classes I am writing now are based on that experience
(pluses, minuses, everything)...

=jason 

On Thu, 2002-12-12 at 12:13, Jason Rogers wrote:
> Somewhat related to this I am working on a hierarchy of Widgets that
> know how to emit themselves as HTML or PDF (and perhaps as XML, etc.
> sometime in the future), which leaves you coding only in Smalltalk. 
> These widgets are added to a Document (currently only HTML, PDF soon to
> come) and the document can then be rendered.  For the actual UI design,
> I still depend on a UI team to give me mock ups of the design, and I
> simply build Screen classes which reflect that design by creating
> Widgets to be added to Documents.
> 
> =jason
> 
> On Wed, 2002-12-11 at 08:29, goran.hultgren at bluefish.se wrote:
> > Hi all!
> > 
> > I am currently learning a bit more about the current crop of different
> > "templating mechanisms" primarily used for web page generation that are
> > in use in the industry today. My list sofar is more or less like this:
> > 
> > - A simple "variable substitution" engine. You can easily hack one of
> > these yourself and I have seen it used the webenging of 4D for example.
> > Typically everyone implements "their own" and there are tons of these
> > out there on the net. Typically quite primitive and can't deal with
> > stuff like "loops" etc.
> > 
> > - Proprietary template mecanisms in web application servers. Seemingly
> > there are many of these too which are probably more advanced than the
> > above "hacks" but still not "standard" in any way.
> > 
> > - Embedding "custom tags". ColdFusion did this early on and it is a
> > "simple" idea that makes all the HTML tools behave quite ok. At least
> > earlier they just ignored tags they couldn't understand (and hopefully
> > didn't remove them) and nowadays they probably deal with them nicely
> > (since XHTML has taken the scene). What the tags are capable of is still
> > up to the proprietary product of course.
> > 
> > - JSP/ASP-pages. From the beginning these approaches were based on
> > embedding imperative serverside code in HTML pages but according to a
> > collegue "JSP best practices" is currently to use "custom tags with
> > parameters" instead making this apporach more declarative and in fact
> > "just another template engine" I guess.
> > 
> > - XML+XSL. XSL is a XML-based language that can describe very complex
> > transforms of XML-documents into other XML-documents. As "standard" as
> > it gets. Which mean tons of tools and tutorials and websites etc but at
> > the sime time quite complex IMHO. Sure, you don't need to use all that
> > complexity but I have heard that one before... ;-)
> > 
> > - Seaside/HttpView. In Seaside and HttpView we have taken a
> > Smalltalk-centric approach (well, Seaside has multiple approaches I
> > think) where we "build" HTML using smalltalk. Almost like DOM but more
> > "streamish", at least in HttpView.
> > 
> > Well, surely there are other approaches out there too.
> > 
> > When I did HttpView I was sick of everything called JSP/ASP and wanted
> > something much simpler and direct. I also wanted something that could
> > work with Forms in a very easy way. The end result turned into a
> > HtmlBuilder object that produces XHTML. Since CSS has come quite a long
> > way and you typically only have one or very few CSS-files this meant
> > that there was essentially only one source for a page - the Smalltalk
> > code. Nice and simple.
> > 
> > I had an intention to implement new HtmlBuilder classes that could also
> > "merge" the HTML into some form of template coming from the "outside".
> > Exactly how that could work is still a bit clouded. One way could be to
> > not change anything and just slap an XSL engine "on top" that can add
> > "looks" as a last step before hitting the client browser. Another way
> > could be to create some "custom" highlevel XML document and feed that
> > into an XSL engine to turn it into XHTML with looks.
> > 
> > Or perhaps use some other templating mechanism that can let the "HTML
> > gurus" do their job. For example - here is one interesting approach that
> > may be impossible:
> > 
> > 1. Build the webapp as simply as possible but actually working.
> > 2. Turn on some form of "ids in tags" generation which means that the
> > HtmlBuilder adds ids in the generated tags to keep track of them.
> > 3. Let the designer run the app and simply do "Save as..." on the HTML
> > pages/HTML components. (Given that any given component easily can be
> > addressed separately or at least "cut out" from an HTML page, for
> > example if contained within a div-tag). Of course you could let the
> > serverside app save out the HTML pages instead of returning them through
> > HTTP, etc. whatever.
> > 4. Let the designer edit them into glorious looking HTML that no mortal
> > can ever read.
> > 5. Feed the new HTML pages (and CSS+any scripts of course) back into the
> > HtmlBuilder that somehow can take the original page and the "glorified"
> > page and from that (and the embedded "track" tag ids) construct an
> > internal template of some kind.
> > 6. Turn of the tag ids, they aren't useful anymore - they were only used
> > for tracking the generated tags.
> > 
> > Anyway, perhaps the above is impossible to accomplish - but it would be
> > cool if it did. I can focus on coding Smalltalk and a simple subset of
> > XHTML, the designer can focus on webpage "good looks" and doesn't need
> > to handcode XSL or anything.
> > 
> > Ok, now Avi and Julian - what do you think? What is the ultimate
> > templating mechanism? :-)
> > 
> > regards, Göran
> > 
> > 
> > 
> 
> 
> 
>