On first read, you are totally correct in everything you are saying. So, that is my thoughts now, and great for completing this weekend:
1.) complete code documentation 2.) In parallell, fosdevel is adding the global aiki updater 3.) at that point I think we need to test the updater code massively 4.) update a few of our sites with the updater 5.) clarify what an AikiApp is, and also separate out the admin content in assets and the custom content, and figure out the clarity of what an AikiApp is purely, so can evolve that idea in future release 6.) push out a new release of the software to get the updater code out there, could be 0.9 or 0.85. 7.) We need to define what an AikiApp is more then, and grow towards a 1.0 release There is a lot more todo. The updater code is going to help us all drastically! I think then having the admin app and the custom app (whatever aikiapp someone makes with the default app) separated is going to give more clarity and will even let us write alternative AikiApps like a new editor/admin widget and make other apps/sites easier. This will also help us refactor and update the code internals easier, and have simple way for others to update their aiki instance! This allows us to iterate faster. Roger, would you like to take a pass at a plan on how we can update the internals more and take some of these ideas in your email as a type of coding best practices for aiki? I'm in complete agreement with your points. Also, seems to me the code that needs the most help is: * widgets.php * records.php * forms.php Cheers!!!! Jon On Fri, Jun 17, 2011 at 4:03 PM, Roger Martín <[email protected]> wrote: > The keys to future aiki success is simplicity, modularity, clarity, and > sturdiness. > > Modularity. > ======= > For example, a simple function that return a id for a given widget-name or > widget-id permits in few lines: > - widget calls by name in all aiki > - control better widget names convention, > - control access to widget by user group in all wiki > > Avoid code as widget.php (the core of aiki) with method that have more than > 1000 lines: untestable!! > > ------ example of modularity ----- > private function get_widget_id($widgetNameOrId){ > //Fictitious example...don't work. > global $db,$aiki; > if ( (int) $widgetNameOrId > 0 ){ > $field= "widget_id='$widgetNameOrId'"; > } else { > $field= "widget_name='" .str_replace("'","",$widgetNameOrId) > ."'"; > } > $groupID= $aiki->membership->group_id(); > $searchSQL= > "SELECT id FROM aiki_widgets ". > "WHERE widget_{$field} > " AND is_active='1' ". > " AND (grouplevel=0 or grouplevel=$groupID ) > " LIMIT 1" ; > return $db->get_var($searchSQL); > } > > > Clarity in little things > =============== > aiki class must be defined in aiki.php not in core.php > widget.php must have a class called widget. Other, called layout. > configs/config.php must be config file or renamed as > configs/config-template.php > A variable must be one purpose. For example > $widget_id = explode("|", $data); //now widget is a array. > $widget_id= $$widget_id[1]; // now a integer... > ..... > Hidden hacks must be avoid ( or prosecuted!!!): > do you know that widgets.normal_select admits two sql separated by |OR| and > the second will be used if the first return no result? > Why normal_select is parsed by L10? > why a widget that contains <form></form> is not parsed by our php script? > what is the fourth argument in (#(form:...)? > what are the difference between (#(widget:97)#) and(#(inherit:97)#) ? > > sturdiness. > ========================== > For example, admin interface depends of AJAX. Links are like : <a href="#" > rel="things-i-do">(1).If something go bad., how can you trace the error? > other example: put a deliberate error in /assets/apps/admin/urls_widgets.php > and try found it.. > > We are using ajax in the wrong direction. If link are like <a > href="/url/list/" rev="div-where-i-must-appears">(1), we can ajaxify calls, > but if something go bad is more simpler see where is the error (deactivate > javascript) > > > Conclusions > ========= > realization of new ideas depends on change our programing style. Then, the > priority must be: > - refactor widget and forms. > - robust admin interface > - new update procedure. > So..basically we are in the good. > > > > (1) see http://www.aikiframework.org/wiki/Aikimarkup > > -- Jon Phillips http://rejon.org/ | http://fabricatorz.com/ chat/skype: kidproto | irc: rejon +1.415.830.3884 (global) | +1-510-499-0894 (sf) +86-187-1003-9974 (beijing) _______________________________________________ Mailing list: https://launchpad.net/~aikiframework-devel Post to : [email protected] Unsubscribe : https://launchpad.net/~aikiframework-devel More help : https://help.launchpad.net/ListHelp
