Dirk Reiners wrote:
> Marcus Roth wrote:
>> 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.
>
> Especially the volumetric file formats contain a lot of additional
> information.
>
>> Number and type of
>> this attrubutes depend on the image type. I don't like the dynamic
>> fields. They are not supported by
>> clustering.
> They should be.
I'd love to be corrected on this, but it seems quite difficult to get
this working. Adding a dynamic filed requires a FieldDescription and
those contain function pointer, which are not easily transported across
a network :(
>> 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.
>
> With the more generic data providers being discussed I don't think it
> will be possible to define an absolute name. Originally I didn't want to
> have a name in the Image as not all Images come from files. In practice
> 99% of Images do come from files, so I'm fine with having the name that
> is used to load the image inside the Image and other info as
> attachments. To get around the DynamicAttachments we might just use a
> generic StringAttachment and use a bunch of them.
What about using a StringAttributeMap ?
Carsten
-------------------------------------------------------------------------
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
