RE: Guidance on XML in Objects vs. Iframes vs. complet

http://www.netcrucible.com/xslt/einclude.htm


I dislike object and iframes because of portability issues.  I use the
referenced stylesheet to build recursively compound documents like you 
describe.  It is pure XSLT and works in Netscape or IE client-side.


> 
> > -----Original Message-----
> > From: bix xslt [mailto:bix_xslt@xxxxxxxxxxx]
> > Sent: Wednesday, March 05, 2003 12:23 PM
> > To: XSL-List@xxxxxxxxxxxxxxxxxxxxxx
> >
> > All,
> >
> > This is more of a design question.  I have come up with a scenario
where
> I
> > would really like to display my data in several different ways using
> > various
> > xslt transformations.  The various transformations together form a
nice
> > GUI
> > environment where I (and my team) can quickly access the information
we
> > are
> > most interested in.  In addition, all of my data is on the client's
> > computer
> > and no access is required across the internet.
> >
> > For instance, suppose the data in the XML file looks something like
> this:
> >
> > <obj>
> >   <obj label="requirements">
> >     <obj label="req_subset">
> >         <obj label="req_a"/>
> >         <obj label="req_b"/>
> >         <obj label="req_c"/>
> >         <obj label="req_d"/></obj></obj>
> >
> >     <obj label="various_reqs"/></obj>
> >
> >   <obj label="design">
> >     <obj label="design_artifacts"/></obj>
> >
> >   <obj label="etc">
> >     <obj label="moreElements"/></obj>
> > </obj>
> >
> > I might want to display a menu (e.g. transform sampleFromAbove.xml
using
> > menu.xslt) which creates a something of the effect:
> > - requirements
> >    + req_subset
> >    * various_reqs
> > + design
> > + etc
> >
> > I might want to display an index of the various items contained
within
> the
> > nodes (i.e. index.xslt).  I might also want to display the current
path
> in
> > another portion of the view (i.e. path.xslt produces
> > requirements->req_subset->req_a).  Another example may be that I
would
> > want
> > to create a small section of the web view where the data could be
> queried
> > for a particular label.  The end result would be a compact, useful
view
> > that
> > all uses that original data file.
> >
> > The question is where does it make sense to transform this data?  Do
I
> > make
> > all of the transformations at the top node, and then, using <div>
> elements
> > produce my desired output?  Do create the html page first, and then
> > fragment
> > the xml data into the different types (i.e. menu, path, index,
search,
> > etc.)
> > with each producing its own html?  If I do the latter method, does
it
> make
> > sense to have embedded xml objects or iframes?
> >
> > At a future point in time, I may wish to update the menu code so
that I
> > can
> > display either a vertical or horizontal display of the data.
Perhaps
> I'd
> > like the index information to reference only the child nodes as
opposed
> to
> > the entire tree.  In other words, I want the environment flexible
enough
> > that it can be extended (hence the various groupings of .xslt
files).  I
> > have noted that iframes allow me to produce a "space" on the screen
> where
> > I
> > would have scrollbars (something that will become significant as my
data
> > grows), allowing me to keep the displayed material compact, and yet
> still
> > be
> > flexible to increased amounts of data.
> >
> > Finally, is there any reference material that anyone might be able
to
> > point
> > me to for this type of design work?
> >
> > Thanks in advance!
> > bix
> >
> > _________________________________________________________________
> > MSN 8 with e-mail virus protection service: 2 months FREE*
> > http://join.msn.com/?page=features/virus
> >
> >
> >  XSL-List info and archive:
http://www.mulberrytech.com/xsl/xsl-list
> >


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