xwiki-devs September 2015

xwiki-devs@xwiki.org

19 participants
51 discussions

[xwiki-devs] [Proposal] Customized Less Variables on the color editor

by Yacine Kebir

Hi Devs, I would to propose an improvement for the color theme editor to make it more powerful and flexible. In order to achieve this, I propose to add a new tab "Customized Variables <http://design.xwiki.org/xwiki/bin/view/Proposal/Improvethecolorthemeeditor>" to the editor. This tab would allow us to add more LESS CSS variables and list them in a list We could use this variable in order to add more LESS css rules in the advanced tab and target any area on the platform. http://jira.xwiki.org/browse/XWIKI-12351 WDYT? -- *Yacine KEBIR* Web Designer / Front End Developer yacine.kebir(a)xwiki.com *Mobile: *+213 550 749 033 *Web Site : *www.xwiki.com

9 years

Re: [xwiki-devs] [Brainstorming] Is the Refactoring module a core module?

by vincent＠massol.net

Hi Edy, On 2 Sep 2015 at 20:08:29, Eduard Moraru (enygma2002@gmail.com(mailto:enygma2002@gmail.com)) wrote: > Hi, > > I get the feeling that we are overengineering it after a certain point. > Yes, you could argue that the really, really, really basic operations > should be in core and then the more elaborate operations can be included > when needed, etc. but let's be real, nobody wants, for example, the XWiki > version that only does create and view, but does not do copy + rename > because in their specific code they don`t use that. Also, nobody wants the > XWiki version that only works with a single document because they never > create more than 1 document, etc. > > With nested spaces, the model has expanded and so did the operations on the > model. They are part of the model, whether we like it or not, and should be > bundled with the model itself. Like the wiki service, we have extended the > model, but to use it in the new way, you need to depend on an "optional" > module. > > There are very many places where XWiki is too monolithic and we need to > break it apart and refactor, yes, I agree, but in these recent discussions > on the topic, I personally feel we are drifting in the wrong direction. > > Just my personal feeling. Yes I definitely agree with you if you consider XE. Now if you consider XWiki as a development platform for developing collaborative web applications it’s more arguable. I’m pretty sure some integrators would be interested in the ability to configure the menus for example, even though this is not required for XE. If we’re talking specifically about splitting the Refactoring module into 2 then I agree that it’s probably overkill at this point. Now on this topic, I believe it’s important that we discuss the alternative whenever we add a new module to the core (ie to PackageMojo) and verify we do want that, because otherwise it’s very easy to go back to a monolith (even though you’d have several modules it can still be a monolith if they all depend on another ;)). We need to fight entropy (aka technical debt)! :) If we’re talking specifically about having configurable menus I don’t think it’s overkill. If we’re talking specifically about implementing a menu UIX for the Delete Action yes I agree it’s overkill. I was just stating what I believe is the canonical way of doing this. Even though we may not want to do it for this case, I felt it was good to mention it since we could and probably should do this in a few places (like in the Drawer for example). If also know Ludovic and probably other users who customize XWiki a lot would like to have more Extension Points and we’re lagging behind on this. Thanks -Vincent > Thanks, > Eduard > > On Wed, Sep 2, 2015 at 6:42 PM, vincent(a)massol.net > wrote: > > > > > > > On 2 Sep 2015 at 14:49:26, Marius Dumitru Florea ( > > mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) > > wrote: > > > > > On Mon, Aug 31, 2015 at 7:26 PM, Eduard Moraru wrote: > > > > I`m not very familiar with the refactoring module and its contents, > > but it > > > > feels wrong to have extensions have to depend on it and use it in > > order to > > > > achieve basic model (CRUD) operations. > > > > > > The low level / basic CRUD operations are in oldcore. The refactoring > > > module doesn't modify the database directly, it uses > > > XWiki#deleteDocument and XWiki#copyDocument from oldcore to implement > > > the refactorings. If you only need to delete a single document from > > > the database without any side effects then you can use the oldcore > > > API. If you want to delete an entire hierarchy or update the backlinks > > > on rename then you should use the refactoring API. > > > > > > The "issue" here is that the DeleteAction (located currently in > > > oldcore) uses the refactoring API in order to support deleting an > > > entire hierarchy. If the DeleteAction were a component outside of > > > oldcore then it could depend on the refactoring-default but currently > > > it can only depend on refactoring-api (to avoid circular dependency on > > > oldcore). > > > > Actually, even if the DeleteAction was located in a module/extension > > outside of oldcore, we would still need to decide if we want to bundle this > > action by default or not in a minimal wiki (i.e. is it a core extension). > > So far we’ve said that yes we need the Delete Action in an empty wiki. > > > > Instead, what we could do in the future is this: > > * Refactor the Page Menu to be made of Extension Points > > * Have a default Extension Point Provider for the Delete Action that > > simply implements Delete using XWiki#deleteDocument(). This would be part > > of core and be available in an empty wiki > > * Have a more elaborate Extension Provider for the Delete Action (that > > overrides the basic one) that uses the Refactoring module. This would be > > packaged in an optional extension (that we would bundle in our Flavors by > > default but that you wouldn’t get by default in a minimal empty wiki). > > > > > > I think that after we finish Nested Spaces coding, it would be nice that > > we start introducing and using more Extension Points (this is long overdue > > IMO). There are plenty of places where they would be useful. Yesterday for > > example I notice the hardcoding of the Wiki Index in core vm (drawer.vm) > > when an Extension Point in the Drawer would offer a better approach IMO. We > > should also discuss best practices for when using UIX vs XClass (see > > http://markmail.org/message/ojgmy7pljzwjq7vp). > > > > > > Thanks > > -Vincent > > > > > The default refactoring implementation is brought in by XE, but > > > functional tests in platform don't have it unless they add a > > > dependency, or we add it to the packager plugin as Vincent did. > > > > > > Thanks, > > > Marius > > > > > > > > > > > Thanks, > > > > Eduard > > > > > > > > On Mon, Aug 31, 2015 at 6:54 PM, vincent(a)massol.net > > > > wrote: > > > > > > > >> Hi, > > > >> > > > >> Right now almost all func tests fail to delete pages when they > > > >> do getUtil().deletePage(…). They fail with: > > > >> > > > >> Caused by: org.xwiki.component.manager.ComponentLookupException: Can't > > > >> find descriptor for the component [role = [interface > > org.xwiki.job.Job] > > > >> hint = [delete]] > > > >> > > > >> The reason is that since XWIKI-12268 the Delete action cannot work if > > the > > > >> Refactoring module isn't bundled, which makes the Refactoring module > > a core > > > >> module. And this module is not part of the core modules ATM. I’ve > > added it > > > >> to the PackageMojo for now but we need to decide what to do. > > > >> > > > >> Personally I’ve always viewed Refactoring as optional and advanced > > > >> features. > > > >> > > > >> I don’t consider basic delete, basic copy and basic rename/move as > > > >> refactoring options. However there are some parts of them that are > > > >> refactorings. For example when Renaming, also check for wiki pages > > having > > > >> the renamed page as parent and updating them or updating wiki links in > > > >> pages. > > > >> > > > >> So we need to decide if: > > > >> > > > >> * We consider the Refactoring module as core. > > > >> * Introduce a new module and move some of the core actions such as > > delete, > > > >> move, etc to it and keep the refactoring module for non-core > > refactoring > > > >> * Split the refactoring into basic refactorings and advanced ones. > > Have > > > >> basic delete, copy, rename + advanced options for them separately > > > >> * Others? > > > >> > > > >> WDYT? > > > >> > > > >> Still hesitating on my side. > > > >> > > > >> Thanks > > > >> -Vincent

