| Previous · Next | |
| User | Message |
|
JT
|
Date: 7/9/2007 5:41 pm · Subject: The Future of Attachments · Rating: -16
I have a personal demon about attachments in WebGUI. Right now if you upload a file using file pile then then it becomes it's own asset. But if you attach it to a forum post, article, or what have you, then it's just an attachment without any privileges or abilities of it's own.On one hand, I'd love for all attachments to be individual file/image assets. On the other hand, that can be cumbersome to deal with, and also decrease performance. The biggest advantage of each attachment being it's own asset is that it can then do everything an asset can do. If it's an image then it can be resized right in WebGUI, and even more stuff in the future. It can be copied separately from it's original parent, it can be linked with shortcuts and the AssetProxy macro. Basically, because it's a full fledged asset, it's just more powerful. However, if it's not a full fledged asset we don't have to ask the database how to get it or where it lives, because it's just a property of the asset it's attached to. This increases performance dramatically, even on assets that don't have a file attached. Because if we use attachments as assets, we then have to look to see if every article has any children, and check if those children are files or images, and then load them. So I'm still on the fence as to which is best. Which way do you think would be better for the future of WebGUI? |
| Back to Top |
Rate [ | ]
|
|
DBell
|
Date: 7/10/2007 11:33 am · Subject: Re: The Future of Attachments · Rating: 7
I think the best course of action is to retain the current behavior of "attachments are part of another asset." This isn't to say we couldn't add some better tools (with the new 7.4 ability for WebGUI::Form elements to have their own www_ methods) to allow some of the same features as file assets. Since these tools will only be loaded with the asset's edit form (or in a new page), there should be no performance detriment. Turning them into complete assets, as you said, will require calls to AssetLineage->getLineage, which can be slow (relatively) in the best of times.
|
| Back to Top |
Rate [ | ]
|
|
xtopher
|
Date: 7/10/2007 1:25 pm · Subject: Re: The Future of Attachments · Rating: -3
I am in favour of Attachments being treated like other Assets. One of the areas that has impacted us the most concerning Attachements is with the Collaboration system and not being able to directly edit the Attachment's attributes (like we can other Assets). For us, this was a 508/WAI issue as we were "out of" user defined fields to use for alt/title and other tags our USG Accessability experts force us to use. A way around it this was to use the userdefined fields, which we quickly ran out of- so some fields pulled double duty as caption and title or alt tag- which is less than optimal. More userdefined fields would have helped, but being able to edit the attributes in the asset panel for an attachment would've been the better solution. That also allows the attachment to be used everywhere in the system, not just with the item it's associated with. We'd still like 10 more userdefined fields in the CS, though.
I think consistently handling attachments and images/file/other assets is the better solution. Even with a performance hit. |
| Back to Top |
Rate [ | ]
|
|
JT
|
Date: 7/10/2007 4:44 pm · Subject: Re: The Future of Attachments · Rating: 5
And there you have it. Both sides of the story. Which is why I'm on the fence. Could everybody else chime in just so I can get a sense of how you feel? Even if the answer is just "make em assets", "status quo", and "i don't care"?
|
| Back to Top |
Rate [ | ]
|
|
greghacke
|
Date: 7/10/2007 5:15 pm · Subject: Re: The Future of Attachments · Rating: -1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
Assets.
For the purposes of educatiing clients, it is much
easier to show them that they all become assets vice teaching them that there
are other types of uploads.
<!-- Converted from text/plain format -->
Greg Hacke |
| Back to Top |
Rate [ | ]
|
|
colink
|
Date: 7/10/2007 4:57 pm · Subject: Re: The Future of Attachments · Rating: 13
I'm halfway serious: Find a way to make asset instanciation and look-ups faster. Then we won't care anymore about the problem. |
| Back to Top |
Rate [ | ]
|
|
JT
|
Date: 7/10/2007 5:12 pm · Subject: Re: The Future of Attachments · Rating: -8
It's not necessarily the instantiation time that is the problem, it's the combination of things that have to happen. Let me try to explain the process.Attachments directly part of another asset: 1. Instantiate asset. 2. Instantiate storage location. 3. Read list of files in storage location. 4. Display. Attachments as assets. 1. Instantiate original asset. 2. Search original asset's children to find attached files. 3. Instantiate each child that is a file (gets worse the more attachments there are) 4. Instantiate the storage location associated with each file asset. 5. Read file from storage location. 6. Display. It looks like there are only two extra steps, but in reality steps 3 through 6 get repeated for each attachment there is. In addition, step 2 has to be performed even if there are no attachments, just to find out if there are attachments, where in the first one we don't have to do that. Regardless though, I get your point of trying to make the whole process faster. |
| Back to Top |
Rate [ | ]
|
|
DBell
|
Date: 7/10/2007 5:09 pm · Subject: Re: The Future of Attachments · Rating: 4
Making them assets would be faster (because of caching) that adding a whole bunch of database or plain-text file stuff to existing attachments. So if we're adding things to attachments, better to make them assets. |
| Back to Top |
Rate [ | ]
|
|
Jesse
|
Date: 7/10/2007 8:46 pm · Subject: Re: The Future of Attachments · Rating: -7
I'd prefer every attachment to be an asset myself. - |
| Back to Top |
Rate [ | ]
|
|
knowmad
|
Date: 7/11/2007 8:07 am · Subject: Re: The Future of Attachments · Rating: -4
I'm for making them all assets. The performance and usability issues that arise from doing so can be addressed in the future. The benefits of having all images behave the same way sounds like it will be an advantage to both developers and users.
|
| Back to Top |
Rate [ | ]
|
