This page aims to define Application Within Minutes application

Main Objective

This application aims to allow end users use XWiki's powerful structured data management to make collaborative web applications with as little steps as possible. The focus on solving most common use cases when creating applications. We are not trying to include all types of features (like notifications, complex fields or workflows). These can be added by programmers. 

Action Plan

NeedUse Case/DeliverableWorkloadExternal NeedsPriorityNotes
Project Management  P1
 Review investigation/plan allP1Done in 3.1 timeframe
 Review Application/Class / What is generated mariusP1Proposal needed by Marius
 Review feature list/importance of features allP1Done on June 27th
 Review fields parameter importance catiP1Cati makes a list, and team reviews
 Review new displayer importance catiP4Extension of the previous list for not existant fields
 General Flow and Design catyP1 
 Class Wizard Design catyP1Done except all displayer design
 Metadata Management caty/martaP5We are not sure we need it. Move to phase 2. 3.3 Roadmap. Deliver current Metadata managmeent that we have as Extensions.
 Current Displayer Design catyP2Done for some types. Still needs to be complete.
 New Displayer Design catyP4To be done once we have validated the new displayer importance list. Probably for 3.3.
 Sheet Management -P4Done. Drag and Drop should be available
 App Within Minute Home Page catiP2Listing of existing applications and entry point to create a new one, place of the delete, export button
 Core Changes for Displaying Sheets mariusP1vote needed
 Core Changes for Page Naming on Creation mariusP1vote needed
 Application Wizard Entry point mariusP1 
 Application Details Screen mariusP2 
 Application Structure Screen with standard class editor mariusP2 
 Application Structure Screen with custom class editor per type stefan m.P3 
 Application Presentation Screen mariusP2 
 Application Sheet Generationmarius + stefan m.P2 
 Application LiveTable Generation mariusP3 
 Application Template Generation mariusP4 
 Application Translation Generation mariusP4 
 XWiki Integration (view structured data) mariusP2vote needed
 Application Structure Screen for specific types stefan Cati needs to provide field priorities and field types for simple + advanced mode for each type
   String stefan  
   Textarea stefan  
   List stefan  
   Date stefan  
   Number stefan  
   Time stefan  
   DBList without advanced UI stefanP1
   DBList with advanced UI (select classes, etc, manage metadata, etc.) ?P5need displayer design
   Date Picker ?P5need displayer design
   User/Group Picker (single/multiple/xem) ?P5need displayer design
   Structured Page Picker (single / multiple) ?P5need displayer design
   Image Picker ?P5 
   Attachment Picker ?P5 
 Validation Support ?P4might not make it in 3.2
 Application Packaging mariusP3Export button
 Define Manual Test Plan sorinP1Need to add sorin in the loop for the test plan
 Define Automated Test mariusP1Define Automated test plan
Final Review     
 Review result of development ludovic, sorin, thibaut, raluca s, communityP3 
 Decide Phase 2 roadmap communityP4need to be done after final review to decide plan for 3.3

Items to Implement / Improve

  • Enpower end user to create XWiki applications and solve XWiki developer issues by:
    • Expose the application from the Admin section and allow to set
      • Default Space
      • Application display name (set as space title)
      • Invitation text
    • Easy structured data creation (class wizard) with a limited set of parameters visible (more in advanced)
      • Choose the name of the field (same used for display)
      • Basic parameter shown (advanced button to see more)
      • Link to metadata management for ListClass fields
      • Checkbox to add to livetable
    • CRUD
      • Create: Automatic form creation (no need to indicate page name, unique id generation), integrated in XWiki UI using templates
      • Read: Spreadsheet-like view: automatic livetable, Sheets activated automatically
      • Delete : delete button available from livetable (bulk delete?)
      • Update : inline edition and merging of structured and unstructured data
    • Metadata management (create, delete, update, list) and easy administration
    • Easy to use
      • Contextual help (tooltips) when creating the app.
      • Polished and shiny
      • More pickers
        • Suggest
        • Advanced suggest (on a class instead of simple key/value datasource)
        • Be able to choose local or global users (global users is not possible AFAIK)
    • Avanced Features
      • Code goes in AppCode space
      • Generated code can be customized / Warnings needed from the wizard
      • Advanced editing of sheets
        • Default sheets should be provided for create/edit/view
        • Sheets should be editable and customizable
        • Sections in sheets
      • Validation Support
      • Translations Management

