Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xsl] Swing-style Glue and Struts

From: Wendell Piez <wapiez@---------------->
To:
Date: 8/1/2001 7:24:00 AM
James,



What you describe is, as you apparently suspect, very ambitious. It is 
perilously close to constraint-based, layout-driven formatting, which is 
still a ways out.



For example, you're bound to find that "count[ing] lines within the 
template match block that were copied through" will be a bear. What's a 
"line"? Will it be a structure in your source (say a <line> element) you 
can count, or will you have to resort to other means to count them?



Another problem you'll have is that HTML is *not* well-suited to support 
this design paradigm: you are bound to require many kluges, browser 
dependencies etc. if you try to get at all complex. (For example, you need 
to go to CSS ... still unevenly supported ... before you can get a notion 
of "vertical line spacing" in HTML.) Trying to teach a dog to dance, etc. 
(Now, *eventually* it is to be hoped that XSL-FO may do this kind of thing 
fairly gracefully. But not soon: let's get v.1 first. Some SVG people are 
beginning to make noises about constraint-based processing for their v.2. I 
hope they try it: it seems a natural place to take a first stab at the 
problem.)



Now, this is not to say the task you describe is impossible, if (as you 
stipulate) your "layout manager" is rudimentary enough. Just don't try to 
get too ambitious: go one tiny step at a time.



Just my impressions. I hope someone whose hands are deeper in the guts of 
the technologies is willing to weigh in. (I'm just a "user".)



Cheers,
Wendell

At 10:03 AM 8/1/01, you wrote:
 In Java Swing, you can nudge components around within a GUI
 layout by adding Glue and Strut components.
 I would like to implement something similar using XSLT with my
 servlet's XML output, resulting in HTML table cells that
 incorporate a rudimentary layout manager...

 I would like to guarentee vertical table cell size, without
 knowing until XML generation time, how many text lines will be in
 the cell.

 I suppose that I would have to generate a tag/value combination
 that would specify the desired vertical line spacing, then I
 would have to count lines within the template match block that
 were copied through, and then take the difference (if one
 existed...) and send that value as a parameter to a subroutine
 that generated lines with just whitespace...

 Before I embark on this XSLT Odyssey, do the experienced XSLTers
 on this list think this is viable? Or are there hidden perils in
 this task that come to mind?

 -Jim Parsons, ArsDigita Corp.
 -jparsons@xxxxxxxxxxxxx

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list




======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================


XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


transparent
Print
Mail
Digg
delicious
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent