xwiki-devs October 2011

xwiki-devs@xwiki.org

29 participants
64 discussions

[xwiki-devs] [UX][Consistency][Vote] "Page" vs. "Document" consistent naming

by Ecaterina Moraru (Valica)

Hi, We are using mixed naming when referring to a document/page, not only on different pages, but also in the same context (Rename step for example). There is also an issue referring to this problem XWIKI-5401<http://jira.xwiki.org/jira/browse/XWIKI-5401>and we need to find an answer in order to move forward consistency. So the question is which version we prefer: "Page" or "Document" ? I'm voting +1 for "Page". "Page" is more used IMO, especially in the "Space"/"Page" context. "Page" is more general than "Document" and better fitted for a platform that encapsulates all kind of content (not just documents). Please cast your vote. Thanks, Caty

9 years, 2 months

[xwiki-devs] Questions about fixing getRenderedContent() bug

by Vincent Massol

Hi, Im trying to fix http://jira.xwiki.org/jira/browse/XWIKI-4274 Basically if you do $xwiki.getDocument("someDoc").getRenderedContent() it'll get executed in the context of the current doc which I believe is wrong especially since other signatures of getRenderedContent() execute in the target document's context. I have fixed this locally but found that admin.vm for example is assuming that getRenderedContent() will get executed in the context of the calling doc (i.e. XWiki.Import when doing an import for example). FYI the chain flow is admin.vm -- getRenderedContent() --> XWiki.AdminSheet --> XWiki.AdminImportSheet --> importinline.vm, which requires the current doc to be XWiki.Import (to get/put attachments from/to it). I can fix this easily using a new getRenderedContent signature I've introduced. However I'm wondering if we have other places that incorrectly use getRenderedContent() and assume it won't be rendered in the context of the target document. Is this change too dangerous to make? If not know, we'll need to it quickly (2.1M1?) since it's an important bug IMO. WDYT? Thanks -Vincent

9 years, 9 months

[xwiki-devs] [Proposal] Cleaning our POM deps by explicitly listing used dependencies?

by Vincent Massol

Hi devs, Running mvn dependency:dependency-analyze produces interesting results. For example: [INFO] --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- [INFO] Building XWiki Commons - Properties 3.2-SNAPSHOT [INFO] --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- … [INFO] --- maven-dependency-plugin:2.3:analyze (default-cli) @ xwiki-commons-properties --- [WARNING] Used undeclared dependencies found: [WARNING] org.slf4j:slf4j-api:jar:1.6.1:compile [WARNING] javax.inject:javax.inject:jar:1:compile [WARNING] Unused declared dependencies found: [WARNING] org.xwiki.commons:xwiki-commons-component-api:jar:3.2-SNAPSHOT:compile [WARNING] org.xwiki.commons:xwiki-commons-test:jar:3.2-SNAPSHOT:test [WARNING] org.hibernate:hibernate-validator:jar:4.2.0.Final:test [WARNING] org.hamcrest:hamcrest-core:jar:1.1:test [WARNING] org.jmock:jmock:jar:2.5.1:test The question is (for this module but more generally for all others): * Should we add slf4j and javax.inject reps in the pom.xml for this module? (for ex today slf4j and javax.inject are found in the component-api dep) I think we should, wdyt? Note that the "Unused declared dependencies found:" doesn't always generate correct results as is the case here. This is mostly because it's a static byte code check so any dep used at runtime will be considered unused. See http://www.sonatype.com/books/mvnex-book/reference/optimizing-sect-dependen… Thanks -Vincent

10 years, 5 months

[xwiki-devs] [Proposal] Finding how many active instances of XWiki there are out there

by Vincent Massol