More Explanations

Expose the application

One important thing is to have the application well exposed in the wiki as well as correctly isolated. This means:

  • Applications get their own space
  • Find the right location of the link to it
    • From the UI "Adding" a page in the application should be available
    • The space home page allows to list items by default
    • From the UI a list of "Structured data" is available allowing to access the list
    • The configuration of application should be available for Admins
  • and finally make sure that work has been done usability / design side.

Easy Structured data creation

Current class wizard is very helpful for creating XWiki classes. Slight modifications could be added, like page sheet setting in an advanced section, but nothing clearly identified at the moment. The one thing is that class wizard should be integrated into application within minutes pages.



Item page name: Once data structure has been defined, we will want to be able to create items (understand XWiki objects). In the context of an application, it does not always make sense to fill in a page name and then access creation form. Therefore, page title should not be needed and only a "Create" button should link to creation form.

Unique id/name generation: In many cases you want to be able to have a number automatically generated. Similarly to what we do in excel where line number identifies an entry, or what you have in a database with auto-increment. From a user point of view, the suggestion is to have a new entry in the type of data for properties (available in class wizard) that says "auto-increment". (We could think of custom auto-increment that can be configured somewhere else allowing with a specific computation algorithm but this goes beyong current need.) It should also be possible to have page name using page title (or another pattern like a static key) and / or a combination of page title plus a counter.

Space: One space should be created per application. All pages created using this application would be located in that space. Home page of the space would be the home page of the application.

Redirect to home page: When it makes sense for a wiki page to display it when saved, it is not the case for applications. When creating an entry, default behaviour would be to redirect user to application home page (or any otherpage if possible) with a message (success message?)


Page sheet detection: Users should not have to create page sheet, it should be done automatically. Page sheet could be pre-filled in a property of the class when using class wizard. (An improvement could be to have an advanced section in class wizard with ability to change page sheet.). Sheets should not have to be included in the content field. XWiki should automatically detect that the page has an object of a class which has a specific displayer (need core change).

Automatic livetable generation: When creating the application, users will be able to select what fields they want to be displayed on the home page. That information will be stored and used to automatically generate a livetable on application home page.

Home page editing: There is a need for people to be able to add some "Welcome message" on the home page of the application, above the livetable. Home page of the application should allow this. One solution could be that editing the home page would allow users to edit the content of the wiki page only. When the page is being viewed, some object (maybe the one that will hold livetable configuration) indicates that once we have displayed "Welcome message" (page content) then we have to render livetable. We want people to be able to edit content, we don't want them to be able to edit (livetable) velocity code.



Deleting could take place in two different locations

From the home page: using livetable actions column. Deleting an entry would keep user on the home page of the application.

From the page: XWiki standard feature.


When editing a page that has structured data, it makes no sense to be able to edit page content (unstructured) and structured data in different mode. We should have one mode: inline mode. When editing the page, the wiki should check what type of page we are editing (what object it contains) and trigger inline editing using the right object sheet.

Note: in the case where we have several objects, it raises the question "What sheet to choose if we have several objects" ? Currently we can discard tag objects and make the asumption that we only have one object per page.

Metadata Management

We should be able to administer application metadata. What we mean by "Metadata" is the available values used by StaticListClass or DBListClass fields. These fields are highly important in many applications and the administration of the data often needs to be made easy, hence usable by and "Administrator" and not by a "Developer".

That administration could be added in space administration section. That administration should enable user to add, delete, update and list metadatas from all properties that have been defined as lists.

Easy to Use

One of the major improvements that could be implemented regarding ease of use and user experience is ajax-suggest for simple and multiple select items.

Here is an example of multiple select property named addstakeholders :


Many fields like that can be added including MetaData Picker, Date Picker, User Picker, Page Picker, Image and Attachment Picker but more importantly other "Structured Data Page" picker. This last one is particularly important for building more complex application where some datasets relate to other dataset.

Show In Progress Status: On some action, like ajax-suggest or when creating a page, we could add a loading image similar to this This is not specific this application though.

Listing applications: To be able to find easily applications. We should have an application list in the Admin section. (this could be managed by the Extension Manager?)

