quasicms/doc/TODO

BUGS:
 * logout does not know if the session has timed out .. FIXME, causes an error.
 * a wrong product id will cause error ..
 
* FINISH checkout:
    - paypal's IPN responder
    - PayPal button on first panel of checkout
    - ensure that there is an address to ship to - either that or just make the address mandatory
    - ensure that an account can only have one primary address - this should be a check in Account on save ..
         
* SECURITY:
    - audit payment submission trail and add checks; possibly use zencart transaction id or encrypt something
      like perhaps a checksum of order id, date and account id or such ..
    - better password encryption - use DES or something, possibly farm this out to the db server ..
    - check input, generally go through and make sure we are being safe anywhere input occurs, check
      especially for XSS and SQL injections. Most of this should be taken care of by QCodo
      but we should double check.
    - validate email address
    - validate zip?
    - validate phone?
TODO items and notes/ideas
    - make installation page
    - fix Account password edit page - it should  indicate when save happens  and reload the Account
    - make other sized images available in product view ..
    - NEED: blog or news module
    - NEED: module configuration scheme (table module_configuration?)
    - ... everything else.
    
* IMPLEMENT - "keep me logged in forever .."

* IMPLEMENT permissions checking/framework, (especially on the MemberMenu). the same goes for products
  and eventually (for bpcb) designs, content items and finally by page.

* IMPLEMENT - managing Persons, ie change/delete my people ...
           
* SEO - implement using .htaccess rewrites when possible:
    if(mod_rewrite configured)
        set Quasi::$Index = ''
    else
        set Quasi::$Index = '/index.php/'
    fix redirects:
        sed s/index.php/Quasi::$Index/g .. 

* do something with account avatars ..

* finish - generic oscommerce import, add categories, images, etc ..

* resolve page loading issue - either use Name or Uri, currently Name is used. Or we could try both ..      

* move any hard coded defaults either into configuration or the ORM classes

* ensure that ORM classes _have_ defaults where a column is NOT NULL.

*  put read define guards on all quasi files - if(!defined QUASI) die and also the include guard defines

*  minimally, brief intro comments for all classes, optimally a real entry with logic and example use
    - also  document non obvious members and methods, at least minimally.

*  clean up the CSS framework, finish implementing style loading from the database/admin UI
 and decide on a coherant approach to all this. needs a good deal of design thinking

*  there are some issues with content blocks appearing multiple times on the same page - won't
work. we need to either find a way around this or to prohibit it in the adminstration page. One
thing that may solve this is tighter treatment of CssIds - currently there are holes in the implementation
and I am not sure we need as much control over id's; its handy for scripting and specific styling but
might be a bit much and classes are much more flexible. Placing conditionals in the MetaControls to
see if they have been passed an id string is a possible solution which leaves it optional; if they are
there an id of type control field is created, if not it is autogenerated in the library...

*  Eventually remove cruft and unused methods from ORM, it would also be good to base class or
 make factories or interface classes for some of this as a great deal is redundant due to generation.
 might be able to script some conversion.

 *  Clean up quasi.css !! ...

 *  maybe make PageView a factory that will create a view for the page type. this may be too much
 flexibility though ... not sure about it, currently you can already do a lot with a "page" just via css
 and turning on the container divs, so far really everything i have needed to do, so this may be
 cruft.  extensibility is about my only reason to keep this, somehow i suspect page types would be
 handy - you could define for a type how the containers are loaded, currently there is only one
 order available... this might have proven handy with the account tool bar wars actually ... think.

 *  Installation page - as usual, if not installed run that instead of the index ..

* base class the shipping calculator and payment action classes - much of the data and behaviour
 is the same, especially the connection (and the paymentaction base class is better ..). This means
 a general purpose "WebServiceAction" class or such that a module or action can use to connect
 to a service, submit a request and read the response ..
 
 ###### Administration UI design notes #########
 
* if a contentblock is assigned to a parent block that is already on a page and you try to assign
it to the page again there is a controlid conflict - resolve this; either make it impossible to do
in the UI (not sure i like this ..) or implement a check in the loader that will alter the id for
duplicate blocks .. this same problem exists for any duplication of a block on a page.

* we need an interface that will create a page with "Add a Content Item"; it shoud do the
following:
    a. create the new page either like the rest or with a wizard .. it must provide sensible default
    layout, top-level menu, etc
    b. create a ContentBlock for the new Item, again this must have defaults
    c. provide an interface for adding the content item - by default this should go automatically
    in the center panel.
    d. automatically add the page to the top-level menu - this should be adjustable in a menu
    configuration section, but the default should be functional.
 
 this all needs to be very easy to use - i refer to SilverStripe's admin UI for an example of simplicity
 for the inexperienced user; it is very friendly and i would like to see something similar. I would like
 to implement something like the tree list that they use for arranging pages/menus

* when creating a page: tbd