[whatwg] framesets

[Peter Brawley]

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 <pb at artfulsoftware.com 
> <mailto:pb at 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
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091016/e8e82d63/attachment-0002.htm>