Todo List
UI
- Move these to Overlay (which is the first class that can have effects)
- Should this be moved up into WFView? If so, make sure block.WFViewHiddenHelper.php still works.
- Anything else wrong with calling more than once? This should be idempotent as well as re-callable with different data.
- Make the UI system use this call instead of stringForValue()
- Rename this to executePage or something... this actually runs the whole page infrastructure!
- Something is goofy with the detection of isRequestPage surrounding the action processor... seems to be getting called on the response page too. investiage.
- For efficiency we might want to figure out a way to load it on-demand.
- Factor out propel loading into self-contained custom callback function.
- refactor initPage to move the code from there to here so that it's available earlier in the life cycle.
- Right now this just wraps queryDescription. Eventually re-write here to use a "pretty" description built a la buildQuery.
- Need to make it not-hard-coded to get the form_error.tpl file... should be able to override this in userland.
- Have the system look for the tpl in a userland directory first.
- Have the system look for the tpl in a userland directory first.
- Should this be in WFRequestController?
- Do we need a WFObject::keyExists() function or similar that can "check" for a binding without having to call the accessor? or WFObject::canSetKey()? Or do binding need to have a "readyonly" or "writeonly" option?
- HMM.. I think WFCheckboxGroup already works just like WFRadioGroup.... need to check it out and document. Make the interface consistent for both widget types.
- UPDATE with WFDynamic support a la WFRadioGroup. Actuallym look at both methods (WFSelectionCheckbox vs. WFRadioGroup+WFDynamic) and see if there's any real difference.
- $facet used throughout our WFDieselFacet is actual an AttributeValue object. Confusing; need to re-name.
- check out FacetGenerator.hasMore()... maybe good for long-ass lists. maybe switch from sortByFrequency to alpha once "more" clicked? use with popup edit
- Facets seem to be generating the link to themselves... is this a DP bug? Why would one want to show the current selection? Is it confusing?
- Implement multi-select facets: AND vs. OR.
- Implement TREEs.
- treeRoot cookie trail linking isn't quite perfect yet...
- finish attributeQueryLogicalOperators: add to querystate, buildquery, etc
- I think maybe that WFDynamic should be completely transparent to the view heirarchy. However, currently, subclasses of WFDynamic may not agree. Please check them out and see if this can all be refactored in a better, more consistent way. Maybe WFDynamic should be final? Definitely look into this and WFCheckboxGroup as well. There are related todo's in there.
- Now that valueForString() can return NULL as a legitimate value, need to look at existing formatters to make sure they're compatible.
- Do we need a way to specify a module/page for creating links dynamically? Either a parseable syntax in the "value" field or additional properties?
- Add support for tooltop, linkTarget, and icon
- Once bindings are moved to WFView, this should probably be made into a WFView subclass since it does not use "value" or represent an interactive control.
- Add editingStringForValue capability
- Implement full suite of formatting styles, like that of NSNumberFormatter. There are 5 basic styles, None, Decimal, Currency, Percent, and Scientific.
- Some more refactoring... it's odd that the class has to figure out if it's the requestPage or responsePage. I think instead they should be 2 classes. The base class, WFPage, should be the response page, and the WFRequestPage subclass should add methods / functionality for restoring state and triggering actions, as I think that's the only two things it does more than the responsePage. ** What about errors?**
- Is it possible to make readPaginatorStateFromParams() happen automatically?
- Make sure that the pagination links work properly when this widget is in a composited view. Not sure how the params will work from __construct etc...
- Make sure that the pagination links work properly when this widget is in a composited view. Not sure how the params will work from __construct etc...
- Make sure that the pagination links work properly when this widget is in a composited view. Not sure how the params will work from __construct etc...
- Add property "blankOK" which will not consider it an error if ALL fields are blank (assume "no change"). default TRUE.
- Add property "enterPasswordValidateDuplicate" - will show 2 fields and automatically validate that they're the same (great for "sign up" or "change password" feature). default FALSE.
- At some point in the future, maybe fall 2008, remove the embeddedcontent_min stuff because it should be fixed: http://www.swffix.org/devblog/?p=19
- WFDynamic may need a little refactoring to avoid inserting itself into the view hierarchy. If we refactor, take out WFDynamic stuff.
- Add support for OPTGROUP. I think to do this we'll need a separate way to do values/labels/options for OPTGROUP capable.
- Refactor to coalesce createWidgets and createSelectionWidgets
- Should WFSelectionCheckbox use WFCheckboxGroup internally for consistency?
- Also need to decide about phocoa.js and prototype.js; should these be included in the skin, or by the widgets that need them (I think this is tricky b/c then those widgets can't be added via AJAX since these base js files won't exist), or by modules that know they are using them?
- deal with layout/css/alignment; locale issues?; formatter?
- buildModuleProgrammatically needs a way to specify a parent element to add the module to.
- Add capability for multi-selection of tree items. This one is gonna be tricky! Esp. with dynamic data; need to keep track of checked items even if they never become visisble.
- Deal with filters.
- Document.
Mail_Mailer
- Need to finish packaging and documentation and submit to PEAR!
KeyValueCoding
- Normalize property names. Keep naming convention; properties should read like "class property -> WFArrayController selectsInsertedObjects"
- Should there be a "canSelectMultiple" setting? This was if you're using it in a Master-Detail interface it'd be easier to manage the selection? In this case a combo of selectOnInsert and addObject would make it easy to managed. NO! This is an attribute of the "matrix" widget, not the controller. ArrayController should always be "on" for multiple selections.
- Upgrade to cocoa-compatible defaults DONE! avoidsEmptySelection TRUE - ADD this function DONE! selectsInsertedObjects TRUE - deprecate selectOnInsert, but keep func for BC. WE will keep our FALSE because it makes more sense. Something is wrong with #arrayIndexes# mode I think... see todo's (not yet implemented) preservesSelection TRUE
- Does formatter need to assert for !readOnly? or MULTIVALUE? anything else? I think truly we only want to do it on multivalue bindings, b/c o/w you should just use the widget's formatter. Also, it should only work on read-only ones lest someone get the idea that it can go both ways. http://developer.apple.com/documentation/Cocoa/Reference/CocoaBindingsRef/Concepts/BindingsOptions.html
- Incorporate commonly used binding options here??? In addition to valueTransformer? I think I ended up putting a bunch in WFBindingSetup... coalesce?
- Should we standardize the 4th parameter of all of these functions to take in an array of options? For instance ('required' => true, 'country' => 'US')O This will provide a more consistent interface and make the canned validators ready if we decide to be able to add validation via configuration
- Upgrade to cocoa-compatible defaults automaticallyPreparesContent FALSE --> BC-breaking CHANGE; will require testing all apps that use it avoidsEmptySelection TRUE selectsInsertedObjects TRUE (not yet implemented) editable TRUE preservesSelection TRUE
framework-base
- Convert this to use the www root in the skins/ dir rather than the wwwroot/skins/ dir to consolidate skins into a single subdirectory
- Convert this to use the www root in the skins/ dir rather than the wwwroot/skins/ dir to consolidate skins into a single subdirectory
- Not yet implemented! Where to get email address from? probably WFWebApplicationDelegate, overridable by param Also need to write WFSmartyMail class?
- convert the DIR_SMARTY calls to use a new WFWebApplication::getResource($path) infrastructure that will allow for userland overloads of these templates
- REMEMBER ME code to actually set up / read remember me cookies it NOT implemented.
- Remember Me - there is no implementation yet. Need to "set remember me cookie" in login module (do we need another callback for "rememberMeHash" to get the hash?), clear it in logout, and add support for auto-login if remember me detected in WFSession. Also, make sure that it all interacts with recentLoginTime stuff.
- captcha option
- Remember-me logins not yet implemented.
- Need to have all PHOCOA exceptions that are thrown switched to WFException so code can distinguish b/w PHOCOA and external exceptions.
- Why add WWW_ROOT to the invocationPath checks? is this from the form or something? seems like it's not an invocationPath if it starts with that... document/comment when you figure out why.
- Do I need to pass in the WFSmarty instance here so that you can actually change the TPL file from this callback? If so, also update the willRender() delegate docs/prototype
WebApplication
- Handle 404 situation better -- need to be able to detect this nicely from WFModuleInvocation.. maybe an Exception subclass?
- PATH_INFO with multiple params, where one is blank, isn't working correctly. IE, /url/a//c gets turned into /url/a/c for PATH_INFO thus we skip a "null" param. NOTE: Partial solution; use /WFNull/ to indicate NULL param instead of // until we figure something out. NOTE: Recent change to REQUEST_URI instead of PATH_INFO to solve decoding problem seems to have also solved the // => / conversion problem... test more! WORRY: That the new PATH_INFO calculation will fail when using aliases other than WWW_ROOT. IE: /products/myProduct might break it...
- Should this be named isRootModule? This would be more consistent with setTargetRootModule/targetRootModule.
- Allow properties of page.config files to use shared instances.
- Add a WFModule::willRender() callback called from WFPage::render() to easily allow module-level skin stuff
- Do we need to encapsulate the "login" module in a method of WFAuthorizationManager so that applications can override the login module with their own?
- Evaluate whether the WFModuleInvocation and WFModule should be coalesced into a single class... can they be used apart from each other?
- Eventually we'd like the ability to have multiple BASE directories containing modules. Mainly the purpose of this is so that the framework could ship with some modules, and they would be accessible, but in a different place from the user's modules. We have to make the framework easy to update separately from the user code. We could have some "aliases" inside the path-walking stuff that would shunt over to another dir. for instance, maybe if the first path was "contrib" it would shunt over to contrib/modules/ or that kind of thing.
- Do we need sessionDidStartForFirstTime()?
Documentation generated on Thu, 17 Apr 2008 13:52:25 -0400 by phpDocumentor 1.4.1