Application Within Minutes Plan (XE 2.6)
Description
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
Need | Use Case/Deliverable | Workload | External Needs | Priority | Notes |
---|---|---|---|---|---|
Project Management | P1 | ||||
Done in 3.1 timeframe | |||||
Review Application/Class / What is generated | marius | P1 | Proposal needed by Marius | ||
Done on June 27th | |||||
Review fields parameter importance | cati | P1 | Cati makes a list, and team reviews | ||
Review new displayer importance | cati | P4 | Extension of the previous list for not existant fields | ||
Design | |||||
Done except all displayer design | |||||
Metadata Management | caty/marta | P5 | We 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 | caty | P2 | Done for some types. Still needs to be complete. | ||
New Displayer Design | caty | P4 | To be done once we have validated the new displayer importance list. Probably for 3.3. | ||
- | Done. http://incubator.myxwiki.org/xwiki/bin/download/Improvements/ApplicationWithinMinutesProposalI2/step29.png Drag and Drop should be available | ||||
App Within Minute Home Page | cati | P2 | Listing of existing applications and entry point to create a new one, place of the delete, export button | ||
Development | |||||
Core Changes for Displaying Sheets | marius | P1 | vote needed | ||
Core Changes for Page Naming on Creation | marius | P1 | vote needed | ||
Application Wizard Entry point | marius | P1 | |||
Application Details Screen | marius | P2 | |||
Application Structure Screen with standard class editor | marius | P2 | |||
Application Structure Screen with custom class editor per type | stefan m. | P3 | |||
Application Presentation Screen | marius | P2 | |||
Application Sheet Generation | marius + stefan m. | P2 | |||
Application LiveTable Generation | marius | P3 | |||
Application Template Generation | marius | P4 | |||
Application Translation Generation | marius | P4 | |||
XWiki Integration (view structured data) | marius | P2 | vote 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 | stefan | P1 | |||
DBList with advanced UI (select classes, etc, manage metadata, etc.) | ? | P5 | need displayer design | ||
Date Picker | ? | P5 | need displayer design | ||
User/Group Picker (single/multiple/xem) | ? | P5 | need displayer design | ||
Structured Page Picker (single / multiple) | ? | P5 | need displayer design | ||
Image Picker | ? | P5 | |||
Attachment Picker | ? | P5 | |||
Validation Support | ? | P4 | might not make it in 3.2 | ||
Application Packaging | marius | P3 | Export button | ||
Tests | |||||
Define Manual Test Plan | sorin | P1 | Need to add sorin in the loop for the test plan | ||
Define Automated Test | marius | P1 | Define Automated test plan | ||
Final Review | |||||
Review result of development | ludovic, sorin, thibaut, raluca s, community | P3 | |||
Decide Phase 2 | roadmap community | P4 | need 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
- Expose the application from the Admin section and allow to set
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.
CRUD
Create
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?)
Read
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.
Delete
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.
Update
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 http://ajaxload.info/. 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
Mockups
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 http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ApplicationWithinMinutes
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)
- input
- 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
- input
- 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
Conventions
- 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.
* 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.