Fields need a default configuration.

[jpgimenez]

Fields configuration is set by DefaultConfigureForm on handleSave method. Tiles render uses configuration values to order fields, select html tag, images scale and position, etc... but as values could not be already set, render views has a hardcoded default value that could be different to default value at DefaultConfigureForm...
basically is a mess... there should be a default configuration set on tile creation...
refs issue #92

[frapell]

There's not really a "tile creation" moment. Tiles are rendered when the template parser finds a data-tile attribute with a value such as url/@@tile_type/tile_id
When this happens, the "tiles machinery" gets the data belonging to the "tile_id" tile, in the context's annotations of "url".

Since tile_id can be anything, and we cannot assume tiles are going to be added using the "layout" view of a cover, then tiles need to provide default values for when no data is found.

[hvelarde]

yes, you have said so many time but I still don't understand it ;-)

the fact is we need to initialize the tile at some point, it is not enough to provide default values because the default values only apply if you enter the configuration screen and press the save button (IIUC).

I think we could provide a initialized flag that could be testes every time we add content to a tile; if the tile has not been initialized then we do it there.

comments?

[frapell]

Yes, my comments are already in comment 2.

Tiles do not really exist anywhere, a new instance of a tile gets created each time the tile is rendered. Its information is stored in annotations. Annotations are volatile, and independent from the tile infrastructure, so from the tile template, you cannot assume the annotation values exist.

Maybe you are thinking more on something closer to portlets than tiles...

[hvelarde]

so, you are saying there is no way to guarantee default values set on schema fields are stored in the annotations?

[frapell]

What i'm saying is: "When a tile gets rendered, you cannot assume data is going to be in the annotation for the current context".

There is stuff that can be done to "kinda make it work", like for example, when the adapter tries to access the info, and finds nothing, it can set some default value. However, semantically speaking, it would be wrong.
It also adds extra logic to the tile renderer, which is not a lot and it shouldn't reflect in a performance hit, but is extra logic for the CPU, on each tile rendering. In addition, possible issues can arise when serving a site with Read-only and read-write instances, mantain data integrity when adding removing tiles, etc...

And not to mention the fact that separates tiles further more from where they are going with the Deco stack.