xwiki-devs June 2017

xwiki-devs@xwiki.org

20 participants
42 discussions

Re: [xwiki-devs] [PROPOSAL] So, what display name for the new default flavor ?

by daniel glazman

> > * "Base XWiki Flavor” > > * “Classic XWiki Flavor” > > * “Raw XWiki Flavor” > > * “Starter XWiki Flavor” > > * "Default XWiki Flavor” > > * "Generic XWiki Flavor” > > * “Standard XWiki Flavor” > > * "XWiki Flavor” > > * "Vanilla XWiki" Sorry to send this message without the threading references; I just subscribed to the devs(a)xwiki.org mailing-list and I would like to contribute my €0.02 to the discussion The items below are numbered for commenting convenience but are not ordered in any way. 1. The name XWiki already has its first letter at the end of the alphabet. Marketing-wise in the Software ecosystem, lists of apps are most often alphabetically sorted, granting a bonus to apps with a name in A, B or C, and a minus to the end of the alphabet. So all names there have to counterbalance that handicap and I think "self-descriptiveness" does matter. 2. if you except "XWiki Flavor", the word "XWiki" comes in second position in all proposals, and that is not the best thing ever. 3. the name must be chosen wrt the targeted audience and the product's position on the market. I think Olivier has a point when he writes « what is the audience and the objectives ? » 4. more specifically about the proposals above: 4.1. a "flavor" holds the notion of specialization. 4.2. "Classic" can mean "legacy" in the Software world. Use carefully... 4.3. "Vanilla" is a geeky choice. Nobody else but geeks will get it,sorry. IMHO, "XWiki Foundation", "XWiki Core" or "XWiki Starter Kit" represent quite well what this is all about. </Daniel>

7 years, 6 months

[xwiki-devs] [Brainstorming] Templates exposure

by Ecaterina Moraru (Valica)

Hi devs, This roadmap we had 2 suggestions: - "Find a way of avoiding to have 2 "Add" entries ("+" and "Add new entry")" in AWM - "Drop down on "+" Menu + Admin UI to select some templates" What we have implemented so far was: http://jira.xwiki.org/browse/XWIKI-14310 "Propose and pre-select "recommended" templates in the create UI based on the current location" So now, if you go to the Blog app and create on the "+" button, since Blog provides a template with a create restriction, the "Blog" template will be preselected. Also, AWM has the option to create a template for each application the users create. So after you created your app with AWM and go to the "+" button, the app template will be preselected. This will allow us in the future to remove the AWM actions area and rely on the "+" button. In the future, we could also separate templates in their own "Recommended" category. A separate category will be necessary for applications that provide multiple related templates (like Forum for example that will contain the Forum, Topic templates) or in the more general case when multiple templates are recommended for the current location. Currently we are doing only sorting and preselecting the first one. In terms of implementation we just need to make sure all our recommended apps provide template providers and after that we could change the UI for AWM and remove the "Add" action from the actions area. Now, I want to ask your opinion on the suggestion to add a dropdown for the "+" button. Some input: - a dropdown will not be scalable: you cannot have more than a few options there; - in a dropdown you cannot specify the page name; - in the dropdown you cannot change or specify another location - you always need to go to the page first and after choose a template from the dropdown list; - you will only see an admin selection of templates - so we invalidate the templates filtering and you cannot even choose another template after your initial selection; - we make the current create step deprecated, since users will not see it anymore. The main reason of this request was to increase visibility and order for the templates. In the user recording sessions I've seen and with the current layout (2 columns, templates on right) users don't have problems seeing the "Templates" section in the Create step. Now, for the ordering / selection - the current mechanism of automatic ordering is a step in that direction - but sure we could implement more (like the separate category I described earlier). Another difference between what was asked and what was currently implemented is that now the selection comes from the Template Provider; while the idea was to allow the Administrator to select the displayed Templates. With the current implementation we can still create an administration UI to select them and save the changes in the Template Providers, in a future iteration. ----- So the question is: - Do you have other ideas on how we could solve the requests? - What do you think about having a dropdown with the templates selection - compared to a recommended category in the creation step? Thanks, Caty

7 years, 6 months

[xwiki-devs] [UX][Proposal] Rights

by Ecaterina Moraru (Valica)

Hi devs, I've made a proposal on rights improvements at https://forum.xwiki.org/t/ux-rights-improvements/107 Haven't received much feedback on it so I'm cross posting it here in case you've missed it. Thanks, Caty