Hi devs, I think it would be great to have some indication of how many active instances of XWiki are out there in the wild. The idea is not so much to know the figure but to see how this figures evolves and thus to see if we're doing things right. It will also give us information about how quickly or slowly our user base upgrades from version to version. Here's my proposal: * When installing XWiki on a clean DB (ie first time install) generate a unique id and store it in the DB (similar to the version we're storing in the DB but using some UUID). Thus when an install is upgraded the same id is preserved. * When the Extension Manager is used and thus connects to extensions.xwiki.org (default extension repository), this unique ID is sent too. * In addition the version of XE is sent too * On extensions.xwiki.org side, we only log the unique ID/XE version **without** logging the IP or any other information thus ensuring that the ID remains completely anonymous * We display a counter on xwiki.org about the # of active instances of XE with a graph about XE versions used WDYT? Thanks -Vincent

11 years, 2 months

[xwiki-devs] Redirect to a space

by Bruno Amaro Almeida

Hi How can i redirect the users after login to a space ? I`m looking at login.vm but i have no clue to do this Thanks

11 years, 5 months

[xwiki-devs] Pretty Time library

by Vincent Massol

Could be useful: http://ocpsoft.com/prettytime/ Idea of usage: For ex we could use that to show the last modified document dates for dates in the past week (for ex): "Document created 2 days ago" It's in the maven central repo and it's under LGPL -Vincent

12 years, 4 months

[xwiki-devs] [VOTE] Improving documentation and automating our Release Notes when doing releases

by Vincent Massol

Hi devs, Sergiu has started a script to fully automate a release (more to come - Sergiu will document what it does soon). The only part not automated are the Release Notes. IMO we can "automate" it by a process which I propose to be: * An issue can only be closed if it's documented on xwiki.org and on the release notes page for the upcoming release. * We collectively enforce this by reopening issues if someone doesn't do the first point, asking him/her to do it This will have some nice effects: * xwiki.org will be more up to date than it is now * it's up to the developer to document what they do (I don't think it's good to push this to someone else) which is good since they have the most knowledge (side note: it doesn't mean we don't need a technical writer to improve on the documentation done by developers but it would be about style and not about content) * the release notes will be ready for the release, as we progress and the burden of writing the release notes will not fall on the shoulders of the Release Manager (there's no reason it should) * the whole release process will almost be a joy to do * with a fully automated release process it means we'll be able to perform a lot more bugfix releases which is good for our users Here's my +1 Thanks -Vincent

12 years, 6 months

[xwiki-devs] [Proposal] Changes to Page Creation needed for Application Within Minutes

by Marius Dumitru Florea

Hi devs, For the upcoming Application Within Minutes I need to enhance the XWiki platform with the ability to generate the page name automatically when creating a new wiki page. For some applications it doesn't make sense to have two creation steps: (1) specify the wiki page name (i.e. the location) and then (2) edit the new wiki page with the specified name. Let me give you two examples: * It would be cool to be able to create a new blog post in a single step. The blog post name could be generated from the blog post title specified in the edit form. * An application that manages holiday requests doesn't need meaningful page names (i.e. free text, like a blog post would have) but something like Request_XYZ, where XYZ is a unique counter/identifier. These applications should be able to create new wiki pages with automatically generated names without writing their custom create forms. Since 3.2RC1 was planed for today and these changes are in the 3.2 roadmap, here's a proposal that I think I can implement quickly and safely: (1) Introduce two new components: // Used to generate a document name that doesn't have to be unique (e.g. by cleaning the document title). DocumentReferenceGenerator#generate(DocumentModelBridge):DocumentReference // Used to make a document name unique (by suffixing an unique counter/identifier) DocumentReferenceDifferentiator#differentiate(DocumentReference):DocumentReference (2) Modify editinline.vm to store "documentReferenceGenerator" and "documentReferenceDifferentiator" request parameters in two hidden input fields so that they are passed to the save action. Obviously, these are component hints. (3) Modify editactions.vm to replace "Save & View" + "Save & Continue" with "Create" when "documentReferenceGenerator" or "documentReferenceDifferentiator" (or both) request parameters are set. (4) Modify SaveAction to take into account these two request parameters (only if they are specified). Something along these lines: generateDocumentReference(doc) synchronize(lock) { doc.copyDocument(differentiate(generatedDocumentReference)).save(); } I'm not sure where to place the two components from (1) though. WDYT? Thanks, Marius

12 years, 6 months

[xwiki-devs] [VOTE] New {{display}} macro and changes to the {{include}} macro

by Vincent Massol

Hi devs, As you know in XE 3.0 we've changed the behavior for resolving local links/attachments when they're included using the {{include}} macro (they're now resolved against the included document instead of the including document). Now there might be some use cases (pretty rare IMO but they exist) where you'd want the links to be resolved against the including document. Here's a use case: you have a sheet document that references an image called image.png and you want that the including document provides it (like an Abstract in Java! ;)). So we've brainstormed with Thomas and here's our proposal: * Introduce a new {{display reference="…"/}} macro. This macro will *execute* the passed reference in its own context (it'll do what {{include context="new"…}} was doing before). It'll be located in the new display module. * Deprecate the "context" parameter of the {{include}} macro. The reason is that calling with context=new is not an include, it's a display. * Add a new "resolve" parameter for the {{include}} macro with possible values = "current" | "source", with a default value of "source". resolve=source means that the links/attachments are resolved against the source (ie the document being included). Using resolve=current means that you want the links/attachments resolved against the including document. Pros: * Clearly separate the 2 use cases: display and include * Make the include macro simple (a single "resolve" parameter) * Use the new display module as it should be and start the direction of having displayer macros for displaying all types of entities Note: In the future we'll also want to deprecate the "document" parameter of the include macro in favor of a more generic "reference" parameter, which will allow the macro to include other types of entities (such as an object property for ex). WDYT? Here's my +1 Thanks -Vincent

12 years, 10 months

[xwiki-devs] How to load GWT application on Xwiki pages?

by Leon Wang

Hi Everyone! I have read this document "Writing GWT applications in XWiki" ( http://dev.xwiki.org/xwiki/bin/view/Drafts/WritingGWTApplicationsInXWiki) And I know how to develop GWT module for xwiki now. I also have read the document "WYSIWYG Editor Module" ( http://code.xwiki.org/xwiki/bin/view/Modules/WysiwygEditorModule). I followed the instruction which tried to integrate the WYSIWYG editor(GWT application) in wiki pages, and I put the following code in my wiki editor: "{{html}} <script type="text/javascript" src="XWikiWysiwyg.js"> alert('WYSIWYG code is loaded!'); </script> <textarea id="demo"></textarea> <script type="text/javascript"> Wysiwyg.onModuleLoad(function() { new WysiwygEditor({hookId:'demo'}); alert('WYSIWYG code is loaded!'); }); Wysiwyg.onModuleLoad(function() { editor = new WysiwygEditor({hookId: 'demo'}); }); }); </script> {{/html}}" After saved, it only display a blank text area without any sign of WYSIWYG editor, also there is no alart 'WYSIWYG code is loaded!' popup. Can you help me figure it out what is wrong with it? I am planing to develop a tree view using GWT to display Design Rationale Element. Could you give me some ideas of after my development, how can I embeded the GWT application into Xwiki pages and interact with the GWT application? Thank you very much! Leon

12 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs October 2011