9 years

[xwiki-devs] [Iteration][UX] Nested: Livetable

by Ecaterina Moraru (Valica)

Hi, I've added some ideas on how to display 'Space' column in the AllDocs page: http://design.xwiki.org/xwiki/bin/view/Proposal/NestedLivetable Let me know what you think and if there are other ideas. Thanks, Caty

9 years

[xwiki-devs] [Brainstorming] Is the Refactoring module a core module?

by vincent＠massol.net

Hi, Right now almost all func tests fail to delete pages when they do getUtil().deletePage(…). They fail with: Caused by: org.xwiki.component.manager.ComponentLookupException: Can't find descriptor for the component [role = [interface org.xwiki.job.Job] hint = [delete]] The reason is that since XWIKI-12268 the Delete action cannot work if the Refactoring module isn't bundled, which makes the Refactoring module a core module. And this module is not part of the core modules ATM. I’ve added it to the PackageMojo for now but we need to decide what to do. Personally I’ve always viewed Refactoring as optional and advanced features. I don’t consider basic delete, basic copy and basic rename/move as refactoring options. However there are some parts of them that are refactorings. For example when Renaming, also check for wiki pages having the renamed page as parent and updating them or updating wiki links in pages. So we need to decide if: * We consider the Refactoring module as core. * Introduce a new module and move some of the core actions such as delete, move, etc to it and keep the refactoring module for non-core refactoring * Split the refactoring into basic refactorings and advanced ones. Have basic delete, copy, rename + advanced options for them separately * Others? WDYT? Still hesitating on my side. Thanks -Vincent

