<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Mike,<br>
<br>
>I think the point Rimantas is making is that you aren't bookmarking
that node. <br>
>The fact that one node in the treeview represents one table row
leaves out the <br>
>reality that the node contains a URL and that clicking on the node
simply <br>
>submits a URL to your application and awaits an HTML response.<br>
<br>
Not sure what your point is. Obviously "bookmarking a node" is
shorthand for bookmarking a UI element which webapp logic ties to a
particular database element. What makes you think I forgot that?<br>
<br>
>Users of the application are bookmarking the URL that the <br>
>application uses to retrieve that row and format the response as
HTML. <br>
<br>
That's exactly what we prevent the user from doing. She may use the UI
representation of a node to instruct the webapp to open up its tree
branch or fetch its detail, but may not persist that link as a bookmark.<br>
<br>
>So, as Rimantas mentioned, since the browser owns the bookmark ...<br>
<br>
Eh? He didn't say that; you're quoting me. Browsers  own
bookmarks, database users own database table rows, so it must be
possible in database maintenance webapps to prevent bookmarking of
elements which represent database table rows. And again, I agree that
framesets do not by themselves block such bookmarking; they just make
it easy to do so.<br>
<br>
PB<br>
<br>
-----<br>
<br>
Mike Ressler wrote:
<blockquote
 cite="mid:1fec3f0a0910160951i5ec52b42geb723c798332ad58@mail.gmail.com"
 type="cite">PB,<br>
  <br>
I think the point Rimantas is making is that you aren't bookmarking
that node.  The fact that one node in the treeview represents one table
row leaves out the reality that the node contains a URL and that
clicking on the node simply submits a URL to your application and
awaits an HTML response.<br>
  <br>
Users of the application are bookmarking the URL that the application
uses to retrieve that row and format the response as HTML.  So, as
Rimantas mentioned, since the browser owns the bookmark (and therefore
the URL) and the application itself owns the semantic knowledge of what
that URL means, the application is the appropriate agent to control
what is done when that URL is submitted to it.<br>
  <br>
I thought you had agreed a while ago that there are a lot of inventive
ways of disallowing bookmarking of the particular row in a treeview?<br>
  <br>
Mike<br>
  <br>
  <div class="gmail_quote">On Fri, Oct 16, 2009 at 12:19 PM, Peter
Brawley <span dir="ltr"><<a moz-do-not-send="true"
 href="mailto:pb@artfulsoftware.com">pb@artfulsoftware.com</a>></span>
wrote:<br>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
    <div bgcolor="#ffffff" text="#000000">
Rimantas,
    <div class="im"><br>
    <pre>>How on Earth can you bookmark database table rows? Your database knows
>nothing where its rows go, the browser does not know where does HTML
>originates in: it may be DB, may be XML transformed via XSLT, may be static
>files on the server.
    </pre>
    </div>
?! In a data-driven treeview, one node represents one table row.<br>
    <br>
PB<br>
    <br>
-----<br>
    <br>
Rimantas Liubertas wrote:
    <blockquote type="cite">
      <div>
      <div class="h5">
      <blockquote type="cite">
        <pre>OK and for clarity's sake I'll again repeat framesets don't solve the
navigation problem, they just make it easier to solve than any other
available proved solution, and this wee problem is that browsers  own
bookmarks, database users own database table rows, so usually you shouldn't
bookmark database table rows, and much follows from that, therefore saying
server issues don't bear on this issue is IMO astonishingly & quite wrongly
blinkered.
    </pre>
      </blockquote>
      <pre>How on Earth can you bookmark database table rows? Your database knows
nothing where its rows go, the browser does not know where does HTML
originates in: it may be DB, may be XML transformed via XSLT, may be static
files on the server.

All you can bookmark is some URL. On the server there must be an
application, which maps that particular URL to this particular database
row, retrieves it, transforms it into HTML and sends to browser.
This application then is the right place to solve that "bookmarking"
problem.
It starts to look like you are trying to solve server side problems
(restricting access, of whatever denying bookmarking is supposed to solve)
via client side. Not going to work.

Regards,
Rimantas
--
<a moz-do-not-send="true" href="http://rimantas.com/" target="_blank">http://rimantas.com/</a></pre>
      </div>
      </div>
      <pre><hr size="4" width="90%"><div class="im">

No virus found in this incoming message.
Checked by AVG - <a moz-do-not-send="true" href="http://www.avg.com"
 target="_blank">www.avg.com</a></div> 
Version: 8.5.421 / Virus Database: 270.14.20/2440 - Release Date: 10/16/09 06:32:00

  </pre>
    </blockquote>
    </div>
  </blockquote>
  </div>
  <br>
  <pre wrap="">
<hr size="4" width="90%">

No virus found in this incoming message.
Checked by AVG - <a class="moz-txt-link-abbreviated" href="http://www.avg.com">www.avg.com</a> 
Version: 8.5.421 / Virus Database: 270.14.20/2440 - Release Date: 10/16/09 06:32:00

  </pre>
</blockquote>
</body>
</html>