webCOMAND 3 Roadmap

3.0

• Repository Schema - Design and document new repository database schema that is backward compatible webCOMAND 2 content queries, but that also adds new features required by a COMAND 3 Repository.
  • Backward Compatible - Come up with schema that won't break existing webCOMAND 2 queries that only select from ContentType_X, ContentReference tables, as long as no new COMAND 3 features are utilized. This will handle the large majority of all existing queries coded for webCOMAND 2 and allow webCOMAND 2 instances to be upgraded to webCOMAND 3 without massive code rewrites. The only other consideration is the Link table, but that should probably be removed and queries that use it rewritten. It would be a challenge to hack together transition support to mirror folder relationships in the Link table until old queries are transitioned.
  • New Object-Oriented Features - New COMAND repository features must be supported, including:
    • ID, UUID and Type - All content records should have a globally-unique Object ID (OID) and Universally Unique ID (UUID) as well as a reference to the content record's Content Type (Type).
    • ContentType.Extends - Content type inheritance through a new "extends" field.
    • ParentType - With the introduction of ContentType.Extends, it is possible for a field to reference different content types (you can point to content records of the field's content type or any content type that extends that content type). As a result, additional metadata is needed to specify the type, otherwise there is no way to know what content type table to look in since content IDs are still used for backward compatability. In the future, this new meta-data can be removed if we switch all ID columns to use OID, which can be used to determine the content type. A new ParentType column must be added to the ContentReference table and _ParentType to all content type tables.
  • "Everything is a Content Type" - Create script to migrate all appropriate system tables to new content type schema. This has been completed in Perl so the upgrade can happen from the final webCOMAND v2 Perl code. However, it also needs to happen in PHP.
    • System Properties - Create new SystemProperties content type to store boot-strap IDs and to move out most values from SystemSettings table and setup.pm.
    • System Application - Create new SystemApplication content type to store Tools & Reports titles, icons and scripts.
    • Object - Create new Object table with OID, UUID and Type columns.
    • Folders - ContentGroup + Link > Folder, ContentControl + PublishControl + Link > FolderSettings, RichTextFieldCSS + Link > RichTextEditorSettings, create new "Root" and "Content" folders.
    • Content Types - ContentType > ContentType (add Extends, Color, Icon TableColumns), ContentTypeField > ContentTypeField, Enumeration > FieldChoice, FieldValidation > FieldValidation
    • Publications - OutputTemplate > PublicationProcedure, OutputList > PublicationList, OutputValue > PublicationValue, Distribution + DistributionVersion > Publication (DistributionVersions become their own content types that extend Publication, which is a tricky migration process)
    • Users - UserInfo > User, UserGroup > UserRole, Permission + VersionPermission > ContentAuthorization
    • Scheduled Tasks - Updates > Schedule
    • Type - The Type content type will be added and new Layout Type, Data Type content types will extend it. Content Type will be updated to extend it as well. Finally, the field type for Field.FieldType will be updated to "(Content Type) Type", which will remove the need for the built-in "(Data Type) Field Type".
    • Data Types - Data Types will move from code into the repository for easier CMS independant extension.
    • Layout Types - Layout Types will move from hard-code into the repository for easier CMS independant extension.
    • Location - Field Locations will move from code into the repository.
    • Integrations (Import / Export) - DataFilter > IntegrationProcedure, DataFilterField + DataFilterParams > ?
• cScript Processor - Backward compatible, with the following new features.
  • Backward-compatible - Almost complete, but requires more testing.
  • #CQL($var,query) - Similar to #SQL, except executes cQL queries.
  • #CPATH($var,query) - Similar to #SQL, except executes cPath queries.
  • #EACH($item,$list) - Similar to #LIST, but similar to foreach in other scripting languages. $item is set to the row or object for each iteration through $list.
  • $this - New $this variable is set automatically defined inside the scope of a #LIST, #CONTEXT and #INSERT, to represent the corresponding object.
  • #EDITABLE - Add meta data about objects and fields referenced in files published in edit mode. The resulting meta data in the published HTML files and repository can be used by webCOMAND Apps to provide inline editing features.
  • #EDITGROUP - Provides a way to group #EDITABLE statements to group and structure the meta data into menus and related objects and fields.
  • #ADD and #EDIT - Support for embedded objects and references set as objects, in addition to backward compatibility with "ID=2" and "Identifier=Test, ID=2" style strings to set references.
  • #REMOVE - Official support for removing objects, but updated to respect authorizations.
  • ${cPath} - Add cPath support to cScript ${} notation. cQuery will be added in version 4.0.
• COMAND API - Implement COMAND PHP API.
  • ORM - Use PHP magic functions to implement Object Relational Mapping with basic caching mechanism. Basically everything is always cached when it loads from the database, like webCOMAND 2. A future version should be smarter and unload less frequently used objects after expiration or when a storage threashold is reached.
  • Core Classes
    • Event - Error logging and display similar to webCOMAND 2.
    • COMAND - Used to discover and connect to repositories.
    • Repository - Methods to access all other classes in the context of a specific repository.
    • UUID - Methods to generate and work with UUIDs.
    • Object - This is heavily tied to the ORM.
    • Collection - These need to function like arrays as much as possible, but also offer additional methods to determine the number of objects of a specific content type are in the collection, etc.
    • Query - Encapsulates the query engine. This class relys heavily on a number of expression and parser classes.
    • Script - Encapsulates the cPath and cScript interpretters.
    • Extensions - Class to help implement extensions to the core, similar to how Code Igniter does the same.
  • Query Engine - get, get_first, get_rows, get_row all working with aggregate support.
  • cPath Processor
  • cQL Processor - Initially implement SELECT and then add UPDATE and DELETE later (can SELECT and then use API object->save() and collection->delete() for now).
    • SELECT - including 'AS' field aliases.
    • FROM
    • IN - Accept cPath to collection to select from.
    • WHERE - Implemented most common functions, but need to implement the rest.
    • ORDER BY - Accept cPath to collection to select from.
    • LIMIT - Accept cPath to collection to select from.
    • Operators - Implemented some SQL operators (!, NOT, *, /, %, +, -) for SQL and PHP collections.
    • Comparisons - Implemented some SQL comparisons (=, ==, !=, <, >, <=, >=, LIKE, ILIKE, RLIKE, BETWEEN) for SQL and PHP collections.
    • Logic Operators - Implemented some SQL logic (&&, ||, AND, OR) for SQL and PHP collections.
    • Functions - Implemented some SQL functions (ABS, ISNULL, LOWER, REVERSE, UPPER) for SQL and PHP collections as proof the rest can be implemented as need, but need to implement many more in future versions.
    • COMAND-specific Functions - Implemented non-SQL function KEY to compare a value to the object's key, which is maintained and indexed in the database for efficient comparisons.
    • GROUP BY - Accept cPath to collection to select from.
    • Aggregate Functions - Implemented most common SQL aggregate functions (COUNT, MIN, MAX, AVG) for SQL and PHP collections.
    • INSERT - This will CREATE tables when a content type is added.
    • UPDATE - This will ALTER tables when a content type is modified.
    • DELETE - This will DROP tables when a content type is removed.
    • OTHERS - Should we support CREATE, DROP, GRANT, etc. for more complete SQL compatibility? I don't think so, but worth a discussion. Would be pretty cool and useful to support all common SQL statements in their standard form, so other database applications could use a repository as if it were a relational database.
  • Version Control - Add version control features to repository and update query engine accordingly. [Completed, but not thoroughly tested yet, especially for when connecting to a repository in Active or Draft mode]
  • Temporal Queries / Time Locks - Ability to lock a moment in time within a repository, which essentially retains all content records as they existed at that point in time, so queries can be made based on that point in time. [Completed, but not thoroughly tested yet]
  • Authorizations - Create authorization scheme that supports features of webCOMAND 2 authorizations at a minimum, potentially adding some flexibility. Authorizations need to be enforced in cPath and cQL queries.
  • Validation - 3 validation models implemented to validate object updates at various levels: Content Type (cScript), Field (RegEx) and in PHP code (COMAND-style and CodeIgniter-style).
• webCOMAND - Have implemented basic functionality to be able to view and edit basic content records. This has made it easier to create the Intranet content types. Paused until COMAND API and Intranet are to the point COMAND Solutions backend developers can take over.
  • Login - Reusable login features to support webCOMAND and webCOMAND App logins, including login, security questions, forgot password, security log, lockout threasholds, unlock and reset password.
  • New Responsive UI - Basic prototype working, but needs tons of additional effort to implemented documented features properly.
  • Modular UI Framework - Basic prototype working for alert, backups, console, form, grid and tree, but these all need a significant amount of work and refinement.
    • Header - Dashboard, quick links and options.
      • Dashboard - Customizable dashboard. [Works when manually defined, but no ability to edit yet]
      • Quicklinks - Customizable quicklinks. [Works when manually defined, but no ability to edit yet]
      • Search - We need to implement repository search, but could do brute force search for now and push proper search to v4.0.
      • Help - Display menu of relavant documentation based on context (ie. dashboard would display dashboard link), with main COMAND documentation always at bottom of list, and as fallback if nothing else available. Could push off everything but main docs, but main docs should be moved to App that requires login, at least until we release under official license.
      • Account - Change password, update profile (photo, email, etc.), edit preferences (user preferences and options to clear/reset misc. preferences) and logout.
    • cPath Bar - Display path in user friendly expandable and clickable breadcrumbs, with option to edit underlying cPath. [Main features completed, but needs some clean up, drag-and-drop breadcrumb objects and collections if possible]
    • Menu - Menu to right of cPath Bar should provide all allowed options for view container. Certain menu items (most recently accessed?) should display to left of menu when there is enough room, for easier access. [Many working, but still needs a lot of work, may need to push view management to next version]
    • Action Bar - Update how options in the action bar are produced for a given cPath to implement initial common features and make more modular.
      • Object Options - When the cPath resolves to a single object (that does not implement Folder), the following options should be availalbe.
        • Submit - Only available if authorized with Approve permission (similar to Approve in webCOMAND 2). Calls _submit on the object, which saves the current form (or other object view) data to the active object version. Future versions if a workflow is defined, will trigger the next step in workflow.
        • Save - Similar to Submit, but saves a new draft version.
        • Cancel - Does not save the current form (or other object view) data to the object AND removes all drafts for this object saved by the current user. Consider keeping drafts if required by policy/settings, except will need way to indicate the drafts are no longer "active" or have been deleted, even though they remain a version that can be restored. While option to delete is in Versions sidebar, consider drop-down arrow to show the two delete options as well, for more obvious access.
        • Versions - Sidebar to manage versions. Includes list of drafts, the active version and past versions. Version in form view will be highlighted (see Select below). Also provide a text box to view and edit optional version notes for highlighted version (auto-save text on blur). If authorized, each version will have the following options. Finally, if authorized, provide two delete options: "Delete, but keep history" and "Delete from repository".
          • Select - Select a version to highlight and display version in view. Save current form/view data to new draft first if it contains unsaved changes. If user edits current version and current version is not latest draft, new draft is created to store data.
          • Approve - Only available if authorized (see webCOMAND 2). Makes version new active version.
          • Lock/unlock - lock version so only this user can edit (no collaboration). If already locked, display user/time info when hovered over lock icon. Lock user or authorized administrators can unlock.
          • Delete - will remove the version (if active version, previous version will become active).
        • Workflow - To be implemented in version 4.
      • Collection Options - Import and Export. Should these and other collection options be implemented as Method UIs somehow, for extendability? Or are these so specific and different then Method UIs that we do them as one-offs, at least for now? In either case, the should each provide a few options, including the format to import/export. JSON is only requirement, but CSV (already implemented to some degree) and others (PDF, XML, RSS, Excel) would be really nice. Would be cool if export actually just references a link to an export package/controller that is made visible to user so they can share for regular exports (great for integrations).
      • Method UI - Find Method UI objects in the repository for the object content type or "lowest common content type" for a collection. Method UIs are Content Type Method/Template attributes, which are used to expose a Content Type Method in the user interface by introducing an icon, label, help and other UI options. Initial method UIs will include:
        • Object.Share(Email) - If email address matches user, verify. If not verified or no match, offer to create user (use email for username, configure password reset code and use default user roles). Add user-specific role if not already exists. Add shared object(s) to that role. Email user (different message if new user or existing) to notiy of share and how to access. This will appear in all Object and Collection Action Bars becasue it is associated with Objects.
    • Collection Bar - Collection views and fields will display an additional bar just below the action bar or field label.
      • Edit - Edit collection mode toggle, to switch between view/select and edit collection modes. In edit mode, objects are orderable (when appropriate) and selectable (checkbox to left in list and grid views, toggle outline in map view, etc.). Edit button also provides drop-down with select all, none, invet, undo, redo, save and restore. If not in edit mode, drop-down items enter edit mode. When one or more objects are selected, Action Bar is displayed if not visible, and edit mode buttons (Open, Delete) slide in from left in the Action Bar, pushing existing buttons off to right. When no objects are selected, edit buttons slide back out to left, making more room for others.
      • Search - Performs AJAX search on objects in collection. Should use API search functionality, but could brute force search for now. Ideally update view as you type, if too slow wait until ENTER is pressed. If slower than X, could display animated icon in search (maybe magnifying glass changes) while waiting for Ajax response.
      • Filters (right aligned) - This can wait until v4.0. Drop-down list of data type fields for objects in collection (could do lowest common content type, but don't need to). When field clicked, popup displays control to filter list by values for that field. Control is specific to data type, so it may use Field UI info for control, but should provide range (maybe just min and max Field UIs for now, until we can add sliders, date ranges, etc. in the future). If there is room in search bar, most recently selected field filters are displayed to left of filter button.
      • New - When authorized and collection is based on a field, this button will create a new object based on the field type. If the field type is extended, displays a drop-down of type (first) and those that extend it. NOTE: field scope may limit the types, even restricting to one type, so only display drop-down when appropriate.
    • Form - Already have basics working for most data type fields and some content type fields, but still need to fill out more (reference lists in particular). Once all basics working, refine to completion before moving on.
      • Form Fields - First, consider better way to associate Form Field code with a form field (should they each be in separate files, or is it good the way it is?). Create a working default Form Field for each type of field, including all layout types, data types and content types. See Content Type Fields.
      • Collaboration - Could wait until after v3.0, but may need basics now to avoid confusion and conflicts. At a minimum check if field is not being edited by someone else on focus and report error. One step better is to display border and profile information on fields that are being edited by other users, and update as edits are made.
    • List - Basic features working, but needs to load longer lists on demand with AJAX.
      • Select Mode - Click or tap item to navigate to new cPath in appropriate Content View. Right-click or swipe left to display single item edit mode options to right.
      • Edit Mode - Enter/exit edit mode. Display action bar and/or slide in Open and Delete actions when at least one item selected.
    • Tree - Reduce load time by optimizing queries as cQL instead of cPath, or if needed, optimize cPath itself. Consider only loading folders and objects in vertical scroll view for longer lists if helpful.
      • Rename - Rename on click if object has displayed text line field (edit and save first displayed text line field).
    • Grid - Needs a lot of work to be complete. Sort by any column heading. Edit mode with check boxes to select, order handle to change order (including all selected items as group) and inline form field editors dynamically positioned on click (popup when needed). Edit should only be allowed in edit mode. Otherwise clicking an item selects it, similar to List view. Consider right-click and swipe right options similar to List view.
      • Collaboration - Similar to form view, show border and profile around cells being edited by others.
    • Chart - Basics aren't even in place yet. Need to think about UI and underlying code structure for this. At a minimum, be able to display bar, line and pie charts with object navigation and list view popup.
      • API Key - Come up with easy way to configure Map API Key, probably in map-view-specific settings object (view attribute).
      • Popup List View - Click on a chart area (bar, pie slice or other grouping) to display popup list view of the items in that grouping. Can be opened and selected.
    • Map - Already have basics in place. Need to add object selection, navigation and list view popup. Consider adding server-side clustering (client side will be too slow for huge collections).
      • Maps API Key - Come up with easy way to configure Map API Key, probably in map-view-specific settings object (view attribute).
      • Popup List View - Click on a chart area (bar, pie slice or other grouping) to display popup list view of the items in that grouping. Can be opened and selected.
  • ... fill this out once it is time to get back into it.
• Service - Implement COMAND Service as PHP script, meant to run in background or as a service.

3.5

• Integrations - Content type based integrations replace import/export.

• < Roadmap
• webCOMAND 4 >