- xwiki-devs@xwiki.org - lists.xwiki.org

[xwiki-devs] [ANN] XWebIDE - Working prototype of Application Development Environment in XWiki !
by Caleb James DeLisle 02 Jul '15

02 Jul '15

Hi guys and gals, XWiki Labs is proud to present an early (but working!) prototype of an Application Development Environment in XWiki. I want to put out a big congradulations to the Labs team's most recent member Yann Flory for making this great work possible in record time. We went to great lengths to avoid "nice features" such as syntax highlighting and autocompletion which are likely sources of bugs so that we could provide a basic workflow which is stable enough to provide you something you can start using today. You can install XWebIDE right now from http://extensions.xwiki.org/xwiki/bin/view/Extension/XWebIDE+Application or by searching for "XWebIDE" on the Extension Manager. If you're developing extensions or projects on top of XWiki, start playing with XWebIDE and tell us what you think. If you have ideas for better workflows and user experiences, we want to hear it! * Should it be integrated in App Within Minutes? If so, how? * How would you want to create a project? Should there be a wizard? What steps? * What else would you like this to allow you to do? You can write your feedback ideas and report bugs on JIRA at http://jira.xwiki.org/browse/XWEBIDE or write to me. Thanks, Caleb -- Caleb James DeLisle XWiki SAS calebjamesdelisle(a)xwiki.com irc.freenode cjd 9:00-18:00 GMT+1 http://bit.ly/1suU0Lh Satire is the escape hatch from the cycle of sorrow, hatred and violence. #JeSuisCharlie -- Satire is the escape hatch from the cycle of sorrow, hatred and violence. #JeSuisCharlie

2 1

[xwiki-devs] [Contrib] Request repository for "XWebIDE" application
by Yann Flory 02 Jul '15

02 Jul '15

Hello devs, I'd like a repository on xwiki-contrib and a Jira project for a XWebIDE Application. This application provides an IDE for XWiki which allows users to group pages and spaces in a project. They can then easily navigate between pages and edit them with wiki, object and class editors. It is already available for download at http://extensions.xwiki.org/xwiki/bin/view/Extension/XWebIDE+Application Name of the repo: application-webide Thanks, Yann

2 2

[xwiki-devs] What do we do with space and page templates in ND?
by Eduard Moraru 01 Jul '15

01 Jul '15

