Hi devs,
I just committed a prototype of the class editor that will be used by
the Application Within Minutes. If you want to try it out, you can
either checkout the feature-applicationWithinMinutes platform branch
(see https://github.com/xwiki/xwiki-platform/tree/feature-applicationWithinMinut…
) and build the latest XAR by yourself or you can download the
snapshot I put at http://ubuntuone.com/5dPv28OKz1p3ysY2ypjzrZ . It
requires XWiki Enterprise 3.2+ . Follow this steps after you import
the XAR:
* choose an existing class or any document if you want to create a new class
* add an object of type XWiki.DocumentSheetBinding and set the sheet
property to ApplicationWithinMinutes.ClassEditSheet
* edit the class/document in "Inline form" edit mode (simply click on
the Edit button)
Notes:
* I only tested the editor on Firefox for now but it should work on
other browsers too
* The "hint" and "required" meta properties are not saved yet. I
included them on the prototype just to show you the direction I'm
going in.
A few words about the design:
The class editor is an edit sheet for XWiki documents holding class
definitions. The editor supports only property types described by
FormFieldClass, which are grouped by FormFieldCategoryClass. For
instance ApplicationWithinMinutes.TextArea has an object of type
FormFieldClass which specifies the field icon, category and the list
of meta (configuration) properties that should be displayed. Moreover,
ApplicationWithinMinutes.TextArea holds a class definition with a
single TextArea field that serves as a template for all TextArea
fields added through the class editor. The class editor can store the
default field values in the class template and can generate a basic
class sheet (binding included).
Open questions and limitations:
(1) The editor relies heavily on JavaScript. If we're going to replace
the current class editor with the one used by the Application Within
Minutes then we need to decide if it needs to work without JavaScript.
(2) The editor doesn't save intermediary changes (like the current
editor does when you add a new field or when you delete a field). All
changes are saved when you hit Save.
(3) I don't think the Preview button is really needed because the edit
form already offers a preview of how the sheet will look like
(4) The problem with the Save & Continue button is this: the action
servlet filter forwards the request based on the action_* request
parameter. In order to prevent this (because I want to handle the
submit by myself) I renamed the submit buttons to xaction_* but
actionbuttons.js looks explicitly for action_saveandcontinue submit
button, and since it doesn't find it, it doesn't include it in the
POST request parameters, so I don't know the request is a Save &
Continue request.
(5) Because I process the submit myself (i.e. the form action is '') I
need to find a good way to handle errors so that the user doesn't
loose unsaved changes due to an invalid value (e.g. invalid field
name).
(6) Although the UI allows it, you can't really swap the names of two
fields (e.g. rename 'title' to 'description' and 'description' to
'title').
I'm waiting your feedback.
Thanks,
Marius
Hi devs,
I'd like to propose Andreas Jonsson as a XWiki Core committer. Andreas has been around for a long time now and has tackled complex topics such as Rights rewriting and he deserves our admiration for that! ;)
He's been regularly submitting patches and I'd love to see Andreas contribute even more and would like to encourage him to do so.
Here's his CV:
http://kreablo.se:8080/x/bin/view/Ext/Andreas+Jonssons+CV?language=en
His contributions to XWiki are:
* The Swedish translation
* Parser work (he's a committer on Wikimodel)
* An alternative right service implementation
I say: Let him commit his own patches!
Here's my +1
Thanks
-Vincent
Hi devs,
We're getting closer to the end of the 3.x cycle (see http://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices). We still have to release 3.3, 3.4 and 3.5.
Here are some proposals. Please review them and let me know what you think.
== About the 3.x cycle ==
* We should not include any new major features in the remainder of the 3.x Cycle. Let's just finish what we started so that it can be used: Extension Manager, App Within Minute
* A Cycle is supposed to last 6 releases, i.e. till 3.5 and it supposed to last about 1 year. We're getting close to the 1 year mark. As a consequence I'd like to propose that the next 3 releases (3.3, 3.4 and 3.5) are short stabilization/polishing releases where we finish what we started (no new important features - there could be some minor features possibly if really needed).
* In order to fit in the 1 year timeframe we should make the next 3 releases short releases around 1 to 1.5 month each. Since 3.2 final has been released Mid-october that will lead us to February. I'm proposing:
** XE 3.3M1 (2 weeks)
** XE 3.3M2 (2 weeks)
** XE 3.3RC1 (1 week)
** XE 3.3 Final (1 week)
** XE 3.4RC1 (2 weeks)
** XE 3.4 Final (1 week)
** XE 3.5RC1 (2 weeks)
** XE 3.5 Final (1 week)
Note: the reason for 3.3 being longer than 3.4 and 3.5 is because we need to write the UI for the extension manager.
== About 3.3 specifically ==
=== Date proposal:
* XE 3.3M1 (2 weeks) - 31 October
* XE 3.3M2 (2 weeks) - 14 November
* XE 3.3RC1 (1 week) - 21 November
* XE 3.3 Final (1 week) - 28 November
=== Roadmap proposal
Important tasks:
* UI for extension manager - Sergiu (with help from Thomas on EM backend to fix bugs/issues/improvements)
* Convert extensions.xwiki.org to a XWiki Repository - Thomas
* App Within minutes UI - Marius
* New auto title/page name feature (prerequisite for App Within Minute) - Marius
* XEM and Workspaces as extensions of XE - Eduard (w/ Thomas help)
* Stats module improvements - Fabio (could be committed as an extension on extensions.xwiki.org in a first instance)
* LDAP Admin UI - Jerome
Nice to have:
If anyone is interested in working on one of those please let us know (you don't have to be a committer, you can be a contributor and create a github pull request for merging it).
Backend stuff:
* Change stylesheet and javascript extension filename when a modification is done on those - XWIKI-6073
* Be able to delete a space from the UI - XWIKI-6687
* Use a predefined Space Template like Dashboard, Livetable when creating a new space - XWIKI-6684
* LDAP group sync need to test group membership before adding user to group - XWIKI-7063
* Group LDAP sync needs to be synchronized - XWIKI-7064
* Auto-create Space.WebHome when creating a page in an underfined space - XWIKI-5399
* Page creation date should be the date of the installation - XWIKI-7058
* Be able to rename a space from the UI - XWIKI-6722
* Renaming a page should also rename the title of it - XWIKI-6743
* Performance of blog category panel is still not enough - XABLOG-119
* Problems displaying the correct attachment version when using a proxy - XWIKI-6569
Frontend stuff:
* Cannot filter using "/" on a Date column in the livetable - XWIKI-5889
* Cannot access the object editor for documents with XWikiRights objects on wikis with many users - XE-1015
* Occasionally the livetable fails to load on index pages - XE-844
* AJAX tables do not always load when first hitting them - XE-893
* New floating action menu hides titles in the content of the page when jumping to an anchor - XE-795
* Add more/all configuration parameters in the wiki administration - XWIKI-7066
* Unable to add users to a group on IE9 - XWIKI-7061
* Strange behaviour when pressing back and forward on a page that has 2 WYSIWYG editors displayed - XWIKI-7028
* Activity Stream doesn't show Image Profile change - XWIKI-5930
* Limit dragable width of textareas in FF4 and Chrome - XWIKI-6304
* Tree from document index does not expand on IE9 - XWIKI-6752
* Have an auto-complete for the User and Group visibility inputs for the Message Stream - XWIKI-6728
* When editing a User Profile category, after saving the changes, preserve the category tab - XWIKI-7059
* Add option to 'show more entries' on displaying the Activity Stream - XE-748
* Log-in automatically on registration - XWIKI-6892
* New XWiki Syntax Guide - XE-880
* Better placement of the documentation link - XE-1031
* WebSearch should only display spaces with view right - XASEARCH-12
* Auto-suggest doesn't work for global users - XWIKI-6207
Investigations:
* Solr (to be continued from 3.2 with more details) - Fabio
* XWiki in 5 minutes (to be continued from 3.2) - Caty
* New Stats UI (to be continued from 3.2 with more details) - Caty
Thanks
-Vincent
Hi devs,
The idea is to provide the quickest possible way to programmatically
import a xar on a wiki from outside. Right now you have to attach the
file using REST and then call the import action.
The vote is actually not that much on the idea itself I think but more
on the API.
So her is the proposal:
/wikis/{wikiName}/import?backup=true/false&history=add/reset/replace
The parameters of the URL are the options you can find in the UI.
the resource return void which mean either OK or an exception if it
failed for any reason.
WDYT ?
Here is my +1.
--
Thomas Mortagne
Restarting the vote since the first one was a bit fuzzy, too late in
3.2 cycle and I made some required improvements since then.
The idea is to make as easy as possible to install production ready
XWiki Enterprise (and others later probably) on debian/ubuntu.
Here is what is provided right now:
* a "common" package which is a base package containing a XWiki with
everything except the hibernate setup (but it provide some templates
which are used by other packages)
* a "tomcat-mysql" package which depends on xwiki commons, tomcat6,
mysql-server, libmysql-java debian packages and make sure a MySQL
database is created for XWiki and that it's properly added to tomcat
applications
* a "tomcat-pgsql" package which depends on xwiki commons, tomcat6,
postgresql, libpg-java debian packages and make sure a PostgreSQL
database is created for XWiki and that it's properly added to tomcat
applications
* I wrote a script to run in a cron which update a Debian repository
descriptor (Packages.gz) in releases and snapshot maven repositories
and also create a virtual "stable" Debian repository which contains
only stable releases
* it of course follow Debian standard path (configurations files in
/etc/xwiki/ etc...) and you get nice conflict resolution tools when
upgrading files thanks to dpkg
Some links:
* jira issue: http://jira.xwiki.org/browse/XE-985
* design page: http://dev.xwiki.org/xwiki/bin/view/Design/DebianPackage
* code: https://github.com/xwiki-contrib/xwiki-debian
* the script: /home/maven/xwiki_scanpackages.sh
WDYT ?
Here is my +1
--
Thomas Mortagne
Hi,
I've created a page on incubator with a collection of issues, problems and
ideas that could improve the way the normal user interacts with XWiki.
Initially the study was part of the "XWiki in 5 minutes" investigation
process, but now it covers all kind of usability issues, grouped by
category.
I know the list is not complete (and maybe never will) and the bad thing
about the list is that is manually generated (I've listed some keyword we
could use in JIRA in order to organize them), but it provides lots of ideas
and directions we could take for our next roadmaps.
Feel free to comment on the collection and please add more ideas and
suggestions you have in order to make XWiki easier and more fun, productive
to use.
Thanks,
Caty
Note: this was a test email. Trying to understand why we don't receive HTML emails anymore.
You may receive a few more while I'm testing.
Thanks
-Vincent
On Oct 19, 2011, at 12:18 PM, notifications(a)xwiki.org wrote:
>
> Hello Developers,
>
> This message is sent by XWiki. Here are the documents in your watchlist that have been modified since the last notification:
>
> + XWiki.org
> |
> | + XWiki
> | |
> | | + XWikiNotifications (XWiki.XWikiNotifications): http://www.xwiki.org/xwiki/bin/view/XWiki/XWikiNotifications
> | | |
> | | | - On 2011/10/19 12:17, the document has been modified by Vincent Massol
> | |
> | | + XWiki Preferences (XWiki.XWikiPreferences): http://www.xwiki.org/xwiki/bin/view/XWiki/XWikiPreferences
> | | |
> | | | - On 2011/10/19 12:05, the document has been modified by Vincent Massol
> _______________________________________________
> notifications mailing list
> notifications(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/notifications
Hi devs,
The proposal is to use artifactid as directory names.
Note that this is what I did for commons and rendering when I did the move to top level project. You can check how it looks like here:
http://svn.xwiki.org/svnroot/xwiki/commons/http://svn.xwiki.org/svnroot/xwiki/rendering/
I suggest we keep one strategy only for consistency.
Some discussion here too:
http://www.sonatype.com/people/2011/01/maven-tip-project-directories-and-ar…
I know there are some cons (see my comment in the link above) but overall I find it simple to implement and with autocompletion not such a big issue.
WDYT?
If you don't like this then please propose an alternative solution and remember that we'll need to refactor commons and rendering in this case too.
Thanks
-Vincent