Revision history [back]
Regarding cascaded skins - they are not part of django per se, I've built that system for the forum.
Its weak point is that it makes possibility for two kinds of skins - the "full" ones that have all the files and "lazy" ones that have only some files. They are not the same because you cannot inherit from the "lazy" template in the same way (and it's actually impossible), yet they are stored the same way and may confuse people that they are equivalent in their function.
Secondly we have only one full skin - but I imagine that there might be several - e.g. with different layouts. If we want to support more than one base skin then we need two variables to define skin: name of full base skin and name of "lazy" one.
I thought that it would also be nice to upload media images through the admin UI (something that less tech savvy users will probably like) - so that is asking for another layer for media resolution on top of "lazy"->"full": "uploaded"->"lazy"->"full". However for the templates we'd leave "lazy"->"full". Or "uploaded"->"full" if lazy skin is not defined.
An unsolved issue is resolution of media files in javascript. Currently javascript is pulling media from the skin - i.e. your customized skin - there is no cascaded fallback, that's why you have to copy at least all media files from default into your directory or replace them all with your files. However, media is resolved correctly on the server side. I gues we'll have to provide a javascript media lookup map which has correct url for each media file.
Regarding cascaded skins - they are not part of django per se, I've built that system for the forum.
Its weak point is that it makes possibility for two kinds of skins - the "full" ones that have all the files and "lazy" ones that have only some files. They are not the same because you cannot inherit from the "lazy" template in the same way (and it's actually impossible), yet they are stored the same way and may confuse people that they are equivalent in their function.
Secondly we have only one full skin - but I imagine that there might be several - e.g. with different layouts. If we want to support more than one base skin then we need two variables to define skin: name of full base skin and name of "lazy" one.
I thought that it would also be nice to upload media images through the admin UI (something that less tech savvy users will probably like) - so that is asking for another layer for media resolution on top of "lazy"->"full": "uploaded"->"lazy"->"full". However for the templates we'd leave "lazy"->"full". Or "uploaded"->"full" if lazy skin is not defined.
An unsolved issue is resolution of media files in javascript. Currently javascript is pulling media from the skin - i.e. your customized skin - there is no cascaded fallback, that's why you have to copy at least all media files from default into your directory or replace them all with your files. However, media is resolved correctly on the server side. I gues we'll have to provide a javascript media lookup map which has correct url for each media file.
Regarding cascaded skins - they are not part of django per se, I've built that system for the forum.
Its weak point is that it makes possibility for two kinds of skins - the "full" ones that have all the files and "lazy" ones that have only some files. They are not the same because you cannot inherit from the "lazy" template in the same way (and it's actually impossible), yet they are stored the same way and may confuse people that they are equivalent in their function.
Secondly we have only one full skin - but I imagine that there might be several - e.g. with different layouts. If we want to support more than one base skin then we need two variables to define skin: name of full base skin and name of "lazy" one.
I thought that it would also be nice to upload media images through the admin UI (something that less tech savvy users will probably like) - so that is asking for another layer for media resolution on top of "lazy"->"full": "uploaded"->"lazy"->"full". However for the templates we'd leave "lazy"->"full". Or "uploaded"->"full" if lazy skin is not defined.
An unsolved issue is resolution of media files in javascript. Currently javascript is pulling media from the skin - i.e. your customized skin - there is no cascaded fallback, that's why you have to copy at least all media files from default into your directory or replace them all with your files. However, media is resolved correctly on the server side.
Regarding cascaded skins skins - they are not part of django per se, I've built that system for the forum.
Its weak point is that it makes possibility for two kinds of skins - the "full" ones that have all the files and "lazy" ones that have only some files. They are not the same because you cannot inherit from the "lazy" template in the same way (and it's actually impossible), yet they are stored the same way and may confuse people that they are equivalent in their function.
Secondly we have only one full skin - but I imagine that there might be several - e.g. with different layouts. If we want to support more than one base skin then we need two variables to define skin: name of full base skin and name of "lazy" one.
I thought that it would also be nice to upload media images through the admin UI (something that less tech savvy users will probably like) - so that is asking for another layer for media resolution on top of "lazy"->"full": "uploaded"->"lazy"->"full". However for the templates we'd leave "lazy"->"full". Or "uploaded"->"full" if lazy skin is not defined."lazy"->"full".
Regarding cascaded skins - they are not part of django per se, I've built that system for the forum.
Its weak point is that it makes possibility for two kinds of skins - the "full" ones that have all the files and "lazy" ones that have only some files. They are not the same because you cannot inherit from the "lazy" template in the same way (and it's actually impossible), yet they are stored the same way and may confuse people that they are equivalent in their function.
Secondly we have only one full skin - but I imagine that there might be several - e.g. with different layouts. If we want to support more than one base skin then we need two variables to define skin: name of full base skin and name of "lazy" one.
I thought that it would also be nice to upload media images through the admin UI - so that is asking for another layer for media resolution on top of "lazy"->"full": "uploaded"->"lazy"->"full". However for the templates we'd leave "lazy"->"full"."uploaded"->"lazy"->"full".
Regarding cascaded skins - they are not part of django per se, I've built that system for the forum.
Its weak point is that it makes possibility for two kinds of skins - the "full" ones that have all the files and "lazy" ones that have only some files. They are not the same because you cannot inherit from the "lazy" template in the same way (and it's actually impossible), yet they are stored the same way and may confuse people that they are equivalent in their function.impossible).
Maybe we should also
Secondly we have only one full skin - but I imagine that there might be several - e.g. with different layouts. If we want to support more than one base skin then we need two variables to define skin: name of full base skin and name of "lazy" one.
I thought that it would also be nice to upload media images through the admin UI - so that is asking for another layer for media resolution on top of "lazy"->"full": "uploaded"->"lazy"->"full".