Hi, Now that we are moving to Nested Documents, there is the question of what do we do with the existing space and page templates[1]? How do we (still) display them? In the new create UI we will be showing just the option to create a Nested Document, but for advanced users, we might also show the option to create a terminal document (NS-style i.e. document in a space). Since a ND translates to a space WebHome in the NS approach (or previous approach), we could reuse any existing space templates and display them instead of page templates. Existing page templates were built with the NS approach in mind and I am concerned that, until the app that provides them does not migrate them to space templates (i.e. ND-compatible), we risk breaking their functionality (?). This might now be valid for page templates manually created by the admins that might have no issues since they are content focused and not processed by any application. Until they are migrated, we could just show page templates only when creating terminal documents, as an advanced user. So the options I see are: 1) Show both space and page templates when creating ND and only page templates when creating terminal pages, hoping most of them will work most of the time. 2) Show only space templates when creating ND and only page templates when creating terminal pages, but risk hiding a lot of useful page templates from regular users which would work most of the time. My +1 goes to 1). WDYT? Thanks, Eduard ---------- [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Administration+Applica…

6 5

[xwiki-devs] [VOTE] Summary: NS, ND, Parent/Child
by Ecaterina Moraru (Valica) 01 Jul '15

01 Jul '15

Hi devs, So after discussing the topic of Nested in several mails, we need to reach a conclusion in order to start implementing. There are several open questions that I will summarize. Please cast your votes in order to advance on some topics and maybe discover what we still need to agree on. Q0. **Nested Spaces in model** No matter the UI decisions we still need to take, we are implementing Nested Spaces for 7.2 roadmap. The future is still uncertain regarding changing the model to accommodate Nested Documents, since we can simulate ND using NS. Q1. **NS vs ND in the UI** Q1.1 The majority agreed that since the final purpose are ND, we should display ND in the UI, since it simplifies the mental model of the user. This implies removing the Space concept from the UI. Q1.1.1 A consequence is hiding the 'WebHome' name in the UI. Q1.2 Although the default should be ND, the question is if we want to give the option to display NS in the UI. This would be implemented as an advanced and technical option. The main problem is that we might need to provide UI alternatives for several components (menus, create step, etc.) Q2. **Parent/Child** Q2.1 Deprecate the notion of Parent/Child. Q2.1.1 Provide a migration to transform the relation into NS/ND. Problem: the old URLs[A] (bookmarks) are broken + the user is stuck with long URLs[B] if he wants to keep the hierarchy. Additionally we might need to provide an extension/configuration to transform into short URLs [B -> C]. Q2.1.2 Don't migrate: the parent/child hierarchy will be lost but the old URLs[A] (bookmarks) will be kept. The user needs to use NS/ND to create hierarchies. Q2.2 Don't deprecate the notion of Parent/Child. Q2.2.1 Provide a configuration in the Administration to switch the breadcrumbs between displaying Parent/Child or NS/ND. We might need to provide UI alternatives for several components (tree, breadcrumb navigation, create, etc.) Please cast your votes / add comments. Thank you, Caty

8 21

[xwiki-devs] XWiki's architecture diagram
by Ghosh, Amrita 25 Jun '15

25 Jun '15

Is there any XWiki's detailed architecture diagram documented somewhere? If yes, then can you please point me to this document? Thanks, Amrita

2 2

[xwiki-devs] [Proposal] Object addition/removal/update shouldn't change content author
by Vincent Massol 23 Jun '15

23 Jun '15

Hi, According to the javadoc in XWikiDocument: /** * The last user that has changed the document's content (ie not object, attachments). The Content author is only * changed when the document content changes. Note that Content Author is used to check programming rights on a * document and this is the reason we need to know the last author who's modified the content since programming * rights depend on this. */ private DocumentReference contentAuthorReference; This means that objectadd or objectremove actions shouldn't change the content author as they do now. I'm proposing that we fix this. Do you see any issue? Thanks -Vincent

7 11

[xwiki-devs] [Feedback Request] New 'script' right
by Eduard Moraru 23 Jun '15

23 Jun '15

Hi, For 7.2, we are introducing a new right to control permissions on the execution of scripts. Right now, out of all the scripts we support, Velocity is special and does not require programming rights, since it uses only the public API. Of course, if it has PR available, it can also access privileged API. All other scripts (groovy, python, etc) require PR by default. The new 'script' right should be used to control "light"/sandboxed scripting, such as velocity or any other scripts that are configured to consider this new right when executing (assuming they override the standard PR check). Since the build is not in top shape due to the nested spaces changes, I have currently committed my work on this in a branch, created a PR and would like to profit from this occasion to ask the devs that are more familiar with the rights system for some feedback on it. The Jira issue is http://jira.xwiki.org/browse/XWIKI-12171 The PR is https://github.com/xwiki/xwiki-platform/pull/410 Thanks, Eduard

2 6

[xwiki-devs] [Proposal] Next week, remove DocumentReference constructor accepting a single space (aka breaking the build!)
by vincent＠massol.net 22 Jun '15

22 Jun '15

Hi devs, Following http://markmail.org/message/sfqing2nnvk2lhqg I’d like to propose that starting on the 29 we do the following: * Move the DocumentReference constructors and Script Services accepting a single space to legacy (using Aspects) * Update RN for 7.2M1 to indicate that extensions depending on 7.2M1+ need to either update their code or depend on the legacy modules * All work together to fix the build which will be broken to fix the 1500 occurrences or so (a lot of them are tests) * At the same time update the tests to always test using more than 1 space since testing for 2 spaces will make sure the code supports nested spaces (this is not true when testing with a single space). * Whenever it’s too difficult to fix the code right away to support NS, pass a single space (but using the "List<String> spaces” constructor signature) BUT create a JIRA issue to remember to fix the issue. The idea is that there will be build chaos for the week of the 29th but that we take the week to stabilize the build, all together. I believe this would help us get faster to supporting NS. WDYT? Too bold or ok? :) Thanks -Vincent

2 1

[xwiki-devs] Fwd: [Proposal] Introduce the notion of Nested Documents
by Denis Gervalle 22 Jun '15

22 Jun '15

** BE CAREFUL, REPLYING VINCENT MAIL WITHOUT TRUNCATING HISTORY CAUSE MAILMAN TO REJECT YOUR ANSWER ** I hope this forward will not cause disruption in the mail thread. On Thu, Jun 18, 2015 at 12:33 PM, vincent(a)massol.net <vincent(a)massol.net> wrote: > So we really need to start deciding what will be the differences from a > user POV about the “Nested Spaces” view and the “Nested Documents” view. > > There are 2 possibilities I can think ok. > > Assumptions: > - In both cases we assume that by default XE is in “Nested Documents” view > when you install it and that going to the “Nested Spaces” view is an > advanced and technical option. > - In both cases we implement the hiding of WebHome everywhere in the UI by > assimilating WebHome and the Space it’s in. > Well, if we can assume that WebHome and space are the exact same thing, NS became really a edge case. > > Option 1 > ======== > > Concept: We clearly show the differences between Spaces and Documents in > the UI > > * Have an checkbox option in the user profile that is named something like > “Show the Space concept” > * Everywhere in the UI where we display spaces (and there are lots of > places), we display them differently than documents. Some examples: > ** In the Document Tree the icon used to display spaces is different than > the one used to display documents > ** In the Index application we would need to either have 2 tabs: one for > Documents and one for Spaces or a single one but in this case the Livetable > column should be named “Document and Spaces” and both entities should be > displayed differently (I’m assuming we want a single column, see T13 at > http://design.xwiki.org/xwiki/bin/view/Proposal/NestedSpaces#HOriginallisto… > ) > ** The Add button would list 2 actions: Add > Page and Add > Space > ** In the Main Wiki administration UI we have a “Select Space to > Administer” label to choose the space to administer > ** In the Add Page UI we ask the user to select both the document name and > the space in which it’s located > ** We can keep the “Space List” on the home page’s dashboard > > Option 2 > ======== > > Concept: We show Spaces and Documents as similarly as possible in the UI > to have the same UI as much as possible between “Nested Spaces” and “Nested > Documents”. > > * In the user profile, we would have a checkbox option named something > like “Ability to create several Documents in the same Space” > * Everywhere in the UI we don’t differentiate Spaces and Documents. The > same examples as above would become: > When you are in NS or ND mode, you still have an issue regarding existing document that are not WebHome. This is not really a matter of showing them the same or differently, but more of showing them or not. ** In the Document Tree we use the same icon (a node icon) to display > either spaces or documents -1, since here Document are not all document that could have childs. So, if I take your word about assumptions, there should be no difference with option one in term of icons. The difference could be that for ND, those documents that are not Webhome are simply not shown by default. > ** In the Index Application, we have a single Document tab and in the > Livetable column is named “Location” (or “Document Names”) and the > reference is displayed but without showing different icons for Spaces or > Documents. > Exact same effect here, even with ND, we still need to distinct those WebHome from simple documents. > ** The Add > Space menu entry could be removed and only an Add > Page > entry would stay but when you click on it, you’d still have the ability to > create new Spaces. Basically we ask the user to select both the document > name and the space in which it’s located > This is probably fine, and a good simplification of the UI. > ** We replace the “Space List” on the home page’s dashboard by a “Document > List” widget (showing both spaces and pages). > Fine, but again, in either mode, we need ways to distinct WebHome and simple documents. And again, the visibility of simple documents in ND mode should probably be hidden by default. > > In summary, option 2 reduces the difference between Nested Documents and > Nested Spaces to the Add > Page UI. > > Pros/Cons > ========= > > * Option 1: > ** Strong difference between Space/Documents in the UI > ** Hard to implement: lots of places need to have different behavior > depending on whether the user profile option is turned on or off > ** Existing extensions don’t need to be modified to feel natural if you’re > in the “Nested Spaces” mode. However note that since we want to have Nested > Documents by default these extensions must be updated ASAP anyway to > reflect that. > * Option 2: > ** Smaller difference between Space/Document in the UI > ** Easy to implement since the only UI > ** Existing extensions may not feel natural (until they’re updated for > Nested Documents but we need to do that anyway) > > WDYT? I’m worried that Option 1 is going to be costly to develop and > maintain. > I agree, we should think as much as possible in a way that makes development as sharable as possible between the two mode. Once, again, in either mode, we will need to support both type of documents (WebHome vs other documents), and it will require them to be clearly identifiable IMO. > Anca, since you were the one who raised this idea of keeping both “Nested > Spaces” and “Nested Documents” in the UI, what’s your POV? > > Thanks > -Vincent > > > -- Denis Gervalle SOFTEC sa - CEO

3 2

[xwiki-devs] [Contrib] Filesystem Attachment Porter
by Paul-Catalin Cojan 19 Jun '15

19 Jun '15

Hello devs! I did some customization on http://extensions.xwiki.org/xwiki/bin/view/Extension/Filesystem+Attachment+… and I want to put them on github. Can we have a repository for it? The name can be: filesystem-attachment-porter or if you have any suggestion. Thank you!

1 0