7 years, 6 months

[xwiki-devs] Handling default values and displaying them in form elements

by Eduard Moraru

Hi, devs, While handling https://jira.xwiki.org/browse/XWIKI-14157 (Display the default and inherited values in the Administration), I`m trying to come up with a solution that is applicable more generally and avoid having to manually patch just the problem at hand. We could think of this as a 2 piece problem: 1) getting or specifying the default value (or maybe it's more correct to say default display value?) 2) displaying a form field and handling the default value (view/edit modes) 1) would be much simpler if we only had to handle a flat level class and its objects, but, for XWikiPreferences, we also have the "space<space<wiki<xwiki.cfg" inheritance to consider. This inheritance is done through the use of various ConfigurationSource implementations that delegate one to another. The problem with ConfigurationSource is that, through its use of getPreference(preferenceName, defaultValue), we end up in proliferating default values throughout the code, each time we just want the value of that preference, resulting in a big mess and not knowing what is the default value for that preference and where it is set. I was thinking of adding some: * <T> T getPropertyDefault(String name) method which would allow a ConfigurationSource to handle by itself the retrieval of the default value for a property and a * <T> T getPropertyOrDefault(String name) convenience method for callers to fallback on the internally-determined default value, without caring what it actually is. As an example, this would be useful when calling $xwiki.getXWikiPreference(...) since we don`t have to specify the default value in the caller, but it will be retrieved by performing the fallbacks mechanism space<space<...<wiki<xwiki.cfg. Still for 1) but for ConfigurableClass sections that rely on a simple configuration class (or any other form that relies on properties defined by a class), one idea would be to add a "defaultValue" meta-property (with associated getter/setter in PropertyClass) in the class that allows specifying the default value of a property when defining it. This would allow a displayer to have the default value and properly display it, instead of weird "---" stuff we do now and all kinds of *fake* values, just so that the user can select them. (We may also need a "defaultPrettyValue" or "defaultDisplayValue", with associated getter/setter, for things like DBList). Reminder: We already have a "defaultValue" meta-property for BooleanClass, so it looks like we had the idea before, just did not take it all the way. So XWikiPreferences goes more into the "specifying the default value at display time" workflow, IMO (because we would have to provide the default value that is retrieved from a "special" mechanism, i.e. $xwiki.getXWikiPreference(...))... and we should use the "getting the default value" (from the class property's "defaultValue) as the default behavior, for simple objects of simple classes. Finally, for 2), I`m thinking that we might need a way to also pass the default value to a display() call, overwriting anything else, in order to support custom fields that get their defaults from external sources or other mechanisms that don`t involve the XClass and the "defaultValue" defined there (like XWikiPreferences does, for example, or other custom stuff). This also introduces the problem that not everybody might want a default value proposed in their form for a certain element, so we should also be able to specify, at display time, if the default value should be proposed or not. These optional additions to the display method ("defaultValue", "defaultDisplayValue", "showDefault", etc.), including the existing ones ("prefix", "wrappingSyntaxId", etc.) should probably be done with a new signature that also takes a map of parameters. The aim is to rely as much as possible on $doc.display(property, parameters) when creating forms in XWiki, while also encapsulating the default value to the location responsible for it, and not to the caller. WDYT? Thanks, Eduard

7 years, 6 months

[xwiki-devs] [GSoC] More extension repositories [Bintray / Artifactory]

by Krzysiek Płachno

Hey! I investigated a bit Binatray and Artifactory and uploaded relatively short raport: http://design.xwiki.org/xwiki/bin/view/Proposal/MoreextensionrepositoriesAr… Any comments, ideas, relfections - highly appreciated. Best, Krzysztof Płachno

7 years, 6 months

[xwiki-devs] [Contrib] GitHub and JIRA project for application-hubot

by Ludovic Dubost

Hi I've created a github repo on https://github.com/xwiki-contrib/application-hubot for a XWiki/Hubot/Matrix integration. I might not have setup the repository completely for this and also did not create Jira project. Could the dev team complete this ? Thanks Ludovic -- *Ludovic Dubost* *Founder and CEO* ludovic(a)xwiki.com skype: ldubost Blog: http://blog.ludovic.org <https://r.clb.pt/r/b13683e7987e2155d687c1636911d8fe?d=http%3A%2F%2Fblog.lud…>Try XWiki on the cloud <https://r.clb.pt/r/b13683e7987e2155d687c1636911d8fe?d=http%3A%2F%2Fwww.xwik…> - Try Cryptpad: Secure realtime Wysiwyg Editing <https://r.clb.pt/r/b13683e7987e2155d687c1636911d8fe?d=https%3A%2F%2Fcryptpa…>

