Hi, On Tue, Nov 30, 2010 at 17:47, Jean-Vincent Drean <[email protected]>wrote:
> On Tue, Nov 30, 2010 at 5:34 PM, Vincent Massol <[email protected]> > wrote: > > > > On Nov 30, 2010, at 5:24 PM, Guillaume Lerouge wrote: > >> That's not necessarily needed. There are already 2 mechanisms that can > be > >> leveraged in order to handle this use case: > >> > >> - The ability to restrict a template to a given space -> the > ColorTheme > >> template could be provided only in the ColorThemes space for instance > > > > That makes a colortheme template provider quite useless since there's > already a way to create color themes from the color theme space... ok it > allows a user to create a new theme when viewing another theme, sure, but > that use case is not the main one IMO and it's covered by the create color > theme feature of the color them webhome. > > > >> - The $blacklistedSpaces variable -> it's already used to hide > technical > >> spaces. Coupled with the above mechanism, it could be sufficient > > > > See previous comment. Template providers are not really useful when > restricted to a space IMO. > > > > I think we need to be careful with our choice here, having too much > entries in the global list of available templates can make the page > creation look complex. > I agree as well. Maybe we could solve that by hiding some template providers for simple users? Guillaume > IMHO some applications would deserve it. The blog for example, but > IIRC it's made to allow to have 1 space / 1 blog (at least it's been > asked several times). Other applications like a meeting manager or a > todo manager would definitely get my +1 to be suggested everywhere in > the wiki, provided those apps handles objects coming from the entire > wiki of course. > > Thanks, > JV. > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
