Hi all, My humble suggestions: * adding one point to point 8 (sub-spaces) * adding one point to point 6 (move fs storage to production-ready) * add possibility to apply some transversal organization to a wiki (not relying only on spaces or unstructured tags). Something like a merge between tags system and blogs "tree-like" categories. Could be done by adding new objects to pages, but re-using tags and structuring them could be both pertinent and avoid adding new objects for that (and adding new ui bits). (that being said, I don't know what's the state of the structured tags feature that once existed). The usual issue I have with the wiki, is that there usually isn't only one way to structure the site. When you choose one and use spaces to materialize it, you're left with tags to materialize any other transversal organization, but they're unstructured so they're not really efficient for that. BTW tags could be structured and unstructured at the same time (propose suggestions from tree-like categories and authorize free values entered by user). * improve richness and versatility of fundamuntal UI components. Already done for some (livetables, charts...) but could be improved. For example, it's not really possible to combine charts together, or to directly plug them to wiki objects (for example, say "I want a time graph of count of this xwiki object creation per month"). Livetables customization could be simplified (merging/joining json for additional columns instead of having to generate json for the whole). Defining new columns by "joining" with other classes could be easier (for example to display a "Tag" column, which is a different use-case than the tag cloud). Components needing a data source could have some common way of providing the data source (ie, from xwiki classes+fields or from json, as for livetable and fullcalendar app). It should be possible to provide a "type" for macros parameters (as if they were fields from classes, ie lists, strings, numbers...) and to display fields accordingly when inserting a macro from wysiwyg. Etc ...
A bit of a mixed-bag, but the idea overall could be something like "enrich existing concepts". Br, Jeremie 2012/9/18 Dmitry Bakbardin <[email protected]>: > Hi, Andreas, > > See below, > > > Tue, 18 Sep 2012 15:36:15 +0200 от Thomas Mortagne > <[email protected]>: >>On Tue, Sep 18, 2012 at 2:20 PM, Vincent Massol <[email protected]> wrote: >> >> Hi Dmitry, >> >> >> >> Thanks for your inputs! See below. >> >> >> >> On Sep 18, 2012, at 2:10 PM, Dmitry Bakbardin <[email protected]> wrote: >> >> >> >>> Hi, Vincent, >> >>> >> >>> My 10 coins to the suggested topic :-) >> >>> >> >>> 1. New Access Rights management system. There are a lot of weak points >>> already known. Probably, it's time to review this. >> >> >> >> Have you been able to play with it already? Would be great to provide >> feedback and details. I'm sure Denis would love some feedback. >> >> > Andreas too ;) >> >> > Do you actually know there is a new right management system ? It's not >> > clear in your question if you talk about introducing a new right >> > management system or using more the new one.I mean situations like > http://jira.xwiki.org/browse/XWIKI-2184 and > http://jira.xwiki.org/browse/XWIKI-6987 > > Probably I missed something in the roadmap and release notes, but I didn't > see it fixed. And these reports were not the only "bugs" found as far as I > remember mailing lists conversations. All of them required brand new system > and Vincent said, that these changes are planned after comprehensive > discussion and voting in futher releases. So, I mean BRAND NEW system that > acts as expected, e.g. user with edit rights is in the "god mode" as to the > page. I expect edit rights means edit page, but not access rights change. > Access rights looks more admin function. And so on. IMHO it worth discussion. > > >> >> >> >> >>> 2. Second level XWiki virtualization http://jira.xwiki.org/browse/XEM-207 >> >>> >> >>> 3. Add WYSIWYG's editor logic while adding the link Space -> Page -> Anchor >>> on the page http://jira.xwiki.org/browse/XWIKI-4084 >> >>> >> >>> and the same in XEM Environment: Workspace/Virtual Wiki -> Space -> Page -> >>> Anchor >> >>> http://jira.xwiki.org/browse/XWIKI-7483 >> >>> >> >>> 4. WebDAV access to deleted attachments >>> http://jira.xwiki.org/browse/XWIKI-6989 >> >> >> >> So you're using XWiki WebDAV feature ATM? >> >> >> >>> 5. Rebuild Translation System and add possibility to translate not only >>> page content, but objects' content (and field names) also. >> >> >> >> Just on this point, we're planning to work on this in XE 4.3 in the coming >> month. >> >> > Except for the object content translation part which has more to do >> > with the model and is not going to change very soon. Note that fields >> > names are already translatable, for this you can use the id <class >> > full name>_<field name> like in "Blog.BlogClass_title" for the title >> > field name of a blog object. >>Looks disaster for me :-) > > Let's overview simple usecase: > > - I buld FAQ (or something like it) in English with Application within minutes > > - I want to make it multilingual. Looks like I'm stuck by default: "not going > to change very soon" :-( > > - I see the only "human-friendly" option to modify default scripting, produce > templates for each language, then build pages like <PageName>_<Language> and > load required page depending on requested language. I didn't make it like > this yet, but if it is "not going to change very soon", I'd consider this way > as an option to make application running in multilanguage environment. I > understand, that this is not the best solution, but as far as I understand > XWiki - it should work. > > >> >> >> >>> 6. Evolve filestorage system from "experimental" to >>> all-kind-production-ready and make it more or less comprehensive: >> >>> - for example, add possibility of XWiki clustering and automatic >>> attachments synchronization while FS is on. >> >>> - to configure path to store attachments for each XWiki/virtual >>> wiki/workspace/space separetly. >> >>> - fix current bugs (like http://jira.xwiki.org/browse/XWIKI-6917) and >>> probably add some other fatures :-) >> >> >> >> Yeah I also think we need Caleb to work a bit on this so that we could call >> it production-ready ;) >> >> >> >>> 7. Smooth upgrade system (to make it look more like linux upgrades): >>> upgrade AND KEEP all XWiki customization with minimal manual config files >>> comparison and reediting of customized pages inside XWiki. >> >> >> >> Yep, we're working on this one (XAR upgrades). You should see some first >> version with XE 4.2 when it's released next week. Next step is to tackle WAR >> and config file upgrades indeed. >> >> > Note that for the server side (WAR and configuration) you have the >> > Debian package (see >>http://platform.xwiki.org/xwiki/bin/view/AdminGuide/InstallationViaAPT) >> > that can help a lot since apt/dpkg is taking care of configuration >> > file comparison/merging. But that's only for Debian based system of >> > course. >> >> > For the XAR part as Vincent said we are working on it and you get a >> > first version of an install/upgrade Wyzard for it in the coming 4.2.Thanks a > lot. I was going to set up new server soon. Migration to Debian looks fine > for me in this case. :-) > Looking forward to 4.2. It would be "admin-rescue" release :-)))) > > >> >> >> >> >>> 8. Add Space -> Subspace -> Page logic to XWiki hierarchy to build "trees" >>> instead of "horizontal" set of spaces. >> >>> >> >>> 9. Extend TOC macro to logic: ...wiki1:Space1.Page1, >>> wiki2:Space2.Page2... to include TOCs of separate pages inside current TOC. >> >>> >> >>> 10. XWiki Native support for mobile users (Skins, ColorThemes for all kind >>> of mobile users bundled with XE/XEM) >> >> >> >> Ludovic has a pull request for improving mobile skin support for XE 4.3 but >> probably not to the extent you're interesting in at the moment. >> >> >> >> Thanks, keep the ideas coming. No promise that they'll be implemented but >> the more people who want the same thing the more weight it has. And >> developers are reading this! >> >> -Vincent >> >> >> >>> Hope it helps :-) >> >>> >> >>> Kind Regards, >> >>> >> >>> Dmitry >> >>> >> >>> >> >>> Tue, 18 Sep 2012 08:58:04 +0200 от Vincent Massol <[email protected]>: >> >>>> >> >>>> >> >>>> >> >>> >> >>> >> >>>> >> >>> >> >>> >> >>> >> >>>> Dear XWiki lovers ;), >> >>>> >> >>>> >> >>> We're getting close to the end of the 4.x cycle which is about to be >>> finished with XWiki 4.5 around end of January and we need to start >>> brainstorming about the 5.x cycle (1 year duration from Feb 2013 to Jan >>> 2014). >> >>>> >> >>>> >> >>> * 3.x was about "Building Apps and Distributing them" (priority 1) and >>> "Polishing" >> >>>> >> >>> * 4.x was about "Ease of use" (priority 1) and "Quality" >> >>>> >> >>>> >> >>> So what would you like to see in the coming year? >> >>>> >> >>>> >> >>> You can suggest both general themes and specific items. >> >>>> >> >>>> >> >>> Thanks >> >>>> >> >>> -Vincent >> >>>> >> >>>> >> >>> >> >>> >> >>> >> >>> >> >>> Kind regards, >> >>> >> >>> Dmitry >> >>> WebDAV access to deleted attachments >> >> >> >> _______________________________________________ >> >> users mailing list >> >> [email protected] >> >> http://lists.xwiki.org/mailman/listinfo/users >> >> >> >> > -- >> > Thomas Mortagne >> > Thank you for good news and excellent work. > > > Kind regards, > > Dmitry > _______________________________________________ > users mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/users _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