7 years, 6 months

[xwiki-devs] [Contrib] RedPen Integration - Request for project

by deshengchuan

Hi, so I'd like to request for a Github repository for my RedPen integration project. As of now, I'd like to name the repository application-document-checker (yeah it's two words instead of one but I feel it is necessary to capture the full meaning of this application) As for description, I think it is enough for now to describe it as a proofreading tool to ensure that the quality standards of a Wiki document is met. My GitHub name is laskjk (It is an old username made a year back and I'd like to keep the history of my commits in one account) As of now this is what I need. I'll request for more hosting tools at a later date, when I am nearer to producing a working application. Thank you for your help! -- View this message in context: http://xwiki.475771.n2.nabble.com/Contrib-RedPen-Integration-Request-for-pr… Sent from the XWiki- Dev mailing list archive at Nabble.com.

7 years, 6 months

[xwiki-devs] [PROPOSAL] So, what display name for the new default flavor ?

by Thomas Mortagne

Hi devs, I'm getting closer to finish with the hard work around new platform flavor which is going to replace XE. Need to decide what user will see in the Flavor picker when installed XWiki now. As a reminder we decided that this would be a generic flavor, not tied to any specific use case (so forget about "Knwonledge Base Flavor" :)). Here is a few ideas gathered in previous mails: * "XWiki Flavor" * "Default XWiki Flavor" * "Generic XWiki Flavor" * "Base XWiki Flavor" "Generic" is probably a way too technical term. "Base" would be misleading IMO since it's not really a base flavor. Its primary goal is not to be used as a dependency (of course it's fine to have it as dependency if you just want to add pre installed extensions to the default flavor). It's a -1 for me. Frankly I would simply go for "XWiki Flavor". I know, it's not going to be the only flavor for XWiki but it's obvious when you actually see severals of those in the picker anyway and I find it nicer than "Default XWiki Flavor" which basically means the same thing since the XWiki core project does not plan to provide any other flavor. I'm also fine with "Default XWiki Favor" if others think it's a better name. WDYT ? -- Thomas Mortagne

7 years, 6 months

[xwiki-devs] [Update 2] RedPen Integration

by deshengchuan

Hi all, this is another weekly update with regards to the work on the RedPen extension. I've more or less created a component + scriptservice that helps to validate an input string of text. How I envision this to work is that an Event Listener would obtain the context of the document when the user saves the page, parse it using the syntax rendering component to plain text, then run it through the component I've made. Hence, the next week would be dedicated to writing the event listener. I have still not designed how I am going to take in the user's validation settings, hence I have an incomplete Java class and will work on it after writing the event listener With that in mind, I think I should request a repository on xwiki-contrib, since I already have some starting code available locally. May I know what are the required steps I need to achieve that? Next, I understand that there are three ways that one can write an event listener, either using an XWiki Component in a jar, a Wiki Component or using Groovy. I am currently considering using Groovy to create the Event Listener directly within a wiki page. Any thoughts on that? Lastly, I am unsure of the report format and details to submit as part of the GSOC programme. Can I get some clarifications with regards to it? Thanks. -- View this message in context: http://xwiki.475771.n2.nabble.com/Update-2-RedPen-Integration-tp7604136.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

7 years, 6 months

[xwiki-devs] [VOTE] Move the WebDAV feature to xwiki-contrib

by Vincent Massol

Hi devs, With https://jira.xwiki.org/browse/XE-1527 (http://markmail.org/message/t7khe7ufdtlsf5gl) we’ve removed the WebDAV feature by default in XE. I’d like to propose to go one step further and consider the webdav feature as non-core and move it outside of the xwiki github organization and into xwiki-contrib. I’d also propose that the XWiki Core Dev Team stops supporting it. Rationale: * We haven’t touched it in a long long time * It’s not a feature requested by our users anymore * If any contributor is interested in working on it one day, it’s simpler in xwiki-contrib and it can be released independently of XWiki Here’s my +1 Please cast your vote Thanks -Vincent

7 years, 6 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs June 2017