Skip to Content
Last modified by Vincent Massol on 2024/11/19 16:12
Show last authors
1 {{box title="Contents"}}
2 {{toc/}}
3 {{/box}}
4
5 {{include document="XWiki.DesignClassSheet"/}}
6
7 {{info}}
8 This page aims to define Application Within Minutes application
9 {{/info}}
10
11 == Main Objective ==
12
13 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.
14
15
16 == Action Plan ==
17
18 |=Need|=Use Case/Deliverable|=Workload|=External Needs|=Priority|=Notes
19 |**Project Management**|| | |P1|\\
20 | |--Review investigation/plan--|-- --|--all--|--P1--|Done in 3.1 timeframe
21 | |Review Application/Class / What is generated| |marius|P1|Proposal needed by Marius
22 | |--Review feature list/importance of features--|-- --|--all--|--P1--|Done on June 27th
23 | |Review fields parameter importance| |cati|P1|Cati makes a list, and team reviews
24 | |Review new displayer importance| |cati|P4|Extension of the previous list for not existant fields
25 |**Design**| | | | |
26 | |--General Flow and Design--|-- --|--caty--|--P1--|
27 | |--Class Wizard Design--|-- --|--caty--|--P1--|Done except all displayer design
28 | |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.
29 | |Current Displayer Design| |caty|P2|Done for some types. Still needs to be complete.
30 | |New Displayer Design| |caty|P4|To be done once we have validated the new displayer importance list. Probably for 3.3.
31 | |--Sheet Management--|-- --|-|--P4--|Done. http:~/~/incubator.myxwiki.org/xwiki/bin/download/Improvements/ApplicationWithinMinutesProposalI2/step29.png Drag and Drop should be available
32 | |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
33 |**Development**| | | | |
34 | |[[Core Changes for Displaying Sheets>>ApplicationWithinMinutesCoreChangeSheetDisplay]]| |marius|P1|vote needed
35 | |[[Core Changes for Page Naming on Creation>>ApplicationWithinMinutesPageCreation]]| |marius|P1|vote needed
36 | |Application Wizard Entry point| |marius|P1|
37 | |Application Details Screen| |marius|P2|
38 | |Application Structure Screen with standard class editor| |marius|P2|
39 | |Application Structure Screen with custom class editor per type| |stefan m.|P3|
40 | |Application Presentation Screen| |marius|P2|
41 | |Application Sheet Generation||marius + stefan m.|P2|
42 | |Application LiveTable Generation| |marius|P3|
43 | |Application Template Generation| |marius|P4|
44 | |Application Translation Generation| |marius|P4|
45 | |XWiki Integration (view structured data)| |marius|P2|vote needed
46 | |Application Structure Screen for specific types| |stefan| |Cati needs to provide field priorities and field types for simple + advanced mode for each type
47 | | String| |stefan| |
48 | | Textarea| |stefan| |
49 | | List| |stefan| |
50 | | Date| |stefan| |
51 | | Number| |stefan| |
52 | | Time| |stefan| |
53 | | DBList without advanced UI| |stefan|P1|\\
54 | | DBList with advanced UI (select classes, etc, manage metadata, etc.)| |?|P5|need displayer design
55 | | Date Picker| |?|P5|need displayer design
56 | | User/Group Picker (single/multiple/xem)| |?|P5|need displayer design
57 | | Structured Page Picker (single / multiple)| |?|P5|need displayer design
58 | | Image Picker| |?|P5|
59 | | Attachment Picker| |?|P5|
60 | |Validation Support| |?|P4|might not make it in 3.2
61 | |Application Packaging| |marius|P3|Export button
62 |**Tests**| | || |
63 | |Define Manual Test Plan| |sorin|P1|Need to add sorin in the loop for the test plan\\
64 | |Define Automated Test| |marius|P1|Define Automated test plan
65 |**Final Review**| | | | |
66 | |Review result of development| |ludovic, sorin, thibaut, raluca s, community|P3|
67 | |Decide Phase 2| |roadmap community|P4|need to be done after final review to decide plan for 3.3
68
69 == Items to Implement / Improve ==
70
71 * Enpower end user to create XWiki applications and solve XWiki developer issues by:
72 ** Expose the application from the Admin section and allow to set
73 *** Default Space
74 *** Application display name (set as space title)
75 *** Invitation text
76 ** Easy structured data creation (class wizard) with a limited set of parameters visible (more in advanced)
77 *** Choose the name of the field (same used for display)
78 *** Basic parameter shown (advanced button to see more)
79 *** Link to metadata management for ListClass fields
80 *** Checkbox to add to livetable
81 ** CRUD
82 *** Create: Automatic form creation (no need to indicate page name, unique id generation), integrated in XWiki UI using templates
83 *** Read: Spreadsheet-like view: automatic livetable, Sheets activated automatically
84 *** Delete : delete button available from livetable (bulk delete?)
85 *** Update : inline edition and merging of structured and unstructured data
86 ** Metadata management (create, delete, update, list) and easy administration
87 ** Easy to use
88 *** Contextual help (tooltips) when creating the app.
89 *** Polished and shiny
90 *** More pickers
91 **** Suggest
92 **** Advanced suggest (on a class instead of simple key/value datasource)
93 **** Be able to choose local or global users (global users is not possible AFAIK)
94 ** Avanced Features
95 *** Code goes in AppCode space
96 *** Generated code can be customized / Warnings needed from the wizard
97 *** Advanced editing of sheets
98 **** Default sheets should be provided for create/edit/view
99 **** Sheets should be editable and customizable
100 **** Sections in sheets
101 *** Validation Support
102 *** Translations Management
103
104 == More Explanations ==
105
106 === Expose the application ===
107
108 One important thing is to have the application well exposed in the wiki as well as correctly isolated. This means:
109
110 * Applications get their own space
111 * Find the right location of the link to it
112 ** From the UI "Adding" a page in the application should be available
113 ** The space home page allows to list items by default
114 ** From the UI a list of "Structured data" is available allowing to access the list
115 ** The configuration of application should be available for Admins
116 * and finally make sure that work has been done usability / design side.
117
118 === Easy Structured data creation ===
119
120 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.
121
122 === CRUD ===
123
124 ==== Create ====
125
126 **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.
127
128 **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.
129
130 **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.
131
132 **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>>http://jira.xwiki.org/jira/browse/XE-723]]?)
133
134 ==== Read ====
135
136 **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).
137
138 **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.
139
140 **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.
141
142 [[image:EventsExtra-WaterWiki-MozillaFirefox.jpg||style="width: 631px; height: 255px;"]]
143
144 ==== Delete ====
145
146 Deleting could take place in two different locations
147
148 **From the home page**: using livetable actions column. Deleting an entry would keep user on the home page of the application.
149
150 **From the page**: XWiki standard feature.
151
152 ==== Update ====
153
154 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.
155
156 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.
157
158 === Metadata Management ===
159
160 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".
161
162 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.
163
164 === Easy to Use ===
165
166 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.
167
168 Here is an example of multiple select property named **addstakeholders** :
169
170 [[image:ApplicationsWithinMinutesRoadmap.ApplicationsWithinMinutes-XWiki-MozillaFirefox2.jpg]]
171
172 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.
173
174
175 **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.
176
177 **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?)
178
179 == Additional Features ==
180
181 * Validation of fields
182 * Application Packaging: allowing to export the application (related to Extension Manager)
183 * Translations Management: allow to generate the translations pages
184 * Specialized Search and XWiki Search Integration and also ajax-suggest search (à la jira)
185 * 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.
186 * Excel export feature : XWIKI-5458 (patch) and XE-184
187 * Advanced editing of sheets
188
189 == Mockups ==
190
191 A mockup for "Document Type Manager" was done: [[Mockups.DocumentTypeManager>>http://incubator.myxwiki.org/xwiki/bin/view/Mockups/DocumentTypeManager]]
192
193 Here is an example of how the application creation process may be organized and look like:
194
195 === Home page / Step 1 ===
196
197 [[image:1.HomePage.png||style="width: 670px; height: 389px;"]]
198
199 === Step 2 ===
200
201 [[image:2.DataCreation.png||style="width: 681px; height: 222px;"]]
202
203 === Step 3 ===
204
205 [[image:3.ApplicationHomepage.png||style="width: 727px; height: 594px;"]]
206
207
208 === Idea: IDE sketch ===
209
210 You can read more about this idea at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ApplicationWithinMinutes
211 [[image:http://incubator.myxwiki.org/xwiki/bin/download/Improvements/ApplicationWithinMinutes/idegeneral.jpg||width="700px"]]
212
213 == Field types and simple field parameters ==
214
215 * all fields: name (display name as optional)
216 * text: size, picker
217 * textarea: size / wysiwyg
218 * date: none (picker automatic)
219 * single page: class / display field
220 * single user: xe / xem / both
221 * multiple page: picker by default, class / display field
222 * multiple user: picker by default, xe / xem / both
223 * single static list: picker/no picker, metadata mngt
224 * single db list: picker/no picker, choose class, display field, metadata mngt
225 * multiple static list: picker/no picker, size, metadata mngt
226 * multiple db list: picker/no picker, size, choose class, display field, metadata mngt
227 * image picker: current page/all wiki
228 * attachment picker: current page/all wiki
229
230 A review of competing applications would be interesting to check what they support
231
232 == Application vs Class technical Issue ==
233
234 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.
235
236 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.
237
238 Therefore an Application is reprenseted by a MAIN class and all classes are not applications.
239
240 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.
241
242 == MetaData Management Technical Details ==
243
244 Here is an architecture proposal for the Metadata Management:
245
246 * Page 1: Metadata administration home page (page 1)
247 ** **input**
248 *** class name
249 ** **output**
250 *** list of properties with a link to administer that metadata (page 2)
251
252 * Page 2: Page that administers one metadata.
253 ** **input**
254 *** property type (convention should be that property name in class definition equals type of metadata)
255 *** application name (so that we know where to store metadata objects\\
256
257 * Page 3: Page that defines MetadataCode.MetadataClass
258 ** type (string)
259 ** key (string)
260 ** value (string)
261 ** parent (string)
262
263 * Pages holding metadata
264 ** 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
265
266 === Conventions ===
267
268 * **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.
269
270 {{code}}
271 * type: location
272 * key: new-york
273 * value: New-York
274 * parent:
275
276 * type: location
277 * key: rio-de-janeiro
278 * value: Rio de Janeiro
279 * parent:
280 {{/code}}
281
282
283 * **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?)
284
285 * Some parameters can be stored in {{code}}Space.Parameters{{/code}} page.
286
287 * Advanced metadata: Advanced metadata are metadata that need a more complex class definition that standard one ({{code}}MetadataCode.MetadataClass{{/code}}). Those classes should be created in SpaceCode space ({{code}}CompanyCode.MyAdvancedClassName{{/code}}). Metadatas are stored in {{code}}Company.<MyAdvancedClassName>Metadata{{/code}}. Taking the example of a company that can have products (a product has a price, an id, a color, etc.), we would create {{code}}CompanyCode.ProductClass{{/code}} that would sit in {{code}}Company.ProductMetadata{{/code}}
288
289 * 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.

About

About

Support

Platform

User Guide

Admin Guide

Developer Guide

Projects

XWiki

Extensions

Other

Contribute

Status

Practices

Under the Hood

Get Involved

Get Connected