"Phillip J. Eby" wrote:
By the way, RenderingKinds is a sort of specialist that hasn't been discussed much outside of the apps Ty and I work with - the "constant" Specialist, one which contains application configuration or metadata rather than "content". Oftentimes it's handy to simply base a Specialist on a TinyTable or similar product in order to set up configuration of constant items like RenderingKinds. Consider the TinyTable data below:
Columns: name:string scaling:float width:int height:int rackname:string
"fullsize",1.0,0,0,"bigimages" "halfsize",0.5,0,0,"bigimages" "thumbnail",0.0,64,64,"thumbnails"
In my application, I'm only interested in specifying the 'maximum dimension' in any direction. This seems to work better generally, because it accounts automatically for images that are landscape or portrait oriented. So my TinyTable only has two columns: Columns: name:string maxdimension:int
The RenderingKinds specialist would have a single rack, which uses SkinScript to pull in the data from the TinyTable (WITH theTinyTable[self.id] COMPUTE scaling,width,height,rackname).
The SkinScript (which I placed in the RenderingKinds Specialist, not in it's defaultRack) has the following line in it: WITH sizes[self.id] COMPUTE maxdimension I eliminated the 'rackname' column, because you reccomended that all Renderings(RackImages) be stored in the same Rack, for simplicity. This also seems the more flexible approach (ie. I don't have to create management screens to add and delete racks when the sizes change), so there is less 'hardwiring'. Now, am I correct in assuming that the 'sizes' TinyTable should be in the RenderingKinds Specialist? I'm also assuming that RenderingKinds' defaultRack is set to use 'ZPatterns: DataSkin' and be set to load by accessing the 'id' attribute. Is this correct? Thanks, Michael Bernstein.