9 years

[xwiki-devs] [ANN] XWiki 6.4.5 released

by Ecaterina Moraru (Valica)

The XWiki development team is proud to announce the availability of XWiki 6.4.5. This is a stabilization release that fixes important bugs discovered in the 6.4.4 version. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki645 The following people have contributed code to this release: Anca Luca Denis Gervalle Ecaterina Moraru (Valica) Eduard Moraru Guillaume Delhumeau Jean SIMARD Manuel Smeria Marius Dumitru Florea Thomas Mortagne Vincent Massol Thanks for your support -The XWiki dev team

9 years

[xwiki-devs] [Iteration][UX] Nested: Tree Location

by Ecaterina Moraru (Valica)

Hi devs, By default our Tree is localized in AllDocs. This iteration investigates additional ways to access the current's page position in the hierarchy. http://design.xwiki.org/xwiki/bin/view/Proposal/NestedTreeLocation Thanks, Caty

9 years

[xwiki-devs] [VOTE] Make the Wiki API + Script modules be core modules

by vincent＠massol.net

Hi devs, Problem: * We have several ways of getting the main wiki id and the current wiki id: ** way 1: $services.wiki.mainWikiId and $services.wiki.currentWikiId ** way 2: $xcontext.getMainWikiName() and $context.getDatabase() * In menu_macros.vm we set: #set ($mainWikiId = $services.wiki.mainWikiId) ** This is used in some other templates such as drawer.vm: #set ($hasHomeWikiAdmin = $xwiki.hasAccessLevel('admin', $xcontext.user, "${mainWikiId}:XWiki.XWikiPreferences”)) ** This means that currently is a module doesn’t declare a dependency on the wiki module, its functional tests will fail with: 15:29:29.868 [Thread-13] ERROR o.x.t.i.XWikiLogOutputStream - 2015-08-31 15:29:29,868 [http://localhost:8080/xwiki/bin/register/XWiki/Register] WARN o.h.u.JDBCExceptionReporter - SQL Error: -4850, SQLState: 3F000 15:29:29.869 [Thread-13] ERROR o.x.t.i.XWikiLogOutputStream - 2015-08-31 15:29:29,868 [http://localhost:8080/xwiki/bin/register/XWiki/Register] ERROR o.h.u.JDBCExceptionReporter - invalid schema name: ${MAINWIKIID} 15:29:29.884 [Thread-13] ERROR o.x.t.i.XWikiLogOutputStream - 2015-08-31 15:29:29,883 [http://localhost:8080/xwiki/bin/register/XWiki/Register] ERROR .a.DefaultAuthorizationManager - Failed to load rights for user [Public] on [${mainWikiId}:XWiki.XWikiPreferences]. Solution: * Make the Wiki API Module and the Wiki Script Module a core API (ie the most minimal version of XWiki cannot work without them) Actions to take: * Add a dep on these 2 modules in PackagerMojo.java * Deprecate $xcontext.getMainWikiName() and $context.getDatabase() and favor using $services.wiki.mainWikiId and $services.wiki.currentWikiId (once we finish adjusting all places, move xcontext.getMainWikiName() and context.getDatabase to the oldcore legacy module). * Remove all the checks we do to check for the availability of the wiki script service. For example: admin.vm: #if ("$!services.wiki" != '' && $services.wiki.currentWikiId != $services.wiki.mainWikiId) Activity.xml: #if ("$!services.wiki" != '' && $services.wiki.mainWikiId == $services.wiki.currentWikiId) menuview.vm: #set ($isWikiAPIAvailable = ("!$services.wiki" != '') && ("!$services.wiki.user" != '')) CreateWiki.xml: #if ($services.wiki && $services.wiki.creationjob) WDYT? Thanks -Vincent

