Re: creating templates for page fragments?

Hi Arno,

In #3 when you say "ASP tags", I think you mean Server-Side
Includes (SSI's) which are *not* Microsoft ASP specific.  SSI's are
a standard feature that is implemented by most, if not all, webservers
around.  I put snippets in .ssi's and include them in my mockup
pages.  To view the mockups, I just run them through a standard
webserver like Apache with SSI support on.  XMLC recognizes SSI
syntax and will compile those snippets right into the XMLC
object.

For runtime inclusion of Widgets, I suggest that you check out the
Barracuda framework (
http://barracuda.enhydra.org/
).  It treats HTML elements as components.  Normally, widgets would be form elements, but any element can work here.  In addition, you can use BTemplate which simplifies lots of stuff like the creation of multiple rows in HTML tables and such.

Also, with the upcoming XMLC-2.2, there will be runtime reloading of HTML pages and XMLC classes.  See David Li's demo app using XMLC-2.2alpha.  It is really eye-opening how well the reloading works!  You get the benefits of JSP-like reloading without all the negatives of JSP.

http://homepage.mac.com/taweili/XMLC.html

Jake

At 10:35 AM 12/13/2002 +0100, you wrote:
> Hi David,
>
> there are serveral approaches to your problem, which we have too.
>
> 1. the one you are describing, combining the fragments at runtime (disadvantage is that you have to code that in your app for each wifget, and the fragements by themselves are more difficult to develop because to view the hole page you need to run the application)
>
> 2. use the Server side include functionality of XMLC, which I actually never used so I just can point you to the manual.
>
> 3. (my favorite) For static HTML the HTML designer have a mechanism in place to deal with these snippets already (some use ASP tags inside their snippets, and when they want to deploy the site, they generate every page). The thing I like about XMLC is that the HTML designer can work as if it was an static HTML. Many tools (for HTML designers) already have these kind of functionality, they can just use that. So they have a set of fragments and produce the whole site as if it was static, then XMLC compiles those pages.
>
> 4. (for compeletness) In actual projects it happens, that the HTML is redundantly maintained. :-(
>
> If someone else has a diferent method, please pitch in...
>
> Arno
>
> David Michaels wrote:
> > It could be argued that (in some cases) XMLC requires more effort vs. writing classes to render commonly used UI elements.  For instance, if the same exact list widget appears on a dozen pages, the XMLC approach would require the UI designer to mockup that same list on each page in which it will appear.
> >  
> > Perhaps I could mockup commonly-used UI components in their own HTML ?fragment? pages, compile them via XMLC, and create the page at runtime consisting of multiple XMLC page objects.  
> >
> > Anyone have thoughts on doing this?  Is it straightforward to call multiple writeDOM() methods in sequence to build the final page?
> >  
> > Thanks!
> >  
> > --
> > David Michaels <dkm@xxxxxxx <mailto:dkm@xxxxxxx>>
> > Director of Web Engineering
> > PGP Corporation (650) 319-9009
> >  
>
> _______________________________________________
> XMLC mailing list
> XMLC@xxxxxxxxxxx
> http://www.enhydra.org/mailman/listinfo.cgi/xmlc