Development

bschussek (diff)

You must first sign up to be able to contribute.

Changes between Version 4 and Version 5 of bschussek

Show
Ignore:
Author:
bschussek (IP: 77.220.111.5)
Timestamp:
07/01/08 08:45:48 (9 years ago)
Comment:

Minor modifications

Legend:

Unmodified
Added
Removed
Modified
  • bschussek

    v4 v5  
    2828Besides: I was planning to develop this generator based on Doctrine because of the easier syntax and better support of relations, inheritance and nested sets. 
    2929 
    30 == Major Modifications == 
     30== Major Additions == 
    3131 
    3232=== Modification of Contextual Records === 
    3636In many applications the business model can be (mostly) separated in two groups: 
    3737 
    38  1. Informational Entities (valuable information), for instance 
     38 1. '''Informational Entities''' (valuable information), for instance 
    3939   * Article 
    4040   * Town 
    4242   * Booking 
    4343   * Page 
    44  2. Contextual Entities (providing contextual information for the above, mostly "groups" or "categories"), for instance 
     44 2. '''Contextual Entities''' (providing contextual information for the above, mostly "groups" or "categories"), for instance 
    4545   * Group 
    4646   * Tag 
    5050(of course this separation does not apply to all models, but from my experience to many of them) 
    5151 
    52 The difference between is that users generally don't want to know about the second. 
    53  
    54 '''Example:''' 
    55  
    56 For instance, the model may require to define a related "AccomodationType" for "Accomodation" records. Real users will not be interested in the type. They want to create a new accomodation, defining (and eventually creating) a type is only a burden, especially when the type has to be created in a different list view. Users will enter the accomodation creation form, fill half of the fields only to realize that the related type does not exist yet. Advanced users will open the type list in a new tab or window, but inexperienced users will just leave the form and lose all their entered data. 
    57  
    58 The only real use in such contextual entities ''for the user'' lies in filtering list views (in this example - filter accomodations by type). 
     52The difference between them is that users generally don't want to know about the second. 
     53 
     54  '''Example:''' 
     55 
     56  For instance, the model may require to define a related "AccomodationType" for "Accomodation" records. Real users will not be interested in the type. They want to create a new accomodation, defining (and eventually creating) a type is only a burden, especially when the type has to be created in a different list view. Users will enter the accomodation creation form, fill half of the fields only to realize that the related type does not exist yet. Advanced users will open the type list in a new tab or window, but inexperienced users will just leave the form and lose all their entered data. 
     57 
     58  The only real use ''for the user'' in such contextual entities is the ability to filter list views (in this example - filter accomodations by type). 
    5959 
    6060So our tasks are: 
    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.)[[BR]] 
    70    '''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.)[[BR]] 
    72    '''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.[[BR]] 
    74    '''Example:''' When the user clicks on an AccomodationType entry in the sidebar of the Accomodation list view, filter the list by this type. 
     69 * ''Add'' contextual records through sub-forms while modifying the informational entities (solves 1.) 
     70 
     71    '''Example:'''  
     72     
     73    Create AccomodationTypes while modifying an accomodation through subforms 
     74 
     75 * ''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.) 
     76 
     77    '''Example:'''  
     78     
     79    Display AccomodationTypes in Accomodation list and edit views, create, delete and modify them using AJAX 
     80 
     81 * ''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. (solves 2.) 
     82 
     83    '''Example:'''  
     84     
     85    When the user clicks on an AccomodationType entry in the sidebar of the Accomodation list view, filter the list by this type. 
    7586 
    7687==== Realisation ==== 
    8394    model_class: Accomodation 
    8495    sidebar: 
    85       display:   [_types, _tags]                                               # Specification of order. All of these can be overridden by partials 
     96      display:   [_types, _tags]                                               # Specification of order. All of these can be  
     97                                                                               # overridden by partials 
    8698      tabs: 
    8799        _types:  { relation: Accomodation.Type }                               # Name and title implicitly set to "Types" 
    97109The 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''. 
    98110 
    99 '''Use case 1:''' 
     111==== Use case 1: ==== 
    100112 
    101113The 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. 
    105117  param: 
    106118    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 
     119      AccomodationType: { type: SelectRelation, param: add=true } # Uses SelectRelationAdminWidget, the original record and  
     120                                                                  # the name of the field (relation in this case) are  
     121                                                                  # automatically provided to the widget 
    108122}}} 
    109123 
    114128 * validation of selected types (model) 
    115129 
    116 '''Use case 2:''' 
     130==== Use case 2: ==== 
    117131 
    118132The 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: 
    122136  param: 
    123137    edit: 
    124       _coordinates: { type: GoogleMap, param: longitude=longitude_field latitude=latitude_field } # uses GoogleMapAdminWidget with the given parameters 
     138      _coordinates: { type: GoogleMap, param: longitude=longitude_field latitude=latitude_field } # Uses GoogleMapAdminWidget  
     139                                                                                                  # with the given parameters 
    125140}}} 
    126141 
    144159There shouldn't be any further configuration necessary to enable this feature. 
    145160 
     161 
    146162=== Support of Inheritance === 
    147163 
    152168The generator should be able to deal with translated records. How to do this in detail needs to be discussed. 
    153169 
    154 == Minor Modifications == 
     170== Minor Additions == 
    155171 
    156172=== Global Navigation === 
    197213    list: 
    198214      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 
     215        _create:  ~                                   # Default values: { name: Create, display: normal, scope: none } 
     216        _filter:  { display: collapsible }            # The partial _filter.php is toggled open/closed when the button is  
     217                                                      # pressed and contains a form used to apply specific filters 
    201218        _delete:  { scope: selected, action: delete } # The selected record identifiers will be handled to the specified action 
    202219}}}