20 Sep
2012
20 Sep
'12
11:12 a.m.
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 <haru_mamburu(a)mail.ru>ru>:
Hi, Andreas,
See below,
Tue, 18 Sep 2012 15:36:15 +0200 от Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>:
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.
>> 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
<vincent(a)massol.net>et>:
>>
>>
>>
>
>
>>
>
>
>
>>> 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
> users(a)xwiki.org
>
http://lists.xwiki.org/mailman/listinfo/users
--
Thomas Mortagne
Thank you for good news and excellent
work.
Kind regards,
Dmitry
_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
On Tue, Sep 18, 2012 at 2:20 PM, Vincent Massol
<vincent(a)massol.net> wrote:
Hi Dmitry,
Thanks for your inputs! See below.
On Sep 18, 2012, at 2:10 PM, Dmitry Bakbardin <haru_mamburu(a)mail.ru> wrote:
Andreas too ;)
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.
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.