rocksolidwebdesign / awecms Goto Github PK

Lacking this prevents deletion of sub records because it appears that Doctrine either doesn't use InnoDB or doesn't add the constraints

Set up some reasonable column based defaults such as Zend_Form_Element_Text for type="string" on the @column annotations so that the user only needs to add an empty @AWe annotation to set up the form and can then further customize if desired

Implement a config setting to let you choose your theme

Set up the doctrine config to check for entities in the various module folders so that entities can be coupled per module, also aiding in the core vs 3rdparty separation so that 3rdparty modules can have their own personal entities.

When e.g. editing a specific article and not yet logged in, the redirect goes to the edit page but drops the params so you just end up at a "create new" page.

Implement model elements that can only be set on creation, and then the form field is greyed on on the edit form (possibly also set a restriction on the backend to simply skip these fields so that even if somehow erroneous data gets passed, the field will not update.

Useful for things like e.g. an SKU or something that should never change after creation for accounting history purposes, or whatever.

The save action of the controller currently just uses the column names to figure out what to do, e.g. if the column name ends in _id then it knows it's a foreign key. This is not robust and poses limitations in terms of column naming and is not very stable either. This should be changed to use the actual schema information and the annotations.

I thought that layout partials didn't take vars, but they do, it's just the layouts themselves that have separate var spaces from the view, but if you put a partial in a layout, that partial will use the template vars assigned to the view.

Placeholders apparently take up a lot of memory, not only that but the way this is currently implement a completely new and extra Zend_View has to be instantiated to be able to pass data to so that the placeholder can be dynamic. Right now you have to pass data to a new view, then render that view, take the resultant html and pass that html to the placeholder.

This should be changed to just package up the vars in an array (to prevent namespace conflicts) and pass that data to the partial.

Implement Zend_Form_Element based CKEditor and or TinyMCE because the current dojo rich text editor does not allow switching to plain HTML view.

Write a custom "database" route for the CMS using the Zend "database" route. Also implement caching on this route.

Implement a list view for subentities instead of the inline edit, e.g. on blog comment edit page, the bottom would just have an HTML table with the list of associated comments and then you could click the edit link for each comment one at a time. Implement an annotation to be able to choose between inline edit and "regular" list view for sub entities.

figure out how to get the DojoX plugins for the editor working with Zend_Dojo_Form_Element_Editor

The dynamic widget feature should be changed to be per layout, there should be an extra model called "widget_layout" that combines a layout template file with a list of widgets, then things like the CMS should be able to have both a default "widget_layout" and if desired, a per page override to use different "widget_layouts" per page.

Setup and enhance the defaults for the Zend_Dojo_Form_Element_Editor to allow e.g. source view and more buttons

implement URL based full page caching, md5 the URL and place the cached contents in to a file with that name (or into whatever works, whatever APC uses, etc)

Add JSON (and possibly support for XML) compatibility to the autocrud when you append a parameter like /format/json or /format/xml

Create an admin interface for managing files uploaded through using the file-upload annotations on models. Ideally there would be nested categories available for organization and navigation.

implement a way to add and change application wide configuration settings.

Start with database table key/value pairs.
Next use JSON config files
Next save the hydrated JSON files into serialized php for caching

yeah, not cool... investigate extending dijit.Editor to not suck? try to just use CKEditor?

Restructure the filesystem for core vs 3rd party plugins and layouts etc... set up git submodules to deal with keeping the Awe core and the project specific code bases separate.

Set up the bootstraps to allow placing custom routing rules in each bootstrap file rather than in the master routing file, further allowing customization of core vs 3rdparty code

implement pagination of results on the list view of the auto-admin pages

It seems slightly difficult to pull both the schema information and the annotation information together - this results in issues like repetition of things like the column name on both the annotation and in the name of the class property. the system should just have both the schema and annotation information side by side so it knows what's what and the user doesn't need to repeat themselves when writing models.

Implement a JavaScript based Datagrid like jqGrid or Dojo Enhanced Grid on the list view of the auto-admin. Implement a configuration setting to choose between the standard paginated hard coded grid or the dynamic ajax style datagrid.

Add a new annotation on models for file uploads and implement form processing to handle the uplaods. Would be good to have both "file system" based storage as well as "blob column" database storage. Probably implement the file system based version first.

Once the list view is implemented for sub-entities (instead of the inline edit style) and once the datagrid is implemented on the main auto-admin list pages, implement that datagrid for subentity lists.

Extend the abstract bootstrap to provide my own bootstrap that will check a list of enabled/registered modules at boot time so that only the module-bootstraps of modules that are active will actually be loaded, thus eliminating all functionality/overhead/routes/etc