Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. XML / XSL
  4. Automatic processing XML/XSLT on client or server side

Automatic processing XML/XSLT on client or server side

Scheduled Pinned Locked Moved XML / XSL
xmlquestionjavahtmldatabase
2 Posts 2 Posters 3 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • K Offline
    K Offline
    Kosta Cherry
    wrote on last edited by
    #1

    Hi All! OK, here is architecture question: My ultimate goal is: move "clent/server" application to web-site using XML/XSL. If user's browser is capable of processing XML/XSLT, processing should be performed on the cliend side, if not - on the server side. That is a problem that I don't understand how to implement it: 1. I cannot let user access URL where it will be name like http:///myform.xml for two reasons: - I cannot process DB connection in that .xml file. Situation is: some users will access data using common DB name, some will access it using their very own DB name. As far as I understand, I cannot do that in .xml file, so I need some sort of .asp or jsp or something else. - User's browser could be so old that it will not understand .xml extention. I don't know is it valid reason or not (I'm VERY new to web development). 2. So I need to let user access URL where it will be name like http:///myform.asp or http:///myform.jsp. That page will internally (depending on a user's browser) do one of this: - either take my .xml page, process it with my .xsl page and send result .html to the user; OR - take my .xml page and send it directly to user'sd browser. User's browser will see .xsl reference inside, automatically load that .xsl from my site, and process both of them locally at client (I hope :)) 3. Now it is a problem. Suppose, user want to resort columns in the table (which he see on the screen). In case of old browser it is easy - link will "POST" form back to server, server will process .xml again and return .html to the user. What if user uses new browser and I want it process it again locally? If user accessed URL http:///myform.xml, than myform.xml would be sitting in cash on user's computer (together with .xsl), so I could call "load" method of XSLT locally in browser, so browser will not connect to server again. But in my scenario user accesed http:///myform.asp. If I will specify that name as parameter for "load" function, browser will go to server for new copy of the same data (which I'm trying to avoid). If I will specify http:///myform.xml - such file does not exist locally, it exists with some other name (which I don't know). So what could be a solution? I'm sure it's obvious, I'm just overloaded with this new technic and cannot get it :( Hope my description of a problem was clear :). SY- Kosta.

    M 1 Reply Last reply
    0
    • K Kosta Cherry

      Hi All! OK, here is architecture question: My ultimate goal is: move "clent/server" application to web-site using XML/XSL. If user's browser is capable of processing XML/XSLT, processing should be performed on the cliend side, if not - on the server side. That is a problem that I don't understand how to implement it: 1. I cannot let user access URL where it will be name like http:///myform.xml for two reasons: - I cannot process DB connection in that .xml file. Situation is: some users will access data using common DB name, some will access it using their very own DB name. As far as I understand, I cannot do that in .xml file, so I need some sort of .asp or jsp or something else. - User's browser could be so old that it will not understand .xml extention. I don't know is it valid reason or not (I'm VERY new to web development). 2. So I need to let user access URL where it will be name like http:///myform.asp or http:///myform.jsp. That page will internally (depending on a user's browser) do one of this: - either take my .xml page, process it with my .xsl page and send result .html to the user; OR - take my .xml page and send it directly to user'sd browser. User's browser will see .xsl reference inside, automatically load that .xsl from my site, and process both of them locally at client (I hope :)) 3. Now it is a problem. Suppose, user want to resort columns in the table (which he see on the screen). In case of old browser it is easy - link will "POST" form back to server, server will process .xml again and return .html to the user. What if user uses new browser and I want it process it again locally? If user accessed URL http:///myform.xml, than myform.xml would be sitting in cash on user's computer (together with .xsl), so I could call "load" method of XSLT locally in browser, so browser will not connect to server again. But in my scenario user accesed http:///myform.asp. If I will specify that name as parameter for "load" function, browser will go to server for new copy of the same data (which I'm trying to avoid). If I will specify http:///myform.xml - such file does not exist locally, it exists with some other name (which I don't know). So what could be a solution? I'm sure it's obvious, I'm just overloaded with this new technic and cannot get it :( Hope my description of a problem was clear :). SY- Kosta.

      M Offline
      M Offline
      Michael A Barnhart
      wrote on last edited by
      #2

      Given that it looks like you do not have good control on the browser the client will be using, I would highly recommend only doing server side processing. I.E. keep it as you say easy with the POST. Even if you have some performance issue, Make it work right first with the extra database calls. Then you can take time to make it work better after you have some experience. "I will find a new sig someday."

      1 Reply Last reply
      0
      Reply
      • Reply as topic
      Log in to reply
      • Oldest to Newest
      • Newest to Oldest
      • Most Votes


      • Login

      • Don't have an account? Register

      • Login or register to search.
      • First post
        Last post
      0
      • Categories
      • Recent
      • Tags
      • Popular
      • World
      • Users
      • Groups