Quote:
Originally Posted by chaley
Wonderful example of why I am not sure I want to go here. 
Moving from one to two links is 20 times the work (1-N table associations and the like). Ensuring that clickable links work everywhere (book details, library display, content server) is more work. I mean no criticism here. You are absolutely correct to point out the logical consequences starting down a path. Of course, a user will want to manage the application used to open a particular link type, and of course any data should be in known places (although along with kiwidude I am not convinced that the library is that place). These issues should be thought of in advance, and comments like yours help.
@kiwidude: integrating an authors database into the GUI beyond single line management and/or ensuring that the lifetime of an author is independent of all book references is far beyond where I am willing to go.
@kovid: the difficulty here is that the authors table must be extended to have another column for the link (assuming a 1-1 link/author relationship). This creates problems of management, of consistent availability (can it be clicked in book details but not content server and the library view?), and of meaning (is extension sufficient for open/with?). I do agree that having a default link template for authors in book-details would be reasonably straight-forward. |
Could custom columns be made to link to other tables? (i believe the current is to Books)