Additional Features

  • Validation of fields
  • Application Packaging: allowing to export the application (related to Extension Manager)
  • Translations Management: allow to generate the translations pages
  • Specialized Search and XWiki Search Integration and also ajax-suggest search (à la jira)
  • Be able to instanciate an application created (eg 1/ you set a different key which allows you to create new entries based on the same code. Eg 2/ You copy an app to be keep the structure and adapt it to another company departement). The same code would then be used in another space or wiki.
  • Excel export feature : XWIKI-5458 (patch) and XE-184
  • Advanced editing of sheets


A mockup for "Document Type Manager" was done: Mockups.DocumentTypeManager

Here is an example of how the application creation process may be organized and look like:

Home page / Step 1


Step 2


Step 3


Idea: IDE sketch

You can read more about this idea at

Field types and simple field parameters

  • all fields: name (display name as optional)
  • text:  size, picker
  • textarea: size / wysiwyg
  • date: none (picker automatic)
  • single page: class / display field
  • single user: xe / xem / both
  • multiple page: picker by default, class / display field
  • multiple user:  picker by default, xe / xem / both
  • single static list:  picker/no picker, metadata mngt
  • single db list: picker/no picker, choose class, display field, metadata mngt
  • multiple static list: picker/no picker, size, metadata mngt
  • multiple db list: picker/no picker, size, choose class, display field, metadata mngt
  • image picker: current page/all wiki
  • attachment picker: current page/all wiki

A review of competing applications would be interesting to check what they support

Application vs Class technical Issue

It's not clear reading this spec, if the main notion is the "Application" or is the "Class" or if it is both. We need a way to identify the applications (to list them) and it's not ALL the classes. We also need a way to link the class to the sheets so that XWiki automatically displays the sheets.

A proposed implementation is to have a property in the Class (yes/no) which says that this class is also an application. The default space would be listed in the class too which allows to know where the data for that application are listed. The sheets to be used would also be listed.

Therefore an Application is reprenseted by a MAIN class and all classes are not applications.

Another approach is to define a notion of Application and a list of classes are attached to that application. This second solution makes more sense once the Extension Manager is available and also allows to connect templates in a simpler way then having to look at the classes used by the templates.

MetaData Management Technical Details

Here is an architecture proposal for the Metadata Management:

  • Page 1: Metadata administration home page (page 1)
    • input
      • class name
    • output
      • list of properties with a link to administer that metadata (page 2)
  • Page 2: Page that administers one metadata.
    • input
      • property type (convention should be that property name in class definition equals type of metadata)
      • application name (so that we know where to store metadata objects
  • Page 3: Page that defines MetadataCode.MetadataClass
    • type (string)
    • key (string)
    • value (string)
    • parent (string)
  • Pages holding metadata
    • a given metadata should be stored in a specific page. For example, if we have a "location" metadata (class property) for our main class Company, all locations should be stored in Company.LocationMetadata


  • Property name: Convention should be that property name in class definition equals type of metadata. As an example, if we have Company class that we want to manage, with one of the properties being "location", then we will want to use location as a standard metadata, meaning that we will use MetadataCode.MetadataClass (cf. above). Using this class, a type needs to be used. The convention would be that type = location.
* type: location
* key: new-york
* value: New-York
* parent:

* type: location
* key: rio-de-janeiro
* value: Rio de Janeiro
* parent:
  • Metadatas: Metadatas are stored in a page called Space.PropertyNameMetadata: With the example above, that would mean Company.locationMetadata (do we want first letter uppercase?)
  • Some parameters can be stored in Space.Parameters page.
  • Advanced metadata: Advanced metadata are metadata that need a more complex class definition that standard one (MetadataCode.MetadataClass). Those classes should be created in SpaceCode space (CompanyCode.MyAdvancedClassName). Metadatas are stored in Company.<MyAdvancedClassName>Metadata. Taking the example of a company that can have products (a product has a price, an id, a color, etc.), we would create CompanyCode.ProductClass that would sit in Company.ProductMetadata
  • Creation of Advanced metadatas and pages holding metadatas (Space.*Metadata) are generated in a seperate code than actual metadata management (CRUD). That piece of code shoud be sitting somewhere else.


Created by Thibaut Camberlin on 2011/01/27 17:15

Get Connected