Todo List

Class frepple::CommandMoveOperationPlan
Moving in a routing operation can't be undone with the current implementation! The command will need to store all original dates of the suboperationplans...

Member frepple::Operation::calculateOperationTime (Date start, Date end, TimePeriod *actualduration) const

not implemented yet

  • the availability calendar of the locations of all resources loaded

not implemented yet by the operation

not implemented yet

  • the availability calendar of the locations of all resources loaded

not implemented yet by the operation

Class frepple::PeggingIterator
does not support sub-operationplans

Member frepple::SolverMRP::solve (const Resource *, void *=NULL)

resource solver should be using a move command rather than direct move

The flow quantity is handled at the wrong place. It needs to be handled by the operation, since flows can exist on multiple suboperations with different quantities. The buffer solve can't handle this, because it only calls the solve() for the producing operation... Are there some situations where the operation solver doesn't know enough on the buffer behavior???

moving routing opplan doesn't recheck for feasibility of steps...

Class frepple::utils::DataElement
only takes care of transformation from external format to C++. Not the C++ to external format yet.

Class frepple::utils::HasName< T >::iterator
not thread-safe: needs to lock the tree during iteration

Class frepple::utils::PythonObject

endelement function should be shared with setattro function. Unifies the python and xml worlds: shared code base to update objects! (Code for extracting info is still python specific, and writeElement is also xml-specific) xml->prevObject = python->cast value to a different type

object creator should be common with the XML reader, which uses the registered factory method. Also supports add/add_change/remove. Tricky: flow/load which use an additional validate() method

improper use of the python proxy objects can crash the application. It is possible to keep the Python proxy around longer than the C++ object. Re-accessing the proxy will crash frePPLe. We need a handler to subscribe to the C++ delete, which can then invalidate the Python object. Alternative solution is to move to a twin object approach: a C++ object and a python object always coexist as a twin pair.

Class frepple::utils::TimeLine< type >::const_iterator
Make the timeline iterators fully STL compliant.

Generated on 25 Sep 2009 for frePPLe by  doxygen 1.6.1