9 years

[xwiki-devs] [Proposal] Consider Wiki Syntax to be advanced and working in the Nested Spaces paradigm

by vincent＠massol.net

Hi devs, I had created JIRA issue http://jira.xwiki.org/browse/XWIKI-12304 entitled "Make wanted wiki links create Nested Documents” but I’ve brainstormed with Edy and we don’t agree about it anymore :) We’d like to propose that when the user edits a document using the wiki editor then he’s using the Nested Spaces paradigm (and thus uses “WebHome” to create links to Space homes) and when he edits using the WYSIWYG editor he uses the Nested Document paradigm (no Space concept, only create WebHome documents unless he’s an advanced user). The rationale for this is that a lot of macros accept a reference parameter and I don’t think we should change them to support hiding “WebHome” and do an automatic redirect. That would be too complex. In addition, if you use a script macro, then you’ll also see WebHome mentions. Note that when editing a macro in WYSIWYG editor we’ll need to have a macro parameter displayer for Reference-type parameters to display a tree, so that the non-technical doesn’t have to enter “WebHome”. WDYT? Thanks -Vincent

9 years

[xwiki-devs] [ANN] XWiki 7.2 Milestone 3 released

by Marius Dumitru Florea

The XWiki development team is proud to announce the availability of XWiki 7.2 Milestone 3. This milestone release brings more changes to the Flamingo Skin in order to support Nested Documents. The top menu has been replaced by a drawer and the create, copy, rename and delete page actions have been revamped. This release also fixes some Watch List issues related to Nested Documents and provides a new configuration option for the LDAP module. The developers should check out the new job-related REST resources and the support for skins in Nested Spaces. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki72M3 The following people have contributed code to this release: Clemens Robbenhaar Ecaterina Moraru (Valica) Eduard Moraru Gabriela Smeria Guillaume Delhumeau Jean SIMARD Marius Dumitru Florea Sergiu Dumitriu Thomas Mortagne veronikaslc Vincent Massol Thanks for your support -The XWiki dev team

9 years

[xwiki-devs] $showannotations, messy....

by vincent＠massol.net

Hi, Some analysis that took me time so I’m putting it here in case it helps someone and for us to consider changing the way this velocity parameter works. Problem: I was moving the Annotation functional test from enterprise to platform and the test was failing because there are 2 Annotations entries displayed in the More Actions menu and the PageObjects picks the first one (the wrong one). This doesn’t show in XE, nor in an empty wiki. Cause: * If you’re in XE, then we provide a custom XWikiPreferences which has showannotations set to false. Thus Comments and Annotations are merged * If you’re in an empty wiki, then there’s no XWikiPreferences but there’s also no AnnotationConfig page and thus this code in xwikivars.vm sets showannotations to false: #retrieveSetting('showannotations' $settingValue) #set ($showannotations = $settingValue) #if ($showannotations) ## The general settings allow displaying the tab #set ($showannotations = false) #if ($xwiki.exists('AnnotationCode.AnnotationConfig')) #set ($annotationConfigObject = $xwiki.getDocument('AnnotationCode.AnnotationConfig').getObject('AnnotationCode.AnnotationConfig')) #if ($annotationConfigObject.getProperty('activated').value != 0 && !$annotationConfigObject.getProperty('exceptionSpaces').value.contains($doc.space)) #set ($showannotations = true) #set ($annotationClass = $annotationConfigObject.getProperty('annotationClass').value) #set ($annotationCount = $doc.getObjects($annotationClass).size()) #end #end #end * If you’re in the functional test of the annotation module. You don’t have XWikiPreferences but you do have an AnnotationConfig object and thus showannotations = true, thus displaying the 2 tabs: both the Comments tab and the Annotation tab. Am I the only one to believe that Comments and Annotations should be merged by default, ie that by default showannotations = false without having to override it in XWikiPreferences? I guess we did this for backward compatibility? Can you imagine what problem we would have if we changed the default now? Thanks -Vincent

9 years

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs September 2015