DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 9 of 9

Thread: framesets in XSL?

  1. #1
    kevin Guest

    framesets in XSL?


    We are following a servlet model wherein our servlets generate XML documents,
    transform the documents with XSL and then send the translated output (HTML)
    down to the browser. We are trying to stick to an MVC model, which means
    the construction of the XML doc does not know about what work the XSL stylsheet
    will do to construct the UI.

    In general, this works great for us. BUT we are struggling with how to support
    framesets in this model. We do NOT want to have to generate frame specific
    content, since that would mean potentially structuring our server code to
    be appropriate for every UI permutation we need to support (our environment
    is highly customizable). If we have five customers that want five custom
    user interfaces, we do not want to implement each differently in the middleware
    - we'd like to isolate the differences at the XSL level.

    XSL 1.1 has a new feature that allows frames to be supported by writing XML/XSL
    output to the file system as a new document and then referencing the new
    document (.html) in a frameset. So you could have a stylesheet that creates
    a couple frames, as new docs in the file system, that are then pulled down
    by the browser. This is supported in SAXON.

    However, this seems inelegant because it results in all your dynamic content
    being written into the file system, creating a potential file management
    and security nightmare. I also would expect that customers might be queasy
    about the idea of writing their content into the file system in this way.


    Has anybody solved the frameset problem a different way or do you know of
    any standard schemes for dealing with transforming an XML doc across a frameset?
    I can't believe there isn't a better solution out there.

    Thanks in advance for insights.



  2. #2
    Russell Jones Guest

    Re: framesets in XSL?

    You can isolate the changes at the XSL level by creating templates that
    return individual frame contents from the same XML document. For example,
    suppose the user requests the top file. You use an XSLT template that simply
    outputs the appropriate frame structure for that client. Each frame calls
    back to the same page (or a different page, if you prefer) which transforms
    the XML document by sending parameters to the same template. For example a
    parameter of "leftframe" might retrieve a list of authors from a document
    containing book information, while the a parameter of "rightframe"
    accompanied by an AuthorID parameter might return the detail information for
    a particular author.

    You can then refactor the information in any frame by simply writing a new
    XSLT template or creating a new parameter that handles the permutation for a
    different client or frame.

    There's no need to write any of this into a file--just return the template
    output based on the frame that's requesting it and the client type.

    HTH
    Russell Jones
    Sr. Web Development Editor
    DevX.com



    "kevin" <kpolk@iconstructs.com> wrote in message
    news:3b1bee72$1@news.devx.com...
    >
    > We are following a servlet model wherein our servlets generate XML

    documents,
    > transform the documents with XSL and then send the translated output

    (HTML)
    > down to the browser. We are trying to stick to an MVC model, which means
    > the construction of the XML doc does not know about what work the XSL

    stylsheet
    > will do to construct the UI.
    >
    > In general, this works great for us. BUT we are struggling with how to

    support
    > framesets in this model. We do NOT want to have to generate frame specific
    > content, since that would mean potentially structuring our server code to
    > be appropriate for every UI permutation we need to support (our

    environment
    > is highly customizable). If we have five customers that want five custom
    > user interfaces, we do not want to implement each differently in the

    middleware
    > - we'd like to isolate the differences at the XSL level.
    >
    > XSL 1.1 has a new feature that allows frames to be supported by writing

    XML/XSL
    > output to the file system as a new document and then referencing the new
    > document (.html) in a frameset. So you could have a stylesheet that

    creates
    > a couple frames, as new docs in the file system, that are then pulled down
    > by the browser. This is supported in SAXON.
    >
    > However, this seems inelegant because it results in all your dynamic

    content
    > being written into the file system, creating a potential file management
    > and security nightmare. I also would expect that customers might be queasy
    > about the idea of writing their content into the file system in this way.
    >
    >
    > Has anybody solved the frameset problem a different way or do you know of
    > any standard schemes for dealing with transforming an XML doc across a

    frameset?
    > I can't believe there isn't a better solution out there.
    >
    > Thanks in advance for insights.
    >
    >




  3. #3
    kevin Guest

    Re: framesets in XSL?


    >outputs the appropriate frame structure for that client. Each frame calls
    >back to the same page (or a different page, if you prefer) which transforms
    >the XML document by sending parameters to the same template. For example

    a

    Thanks for the reply.

    I've thought about this approach. The main concern I have is the inefficiency
    of loading the document back up multiple times (for each frame). If there
    were 3 frames, for example, and 2 were fairly sparse but the 3rd contained
    a fair amount of data, it seems like you'd be hitting the server/db quite
    a few times to retrieve data "unnecessarily." That concerns me.

    I don't have any better suggestions though. Have you put this into practice
    and do you have any concerns about the amount of server traffic that is unnecessarily
    generated?

  4. #4
    Russell Jones Guest

    Re: framesets in XSL?

    Kevin:

    Frames *always* hit the server multiple times--it's one reason to avoid
    frames. A page with frames always makes--at minimum--framecount + 1
    requests: one for the frameset page and one for each frame. If you're
    interested in avoiding the frames approach, there are better ways, but their
    suitability depends on the client capabilities. For example, you can build
    the page all at once on the server using <div> tags to separate the various
    areas of the screen. The problem with this approach is that the entire page
    refreshes when you need to change the data in an area of the screen rather
    than just that one area. Again, depending on the client, you may be able to
    offload much of that processing to the client machine and minimize the
    number of page refreshes required.

    For example, if all your clients have IE 5 or higher, you can deliver the
    data to the client via XML, and then use XSLT to insert the appropriate
    contents into the various areas of the screen, divided into <div> tags. You
    can use the XMLHttpRequest object to retrieve new data from the server and
    replace the content of a <div> in response to a user action. Using this type
    of approach, your application becomes one (or just a few) pages and acts
    much more like a Win32 application. This approach reduces server hit count
    the most, because you presumably send appropriate data to the client during
    the first access, and the client simply transforms bits of that data as
    necessary thereafter.

    If the clients all have JavaScript (or ECMAScript) and DHTML capabilities,
    you can use remote scripting to retrieve the data. If the client can
    transform the data locally, great; if not, you can return HTML from the
    server. Note that this approach only reduces server hit count on the first
    access--each update will require a round-trip. But it does solve the frames
    problem, by letting you update only specific areas of the screen.

    The lowest common denominator consists of clients that can only display data
    and don't support frames, JavaScript, or DHTML. For these clients, you must
    serve the entire page for *any* display change. XSLT
    transformations--because they're optimized code--are generally faster than
    homegrown methods for building responses to requests for data.

    If you're going to support frames, as I said in the previous note, you can
    avoid writing content to the file system by using XSLT to provide the frame
    content from the same source document, but you can't avoid getting multiple
    hits to serve a single page.

    Russell Jones
    Sr. Web Development Editor,
    DevX.com

    "kevin" <kpolk@iconstructs.com> wrote in message
    news:3b1c30d2$1@news.devx.com...
    >
    > >outputs the appropriate frame structure for that client. Each frame calls
    > >back to the same page (or a different page, if you prefer) which

    transforms
    > >the XML document by sending parameters to the same template. For example

    > a
    >
    > Thanks for the reply.
    >
    > I've thought about this approach. The main concern I have is the

    inefficiency
    > of loading the document back up multiple times (for each frame). If there
    > were 3 frames, for example, and 2 were fairly sparse but the 3rd contained
    > a fair amount of data, it seems like you'd be hitting the server/db quite
    > a few times to retrieve data "unnecessarily." That concerns me.
    >
    > I don't have any better suggestions though. Have you put this into

    practice
    > and do you have any concerns about the amount of server traffic that is

    unnecessarily
    > generated?




  5. #5
    kevin Guest

    Re: framesets in XSL?


    Russell:

    Thanks for the reply and the insight on frames.

    I'll leave it at this. Our application is extensively customer configurable
    and it is meant to accomodate our customers' varying UI requirements. In
    some cases, we can successfully steer our customers away from frame-based
    implementations, in others cases we cannot. For example, we recently went
    through an iterative design process with a customer and were relieved to
    have at least whittled their frame design down from 9 frames to 4. Unfortunately,
    the customer sometimes drives these decisions. And of course not all applications
    can be restricted to a subset of the browser market. We need to support
    Netscape, IE, Mac, Windows - our solution choices are thus limited.

    In the case where frames are required and XML/XSL is the scheme, it still
    seems to me that this points to an inherent weakness of the model. You don't
    want your XML generation to be aware of the frameset and you don't want to
    generate the document multiple times, once for each frame + once more for
    the frameset. Neither approach is really acceptable IMO. Nor do you really
    want to output the frame content to the file system, as the new capabilities
    of XSL 1.1 encourages. While the latter scheme avoids the multi-gen problem,
    it has its own weaknesses.

    I have yet to come across an interesting scheme that allows a single XML
    document, generated once, to be distributed across a framed UI in an efficient
    manner. That seems like a serious limitation for which there is no good
    solution at this time.



  6. #6
    Sean Guest

    Re: framesets in XSL?


    Kevin,
    XSLT is more than just for creating HTML Pages. It is used for transforming
    xml to other formats.
    If parts of the frames are static then perform 4 transformations and cache
    the static ones for further use.
    The problem people have is these technologies are forcing people to think
    about the design and architecture of their web sites/applications, this is
    a major change in the industry.

    Sean

    "kevin" <kpolk@iconstructs.com> wrote:
    >
    >Russell:
    >
    >Thanks for the reply and the insight on frames.
    >
    >I'll leave it at this. Our application is extensively customer configurable
    >and it is meant to accomodate our customers' varying UI requirements. In
    >some cases, we can successfully steer our customers away from frame-based
    >implementations, in others cases we cannot. For example, we recently went
    >through an iterative design process with a customer and were relieved to
    >have at least whittled their frame design down from 9 frames to 4. Unfortunately,
    >the customer sometimes drives these decisions. And of course not all applications
    >can be restricted to a subset of the browser market. We need to support
    >Netscape, IE, Mac, Windows - our solution choices are thus limited.
    >
    >In the case where frames are required and XML/XSL is the scheme, it still
    >seems to me that this points to an inherent weakness of the model. You

    don't
    >want your XML generation to be aware of the frameset and you don't want

    to
    >generate the document multiple times, once for each frame + once more for
    >the frameset. Neither approach is really acceptable IMO. Nor do you really
    >want to output the frame content to the file system, as the new capabilities
    >of XSL 1.1 encourages. While the latter scheme avoids the multi-gen problem,
    >it has its own weaknesses.
    >
    >I have yet to come across an interesting scheme that allows a single XML
    >document, generated once, to be distributed across a framed UI in an efficient
    >manner. That seems like a serious limitation for which there is no good
    >solution at this time.
    >
    >



  7. #7
    Russell Jones Guest

    Re: framesets in XSL?

    Kevin:

    If the client is script-enabled, then you can write functions in the first
    frame that return the content for the other frames, thus enabling you to
    make only one trip to the server. For example, in the first defined frame,
    write a script that returns the content for another frame:

    **** frameset page *******
    <HTML>
    <HEAD>
    <META NAME="GENERATOR" Content="Microsoft Visual Studio 6.0">
    <TITLE></TITLE>
    <frameset cols="50%,*">
    <frame name="leftFrame" src="frames.asp" frameborder="yes">
    <frame name="rightFrame" frameborder="yes" src="">
    </frameset>
    </HEAD>
    </HTML>

    ********** frames.asp page *********
    <script language="JavaScript">
    var s = "<html><head></head><body>This is a test</body></html>";
    window.parent.frames(1).document.body.innerHTML = s;
    </script>

    Now you can load all your content into the first frame and have only two
    server calls -- one for the frameset page and one for the frames.asp page.

    The frames problem itself has nothing to do with XSLT or XML. The fact is
    that the browser loads frames by making multiple requests to the server;
    therefore, if you use frames, you must be able to serve the content for each
    frame as a separate request. You can get around this to some degree using
    the methods I've already described.

    "Sean" <sean@ireland.com> wrote in message news:3b1dd04b$1@news.devx.com...
    >
    > Kevin,
    > XSLT is more than just for creating HTML Pages. It is used for

    transforming
    > xml to other formats.
    > If parts of the frames are static then perform 4 transformations and cache
    > the static ones for further use.
    > The problem people have is these technologies are forcing people to think
    > about the design and architecture of their web sites/applications, this is
    > a major change in the industry.
    >
    > Sean
    >
    > "kevin" <kpolk@iconstructs.com> wrote:
    > >
    > >Russell:
    > >
    > >Thanks for the reply and the insight on frames.
    > >
    > >I'll leave it at this. Our application is extensively customer

    configurable
    > >and it is meant to accomodate our customers' varying UI requirements. In
    > >some cases, we can successfully steer our customers away from frame-based
    > >implementations, in others cases we cannot. For example, we recently

    went
    > >through an iterative design process with a customer and were relieved to
    > >have at least whittled their frame design down from 9 frames to 4.

    Unfortunately,
    > >the customer sometimes drives these decisions. And of course not all

    applications
    > >can be restricted to a subset of the browser market. We need to support
    > >Netscape, IE, Mac, Windows - our solution choices are thus limited.
    > >
    > >In the case where frames are required and XML/XSL is the scheme, it still
    > >seems to me that this points to an inherent weakness of the model. You

    > don't
    > >want your XML generation to be aware of the frameset and you don't want

    > to
    > >generate the document multiple times, once for each frame + once more for
    > >the frameset. Neither approach is really acceptable IMO. Nor do you

    really
    > >want to output the frame content to the file system, as the new

    capabilities
    > >of XSL 1.1 encourages. While the latter scheme avoids the multi-gen

    problem,
    > >it has its own weaknesses.
    > >
    > >I have yet to come across an interesting scheme that allows a single XML
    > >document, generated once, to be distributed across a framed UI in an

    efficient
    > >manner. That seems like a serious limitation for which there is no good
    > >solution at this time.
    > >
    > >

    >




  8. #8
    kevin Guest

    Re: framesets in XSL?


    >The problem people have is these technologies are forcing people to think
    >about the design and architecture of their web sites/applications, this

    is
    >a major change in the industry.


    Let me present sample scenario so that I might better understand how to look
    at all this the Right Way.

    Let's say our server generates an XML document, the contents of which contain
    a list of patients for a doctor; let's say that this list typically includes
    50 names + related info.

    The application is sold to different hospitals. Let's say that one hospital
    wishes to display the patient list in a single HTML page. Let's say that
    another hospital wants to display the patient list in two frames, with male
    patients on the left and female patients on the right. Both these customers
    are "right" about what they need and want from our app and our job is to
    simply our app work properly for each.

    It seems to me that we do not want to make our middleware cognizant of the
    different ways in which the UI will be permutated or to generally have to
    accomodate different UI implementations in the middleware. These differences
    should be isolated in the XSL layer, in my opinion. This seems like this
    would be a reasonable way to view things if you are working with an MVC model
    in mind. It brings along some headaches but that's the design challenge.

    It still seems to me that to implement the frameset within XSL, which requires
    two loads of the XML document in the worst case of this example, which in
    turn requires two traversals through the data retrieval and document construction
    path, can be woefully inefficient. I understand that this is the nature
    of frames, that they incur multiple hits to the server, etc. Yet I do not
    buy that the choices are a) let each frame hit the server to reconstruct
    the same document just to display a different portion of it or b)to create
    server code that constructs the specific content of each frame.

    The challenge is not to choose the lesser of a few evils that are readily
    apparent, the challenge seems to be to find a way to optimize around the
    limitations that these challenges present. That would mean finding a way
    to generate the document once per frameset, to cache it but in memory and
    thus facilitate the appropriate transformation for each frame more efficiently,
    and to free it up when it is no longer needed. I would be disappointed to
    find that there have been no solutions that are more creative than simply
    having the document reloaded once per frame + frameset. That just seems
    to incur unacceptable server work.

    Russellls suggestion of using innerHTML is a great option that we considered.
    The problem is that this is not available on Netscape, which is a problem
    for us. I would be looking for conceptually equivalent solutions with different
    less browser restrictive implementations. Any specific ideas along these
    lines would be appreciated.




  9. #9
    Russell Jones Guest

    Re: framesets in XSL?

    Kevin:

    Just because the browser is going to make multiple requests to the server
    does not mean that you can't cache the results in memory. For example,
    because you control the code--you *know* that if a browser requests the
    frameset page, that you can expect to get a request for each frame
    momentarily. Therefore, you can load the document once, perform the
    processing required to create the frames while the document is loaded, and
    cache the results in memory. Then, when the requests for the frame content
    arrive, you'll have already built the page.

    > It still seems to me that to implement the frameset within XSL, which

    requires
    > two loads of the XML document in the worst case of this example, which in
    > turn requires two traversals through the data retrieval and document

    construction
    > path, can be woefully inefficient.

    I don't know what technology you're using on the server, but MSXML has
    excellent support for caching objects in memory, including the
    FreeThreadedDOMDocument object, the XSLTemplate object and the SchemaCache
    objects. In other words, having loaded the documents, templates and schemas
    once, you can leave them in memory for the duration of the application or
    session.

    In your earlier posts, you said you were trying to minimize the number of
    server round-trips. I showed you how to do that in my preceding post. Now,
    you're saying that you simply want to pre-build the frame results. You can
    do that too, by caching the objects in the preceding paragraph.



    "kevin" <kpolk@iconstructs.com> wrote in message
    news:3b1ee67c$1@news.devx.com...
    >
    > >The problem people have is these technologies are forcing people to think
    > >about the design and architecture of their web sites/applications, this

    > is
    > >a major change in the industry.

    >
    > Let me present sample scenario so that I might better understand how to

    look
    > at all this the Right Way.
    >
    > Let's say our server generates an XML document, the contents of which

    contain
    > a list of patients for a doctor; let's say that this list typically

    includes
    > 50 names + related info.
    >
    > The application is sold to different hospitals. Let's say that one

    hospital
    > wishes to display the patient list in a single HTML page. Let's say that
    > another hospital wants to display the patient list in two frames, with

    male
    > patients on the left and female patients on the right. Both these

    customers
    > are "right" about what they need and want from our app and our job is to
    > simply our app work properly for each.
    >
    > It seems to me that we do not want to make our middleware cognizant of the
    > different ways in which the UI will be permutated or to generally have to
    > accomodate different UI implementations in the middleware. These

    differences
    > should be isolated in the XSL layer, in my opinion. This seems like this
    > would be a reasonable way to view things if you are working with an MVC

    model
    > in mind. It brings along some headaches but that's the design challenge.
    >
    > It still seems to me that to implement the frameset within XSL, which

    requires
    > two loads of the XML document in the worst case of this example, which in
    > turn requires two traversals through the data retrieval and document

    construction
    > path, can be woefully inefficient. I understand that this is the nature
    > of frames, that they incur multiple hits to the server, etc. Yet I do not
    > buy that the choices are a) let each frame hit the server to reconstruct
    > the same document just to display a different portion of it or b)to create
    > server code that constructs the specific content of each frame.
    >
    > The challenge is not to choose the lesser of a few evils that are readily
    > apparent, the challenge seems to be to find a way to optimize around the
    > limitations that these challenges present. That would mean finding a way
    > to generate the document once per frameset, to cache it but in memory and
    > thus facilitate the appropriate transformation for each frame more

    efficiently,
    > and to free it up when it is no longer needed. I would be disappointed to
    > find that there have been no solutions that are more creative than simply
    > having the document reloaded once per frame + frameset. That just seems
    > to incur unacceptable server work.
    >
    > Russellls suggestion of using innerHTML is a great option that we

    considered.
    > The problem is that this is not available on Netscape, which is a problem
    > for us. I would be looking for conceptually equivalent solutions with

    different
    > less browser restrictive implementations. Any specific ideas along these
    > lines would be appreciated.
    >
    >
    >




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center