mressler at gmail.com
Fri Oct 16 09:51:57 PDT 2009
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?
On Fri, Oct 16, 2009 at 12:19 PM, Peter Brawley <pb at artfulsoftware.com>wrote:
> >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.
> 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
> 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"
> 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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg