Mike,
>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.
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?
>Users of the application are bookmarking the URL that the
>application uses to retrieve that row and format the response as HTML.
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.
>So, as Rimantas mentioned, since the browser owns the bookmark ...
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.
PB
-----
Mike Ressler wrote:
PB,
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.
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.
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?
Mike
On Fri, Oct 16, 2009 at 12:19 PM, Peter Brawley <p...@artfulsoftware.com
<mailto:p...@artfulsoftware.com>> wrote:
Rimantas,
>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.
?! In a data-driven treeview, one node represents one table row.
PB
-----
Rimantas Liubertas wrote:
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.
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
--
http://rimantas.com/
------------------------------------------------------------------------
No virus found in this incoming message. Checked by AVG -
www.avg.com <http://www.avg.com>
Version: 8.5.421 / Virus Database: 270.14.20/2440 - Release Date: 10/16/09 06:32:00
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.421 / Virus Database: 270.14.20/2440 - Release Date: 10/16/09 06:32:00
