Generic implementation of $searchable_fields on DataObject, with definition for different searching algorithms (LIKE, FULLTEXT) and default FormFields to construct a searchform.
Allow for other HTML4 doctypes (e.g. Transitional) in html()
Check for correct XHTML doctype in xhtml()
Make content replacement and doctype setting two separately configurable behaviours - some devs might know what they're doing and don't want contentnegotiator messing with their HTML4 doctypes, but still find it useful to have self-closing tags removed.
Allow for other HTML4 doctypes (e.g. Transitional) in html()
Check for correct XHTML doctype in xhtml()
Make content replacement and doctype setting two separately configurable behaviours - some devs might know what they're doing and don't want contentnegotiator messing with their HTML4 doctypes, but still find it useful to have self-closing tags removed.
figure out how we pass configuration parameters to search filters (note: parameter hack now in place to pass in the required full path - using $this->name won't work)
Refactor to using FileIFrameField and ImageField as a controller for the upload, rather than something totally disconnected from the original Form and FormField context. Without the original context its impossible to control permissions etc.
Admittedly this is a bit of a hack; but we need a way of ensuring that large TEXT fields don't stuff things up for the rest of us. Perhaps a separate search table would be a better way of approaching this?
Access-Control for relations (you might be allowed to view Members and Groups, but not their relation with each other)
Access to decoratable methods/relations like SiteTree/1/Versions or SiteTree/1/Version/22
Allow for range-searches (e.g. on Created column)
Allow other authentication methods (currently only HTTP BasicAuth)
Custom filters per DataObject subclass, e.g. to disallow showing unpublished pages in SiteTree/Versioned/Hierarchy
Exclude relations when "fields" are specified through URL (they should be explicitly requested in this case)
Filter relation listings by $api_access and canView() permissions
Finish RestfulServer_Item and RestfulServer_List implementation and re-enable $url_handlers
i18n integration (e.g. Page/1.xml?lang=de_DE)
Implement PUT/POST/DELETE for relations
Make SearchContext specification customizeable for each class
Respect $api_access array notation in search contexts
URL parameter namespacing for search-fields, limit, fields, add_fields (might all be valid dataobject properties) e.g. you wouldn't be able to search for a "limit" property on your subclass as its overlayed with the search logic
Access-Control for relations (you might be allowed to view Members and Groups, but not their relation with each other)
Access to decoratable methods/relations like SiteTree/1/Versions or SiteTree/1/Version/22
Allow for range-searches (e.g. on Created column)
Allow other authentication methods (currently only HTTP BasicAuth)
Custom filters per DataObject subclass, e.g. to disallow showing unpublished pages in SiteTree/Versioned/Hierarchy
Exclude relations when "fields" are specified through URL (they should be explicitly requested in this case)
Filter relation listings by $api_access and canView() permissions
Finish RestfulServer_Item and RestfulServer_List implementation and re-enable $url_handlers
i18n integration (e.g. Page/1.xml?lang=de_DE)
Implement PUT/POST/DELETE for relations
Make SearchContext specification customizeable for each class
Respect $api_access array notation in search contexts
URL parameter namespacing for search-fields, limit, fields, add_fields (might all be valid dataobject properties) e.g. you wouldn't be able to search for a "limit" property on your subclass as its overlayed with the search logic
Implement a special "translation mode" which triggers display of the readonly fields, so you can translation INTO the "default language" while seeing readonly fields as well.
Document the different source data that can be used with this form field - e.g ComponentSet, DataObjectSet, array. Is it also appropriate to accept so many different types of data when just using an array would be appropriate?
Make use of FormField->createTag() to generate the HTML tag(s) for this field.
Document the different source data that can be used with this form field - e.g ComponentSet, DataObjectSet, array. Is it also appropriate to accept so many different types of data when just using an array would be appropriate?
Make use of FormField->createTag() to generate the HTML tag(s) for this field.
Control width/height of popup by constructor (hardcoded at the moment)
Find a less fragile solution for accessing this field through the main controller and ReferencedField, e.g. build a seperate CTF-instance (doesn't necessarly have to be connected to the original by ReferencedField)
Integrate search from MemberTableField.php
Less performance-hungry implementation of detail-view paging (don't return all items on a single view)
Use automatic has-many and many-many functions to return a ComponentSet rather than building the join manually
Control width/height of popup by constructor (hardcoded at the moment)
Find a less fragile solution for accessing this field through the main controller and ReferencedField, e.g. build a seperate CTF-instance (doesn't necessarly have to be connected to the original by ReferencedField)
Integrate search from MemberTableField.php
Less performance-hungry implementation of detail-view paging (don't return all items on a single view)
Use automatic has-many and many-many functions to return a ComponentSet rather than building the join manually
has_many/many_many relation autocomplete field (HasManyComplexTableField doesn't work well with larger datasets)
Long term TODOs:
Hook into RESTful interface on DataObjects (yet to be developed)
Permission control via datamodel and Form class
relation formfield scaffolding (one tab per relation) - relations don't have DBField sublclasses, we do we define the scaffold defaults. can be ComplexTableField instances for a start.
saving logic (should mostly use Form->saveInto() and iterate over relations)
has_many/many_many relation autocomplete field (HasManyComplexTableField doesn't work well with larger datasets)
Long term TODOs:
Hook into RESTful interface on DataObjects (yet to be developed)
Permission control via datamodel and Form class
relation formfield scaffolding (one tab per relation) - relations don't have DBField sublclasses, we do we define the scaffold defaults. can be ComplexTableField instances for a start.
saving logic (should mostly use Form->saveInto() and iterate over relations)