The stack :

 caching 

 new templating system : sorting for lists w/ pagination ( example )

 new templating system : better error messages
 new templating system : add radio boxes

 Cron still has problems?

 Clear out obj manager cache and guest token by checking who logged in times. Good thing for cron.


 rewrite yote_util and define special characters better ( scaffold this...replace one piece at a time since its largely working )

   First thing - the flow of execution
       * variables are registered
       * ui_init is called
       *   init checks for yote_panel and control_panel classes to run el_init on
       *   el_init is called for each of those that are not marked as completed
       *         el init fills in the anchor points ( the div or other element that has the class name ) by analyzing the attribute values of the element.
       *         if part of the fill in includes an other yote_panel or control_panel that appears in a cell of an item row ( control_panels show lists of items in rows ), then the magic $$ variable is assigned to that item.
 ( talk about how $$ is the default item and is assigned if there is no item attribute )
       *   if el_init had been called, it may have written more yote_panel and control_panel elements so ui_init is called again

   options :

    

          - wrap the value in a javascript function as the return and invoke it..thus
                      prop="$variable"  looks in registered variables for the value and places it in during INIT 
                      prop="&some_app.get_foo()"  would return the value of foo for some_app immediately during INIT
                      prop="&function() { return some_app.get_foo(); }" would return a function that would return the value of foo for some_app
                      prop="~html" puts the html value into the propery or column value
                      prop="[....]" assign the value of the data structure to prop. This is eval'd
                      prop="{....}" assign the value of the data structure to prop
		      
     OK, this is hard to at first wrap ones head around. At the time of writing I don't copmletely yet either.  
     Have to meditate on the flow of exectution :
           

		      
 hash_paginator in js like list_paginator

 attrs for html entities : maybe prefix these with 'yote' and catch all attrs that begin with yote ( see init_el function ( aroun dline 839 ) of yote.util.js

 Reset cron
  
 Control table filter/search

 How about admin making accounts validated. Also account change its email now validates.
  Ugh, more todo? Well, I want to have a good way to update the UI when a list even happens. The UI does not usually keep list objects in it, just slices of them, 
   and those slices do not get updated when things get added to the list ( or hash ) object.
     [ so, my thought for the above is to register an object/list pairing using ObjManager, then mark the lists as a list dirty when updated
       The objmanager will know which account is tracking which lists.
       On the client side, there can be event handlers that fire when objects or those lists are updated ]




  Testing : need a test for the web app server.

  Idea for updating things...Use something cron like - a program that is run once and does things like $root->get_foo(afdasdf);

  Also, how about an even handler for when an object does receive an update, and an update to its list.
  
  make sure yote_root http pages are not overwritten during install/upgrade

Currently on my plate :
  * think about validation, login vs account.  would you have the case where one login would be valid in one app but not an other?  Of course, the app itself could override the token_login method to die if the desired configuration is not met.
  * yote.js object handle objects
  * template 
  * update madyote pages
  * limited html widget that disallows invalid html and script.
  * text only editor
  * object editor
  * object command line
  * better error messages for javascript when permissions errors occur
  * log in with email as well as handle
________________________________________________

It would be nice to have a <DIV> have information that links it to an editing session.
Something like
<DIV object="objname" field="somefield" editable="root||owner||all||none" editfilter="text|html|limitedhtml"></DIV>

where limitedhtml disallows script tags and certain tags. It might whitelist a set of tags.

It would be supernice to extend this to control tables

<DIV object="objname"
     list_name="foo"
     fields="foo,bar,baz"
     field_titles="Foo,Bar,Baz"
     can_remove="true"
     can_create="true"
>
</div>

_________________________________________________

The Phases :
  * GET IT WORKING        Alpha 1
  * GET IT CORRECT        Alpha 2
  * GET IT COMPREHENSIBLE BETA  1
  * GET IT PRETTY         BETA  2
  * ADD MORE FEATURES     BETA  3 / Release Candidate 1 

Currently
   Alpha 1 is complete
   Alpha 2 is nearing completion
   Beta  1 is started in parallel
   Beta  2 has a few things started   

  * try/catch on the javscript side. dump the cache should there be exceptions that would warrent that.


Beta 3
 MORE FEATURES
  * Add object versioning? Store a new field in the database : version. Then _load can be used to check the version.
  * Security improvement : offer up proxies for other users' accounts. This makes sure that
     the client does not access account data it shouldn't
  * More yote tools
  * Add at least simple modperl support. Maybe use plack?
  * method to get version to client
  * add GRU module for searches against tag lists
  * yote objects that bridge to files an allow for editing.
  * For cron, a repeat_special - something like 'first tuesday of the month or something like that' ( can deal with this much later )
  * Something to kill and restart all server threads to refresh classes

Beta 2
 GET IT PRETTY
  * admin page prettier
  * remove password display from launch
  * do not show even scrambled password when generating config
  * madyote edit program - html in objects accessed from WebAppServer. This means that YoteRoot will be checked for html files if the filesystem does not have them. This allows for easy editing of the web pages from the web, wiki style for admins. The files can be flushed to disk after editing. Controls to add pages should be there, etc.
  -* add test for disabling / enabling accounts and logins
  -* account and login enabling and disabling.
  * Do not send whole object in a list if the client already is known to have it ( may just send the id in any case and the client would automatically fetch it )
  * Fix page counter
 -* Make simple WIKI for updating Yote News
  * build page editor
  * make into daemon if possible. did not have much luck with this before
  * implement email validation request
  * implement a list_delete that removes from a specific index. (rename old list_delete to be remove_from )
  * control_table to work with the cool built in pagination that objects already have!
  * MongoIO pagination update - use different collection for large tables
  * for mongo db, maybe do a separate collection for list parts. When a list is too big, maybe its object nodes uses this other collection to split the list.
  x* caching of paginated lists ( wont do now )
  * Add timing alarm and max execute length parameter for configuration ( though use something other than sleep, a watchdog thread maybe

 js/perl IO
  * have methods sent just once per class
  * clean up widgets to make sure tag id fields are unique. prep_edit, for example, does not guarantee this
  * bug : undefined showing up for undefined me.prefix_classname

Beta 1
 GET IT COMPREHENSIBLE
  * review all methods and classes and remove those that no longer fit
 -* Indexing for lists always starts at 0...no jumping around with undefs? Agreed. Done and done.
 x* Cron - make scheduled_times a list of objects with 'time' and 'note' fields.
  * add comments for crons
  * Document all the widgets
 -* for control_table, show showing a-n of y numbering.
 -* Move MongoIO, etc, to an IO sub package
  * Create admin pages
 -* Unify unit tests for different stores
 -* add test only requirements to Build.PL
 -* include app class rather than app id in the IO
 -* Create yote admin page for
        -* viewing apps
        -* viewing user login objects
        -* cron admin
  * Create guest page to be hosted at madyote.com
 -* build yote homepage
  * reorganize package structure
  * Update how logging is done. Access log and error log like apache. Capture STDERR and collect to error log
  x* consider moving this list to github for tracking. ( this is always here. just need discipline to do it)

 Javascript Side
  * control table for scalar list entries ( javascript )
  * control_table sort
  * nicer cron crontrol. Decide how cron gets done. Use minute or second? I'm guessing minute.

Alpha 2
 GET IT CORRECT

 Perl Side
 -* sendmail setup
 -* unit tests for new permissions models for Yote::Obj, Yote::UserObj, Yote::RootObj
 -* cron reclaculate not working for scheduled times. fix
 -* check to see if recycling needs the rest shut down. Actually fixed in the IO modules so that objects can only be recycled after being completely written to disk. 
    May need more testing of course.
 -* add tests for list_insert, list_delete, hash_insert, hash_delete ( done, needs test )
 -* make sure dirty is marked for list_insert, list_delete, hash_insert, hash_delete. (add a dirty_if_present?)
 -* make sure search and sort fields can both be given. update the tests for that.
  x* Permissions updates
        -x* Consider with the LOCK_MODE change below. Maybe the default should be make things as permissive as 
           possible and the user can override that permissivity, possibly with a set of tags or conditions to allow the thing to happen.
    	   with a double underscore as the reserved space for this __. The goal for this is ease of programming. Maybe the default is
    	   the object creator or root can edit it. CRUD permissions? Or use the subclassing below ( or even configuring with __ )
         x* configuration for LOCK_MODE
 -* Object Locking updates. The objects can be cooperatively locked between threads with the _lock method on the object. This requires that the user 
 -* new subclasses for Yote::Obj, one that allows anyone to update its fields, and the other that allows only root to - these should supplant creating some objects. may be made moot with the permissiveness above
 x* Exclusive cron. Means cron entry must have a unique name and that by default only one of that name may be run at once.
 x* changed permissions model so that YoteRoot checks if accounts are root. (won't do it now)
 -* complete test cases for hash pagination
 -* search_hash for all IO types, as well as tests for it ( just one sort )
 -* add sort for control table for Mongo and Mysql
 -* unify sort, search and pagination
 -* Move encrypt_pass to somewhere self, maybe? Moved to ObjProvider
 -* Make guest tokens required for running any non-root app command.
 -* Enable caching that pays attention to who has what.
 -* Make installer work for the common case of user having root. [ done, needs testing ]
 -* Have server respond to javascript permissions requests. ( this is now moot )
 x* update to not use backticks for cron ( since admin crons, it should have freedom )
 -* replace Crypt:Passwd with something better.


 Javascript Side
 -* javascript bug! if an object is returned in a list that already was in the client, bad things may happen
 -* test for pagination in unit_tests.html
 -* Control table : make sure that html tags it creates have appropriate classes. Use the new 'prefix_classname' variable
 -* update control table widget to use new paginate
 -* UI - account change password and request password reset link [ note - may need configuration for mail. may not need anything fancy, just something to pipe to sendmail or telnet to port 25


Alpha 1
 GET IT WORKING

 -* add_to, remove_from, delete_key - Obj methods to allow for list or hash manipulation off of this object. Will work only for root if _ is the first letter
 -* count for searches! This is missing and makes control_table buggy.
 -* add option to yote_server to do a full reconfiguring of the server
 -* deadlock test cases
 -* cache clearning test cases
 ?x* refactor Mongo IO to include better back references. Object will have to take note. ( again, maybe not with the new paginate )
 -* Enable Cron
 -* Create program to reset root password
 -* Create program to reset whole config ( code for this is done as part of Yote.pm )
 -* installer so that other scripts work (rename them to yote_ )
 -* make sure installer script works universally ( well, windows fails due to threads :( )
