Ticket #2308 (closed defect: fixed)

Opened 9 years ago

Last modified 9 years ago

Refactor: attached files and images URIs in widgets

Reported by: gracinet Owned by: gracinet
Priority: P1 Milestone: CPS 3.5.2
Component: CPS (global) Version: 3.5.1
Severity: major Keywords: attached file image widget


Currently, the File and Image widgets, with all their derivatives use terrible code to obtain URIs for attached files (including images) : adapter lookup, lots of conditions about existence of proxies or not, etc. Fortunately, the run to low level stops at the level of adapters, by calling getContentUrl. It would be even worse instead.

  1. Widgets don't have to know about adapters and query them in dirty code. The API should be on DataModel?.
  2. problems with images in directories (tracked as #1557) show that storage adapters don't provide enough uniformity, and that has to be fixed.

All of this is needed for #2234, which further demonstrates that a single API is not enough. Indeed, several URIs must be returned (depending on the wished display size).

Finally, I'm not very fond of this name getContentUrl(), finding it to be ambiguous (all that's in the data model " qualifies as "content" imho).

Attempt to find better names (with self being a DataModel instance)

getSubContentUri(field_name, absolute=False)
getImageUri(field_name, height=0, width=0, absolute=False)

Suggestions welcome

Change History

comment:1 Changed 9 years ago by gracinet

  • Status changed from new to closed
  • Resolution set to fixed

Done. Final API:

 getSubFileUri(key, absolute=False) 
 getSubImageUri(key, height=0, width=0, largest=0, absolute=False)

the latter can default on the former depending on Storage Adapter capability and/or objects it's working for

comment:2 Changed 9 years ago by gracinet

Adjustments have been necessary (nice case of integration error done in code and tests) API wasn't so final after all : this 'Sub' thing was really meaningful for AttributeStorageAdapter only (for which the file/image is indeed a sub-object, not to be confused with subobjects fields), but on DataModel?, this makes no sense : the file or image is a field value like any other.

Also, the 'get' part is useless, and this is no getter. Therefore now we have:

 dm.fileUri(key, absolute=False) 
 dm.imageUri(key, height=0, width=0, largest=0, absolute=False)
Note: See TracTickets for help on using tickets.