Development

bschussek (diff)

You must first sign up to be able to contribute.

Changes between Version 3 and Version 4 of bschussek

Show
Ignore:
Author:
bschussek (IP: 217.196.78.67)
Timestamp:
06/30/08 18:42:26 (9 years ago)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • bschussek

    v3 v4  
    2222 
    2323 * Most of the ideas presented in here are based on successful applications such as [http://www.silverstripe.org Silverstripe], [http://www.pinkorange.at/de/overview/jacomo_datenverwaltung.htm Jacomo] (a very usable and customizable db administration tool developed by my previous employer) and [http://www.joyent.com Joyent] (a collaboration tool with a very innovative UI). 
    24  * I'm trying to illustrate most of the sections with concept art screenshots. 
    2524 * I'm basing my concepts on the current syntax of configuration files. These need to be modified in case the new admin generator makes radical changes here. 
     25 * Many of the examples are incomplete and require further discussion 
    2626 * I'm refering to inexperienced, non-technical users when talking about "users" 
    2727 
    6767I came up with the following concept when I stumbled upon [http://www.joyent.com Joyent Connector] while analising different web applications: 
    6868 
    69  * ''Add'' contextual records through sub-forms while modifying the informational entities (solves 1.) 
     69 * ''Add'' contextual records through sub-forms while modifying the informational entities (solves 1.)[[BR]] 
    7070   '''Example:''' Create AccomodationTypes while modifying an accomodation through subforms 
    71  * ''Display'', ''add'' and ''modify'' contextual entities in a '''tabbed sidebar''' in the views of the informational entities they're related to. Don't waste space by creating a dedicated list view which users will never use (solves 1.) 
     71 * ''Display'', ''add'' and ''modify'' contextual entities in a '''tabbed sidebar''' in the views of the informational entities they're related to. Don't waste space by creating a dedicated list view which users will never use (solves 1.)[[BR]] 
    7272   '''Example:''' Display AccomodationTypes in Accomodation list and edit views, create, delete and modify them using AJAX 
    73  * ''Filter'' a list of informational entities when clicking on a contextual entity in the tabbed sidebar. Users know this behaviour from browsing f.i. file browsers, music applications etc. 
     73 * ''Filter'' a list of informational entities when clicking on a contextual entity in the tabbed sidebar. Users know this behaviour from browsing f.i. file browsers, music applications etc.[[BR]] 
    7474   '''Example:''' When the user clicks on an AccomodationType entry in the sidebar of the Accomodation list view, filter the list by this type. 
    7575 
    7676==== Realisation ==== 
    7777 
    78 One could realise this with the following configuration: 
    79  
    80 {{{ 
    81 generator: 
    82   param: 
    83     model_class: Accomodation 
     78One could realise the sidebar with the following configuration: 
     79 
     80{{{ 
     81generator: 
     82  param: 
     83    model_class: Accomodation 
    8484    sidebar: 
    8585      display:   [_types, _tags]                                               # Specification of order. All of these can be overridden by partials 
    8989}}} 
    9090 
     91(Note: this code sample is incomplete) 
     92 
     93Adding a contextual entity through a subform while editing an informational entity can be handled through a widget (see below). 
     94 
    9195=== Widgets === 
    9296 
    93 The generator support widgets, meaning a generalized way of representing and modifying record data. These widgets as I speak of them are different from symfony 1.1 form widgets in that they incorporate ''view'', ''validation'' and partially ''business logic''. 
     97The generator should support widgets, meaning a generalized way of representing and modifying record data. These widgets as I speak of them are different from symfony 1.1 form widgets in that they incorporate ''view'', ''model'' (validation) and partially ''business logic''. 
    9498 
    9599'''Use case 1:''' 
     100 
     101The record class "Accomodation" contains a many-to-one foreign relation "AccomodationType". When editing an accomodation, the user can select its type. Additionally he should be able to create a new type if the desired type does not exist yet. This can be done through a subform for adding the record. 
     102 
     103{{{ 
     104generator: 
     105  param: 
     106    edit: 
     107      AccomodationType: { type: SelectRelation, param: add=true } # uses SelectRelationAdminWidget, the original record and the name of the field (relation in this case) are automatically provided to the widget 
     108}}} 
     109 
     110The (conceptual) widget incorporates the following logic: 
     111 
     112 * display of all available types (model, view) 
     113 * addition of a new type (model, business logic) 
     114 * validation of selected types (model) 
     115 
     116'''Use case 2:''' 
    96117 
    97118The record class "Accomodation" contains two fields "longitude" and "latitude". They should be modified through a Google Map with a draggable marker. These fields do also appear in other classes, so a reusable widget is needed which can be configured in all classes: 
    104125}}} 
    105126 
    106 The (conceptual) widget incorporates the following logic: 
     127The widget incorporates the following logic: 
    107128 
    108129 * display of the map, javascript (view) 
    109  * validation of the coordinates (model, business logic) 
    110  
    111 '''Use case 2:''' 
    112  
    113 The record class "Accomodation" contains a many-to-one foreign relation "Type". 
     130 * validation of the coordinates (model) 
     131 
     132=== Simultaneous Modification === 
     133 
     134This is not as important, but useful anyway. 
     135 
     136The user should be able to modify several objects at once by selecting them (see Enhanced List View Actions below) and pressing the button "Edit". When multiple records are modified, the form contains a checkbox "Don't modify" for each form field which is checked by default. Form fields which are the same in all selected records are filled out, the other ones are left empty. If the user changes the content of a form field, unchecks "Don't modify" and saves the record, the given property is changed to the new value on all objects. 
     137 
     138This feature is very useful for batch editing of all sorts. 
    114139 
    115140=== Support of Nested Sets === 
    117142The generator should be able to automatically display nested sets as trees in the list view. Nested sets do always represent hierarchical data and thus can basically always be represented by trees, which are more intuitive to use for people than plain lists. 
    118143 
    119 There shouldn't be any further configuration necessary for this feature. 
     144There shouldn't be any further configuration necessary to enable this feature. 
    120145 
    121146=== Support of Inheritance === 
    122147 
    123148The generator should be able to automatically deal with Doctrine's inheritance schemes. I have too little experience in terms of real use cases to come up with a usable concept here though. 
     149 
     150=== Support of I18N === 
     151 
     152The generator should be able to deal with translated records. How to do this in detail needs to be discussed. 
    124153 
    125154== Minor Modifications == 
    151180}}} 
    152181 
    153 === Enhanced List Actions === 
    154  
     182=== Enhanced List View Actions === 
     183 
     184The support of custom actions in the list view should be enhanced. There should be two types of display modes: 
     185 
     186 * normal (normal button that does something) 
     187 * collapsible (the visibility hidden partial is toggled when the button is pressed, that could contain filters for the list view etc. 
     188 
     189Additionally one should differ between to types of action scope: 
     190 
     191 * none (the action does not affect a specific record) - for instance "Create", "Filter" 
     192 * selected (the action affects only selected records) - for instance "Delete", "Edit". One or more records need to be selected using checkboxes in the list view first 
     193 
     194{{{ 
     195generator: 
     196  param: 
     197    list: 
     198      actions: 
     199        _create:  ~                                   # default values: { name: Create, display: normal, scope: none } 
     200        _filter:  { display: collapsible }            # The partial _filter.php is toggled open/closed when the button is pressed and contains a form used to apply specific filters 
     201        _delete:  { scope: selected, action: delete } # The selected record identifiers will be handled to the specified action 
     202}}}