Hi, I ported the Image to a FieldContainer. The reason for the dynamic field approach for attributes is that an image should hold additional attributes for special image types. Number and type of this attrubutes depend on the image type. I don't like the dynamic fields. They are not supported by clustering.
File path should be a field and name should be a NameAttachment. I would store always the absolute path in the filePath field because it is difficult to define a relative path if the image is shared. Marcus Carsten Neumann wrote: > Hi Allen, > > Allen Bierbaum wrote: > >> I have been looking at the code for OSG::Image today and there seems to >> be some crufty code related to name and filename. >> > Yeah, quite possible. IIRC Image originally wasn't a FieldContainer and > so there was no (easy) way to use attachments on it. > > >> At first it looked like Image has a field called "name" that seems to be >> used to hold the filename of the image instead of a name describing the >> image. But then after looking at the image loader I found that it adds >> attachment fields for the filename and the full file path even though it >> still puts the full file path in the name field. The VRML writer seems >> to look for the attachment first and thens falls back on the name >> field. On the other hand the OSB field only looks at the name field. >> > Hm, this inconsistency is probably a side effect of Image's evolution. > How much clean-up can be done mainly depends on the amount of breakage > it would cause and we are willing to accept. > > >> So, I have a few questions: >> >> - Why isn't there a filename field for storing the name of the file? >> (this would allow the name field to be used to describe the image) >> - Why does the loader store the filename and full file path in attachments? >> >> In a perfect world I would think the code would have separate name and >> filename fields and that the filename would be a relative path from the >> file that the image is used within. That way when a loader loads a file >> it can find the image and load it. Or perhaps there could be a file >> search path that is used to find the file. This seems to be what >> PathHandler is for, but I don't know for sure. >> > > I don't know the "official" word this, but my own opinion is: > For consistency, naming of objects should be done via the NameAttachment > whenever possible -- yes, for ContainerPool I recently suggested a name > field myself ;) > Likewise paths should be stored in an attachment as well, as there are > Images that do not correspond to files on disk (ImageGrabForeground > comes to mind). Likewise if an Image is used as part of a model (e.g. a > texture) it can hold the model's file path in its attachment. > ImageGenericAttachment is a DynFieldAttachment so you can add fields for > this type of information to it - there is even a convenience interface > in Image for this: setAttachmentField/findAttachmentField. > > Cheers, > Carsten > > PS: In 2 DynFieldAttachment is broken, hence ImageGenericAttachment can > not be really used ATM. > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Opensg-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-users > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
