inline files. last desparate attempt.
Hello Last week and this week I am finalizing some work for remixreading (now remixcommons). One of the aims of us, was to move closer to vanilla Drupal. Using pure vanilla is still not possible, because of the limited file supprt. I have started betterupload, which I am developing primarily for remixcommons. But for now its still too betha to use in a production environment. However, since getting that drnd inline patch updated is far too much work after all the fapi changes, I decided to leave core what is and add some nice features to inline.module. * autoinline. One can now choose per node type, if attacements should go inline automatically: ** in the teaser ** in the body ** in both, ** not at all. * how small an image must be to show up inline. (dont show larger then 400*500, for example) * For themes: I add an inline flag: $node->file[fid]->inline == TRUE for inline files. All of this has rather crude default settings, but can be very well themed. None of this changes the default filter tokens or their behaviour. I have a few questions though: * Why does inline module not use the filter system, nodeapi(view) it uses now performs horrible! And previews do not show us the inline files. * How could we enhance the UI for inline images? I personally prefer to add a hook_quicktags, to add a JS button in the quicktags bar for each attached file. * How can we keep all this consistent? We should really re-think the ** logic to decide when an img must be inserted with an img tag (see above about settings) ** logic when to show a link and when to show nothing. ** how the tokens and the autoinline work together. e.g. should an image not be auto-inlined when a token for that image is inserted? Should we add a token autmatically rather then changing $node->body on nodeapi(view) ? and so on, I would love some feedback. (initial patch will follow soon) Bèr
At 3:32 PM +0100 6/12/05, Bèr Kessels wrote:
I decided to leave core what is and add some nice features to inline.module.
Great! Inline is in need of some love and attention. I am helping Matteo with maintenance of the inline module, and there are a few enhancement patches in the queue already.
* autoinline. One can now choose per node type, if attacements should go inline automatically: ** in the teaser ** in the body ** in both, ** not at all.
But where in the node? The user must place the image where they want it and also have the ability to style that image. Personally, I would always disable "autoinline" so that I could have better control of the placement and content of the tag.
* how small an image must be to show up inline. (dont show larger then 400*500, for example)
A better solution for this would be to create a thumbnail. But without that, yes a way to restrict the size of displayed images could be useful. I wonder though if this isn't just trying to save the user from themself?
* For themes: I add an inline flag: $node->file[fid]->inline == TRUE for inline files.
All of this has rather crude default settings, but can be very well themed. None of this changes the default filter tokens or their behaviour.
The current inline tag syntax needs to be updated. It is inflexible and hard to extend. There is a patch in the inline issue tracker that adds a lot of additional functionality to inline. This patch will definitely be committed to inline in some form before 4.7.
I have a few questions though: * Why does inline module not use the filter system, nodeapi(view) it uses now performs horrible! And previews do not show us the inline files.
There is a patch in the inline tracker that makes it a proper filter.
* How could we enhance the UI for inline images? I personally prefer to add a hook_quicktags, to add a JS button in the quicktags bar for each attached file.
Some sort of button would be good. But the user will still need to customise the inline tag so it shows up as they require. Shouldn't the button be listed next to each image in the 'file attachments' pane? Would this interface add some way of editing the inline tag? There needs to be at a minimum a way to specify: - the class of the img tag - the alt text for the img - alignment - height or width to scale the image.
* How can we keep all this consistent? We should really re-think the ** logic to decide when an img must be inserted with an img tag (see above about settings) ** logic when to show a link and when to show nothing. ** how the tokens and the autoinline work together. e.g. should an image not be auto-inlined when a token for that image is inserted? Should we add a token autmatically rather then changing $node->body on nodeapi(view) ? and so on,
I think you have to insert the inline tag in the body in order to allow the user to specify placement of the image/link. Also remember that inline can be used to place links to non-images. ...R.
Richard Archer wrote:
* autoinline. One can now choose per node type, if attacements should go inline automatically: ** in the teaser ** in the body ** in both, ** not at all.
But where in the node? The user must place the image where they want it and also have the ability to style that image.
Personally, I would always disable "autoinline" so that I could have better control of the placement and content of the tag.
I definitely think this should be optional. Not all sites want the user to actually have control of where the image shows up. Look at newsy sites.
Op dinsdag 06 december 2005 20:46, schreef Earl Miles:
I definitely think this should be optional. Not all sites want the user to actually have control of where the image shows up. Look at newsy sites.
1 it is optional 2 if you look at sites where people have the freedom to place images. Youll see that they use that freedom to place images on the same place all the time. REally, 99% of your images will be in the same place. You dont need that power. 3 Im still thinking that using a token to place an image should turn off autoinline. But i am not to sure yet. Bèr
On 06 Dec 2005, at 15:32, Bèr Kessels wrote:
I have started betterupload, which I am developing primarily for remixcommons. But for now its still too betha to use in a production environment. However, since getting that drnd inline patch updated is far too much work after all the fapi changes, I decided to leave core what is and add some nice features to inline.module.
I just wanted to add that better image handling (and inline support) is high on my list for inclusion in Drupal 4.8. In a couple weeks, we might be "shopping" for an image handling module for core. If you or someone else would like to see his or her image/document/inline/ upload module included in core, make sure it conforms Drupal's coding standards, that it is light-weight and cruft-free. I favor small modules with few settings and clean code. If someone wants to take a lead in this, and see his or her module in Drupal 4.8, let me know. -- Dries Buytaert :: http://www.buytaert.net/
Op 8-dec-2005, om 9:10 heeft Dries Buytaert het volgende geschreven:
On 06 Dec 2005, at 15:32, Bèr Kessels wrote:
I have started betterupload, which I am developing primarily for remixcommons. But for now its still too betha to use in a production environment. However, since getting that drnd inline patch updated is far too much work after all the fapi changes, I decided to leave core what is and add some nice features to inline.module.
I just wanted to add that better image handling (and inline support) is high on my list for inclusion in Drupal 4.8. In a couple weeks, we might be "shopping" for an image handling module for core. If you or someone else would like to see his or her image/document/inline/upload module included in core, make sure it conforms Drupal's coding standards, that it is light-weight and cruft-free. I favor small modules with few settings and clean code. If someone wants to take a lead in this, and see his or her module in Drupal 4.8, let me know.
-- Dries Buytaert :: http://www.buytaert.net/
robrechtj, if your on this list it would be quite awesome if you can do something with the current imageapi. I tested your image.module (sandboxed version) and it's quite amazing! The possibilities are endless.. If you don't want todo it on your own, I'll be the first who offers you any help needed. Stefan --- Stefan Nagtegaal Drupal-Devel@iStyledThis.nl Drupal Development Mailinglist
Op donderdag 8 december 2005 10:16, schreef Stefan:
robrechtj, if your on this list it would be quite awesome if you can do something with the current imageapi. I tested your image.module (sandboxed version) and it's quite amazing! The possibilities are endless..
I am behind this one too. I really like Robrechts Image module. But..... We really need to make a few important decisions first: * An image in any node OR * An image-node-type * Placement of images is automatically (nodeapi + theme) OR * People can place images anywhere in a node (tokens / html / filter) I am personallyreally in favour of: an image in any node + automatically placed images. Tho other options, IMO are complex and should live best in contribs. Which would rule out image.module as it is now. And It would rule out inline.module/image-assist etc. It would mean that we need to add a tiny bit of code to upload.module, rahter then include a new module. -- [ Bèr Kessels | Drupal services www.webschuur.com ]
We really need to make a few important decisions first: * An image in any node OR * An image-node-type
Image (or document) in any node. -- Dries Buytaert :: http://www.buytaert.net/
On 12/8/05 6:56 AM, Ber Kessels wrote:
Op donderdag 8 december 2005 10:16, schreef Stefan:
robrechtj, if your on this list it would be quite awesome if you can do something with the current imageapi. I tested your image.module (sandboxed version) and it's quite amazing! The possibilities are endless..
I am behind this one too. I really like Robrechts Image module.
But.....
We really need to make a few important decisions first: * An image in any node OR * An image-node-type
* Placement of images is automatically (nodeapi + theme) OR * People can place images anywhere in a node (tokens / html / filter)
I am personallyreally in favour of: an image in any node + automatically placed images. Tho other options, IMO are complex and should live best in contribs.
Which would rule out image.module as it is now. And It would rule out inline.module/image-assist etc. It would mean that we need to add a tiny bit of code to upload.module, rahter then include a new module.
I've already stated to the both of you (Ber and Stefan) that I'm looking to incorporate a fair bit of Robrecht's work into 4.7's image.module ... I still maintain that there is room for both. While I think core is better served by image in any node... there are those (photographers and the like) who (I think) will always want an image node as well (until images become CCK field types sometime in 2010). So, Ber... in your "image in any node" and "automatically placed images" scenario (which I agree is probably ideal for core - and yes, could be done best by extending upload.module): do uploaded images get derivatives (thumbnails & various sizes) generated? If so, is that configured globally for upload.module, per node type, etc... Also - which derivative is automatically placed? (or do we just say... stick a thumbnail in the body, that links to the full-size image?) I'm willing to work on this: i.e. I think we move the image derivative building stuff to core's image.inc ... and patch upload (I'll update image.module - for image as nodes) to reflect this. Does that sound like a plan? -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
well, There is betterupload project that i presented @ drupalcon. Due to all the LAstMinute47 changes it is completely and utterly b0rken right now. Note that all the wishes and so stated below are dealt with in that project. On a lower level. As Drupal APIS and hooks and so. Note also that I am not building this for core. But as contrib, that /can/ replace the core filehandling completely. Bèr Op donderdag 8 december 2005 15:43, schreef James Walker:
On 12/8/05 6:56 AM, Ber Kessels wrote:
Op donderdag 8 december 2005 10:16, schreef Stefan:
robrechtj, if your on this list it would be quite awesome if you can do something with the current imageapi. I tested your image.module (sandboxed version) and it's quite amazing! The possibilities are endless..
I am behind this one too. I really like Robrechts Image module.
But.....
We really need to make a few important decisions first: * An image in any node OR * An image-node-type
* Placement of images is automatically (nodeapi + theme) OR * People can place images anywhere in a node (tokens / html / filter)
I am personallyreally in favour of: an image in any node + automatically placed images. Tho other options, IMO are complex and should live best in contribs.
Which would rule out image.module as it is now. And It would rule out inline.module/image-assist etc. It would mean that we need to add a tiny bit of code to upload.module, rahter then include a new module.
I've already stated to the both of you (Ber and Stefan) that I'm looking to incorporate a fair bit of Robrecht's work into 4.7's image.module ...
I still maintain that there is room for both. While I think core is better served by image in any node... there are those (photographers and the like) who (I think) will always want an image node as well (until images become CCK field types sometime in 2010).
So, Ber... in your "image in any node" and "automatically placed images" scenario (which I agree is probably ideal for core - and yes, could be done best by extending upload.module):
do uploaded images get derivatives (thumbnails & various sizes) generated? If so, is that configured globally for upload.module, per node type, etc...
Also - which derivative is automatically placed? (or do we just say... stick a thumbnail in the body, that links to the full-size image?)
I'm willing to work on this: i.e. I think we move the image derivative building stuff to core's image.inc ... and patch upload (I'll update image.module - for image as nodes) to reflect this.
Does that sound like a plan?
-- [ Bèr Kessels | Drupal services www.webschuur.com ]
On 08 Dec 2005, at 4:43 PM, James Walker wrote:
I still maintain that there is room for both. While I think core is better served by image in any node... there are those (photographers and the like) who (I think) will always want an image node as well (until images become CCK field types sometime in 2010).
Sweet. Just in time for the olympics in vancouver and the world cup soccer in cape town. =P -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On Thursday 08 December 2005 11:19, Adrian Rossouw wrote:
(photographers and the like) who (I think) will always want an image node as well
+1 on this. Notwithstanding the awesome power of taxonomy (and I mean that in all seriousness, not sarcastically), it is a Very Good Thing to be able to have a node type that is an image, and only that -- not something with one or more images attached to it. There is a need to be able to make galleries that are just galleries, without a lot of associated text beyond (optional) image captions. Taxonomy is one axis of metadata; node type is another axis. Give me as much freedom of movement as possible in as many axes as possible. Scott One of those "photographers and the like" :-) P.S. I reserve the right to change my mind on this when I see what CCK can do. -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
I think a separage image type makes tons of sense. And I would hope that the image node type would include all kinds of fields for tasty metadata (exif, etc) as well. :)
Op vrijdag 9 december 2005 02:00, schreef Rowan Kerr:
I think a separage image type makes tons of sense. And I would hope that the image node type would include all kinds of fields for tasty metadata (exif, etc) as well. :)
I think it is important to know the audience and use. * Images as node == for galleries. 99% for photo's. * Images in any node == blogs, news, articles, manuals. Not nessecarily photo's, most just for "spice". Blogs, news, forum posts don't need power of placement of inline images (aka handled trough the theme) while manuals and articles will need this. We should consider to include both in core, with a clear line between them, and re-use of code. (again: that is what betterupload does) Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Ber Kessels wrote:
I think it is important to know the audience and use. * Images as node == for galleries. 99% for photo's. * Images in any node == blogs, news, articles, manuals. Not nessecarily photo's, most just for "spice". Blogs, news, forum posts don't need power of placement of inline images (aka handled trough the theme) while manuals and articles will need this.
We should consider to include both in core, with a clear line between them, and re-use of code.
Hi, I'm new here, but here's my take on this discussion: Frankly I feel all images should be a node. Even if an image is included in a content node just for spice or illustration, very likely these images could be thumbnails that link to a larger version. Same story if I include a true photo in a content node, it will most likely also be a thumbnail linking to the full image node. So I see no reason to build two frameworks for handling images when one will do. Why the arbitrary separation? They should all be nodes, and if we need organizational separation of "photos-available-in-galleries" vs "spice-and-illustration-images", that should be handled via taxonomy, and only the desired terms made available in menus/galleries. Sebastian
On 9-Dec-05, at 12:41 AM, Sebastian wrote:
Ber Kessels wrote:
I think it is important to know the audience and use. * Images as node == for galleries. 99% for photo's. * Images in any node == blogs, news, articles, manuals. Not nessecarily photo's, most just for "spice". Blogs, news, forum posts don't need power of placement of inline images (aka handled trough the theme) while manuals and articles will need this.
Ber, you are making broad sweeping statements which are frankly wrong. YOU may not "need power of placement"....but many, many others will.
We should consider to include both in core, with a clear line between them, and re-use of code.
Frankly I feel all images should be a node. Even if an image is included in a content node just for spice or illustration, very likely these images could be thumbnails that link to a larger version. Same story if I include a true photo in a content node, it will most likely also be a thumbnail linking to the full image node.
+1...although I didn't completely agree with "just use taxonomy" so I snipped that part. We need good image management, a way of designating "site images" (i.e. having a node-like page/URL for something like logos which don't display in galleries). File attachments are the wrong way to go about this, as having an image attached to a particular node immediately has issues with re-use of that image. Goals first, implementation second. We have a good set of image handling code, what we need now is good image management and placement. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com
Il giorno ven, 09/12/2005 alle 01.41 -0800, Boris Mann ha scritto:
On 9-Dec-05, at 12:41 AM, Sebastian wrote: +1...although I didn't completely agree with "just use taxonomy" so I snipped that part. We need good image management, a way of designating "site images" (i.e. having a node-like page/URL for something like logos which don't display in galleries).
Can't this be done with taxonomy and more flexible permissions (like taxonomy access control, I guess)? It would be nice to be able to create mini-galleries attached to nodes, like on wired.com, maybe embedded in a sort of a block and ajax powered. This could be useful also for documents like manuals (ie: list of figures). Placement inside the document could then be done with custom tags and TinyMCE (or FCK) special buttons. -- Egon Bianchet <egon.bianchet@gmail.com>
On Fri, December 9, 2005 10:41, Boris Mann wrote:
I think it is important to know the audience and use. * Images as node == for galleries. 99% for photo's. * Images in any node == blogs, news, articles, manuals. Not nessecarily photo's, most just for "spice". Blogs, news, forum posts don't need power of placement of inline images (aka handled trough the theme) while manuals and articles will need this.
Ber, you are making broad sweeping statements which are frankly wrong. YOU may not "need power of placement"....but many, many others will.
Everytime this discussion came up I have asked people to prove my wrong. so far, no one has pointed me to a single professional site where images and / or media is placed all freely in pages. Nor to a book or document that explains how images and medai must be placed or why it should be placed freely. I have, however read numerous articles and books on why free placement is a bad thing. and why consistency and simplicity (aka not overwhelmin people with interface things to place media) is a good thing I agree, and know from experience that people always have one or two pages on a website where they (want to freak out) with layout. I have clients who swear they really need wysiwywfu things. Thos are the pages that I dont even dare to mention in my portfolio, for indeed they do FU the site completely. And I agree with the fact that al people *think* they need to place images freely. But the funny thing is, that (and that indeed is sweeping broadly) that people use the freedom to place images, to..... place images in the same location. Except for those cases where thye FU everything :) So, yes, we definately need to keep the option to let people place media anywhere. And yes, that needs to hook into WYSIWYWFU interfaces. But, no, this is not as badly needed as Simple Inline Media Handling. We need both, we need the flexibility, but IMHO an automatic-no-clutter solution should be the default. In core. Ber
Ber Kessels wrote:
On Fri, December 9, 2005 10:41, Boris Mann wrote:
I think it is important to know the audience and use. * Images as node == for galleries. 99% for photo's. * Images in any node == blogs, news, articles, manuals. Not nessecarily photo's, most just for "spice". Blogs, news, forum posts don't need power of placement of inline images (aka handled trough the theme) while manuals and articles will need this.
Ber, you are making broad sweeping statements which are frankly wrong. YOU may not "need power of placement"....but many, many others will.
Everytime this discussion came up I have asked people to prove my wrong. so far, no one has pointed me to a single professional site where images and / or media is placed all freely in pages. Nor to a book or document that explains how images and medai must be placed or why it should be placed freely. I have, however read numerous articles and books on why free placement is a bad thing. and why consistency and simplicity (aka not overwhelmin people with interface things to place media) is a good thing
I agree, and know from experience that people always have one or two pages on a website where they (want to freak out) with layout. I have clients who swear they really need wysiwywfu things. Thos are the pages that I dont even dare to mention in my portfolio, for indeed they do FU the site completely.
And I agree with the fact that al people *think* they need to place images freely. But the funny thing is, that (and that indeed is sweeping broadly) that people use the freedom to place images, to..... place images in the same location. Except for those cases where thye FU everything :)
So, yes, we definately need to keep the option to let people place media anywhere. And yes, that needs to hook into WYSIWYWFU interfaces. But, no, this is not as badly needed as Simple Inline Media Handling.
" We need both, we need the flexibility, but IMHO an automatic-no-clutter solution should be the default. In core. " Predefined page layouts like in OO Impress ? Ted
Predefined page layouts like in OO Impress ? No, Like in image.module. function theme_image_body($node) { $node->body = '<img ... class="inline preview">' . $node->body return $node; } As in: no interface at all. Just append the image to the body string, on viewm, in a theme function. Its up to the themer to place the image in a nice location, not up to the user to (have to) decide to place the image in the upper right corner for every node. (ooh, imagine the fun when you decide that witha new layout you want them in the bottom left corner, imagine moving ALL the tokens in your body. I get RSI if i only think about this.
Ber --
On Saturday 10 December 2005 05:08, Ber Kessels wrote:
I agree, and know from experience that people always have one or two pages on a website where they (want to freak out) with layout.
And the proposal on the table doesn't preclude this -- it only implies that such pages would require the user to manually code the IMG tags into the node body's HTML, rather than relying on Drupal to place the images for them. Ultimately, as long as Drupal allows HTML (or even PHP!) in node bodies, with appropriate user privileges, the "limitations" of Drupal's inline image support only affect what is *simple* to do for a novice, not what is *possible* to do for an HTML wiz. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
Sebastian wrote:
Frankly I feel all images should be a node. Even if an image is included in a content node just for spice or illustration, very likely these images could be thumbnails that link to a larger version. Same story if I include a true photo in a content node, it will most likely also be a thumbnail linking to the full image node.
So I see no reason to build two frameworks for handling images when one will do. Why the arbitrary separation? They should all be nodes, and if we need organizational separation of "photos-available-in-galleries" vs "spice-and-illustration-images", that should be handled via taxonomy, and only the desired terms made available in menus/galleries.
I agree with Sebastian and would take it one step further; that all uploaded files become nodes, and that they have some super-type common functionality. Our image node would then extend the file type, and so would MS Word types, and PDF types, and MP3 types and so forth. The first step to resolving the problem we have with images is to find a good way to show a relationship between two arbitrary nodes. Uploading any file using our current upload form should create a dedicated node for that file and establish the relationship between them. Let's say that the relationship is called "attached file". The next step is to be able to search through all existing nodes that can possibly fill the roll of "attached file" while creating a new node. A current limitation of our system is that I'd have to upload the same PDF 3 times if I want to have it appear on 3 different nodes. This, we can all recognize, is crap. I should be able to reuse the already uploaded PDF. This raises two issues: a search interface for media assets is hard to build. Image assist is the best working example we have, and with all due respect to its greatness, it is still clunky (haven't tried the newest version though). Second, our node creation process will soon mandate a wizard API. If I have a node that can have an "attached file" relationship, is a location and is an event, there is no way to fit all that on one form page. SO! To fix image, we've got more fundamental work to do!!! We need a relationship API (will Vlado's work suffice? Is it suited for this purpose?), and we need a wizzard API (Adrian, report please). -Robert
On 09 Dec 2005, at 1:31 PM, Robert Douglass wrote:
Second, our node creation process will soon mandate a wizard API. If I have a node that can have an "attached file" relationship, is a location and is an event, there is no way to fit all that on one form page.
Vlado has already started touching on this with his relationship api. He has completely bypassed the node forms as they stand currently. Node forms are too restrictive at the moment, although the latest move that gets rid of nodeapi:form, and forces you to use form_alter might make node generating wizards simpler.
SO! To fix image, we've got more fundamental work to do!!! We need a relationship API (will Vlado's work suffice? Is it suited for this purpose?), and we need a wizzard API (Adrian, report please). My wizard API is slated for 4.8. The forms api was actually just laying the groundwork for the wizard api (or should I say workflow api.)
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 12/9/05 7:06 AM, Robert Douglass wrote:
Adrian Rossouw wrote:
My wizard API is slated for 4.8. The forms api was actually just laying the groundwork for the wizard api (or should I say workflow api.)
do we have an ETD on 4.8? ;-)
2008? -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
SO! To fix image, we've got more fundamental work to do!!! We need a relationship API (will Vlado's work suffice? Is it suited for this purpose?), and we need a wizzard API (Adrian, report please).
Perhaps, but lets not introduce dependencies if possible. If you say that fixing image depends on those, I fear we won't get there until 2010. The wizard API is already delayed by years, and relationship API might go the same way. -moshe, the pessimist/realist
SO! To fix image, we've got more fundamental work to do!!! We need a relationship API (will Vlado's work suffice? Is it suited for this purpose?), and we need a wizzard API (Adrian, report please). That might do the job, but if there is a simple way of doing things why not use it. I'm sceptical about the usage powrtools to hammer down a nail.
Perhaps, but lets not introduce dependencies if possible. If you say that fixing image depends on those, I fear we won't get there until 2010. The wizard API is already delayed by years, and relationship API might go the same way.
-moshe, the pessimist/realist relaist more likely
That might do the job, but if there is a simple way of doing things why not use it. I'm sceptical about the usage powrtools to hammer down a nail.
Perhaps, but lets not introduce dependencies if possible. If you say that fixing image depends on those, I fear we won't get there until 2010. The wizard API is already delayed by years, and relationship API might go the same way.
-moshe, the pessimist/realist relaist more likely
/me is completely aware of how far away those goals are. But nothing like airing out my wishlist ;-)
Robert Douglass wrote:
Let's say that the relationship is called "attached file".
The next step is to be able to search through all existing nodes that can possibly fill the roll of "attached file" while creating a new node. A current limitation of our system is that I'd have to upload the same PDF 3 times if I want to have it appear on 3 different nodes. This, we can all recognize, is crap. I should be able to reuse the already uploaded PDF.
This raises two issues: a search interface for media assets is hard to build. Image assist is the best working example we have, and with all due respect to its greatness, it is still clunky (haven't tried the newest version though).
Smart use of taxonomy for media assets would go a long way towards making them usable in this fashion, however. Perhaps free tagging as well. In reality, this is a problem that lots of people are trying to solve. Apple just tried to "solve" it by throwing Spotlight into its operating system. Apple could improve on that by fixing its Finder, as well (the spatial/browser issue): http://arstechnica.com/articles/paedia/finder.ars/1 Lack of such a perfect solution for finding media assets for re-use should not stop us from treating media that way, however. I agree with Robert. ..chrisxj
On Dec 9, 2005, at 5:31 AM, Robert Douglass wrote:
This raises two issues: a search interface for media assets is hard to build. Image assist is the best working example we have, and with all due respect to its greatness, it is still clunky (haven't tried the newest version though).
I'll be the first to agree on its clunky interface as I'm not a UI guy. http://asitis.org/images/img_assist/img_assist-action.png From writing this module I've learned that: - It's a pain to add inline files to posts and still provide users with the flexibility most are looking for. I ended up implementing a callback system since files could be added through 1) an input format aware textarea 2) a plain textarea (mission, footer, signature) or 3) a WYSIWYG editor. - Users like to have their own workspace. They want a way to browse their media and insert/link files into their posts while they're creating the post. Img_assist does this through wrapping the node/add/ image form in the separate media browser window. After the image is uploaded it's visible in the browsing panel for them to select. - Users want to be able to resize images. For images, img_assist lets you choose the derivative to insert. Oh, and img_assist is currently out of order and awaiting a forms api update. One more thing, I have no official training in human computer interaction so this email might be an evil egotistical ploy by its author to claim brilliance in a field he should pay more attention to. Matt
On 10 Dec 2005, at 7:32 PM, Matt Westgate wrote:
On Dec 9, 2005, at 5:31 AM, Robert Douglass wrote:
This raises two issues: a search interface for media assets is hard to build. Image assist is the best working example we have, and with all due respect to its greatness, it is still clunky (haven't tried the newest version though).
I'll be the first to agree on its clunky interface as I'm not a UI guy.
This is related, so I am adding it here : http://drupal.org/node/40670 That patch allows us to write code that composes a single form out of multiple node forms. Me and vlado met today to discuss the relationship stuff, and that's one of the things that's needed to allow us even more flexibility when remixing forms. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On Dec 9, 2005, at 5:31 AM, Robert Douglass wrote:
This raises two issues: a search interface for media assets is hard to build. Image assist is the best working example we have, and with all due respect to its greatness, it is still clunky (haven't tried the newest version though).
I'll be the first to agree on its clunky interface as I'm not a UI guy. http://asitis.org/images/img_assist/img_assist-action.png From writing this module I've learned that: - It's a pain to add inline files to posts and still provide users with the flexibility most are looking for. I ended up implementing a callback system since files could be added through 1) an input format aware textarea 2) a plain textarea (mission, footer, signature) or 3) a WYSIWYG editor. - Users like to have their own workspace. They want a way to browse their media and insert/link files into their posts while they're creating the post. Img_assist does this through wrapping the node/add/ image form in the separate media browser window. After the image is uploaded it's visible in the browsing panel for them to select. - Users want to be able to resize images. For images, img_assist lets you choose the derivative to insert. Oh, and img_assist is currently out of order and awaiting a forms api update. One more thing, I have no official training in human computer interaction so this email might be an evil egotistical ploy by its author to claim brilliance in a field he should pay more attention to. Matt
Op zaterdag 10 december 2005 22:01, schreef Matt Westgate:
- Users like to have their own workspace. They want a way to browse their media and insert/link files into their posts while they're creating the post. Img_assist does this through wrapping the node/add/ image form in the separate media browser window. After the image is uploaded it's visible in the browsing panel for them to select.
For betteruplod my inteded solution to this is: Not put upload or file management forms in a node/add form; this is clutter. But to add a button to "browse away and do stuff" (like upload a new image, select a file from a DB or search for a taxo term). That button would then save the current form entries in the session, and refill the form once a person gets back ot the node/add (or node/edit; off course) We could even thing of adding a JS layer on top, afterwards, that saves stuf to the session every x mins (for crashing or accidentaly browsing a way). But IMO that needs to be *on top* of a perfectly worjking HTML solution, never the other way around :) I have a feeling that FAPI has made this easier, but havent really investigated its technical details. Yet. -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
Sebastian wrote:
Frankly I feel all images should be a node. Even if an image is included in a content node just for spice or illustration, very likely these images could be thumbnails that link to a larger version. Same story if I include a true photo in a content node, it will most likely also be a thumbnail linking to the full image node.
So I see no reason to build two frameworks for handling images when one will do. Why the arbitrary separation? They should all be nodes, and if we need organizational separation of "photos-available-in-galleries" vs "spice-and-illustration-images", that should be handled via taxonomy, and only the desired terms made available in menus/galleries.
As an admin, I'm afraid I disagree. For people who write articles on my site, I find simplicity to be the absolutely most important issue. They want to be able to attach an image to a node and be done with it. If they have to set up an image node and then figure out how to link that image node to their article, they're going to have a lot fewer articles with images.
On 12/9/05 11:30 AM, Earl Miles wrote:
Sebastian wrote:
Frankly I feel all images should be a node. Even if an image is included in a content node just for spice or illustration, very likely these images could be thumbnails that link to a larger version. Same story if I include a true photo in a content node, it will most likely also be a thumbnail linking to the full image node.
So I see no reason to build two frameworks for handling images when one will do. Why the arbitrary separation? They should all be nodes, and if we need organizational separation of "photos-available-in-galleries" vs "spice-and-illustration-images", that should be handled via taxonomy, and only the desired terms made available in menus/galleries.
As an admin, I'm afraid I disagree. For people who write articles on my site, I find simplicity to be the absolutely most important issue. They want to be able to attach an image to a node and be done with it. If they have to set up an image node and then figure out how to link that image node to their article, they're going to have a lot fewer articles with images.
well "set up an image node" doesn't / shouldn't need to involve going to node/add/image and creating the image then going back to node/add/story, etc. I.e. img_assist (and htmlarea) both allow you to create image nodes when you attach. I've heard both that img_assist is sliced bread and that it's still too confusing, not right, something... We've got a lot of differing opinions and certainly more than a few target audiences... so (imo) flexibility is gonna have to remain king. I think the big thing for Ber's idea of just upload an image and have it automagically placed... it would require some way to maintain the relation that image X is in node Y, which clearly points to all the relationship discussions.... because how long does it take before we want to name those relations. (i.e. this image i'm uploading to my album review node is the cover of the album, and this one is a shot of the band). In the meantime, I'm still committed to doing whatever necessary to see the "state of images" improve in Drupal... but I don't see a real clear winner yet here. Anyone else? -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
On 9-Dec-05, at 8:30 AM, Earl Miles wrote:
Sebastian wrote:
Frankly I feel all images should be a node. Even if an image is included in a content node just for spice or illustration, very likely these images could be thumbnails that link to a larger version. Same story if I include a true photo in a content node, it will most likely also be a thumbnail linking to the full image node. So I see no reason to build two frameworks for handling images when one will do. Why the arbitrary separation? They should all be nodes, and if we need organizational separation of "photos- available-in-galleries" vs "spice-and-illustration-images", that should be handled via taxonomy, and only the desired terms made available in menus/galleries.
As an admin, I'm afraid I disagree. For people who write articles on my site, I find simplicity to be the absolutely most important issue. They want to be able to attach an image to a node and be done with it. If they have to set up an image node and then figure out how to link that image node to their article, they're going to have a lot fewer articles with images.
You're right, simplicity is needed...but you're presupposing a UI/ implementation. If they click on an image insert button, and an image manager pops up that displays existing images that they have access to, as well as a simplified "upload an image" process directly from that manager screen...voila!. Whether an image node is created or not is actually secondary, except in terms of re-use and management. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com
On 12/9/05 11:50 AM, Boris Mann wrote:
On 9-Dec-05, at 8:30 AM, Earl Miles wrote:
Sebastian wrote:
Frankly I feel all images should be a node. Even if an image is included in a content node just for spice or illustration, very likely these images could be thumbnails that link to a larger version. Same story if I include a true photo in a content node, it will most likely also be a thumbnail linking to the full image node. So I see no reason to build two frameworks for handling images when one will do. Why the arbitrary separation? They should all be nodes, and if we need organizational separation of "photos-available-in-galleries" vs "spice-and-illustration-images", that should be handled via taxonomy, and only the desired terms made available in menus/galleries.
As an admin, I'm afraid I disagree. For people who write articles on my site, I find simplicity to be the absolutely most important issue. They want to be able to attach an image to a node and be done with it. If they have to set up an image node and then figure out how to link that image node to their article, they're going to have a lot fewer articles with images.
You're right, simplicity is needed...but you're presupposing a UI/implementation. If they click on an image insert button, and an image manager pops up that displays existing images that they have access to, as well as a simplified "upload an image" process directly from that manager screen...voila!. Whether an image node is created or not is actually secondary, except in terms of re-use and management.
This was exactly the point I was trying to get at.. In fact, there has been a feature request for image.module to set the node title to be the image filename (for bulk uploading... or "quick" uploading), so it would really be the file upload box only. but then... there's upload.module.... -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
but then... there's upload.module....
Here's my highly opinionated contribution to the discussion. 1) All downloadable files should be nodes. 2) Whether upload.module, file.module, or hooha.module does this is a side issue as long as ONE centralized module does it. 3) Attaching a file to another node should involve: a) selecting an exsting file node, or b) uploading a file during node edit/create, which would be saved as a dedicated file node. 4) Inlining an image or a link to a file should be done using tokens. I might be wrong. As I wrote it out, I thought of better ways to do it. But it's one way that it could work that would be consistent and would make sense. --Jeff
On 9-Dec-05, at 9:06 AM, Jeff Eaton wrote:
but then... there's upload.module....
Here's my highly opinionated contribution to the discussion.
1) All downloadable files should be nodes. 2) Whether upload.module, file.module, or hooha.module does this is a side issue as long as ONE centralized module does it. 3) Attaching a file to another node should involve: a) selecting an exsting file node, or b) uploading a file during node edit/create, which would be saved as a dedicated file node.
+1 to everything above. Actually, for #2, it doesn't HAVE to be one module...it just needs to get managed in one place and work well in predictable ways. Which File API kind of does, but is also kind of messy, and definitely doesn't meet the second criteria.
4) Inlining an image or a link to a file should be done using tokens.
Doesn't work with WYSIWYG. I understand the need for tokens, but maybe we can overload something in the HTML? Like, <a href="xx" class="image-xx">? Implementation detail, just wanted to bring up the rich text editor angle...the img_assist toggle works. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 SKYPE borismann http://www.bryght.com
4) Inlining an image or a link to a file should be done using tokens.
Doesn't work with WYSIWYG. I understand the need for tokens, but maybe we can overload something in the HTML? Like, <a href="xx" class="image-xx">? Implementation detail, just wanted to bring up the rich text editor angle...the img_assist toggle works.
Yeah, good point. I stick by the first 3, though. :-) The only potential problem I can see is that if 'file' is a node type, the various permutations of an image (thumbnail, etc) would become individual nodes. I don't know if I like that at all, which puts us back in the same mess. Hmmmm. --Jeff
On 12/9/05 12:17 PM, Jeff Eaton wrote:
4) Inlining an image or a link to a file should be done using tokens.
Doesn't work with WYSIWYG. I understand the need for tokens, but maybe we can overload something in the HTML? Like, <a href="xx" class="image-xx">? Implementation detail, just wanted to bring up the rich text editor angle...the img_assist toggle works.
Yeah, good point.
I stick by the first 3, though. :-)
The only potential problem I can see is that if 'file' is a node type, the various permutations of an image (thumbnail, etc) would become individual nodes. I don't know if I like that at all, which puts us back in the same mess.
Ah. see in my vision a "file" has "derivatives" ... image this is thumbnail, alternate sizes, etc. audio - alternate encodings, bitrates, etc. (same for video)... and on. Thus the node is the collection... and I'd still recommend we keep {files} for tracking the various file parts. but the node would still be the collection of them. (if that makes sense). I.e. the "node" is the main thing with the title that gets uploaded... anything generated from that is kept and included, but not it's own node. -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
-----Original Message----- Ah. see in my vision a "file" has "derivatives" ... image this is thumbnail, alternate sizes, etc. audio - alternate encodings, bitrates, etc. (same for video)... and on.
Thus the node is the collection... and I'd still recommend we keep {files} for tracking the various file parts. but the node would still be the collection of them. (if that makes sense).
I.e. the "node" is the main thing with the title that gets uploaded...
anything generated from that is kept and included, but not it's own node. --
I like that a lot. A whole lot. The different kinds of derivatives would probably differ greatly depending on the type of file. Different resolutions for images, different bitrates or cropped 'teasers' for audio, different compression formats for various downloads. And yes, it does make great sense. I like this option an awful lot. How would different KINDS of files be handled/displayed differently, though? Image.module does a lot of really nice funky stuff to deal with various resolutions. If it became a 'file' node or what not, would there be a set of hooks exposed for other modules to customize the handling of various mime types, etc? One option I've been curious about is a clean way to programmatically access (and restrict access to) file variations. Registered users get high-quality MP3s and high-res images, for example. --Jeff
A brief thought: You could keep "nodes" and "files" separate... Where nodes are any kind of actual content that is typed into the site And files are anything that is uploaded by the user Then you'd have node types and file types.. that could decide just how to display different things. nodes would be stuff like: blog, page, article, book page, etc... files would be stuff like: document, image, spreadsheet, movie, audio... Because files that are uploaded, I would not really expect should be given a normal title, body, published/unpublished, etc... that nodes (actual _content_) would have. Really, node's don't have a filename, file size, mime type, filesystem path, etc... Then you get into more of a document management system where things are clearly defined instead of combining content and external files under one container. -Rowan
On 12/9/05 12:43 PM, Rowan Kerr wrote:
A brief thought: You could keep "nodes" and "files" separate...
Where nodes are any kind of actual content that is typed into the site And files are anything that is uploaded by the user
Then you'd have node types and file types.. that could decide just how to display different things.
nodes would be stuff like: blog, page, article, book page, etc... files would be stuff like: document, image, spreadsheet, movie, audio...
Because files that are uploaded, I would not really expect should be given a normal title, body, published/unpublished, etc... that nodes (actual _content_) would have. Really, node's don't have a filename, file size, mime type, filesystem path, etc...
Then you get into more of a document management system where things are clearly defined instead of combining content and external files under one container.
except that... what happens when I want to apply taxonomy, etc to my files? (you better believe people wanna tag their images. ask flickr). I think what we've identified is that "files" are a special type of node... but i think a node nonetheless. (I'd argue that files absolutely are publish/unpublishable - in a real document management system - title / description generally apply as well). I'd rather not see files become yet another first order object in drupal (not to start any "everything's a node" wars)... -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
On 12/9/05, Rowan Kerr <rowan0@gmail.com> wrote:
A brief thought: You could keep "nodes" and "files" separate...
I think this is the way to go, three base types: user, node, file
Where nodes are any kind of actual content that is typed into the site And files are anything that is uploaded by the user
Then you'd have node types and file types.. that could decide just how to display different things.
Then things like image and audio wouldn't have to re-implement all the upload/preview, infact they'd just be hooks to load meta data from the file.
On Fri, 09 Dec 2005 19:10:00 +0100, andrew morton <drewish@katherinehouse.com> wrote:
On 12/9/05, Rowan Kerr <rowan0@gmail.com> wrote:
A brief thought: You could keep "nodes" and "files" separate...
I think this is the way to go, three base types: user, node, file
Don't forget comments. :) -- Tim Altman
On 12/9/05, Tim Altman <web@timaltman.com> wrote:
On Fri, 09 Dec 2005 19:10:00 +0100, andrew morton <drewish@katherinehouse.com> wrote:
On 12/9/05, Rowan Kerr <rowan0@gmail.com> wrote:
A brief thought: You could keep "nodes" and "files" separate...
I think this is the way to go, three base types: user, node, file
Don't forget comments. :)
well, you can disable the comment module...
On Sat, 10 Dec 2005 01:51:03 +0100, andrew morton <drewish@katherinehouse.com> wrote:
On 12/9/05, Tim Altman <web@timaltman.com> wrote:
On Fri, 09 Dec 2005 19:10:00 +0100, andrew morton <drewish@katherinehouse.com> wrote:
On 12/9/05, Rowan Kerr <rowan0@gmail.com> wrote:
A brief thought: You could keep "nodes" and "files" separate...
I think this is the way to go, three base types: user, node, file
Don't forget comments. :)
well, you can disable the comment module...
And the node module... -- Tim Altman
On Fri, Dec 09, 2005 at 10:10:00AM -0800, andrew morton wrote:
On 12/9/05, Rowan Kerr <rowan0@gmail.com> wrote: Then things like image and audio wouldn't have to re-implement all the upload/preview, infact they'd just be hooks to load meta data from the file.
|This is the summary of what my betterupload was aiming for. Ber
This is a point of endless discussion in Drupal. In myworld a node is a "thing" where all sorts of data meet. The node is nothing more then an entity to bind that data and make it a "thing". Unfortunately, in Drupal nodes are only used for content. For posts, to be more precisely. So over time drupaleers tend to think about a node as a post. Rather then the much more powerfull abstract "thing"it actually is. So, in this a file would be nothing more then a "thing" of type "document", "image" etc. Ber On Fri, Dec 09, 2005 at 12:43:34PM -0500, Rowan Kerr wrote:
A brief thought: You could keep "nodes" and "files" separate...
Where nodes are any kind of actual content that is typed into the site And files are anything that is uploaded by the user
Then you'd have node types and file types.. that could decide just how to display different things.
nodes would be stuff like: blog, page, article, book page, etc... files would be stuff like: document, image, spreadsheet, movie, audio...
Because files that are uploaded, I would not really expect should be given a normal title, body, published/unpublished, etc... that nodes (actual _content_) would have. Really, node's don't have a filename, file size, mime type, filesystem path, etc...
Then you get into more of a document management system where things are clearly defined instead of combining content and external files under one container.
-Rowan
And now a word from one of the little people... :-) I have to largely agree with Ber here. A node is a "piece of stuff to which we can do things". We can organize them (taxonomy), we can restrict access to them (hook_per(), node_access_by_role, lots of others), what we can't easily do yet is link to them. But we should leverage that existing organizational power as much as possible. Really, what is a photo gallery but a bunch of "image stuff"s categorized (taxonomy) in some user-defined way? What is a music collection but a bunch of "audio stuff"s with extra metadata (taxonomy or tagging or whatever)? As I mentioned above, what's really missing is a way for nodes to relate to each other. Drupal is great at collecting nodes, not so great at tying them together nicely. <insert relationship module(s) here> (What follows is me thinking aloud. If it ends up being dumb, that's what I'll blame. <g>) I think some of this needs to be pushed down into the node module itself. For instance, hook_view() currently has only two "modes": teaser and not. If a node could define additional view modes, then an image node could specify "fullsize", "thumbnail", "resize1", "handheld-optimized", or whatnot. Then it could be accessed with: node/123/fullsize node/123/thumbnail etc. It would simply return the proper image, as mimetype image/whatever. A textual node could link to it as <img src="node/123/thumbnail" />, and all is well. That also allows all the existing permission restrictions to be applied. That textual node, then, could have viewtypes of normal (default), teaser, print, etc. Problem: I'm not sure how that would work with custom paths (url_alias). Hm, maybe that's not such a great idea. <goes back to watching the busy people debate> On Saturday 10 December 2005 02:53 am, Bèr Kessels wrote:
This is a point of endless discussion in Drupal.
In myworld a node is a "thing" where all sorts of data meet. The node is nothing more then an entity to bind that data and make it a "thing".
Unfortunately, in Drupal nodes are only used for content. For posts, to be more precisely. So over time drupaleers tend to think about a node as a post. Rather then the much more powerfull abstract "thing"it actually is.
So, in this a file would be nothing more then a "thing" of type "document", "image" etc.
Ber
On Fri, Dec 09, 2005 at 12:43:34PM -0500, Rowan Kerr wrote:
A brief thought: You could keep "nodes" and "files" separate...
Where nodes are any kind of actual content that is typed into the site And files are anything that is uploaded by the user
Then you'd have node types and file types.. that could decide just how to display different things.
nodes would be stuff like: blog, page, article, book page, etc... files would be stuff like: document, image, spreadsheet, movie, audio...
Because files that are uploaded, I would not really expect should be given a normal title, body, published/unpublished, etc... that nodes (actual _content_) would have. Really, node's don't have a filename, file size, mime type, filesystem path, etc...
Then you get into more of a document management system where things are clearly defined instead of combining content and external files under one container.
-Rowan
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On 10 Dec 2005, at 8:19 PM, Larry Garfield wrote:
I think some of this needs to be pushed down into the node module itself. For instance, hook_view() currently has only two "modes": teaser and not. If a node could define additional view modes, then an image node could specify "fullsize", "thumbnail", "resize1", "handheld-optimized", or whatnot. Then it could be accessed with:
node/123/fullsize node/123/thumbnail
node/123/edit the form is just a view of the object. You can create lists using any of the views. Hence the view api =) -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On Saturday 10 December 2005 12:32 pm, Adrian Rossouw wrote:
On 10 Dec 2005, at 8:19 PM, Larry Garfield wrote:
I think some of this needs to be pushed down into the node module itself. For instance, hook_view() currently has only two "modes": teaser and not. If a node could define additional view modes, then an image node could specify "fullsize", "thumbnail", "resize1", "handheld-optimized", or whatnot. Then it could be accessed with:
node/123/fullsize node/123/thumbnail
node/123/edit
the form is just a view of the object.
You can create lists using any of the views.
Hence the view api =)
Ah, good to know I'm not completely off base. :-) How are you handling custom urls? It seems that could make things problematic. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Problem: I'm not sure how that would work with custom paths (url_alias). Hm, maybe that's not such a great idea.
This problem is easily solvable http://drupal.org/node/40696 -- almost complete. I hope Richard will lend me a hand and finish the patch. Regards NK
On 12/9/05 12:29 PM, Jeff Eaton wrote:
-----Original Message----- Ah. see in my vision a "file" has "derivatives" ... image this is thumbnail, alternate sizes, etc. audio - alternate encodings, bitrates, etc. (same for video)... and on.
Thus the node is the collection... and I'd still recommend we keep {files} for tracking the various file parts. but the node would still be the collection of them. (if that makes sense).
I.e. the "node" is the main thing with the title that gets uploaded...
anything generated from that is kept and included, but not it's own node. --
I like that a lot. A whole lot. The different kinds of derivatives would probably differ greatly depending on the type of file. Different resolutions for images, different bitrates or cropped 'teasers' for audio, different compression formats for various downloads.
And yes, it does make great sense. I like this option an awful lot.
How would different KINDS of files be handled/displayed differently, though? Image.module does a lot of really nice funky stuff to deal with various resolutions. If it became a 'file' node or what not, would there be a set of hooks exposed for other modules to customize the handling of various mime types, etc?
well, i think this is up for debate... I think, were upload.module were to become more of an "attach" module - that did the central hooks for attaching other nodes ... I think it should remain node-type per major mimetype - since there is a fair bit of diversion between how each of the files can be / are handled.
One option I've been curious about is a clean way to programmatically access (and restrict access to) file variations. Registered users get high-quality MP3s and high-res images, for example.
This definitely should get done... it's along with the whole "private files aren't really private" issue as well. Not to mention that performance of "private" files is fairly bad (i.e. it would be nice to avoid DRUPAL_BOOTSTRAP_FULL to fetch a private image). yep, lots of fun and exciting room to grow here. -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
On 09 Dec 2005, at 7:17 PM, Jeff Eaton wrote:
stick by the first 3, though. :-)
The only potential problem I can see is that if 'file' is a node type, the various permutations of an image (thumbnail, etc) would become individual nodes. I don't know if I like that at all, which puts us back in the same mess.
Not necessarily. Remember that each node has multiple views. ie: summary view, list view etc. I'm going to be working on getting views in drupal more flexible and visible soon. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Adrian Rossouw wrote:
On 09 Dec 2005, at 7:17 PM, Jeff Eaton wrote:
stick by the first 3, though. :-)
The only potential problem I can see is that if 'file' is a node type, the various permutations of an image (thumbnail, etc) would become individual nodes. I don't know if I like that at all, which puts us back in the same mess.
Not necessarily.
Remember that each node has multiple views. ie: summary view, list view etc.
I'm going to be working on getting views in drupal more flexible and visible soon.
You mean like my Views module?
On 10 Dec 2005, at 2:24 AM, Earl Miles wrote:
Not necessarily. Remember that each node has multiple views. ie: summary view, list view etc. I'm going to be working on getting views in drupal more flexible and visible soon.
You mean like my Views module?
Kind of. Will probably end up using code from that. But this is an extension on the forms api. The form is just one of the views of the 'object'. Every 'object' has a 'view' view, but can have additional views. Instead of definining the form elements specifically, you define generic 'elements' that the object has, and they render differently based on what view you are in. Each view also has the opportunity to alter the properties of the elements if it so wishes (including adding more structure), and each view gets the form api's themeing flexibility. Essentially the model view controller pattern. with some added AOP magic sprinkled in. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 12/9/05 12:06 PM, Jeff Eaton wrote:
but then... there's upload.module....
Here's my highly opinionated contribution to the discussion.
1) All downloadable files should be nodes.
I like this... it certainly gets us away from the modules fighting over {files} too..
2) Whether upload.module, file.module, or hooha.module does this is a side issue as long as ONE centralized module does it.
+1 for hooha.module though
3) Attaching a file to another node should involve: a) selecting an exsting file node, or b) uploading a file during node edit/create, which would be saved as a dedicated file node.
indeed.
4) Inlining an image or a link to a file should be done using tokens.
ahhhhh.... well. maybe. the thing is if I've got a list of 'related' or 'attached' file nodes - i could just jam them in (via a themeable nodeapi('view') call)... which requires no funny tokens or syntax from the user. *or* we have a great filter module with several available markup languages *or* we have the WYSIWYG camp.
I might be wrong. As I wrote it out, I thought of better ways to do it. But it's one way that it could work that would be consistent and would make sense.
and will make oh, 30% of folks happy. :P -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
On 09 Dec 2005, at 18:06, Jeff Eaton wrote:
1) All downloadable files should be nodes.
I disagree with this. If the sole purpose of the file is to be downloadable, there is no value in making it a node. It adds clutter and administration overhead. -- Dries Buytaert :: http://www.buytaert.net/
On 12/9/05 12:44 PM, Dries Buytaert wrote:
On 09 Dec 2005, at 18:06, Jeff Eaton wrote:
1) All downloadable files should be nodes.
I disagree with this. If the sole purpose of the file is to be downloadable, there is no value in making it a node. It adds clutter and administration overhead.
ahhh. but to be downloadable, it needs to be locatable. and, more, it should really be trackable as well... and as has already been mentioned, we need to restrict *who* can download it, and on and on. i dunno about "clutter"... the admin/node filters are pretty handy (and could get better still, I'm sure). no idea what you mean by adminstration overhead... -- James Walker :: http://walkah.net/ :: xmpp:walkah@walkah.net
Dries Buytaert wrote:
On 09 Dec 2005, at 18:06, Jeff Eaton wrote:
1) All downloadable files should be nodes.
I disagree with this. If the sole purpose of the file is to be downloadable, there is no value in making it a node. It adds clutter and administration overhead.
Respecfully, I think that done right it actually adds simplicity. If everything is a node, then you have one model, one framework. All nodes answer to the same api, and all nodes can benefit implicitly from new functionaily introduced in the rest of the system.
Respecfully, I think that done right it actually adds simplicity. If everything is a node, then you have one model, one framework. All nodes answer to the same api, and all nodes can benefit implicitly from new functionaily introduced in the rest of the system.
In the 20 minutes it took for the discussion to take off, my thinking has changed on this. ;) My subsequent 6-part bullet list outlines a more flexible approach. Heh. You might not agree, but I think that while LOTS of files should be nodes, the underlying concept of a 'file' is different and should probably have a bit more flexibility. Links.module does this sort of abstraction for weblinks -- instead of making a dedicated node for each outgoing link, it manages links on its own and provides a 'weblink' node to expose specific links as nodes. This allows other modules (a blogroll, or a 'my favorite sites' list for each user) to use the same infrastructure without simply creating a huge cloud of nodes. It also means that if Link X needs to be changed or redirected, all nodes/etc that use it benefit from the change. That's something that files can definitely benefit from. --Jeff
A thought just occurred to me regarding the image/file is or is not a node debate: What about dividing them not by how they are used but by how they are structured. Specifically, I would prefer to see text nodes and binary nodes. The reason I suggest this is to make it possible to search text files that I upload. Also, Drupal could contain a RCS where it stores the diffs of files. ("Forget bzr, SVN, cvs: Drupal is my RCS!") In a really perfect world, modules could strip the text from complicated text files (say a PDF) and combine a binary and text node to create a searchable file node. Of course, this functionality would be implemented in a contrib module, but the underlying text vs. binary API should be in core. Thoughts? Mark Fredrickson E-Advocacy Manager Planned Parenthood Minnesota, North Dakota, South Dakota 1200 Lagoon Ave. Minneapolis, MN 55408 Ph: 612.821.6154 Fax: 612.825.3522 Email: mfredrickson@ppmns.org Are you a member of the Action Network? http://www.ppaction.org/ppmsd/join.tcl
Regarding pictures and albums, here is something that is feedback from a client project: A client wanted to create a showcase portal type of site. Users would be able to create and account, and then they will have a custom page. The custom page would list all "objects" they like to showcase that they have create, each "object" would contain a description, as well as a main picture. Each picture would be a link to an album/gallery that has more pictures for each object. In essence, this is a multi level one to many relationship: user -> object -> album -> picture. When evaluating this project, Drupal had the building blocks, but the glue was missing. The image node was there, but to get non-technical people to use img_assist or inline is too much, since creating an object was a lengthy and multi step process, without a wizard to help. Moreover, the premissions model did not allow albums to have owners, and users not inserting/deleting in other people's albums. So, an image as a node is a good thing, but we need better ways to embed/link/include images in other nodes, and also have a multi level relationship.
Jeff Eaton wrote:
Here's my highly opinionated contribution to the discussion.
1) All downloadable files should be nodes. 2) Whether upload.module, file.module, or hooha.module does this is a side issue as long as ONE centralized module does it. 3) Attaching a file to another node should involve: a) selecting an exsting file node, or b) uploading a file during node edit/create, which would be saved as a dedicated file node. 4) Inlining an image or a link to a file should be done using tokens.
Yes, yes and yes to all the above. As I think about it more: I see a centralized module that represents a generic/default "file" node, with the concept of 'named' parts. New node types can be added by extending it, implementing hooks for part-type definition, special node creation processing, normal node display, so on. An image node might declare part types called original, thumbnail, resize_1 resize_2 (etc) for instance. Also illustrating this extension mechanism: The default "file" node provides a get_reflink(node,part) that might return a simple <a> link. This is what's executed when a text node references the node in-line or as an attachment. Now the node-type extensions could override that to return some other specific html representation of the file. An <img> for a thumbnail, or a filetype icon, etc. It seems like this node-type framework could be done very cleanly and simply, following the Drupal Way, and would go a long way to satisfying essential file/image needs, while leaving room (and providing opportunity) for more complex functionality in external modules, such as bulk uploaders, galleries, etc. Sebastian
On Fri, Dec 09, 2005 at 11:06:25AM -0600, Jeff Eaton wrote:
but then... there's upload.module....
Here's my highly opinionated contribution to the discussion.
1) All downloadable files should be nodes. 2) Whether upload.module, file.module, or hooha.module does this is a side issue as long as ONE centralized module does it. 3) Attaching a file to another node should involve: a) selecting an exsting file node, or b) uploading a file during node edit/create, which would be saved as a dedicated file node. 4) Inlining an image or a link to a file should be done using tokens.
I might be wrong. As I wrote it out, I thought of better ways to do it. But it's one way that it could work that would be consistent and would make sense.
--Jeff
Wow! two words: perfect idea. :) This simplifies the upload/media system, that I had in mind a huge lot. I will rewrite my docs and code that i have till now to work this way. I know that this might be subotimal, performance wise, but using Jeffs model, upload becomes nothing more then a new use of the relations system! Im impressed by the simplicity and I am very glad this comes up now, instead of after coding a huge lot of patches :) Ber
On Sat, 10 Dec 2005 09:45:42 +0100, Bèr Kessels <ber@webschuur.com> wrote:
On Fri, Dec 09, 2005 at 11:06:25AM -0600, Jeff Eaton wrote:
but then... there's upload.module....
Here's my highly opinionated contribution to the discussion.
1) All downloadable files should be nodes. 2) Whether upload.module, file.module, or hooha.module does this is a side issue as long as ONE centralized module does it. 3) Attaching a file to another node should involve: a) selecting an exsting file node, or b) uploading a file during node edit/create, which would be saved as a dedicated file node. 4) Inlining an image or a link to a file should be done using tokens.
I might be wrong. As I wrote it out, I thought of better ways to do it. But it's one way that it could work that would be consistent and would make sense.
--Jeff
Wow! two words: perfect idea. :)
Yeah. And solves the 'private files' at the same time. Awesome idea!
James Walker wrote:
This was exactly the point I was trying to get at.. In fact, there has been a feature request for image.module to set the node title to be the image filename (for bulk uploading... or "quick" uploading), so it would really be the file upload box only.
but then... there's upload.module....
There's also upload_image.module which intercepts the uploaded images and makes them into image nodes. It needs some help with the CSS and it would be nice if the table generated by upload.module could be overwritten or themed. Cheers, Gerhard
Okay. After reading the responses, let me amend my original idea. :-) It's based in part on the way that links.module handles outgoing weblinks. 1) All downloadable file should be nameable, and support per-file access restriction 2) Files should be uploadable and manageable WITHOUT attaching them to a new or existing node 3) Whenever a file is uploaded, other modules should be able to hook into the process (to create full-fledged nodes, or build file variations, for example) 4) Attaching a file to another node should involve: a) selecting an exsting file node, or b) uploading a file during node edit/create, which would be saved as a dedicated file. 5) A simple 'File' node-type would allow 1-n files to be uploaded together and displayed in normal drupal fashion. 6) Other modules (like image, audio, video, etc) would handle more complex scenarios where variations must be built, or only one attached variation should be displayed at once. This is starting to look a lot like betterupload.module, isn't it? --Jeff
On Fri, 09 Dec 2005 19:08:56 +0100, Jeff Eaton <jeff@viapositiva.net> wrote:
Okay. After reading the responses, let me amend my original idea. :-) It's based in part on the way that links.module handles outgoing weblinks.
1) All downloadable file should be nameable, and support per-file access restriction 2) Files should be uploadable and manageable WITHOUT attaching them to a new or existing node 3) Whenever a file is uploaded, other modules should be able to hook into the process (to create full-fledged nodes, or build file variations, for example) 4) Attaching a file to another node should involve: a) selecting an exsting file node, or b) uploading a file during node edit/create, which would be saved as a dedicated file.
Please keep in mind that comments should be able to contain files, too. We need this for project.module and forum.module, at least. -- Tim Altman
-----Original Message----- From: Tim Altman [mailto:web@timaltman.com]
Please keep in mind that comments should be able to contain files, too. We need this for project.module and forum.module, at least.
Right. The same rules would apply to comments as nodes in this case. Heck, we could attach files to users if we really wanted to. :-) I think my biggest concern involves standardizing what happens to files when they're uploaded, how they can best be exposed to the rest of the drupal system, and how they can be re-used between different nodes. --Jeff
On Friday 09 December 2005 20:04, Jeff Eaton wrote:
Heck, we could attach files to users if we really wanted to.
Why not? :-) Imagine: * My CV/resume' as a PDF file. * My profile picture, handled as "just another file" rather than a special case. * My favorite MP3, or a verbal greeting, that people can play when they are looking at my user profile. * My GPG public key. Not all of these would appeal to every site (not my sites, for sure), but some of these (or other things that haven't occurred to me) might appeal to some webmasters. Generality in design is a Very Good Thing. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
* My profile picture, handled as "just another file" rather than a special case.
user picture is not a special case. user.module uses the file API exactly as it was designed. upload and image modules use file API to achieve their own goals. one way to frame this discussion is to list additional services which ought to be provided by file API. -moshe
On Friday 09 December 2005 20:45, Moshe Weitzman wrote:
user picture is not a special case. user.module uses the file API exactly as it was designed.
I apologize, Moshe, for two reasons. First, I wasn't aware that user pic used the file API, because I haven't needed to dive into the code. I had assumed (incorrectly) that it was coded into user.module. Second, I didn't mean in any way to disparage user.module even if the picture had been a special case. I was just brainstorming of ways that a generalized attachment of files to a user principal might be useful. I'm sorry if this sounded critical of the existing code; that was not my intent. And I'm sorry for the error -- the inner details weren't critical to my overall point, and I glossed over a fact that I shouldn't have. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
On Fri, Dec 09, 2005 at 12:08:56PM -0600, Jeff Eaton wrote:
Okay. After reading the responses, let me amend my original idea. :-) It's based in part on the way that links.module handles outgoing weblinks.
1) All downloadable file should be nameable, and support per-file access restriction 2) Files should be uploadable and manageable WITHOUT attaching them to a new or existing node 3) Whenever a file is uploaded, other modules should be able to hook into the process (to create full-fledged nodes, or build file variations, for example) 4) Attaching a file to another node should involve: a) selecting an exsting file node, or b) uploading a file during node edit/create, which would be saved as a dedicated file. 5) A simple 'File' node-type would allow 1-n files to be uploaded together and displayed in normal drupal fashion. 6) Other modules (like image, audio, video, etc) would handle more complex scenarios where variations must be built, or only one attached variation should be displayed at once.
This is starting to look a lot like betterupload.module, isn't it?
Except for the part where I also introduce/ designeda abstraction on the other end: storage. * Some KIO alike abstraction so files can be stored anywhere, using * .inc file. Its all documented at http://www.webschuur.com/node/247 and http://www.webschuur.com/node/246 Ber
Op 9-dec-2005, om 1:53 heeft Syscrusher het volgende geschreven:
On Thursday 08 December 2005 11:19, Adrian Rossouw wrote:
(photographers and the like) who (I think) will always want an image node as well
At least I want a new node-type 'image', nothing more, nothing less. Though, the imageapi should be reworked to manipulate the uploaded images in different ways. So, for example when I upload a screenshot, it should be handled and processed on another way as when I upload a photograph or an image which will be used inline. Image galleries/photoalbum.module should be handled by contrib modules IMO. Too much people want different thing in such a module, different views and different displaying of (EXIF) data. $0.02 from a photographer itself.. --- Stefan Nagtegaal Drupal-Devel@iStyledThis.nl Drupal Development Mailinglist
participants (29)
-
Adrian Rossouw -
andrew morton -
Ber Kessels -
Boris Mann -
Bèr Kessels
-
B�r Kessels
-
Chris Johnson -
Dries Buytaert -
Dries Buytaert -
Earl Miles -
Egon Bianchet -
Gerhard Killesreiter -
James Walker -
Jeff Eaton -
Karoly Negyesi -
Khalid B -
Larry Garfield -
Mark Fredrickson -
Matt Westgate -
Moshe Weitzman -
Richard Archer -
Robert Douglass -
Rowan Kerr -
Sebastian -
Stefan -
Syscrusher -
Tadej Baša -
Tim Altman -
vlado