On Wed, Jun 15, 2016 at 2:03 PM, Eduard Moraru <[email protected]> wrote:
> Hi, > > A remaining thing to clarify is how to handle these restrictions in > relation with the Nesting feature. > > * For visibility restrictions, I believe it is safe to continue with the > current behavior, that is to show the template provider in the specified > location (space) and its children (subspaces). > > * For the default creation location, this does not apply > > * For creation restrictions, we need some consensus. Do we also allow > creation in the children of the specified location restriction? > ** This can create problems to the usecase when you use this > field/restriction to make sure that an application properly reads the new > entries by restricting creation to a specific space. If you were to allow > children, the app would not properly read the new entries. Sure, you might > say that the app needs fixing, but, depending on the app, it may not be > possible. > ** On the other side, in general templates (or for templates of apps that > support nesting), allowing children for the restriction might be needed. > *** Note that currently (recently implemented) we are allowing the creation > in child spaces of the existing restrictions. > ** Should we have a 4th "allow children" option, a boolean/checkbox value, > to control the behavior of the creation restrictions to suit both major > cases? Of course, we will not be able to have more complex settings (like 2 > spaces with children and 2 spaces without children), but we could accept > this limitation since it would probably be an edge case anyway. > > > Another note on the differentiation between visibility and creation > restrictions is that, in terms of UI, it would require some reworking, > since having 2 trees in the same UI is not a good idea. > We could display the selected paths (restrictions) using the breadcrumb displayer and use a tree picker to add more restrictions. path / to / page [Remove] path / to / some / other / page [Remove] [Add more restrictions] [Remove all restrictions] Something like http://extensions.xwiki.org/xwiki/bin/download/Extension/CKEditor+Integration/linkDialog-pageSuggest.png . Thanks, Marius > Thanks, > Eduard > > On Tue, Jun 14, 2016 at 2:48 PM, Eduard Moraru <[email protected]> > wrote: > > > Hi, > > > > On Tue, Jun 7, 2016 at 6:13 PM, Anca Luca <[email protected]> wrote: > > > >> Hello all, > >> > >> On Mon, Jun 6, 2016 at 6:31 PM, Ecaterina Moraru (Valica) < > >> [email protected] > >> > wrote: > >> > >> > Hi, > >> > > >> > The Template Provider allows setting the locations where the template > >> must > >> > be available. > >> > Some applications need/encourage their pages to be located in a > >> particular > >> > app location. > >> > Currently, if we set such a location for a template, the template will > >> be > >> > listed in the "Create Page" step only if the user navigates to that > >> > location and clicks on the "Add" button. > >> > > >> > One behavior could be that all templates are displayed each time the > >> user > >> > clicks on 'Add', regardless of the initial location. > >> > This would mean splitting the current Location functionality into > >> "Template > >> > Visibility" and "Creation location restrictions": > >> > - Ideally "Template Visibility" should not be restricted, but we would > >> need > >> > to keep this field in order to be backward compatible with the current > >> > behavior. > >> > - "Creation location restrictions" would indicate if the page needs to > >> be > >> > created in a particular location. The user will not be allowed to > create > >> > somewhere else and be warned by an error message. > >> > > >> > >> I would identify 3 things that a template provider should be able to do: > >> * be visible only in certain locations (the current feature, but maybe a > >> bit more sophisticated) > >> * recommend a location for the pages created from that template - > >> "recommend" here would mean that the user could change that location if > >> they wanted > >> * restrict a location for the pages created from that template - > >> "restrict" > >> would mean that the location would be chosen by the template provider > and > >> the user would not be able to change it > >> > > > > I agree. Those 3 fields would need to be added to a template provider > > class. > > > > Note that these restrictions will add yet another point of technical debt > > in the ability to rename/move an application, should we want to support > > that at some point. Maybe we could leave that aside for now since it`s > not > > a priority. > > > > A migrator will also have to be done for existing templates to use the > new > > properties and the create UI and template provider sheet needs to be > > updated. > > > > On the policy side, re the recommendation for new providers, I guess it > is > > up to them to decide if it makes sense for their application to enforce, > > recommend or to allow any location where the template can create pages. > On > > the visibility side, though, I think we can safely recommend to allow the > > template to be visible everywhere by default and let the admin set > > restriction at runtime, depending on his needs. > > > > Thanks, > > Eduard > > > > > >> Note that the 3 above don't exclude eachother, so we can have them all > >> implemented as options of the template provider. > >> I think that the template provider should be able to fully control them. > >> I.e. the template provider should decide if the location is to be > >> restricted or only recommended. In addition, I see usecases for all 3 of > >> them, so I don't think we should completely exclude one from the > picture. > >> > >> Now, in my opinion, the rest is about how we present these options in > the > >> creation screen (do we present them all as equally important?) and what > do > >> we implement for the default applications. See my answers to your > >> questions > >> below. > >> > >> > >> > > >> > This mail's purpose is to debate: > >> > A. If templates should be visible everywhere or just in a particular > >> > location? > >> > > >> > >> As I said, we should allow the template provider to decide that, as we > >> currently do. > >> > >> > >> > B. Should we recommend applications to restrict the creation of pages > >> to a > >> > particular location? > >> > > >> > >> I think this depends on the application, on what kind of data it > >> stores, how it handles rights, etc. > >> > >> Now, for a general recommendation, I think it would not be efficient to > >> recommend restriction. I think at most we could guide towards a > >> "recommended" location for the pages (in the sense described above), but > >> it > >> really depends on each application. There is great value in being able > to > >> create application pages anywhere on your wiki, so we shouldn't > recommend > >> against. > >> HOWEVER > >> My biggest concern here is that the users could very easily get confused > >> between the application concept and the application page concept. For > >> example, assume we'd have a blog post template provider available > >> everywhere on the wiki, without a recommended location. I fear that the > >> users will not realize that choosing the "Blog Post" template provider > in > >> the create page screen is not equivalent with creating a blog post using > >> the create blog post form on the homepage of the blog application (the > >> page > >> accessible when clicking on the blog application). Same for all the app > >> within minutes: "Create new entry" on the homepage of the application > will > >> create a new entry of the application "contained" in the application > (read > >> "in the data subtree of the application"), while choosing the template > of > >> that application from a create screen will not have the same effect. I > can > >> easily see the users getting a little confused with these. > >> > >> I think we can have solutions to this confusion that are only reelated > to > >> presentation, not to technical stuff, so it should not be scary. > >> > >> Thanks, > >> Anca > >> > >> > >> > >> > >> > > >> > Let me know what you think. > >> > > >> > Thanks, > >> > Caty > >> > > >> > Related: > >> > [1] http://jira.xwiki.org/browse/XWIKI-8759 > >> > [2] > >> > > >> > > >> > http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageSketches/HomepageTemplateAvailability/ > >> > _______________________________________________ > >> > devs mailing list > >> > [email protected] > >> > http://lists.xwiki.org/mailman/listinfo/devs > >> > > >> _______________________________________________ > >> devs mailing list > >> [email protected] > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > > > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
