Template mechanisms...

Jason Rogers jacaetevha at fast-mail.org
Thu Dec 12 17:13:42 UTC 2002


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





More information about the Squeak-dev mailing list