Yes, I found it too. But if we will gonna put php in aiki then we should forget about <aiki and put <php? ?> and <?= ?>. this can be another engine (thanks to Roger), so users can switch to php if they want.
Aiki should be ship with few engines and admin panel should allow users to select which they want, I thing that we will have more users if we support wiki, smarty, moustache, php and our own Aiki markup (which I think will be simpler that php and should be the default) out of the box, and we can add new engines that are well known. And if we use only php we will non need lots of stuff like widget level sql, pagination (which is connected to sql). Users will non need forms because they are pain to use (and if there will be no aiki markup this will not work "(#(form:"), so they will probably use php instead, so whole idea behind aiki disappear. So the only thing they will have is to split they code into widgets, which will not give advantages over other tools, why they will what to split they code into widgets? it will complicate they application. So conclusion is that we should create our new markup and make it bullet proof. On Thu, 23 Feb 2012 02:10:42 +0200 Bassel Safadi <bassel.saf...@gmail.com> wrote: > here is a cool project https://github.com/nikic/PHP-Parser > we can get inspired or use this for aiki markup. we should just > allow peaceful php code to be excuted inside the widgets instead of > inventing new markup. it's easier to just write php. > > -- > Bassel Safadi | http://bassel.ws > Skype: i.know.sy | Global: +1-323-545-3855 -- Jakub Jankiewicz twitter: @jcubic www: http://jcubic.pl _______________________________________________ Mailing list: https://launchpad.net/~aikiframework-devel Post to : aikiframework-devel@lists.launchpad.net Unsubscribe : https://launchpad.net/~aikiframework-devel More help : https://help.launchpad.net/ListHelp
