16 Jun
2016
16 Jun
'16
3:38 p.m.
On Wed, Jun 15, 2016 at 2:03 PM, Eduard Moraru <enygma2002(a)gmail.com> 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+Integrati…
.
Thanks,
Marius
Thanks,
Eduard
On Tue, Jun 14, 2016 at 2:48 PM, Eduard Moraru <enygma2002(a)gmail.com>
wrote:
not
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hi,
On Tue, Jun 7, 2016 at 6:13 PM, Anca Luca <lucaa(a)xwiki.com> wrote:
> Hello all,
>
> On Mon, Jun 6, 2016 at 6:31 PM, Ecaterina Moraru (Valica) <
> valicac(a)gmail.com
> > 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 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/HomepageTe…
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs