so here is why I think aiki is useful for and why I started writing it in the first place, when working on custom database driven websites that are actually only database tables with different designs and different relations between those tables you end up (after designing the database) doing forms to insert - update - delete data. so first thing came to my mind is to automate this task with aiki forms. and by that time aiki was only form generator to help me with those forms-database tasks. this is something aiki do pretty well but also can be improved, now you can click on any table and generate a form for it then play with how the form should look then throw it somewhere.
after that came the other problem when working with database driven websites: you end up doing the exactly same thing each time with different sql queries and different output/html you name it. so I started to think how to automate this task and how to make a tool to only write the sql and the html. what you said about css is true. but still you can use a .css file and it's a faster way of doing things. now here is what I think of aiki, and forget all the new markup that people have to use only to do some specific tasks but in general any one can build a database driven website knowing only sql and html and this is the idea behind aiki. now if the current version doesn't do that we should work to make it that simple. aiki saves time because you only need to write sql and html. and it has many built in functions that are easy to use such as membership management and forms handling. so for those tasks I didn't find a name so called it a framework but you can call it whatever you want. this is what aiki do. now for the performance questions this is long and complicated issue but in general since each peice of an app goes throw one model (widgets) it's easy to control the performance by optimizing the way content get transfered from database to html view. other side of this is security where it's easier to control aiki security since there is one door for everything and one exit. I'm happy to discuss each aspect of those and also to work to improve the vision and the status of aiki. -- Bassel Safadi | http://bassel.ws Skype: i.know.sy | Global: +1-323-545-3855 On Thu, Jan 5, 2012 at 4:43 PM, Nathan Kinkade <[email protected]>wrote: > Aiki is a platform for building CMSs? In what way? I keep hearing > and reading about how Aiki is a "framework", but can someone please > define "framework" for me? Are you saying that Aiki is a drop-in > replacement for things like Django in python or Kohana in PHP? Can > someone show me and example of how this is achieved, and even better a > live example, and tell me how it differs from Drupal, Joomla and > WordPress in terms of functionality (not details)? > > What good does a widget ID do me? As far as I know you can't lookup > anything by a widget ID in the admin interface? You need to know the > widget name, and even them it's still ridiculously hard to find it > because it may be buried under some other meta-widget, or whatever you > call it. What speed benefit? Consolidating all CSS is old news for > websites. > > All this stuff about not having to touch PHP seems crazy to me. All > you've done is reimplemented a pseudo-language in some very limited > markup. This makes me think of the Smarty template language, or even > wiki markup. In both cases the object was to make things simpler for > the user, but in reality it's just one more markup language that > someone has to learn to do anything and it would have been more useful > for the user to just learn the basics of the original languages, like > PHP or HTML markup. And to make matters worse, you then need to write > a parser to parse all this newly invented markup, only to turn it back > into PHP and HTML and SQL, or whatever. It's a terrible line of > indirection that is unnecessary. > > But as much as anything, can someone please explain to me why Aiki was > written? What specific problem is Aiki trying to solve? The best > software out there was written because someone perceived a serious > lacking in the existing available tools, so they wrote some code to > fill this gap or go beyond existing tools. If the answer is that > "it's all in the database!", then that is no answer to me, because I > view the fact that it's all in the database a strike against Aiki. > It's a pain in the ass because you are cut off from using decades > worth of amazing tools meant to work on binary and text files, and are > limited to grubbing around with SQL, which is a relatively weak > language. If the answer is that having things in the database makes > Aiki vastly faster, then I'd need to see some hard data and tests. I > read the performance comparisons in the wiki, and they don't tell me > anything that seems legitimate. I mean, how fast can Aiki handle a > document with 10 million links compared to Mediawiki? Come on, that > is not test, and it is designed specifically to hobble Mediawiki > because you know it has to parse all links with the Linker. > Additionally, no document will ever have 10,000,000 links. > > Again, I don't mean all this questioning to be a criticism of the > people who have spent a lot of time developing Aiki. They are just > natural questions that are coming up for me as I thinking about > working with Aiki. You all need a viable story for Aiki, one that > will pass someone who knows anything about computers and technology, > not just someone reading it for buzz words and hype and is impressed > because they don't know any better. Has anyone else other than > Fabricatorz or a Fab affiliate or friend used Aiki for anything? If > not, why is that? > > Thanks, > > Nathan > > 2012/1/5 Jakub Jankiewicz <[email protected]>: > > Aiki is more then CMS is a platform for developing CMSes. The good > > thing about it, is that you can manipulate Database and use CSS HTML, > > and JavaScript without touching php. > > > > And all CSS content should have this /* widget (id) */ comments so you > > can easily find where to change that CSS. It's not like inline style, > > it's more like you want modularize CSS to put in different files, but > > you have speed benefit because they are all combined together. > > > > And Aiki Markup I propose on the Wiki is more like the language, so you > > can do everything you need in it, and don't need to touch extensions > > which are pure php code. > > > > The best thing in any language is the ability to put your code into > > functions/modules/classes to split it up and make abstraction. But the > > Admin Panel should be better to allow to do this things easily. > > > > I have this mental picture of new Admin Panel I want to build, I work > > on it after we release Aiki 0.9 > > > > I think Aiki is great but not as it look right now, because it's mess, > > but how it should/will look like. > > > > On Thu, 5 Jan 2012 10:55:47 +0800 > > Jon Phillips <[email protected]> wrote: > > > >> Ok, under massive deadlines right now, can't address these. Tacked on > >> three who can or can agree with you. The one thing I'll say is its > >> more of a framework, so a lot of the issues you note below are from > >> one way of doing things which is old school openclipart. There are > >> many ways of doing things that would suit what you think is the best > >> practice for developing a site and mention below. > >> > >> All of your questions should be placed into FAQ and on the public > >> mailing list: > >> > >> http://aikiframework.org/wiki/FAQ > >> > >> Can you place these on that FAQ when we've hashed them out? > >> > >> below > >> > >> On Thu, Jan 5, 2012 at 4:04 AM, Nathan Kinkade > >> <[email protected]> wrote: > >> > Hey. This isn't a confrontational email, but I'm just trying to > >> > understand the motivation and reasoning behind Aiki. After having > >> > worked just a tiny bit with it on OCAL, I can't really find one > >> > redeeming quality. Instead, I can only find negatives. I've > >> > already written to you about a couple, but I'll reiterate them > >> > along with a couple of other perceived negatives: > >> > > >> > * Having the CSS scattered all over the database in each widget > >> > seems just wrong and backwards. CSS scattered everywhere defeats > >> > one of the main purposes and advantages of CSS: that styling can > >> > happen in a single place, yet apply to the whole site. Scattering > >> > it around a database is damn near equivalent to inline styles > >> > scattered all over a bunch of HTML files... unmaintainable and > >> > slow. Right now if you want to update some certain CSS you have to > >> > figure our which widget it's in and how does one do that easily? If > >> > all styles were in, say, style.css, then it would be as simply as > >> > looking through the file, finding the selector you want, then > >> > simply changing it. > >> > >> You can place all the style in one widget wit the path style.css and > >> manage a site that way. No problem. In openclipart, there were many > >> people editing the site, so CSS got spread out. We tried to fix this > >> in newer versions so when you turn on debug mode, in the css and > >> output html, there are comments that point out which widgets contain > >> which content. Roger, that works in CSS too now right? > >> > >> The other pointer is that the url to the master css file is a string > >> of widgets. Yes, that nasty url. > >> > >> > * How does one go about themeing an Aiki site with all the content > >> > and styling scattered around in random fields in a database? How > >> > could I write an Aiki theme that a bunch of other people could > >> > easily use? > >> > >> There are many ways you can do this. Its a framework, so you can name > >> widgets a standard way, like wordpress does, and then do it with one > >> master stylesheet. You could also write an extension that implements > >> theming, or an aiki app. There are many ways to do. Others have more? > >> > >> > * How do you manage sane development on an Aiki site when it's > >> > impossible to version changes, since everything is in a database? > >> > How could it be possible to use, say, git to manage dev -> staging > >> > -> production, not in terms of Aiki code, but in terms of site code > >> > and content? > >> > >> I have been pushing hard on this one. Bassel in his recent > >> radicalization slightly set this back in the code, but the code on > >> disk is to be versioned like so: > >> > >> aiki-MAJORREV-MINORREV-BZRREVNO.zip for the packages. > >> > >> We need a fix in the latest code to get those minor and revno back, so > >> its clear in the latest builds what version we are dealing with. > >> BZRREVNO is the revision number in bazaar. > >> > >> As for the code in the database, this is the highest priority piece of > >> code that needs to be completed in aiki to version the changes in the > >> database, and then have an updater for them. > >> > >> Yes, this is super high priority. > >> > >> So, for on-disk changes, aiki code is in bazaar, and is under control, > >> and can be managed by git. For the database, we really need to get > >> that piece completed. I hope that Roger can take this on, but haven't > >> heard from him in a while. Want to help with this part? > >> > >> > * Aiki markup seems way to complicated for any normal person to want > >> > to learn. Seriously, I mean, what in heck is this: > >> > > >> > "[root]/signin?redirect=/(!(0)!)/(!(1)!)/(!(2)!)/(!(3)!)/(!(4)!)" > >> > > >> > That is starting to look like Semantic Mediawiki markup, which is > >> > totally fucked up. > >> > >> I completely agree. Thanks to rg1024 (roger), we now have ability for > >> multiple real parsers, and Jakub (jcubic) has a plan for a better > >> integrated and thought out syntax: > >> > >> http://aikiframework.org/wiki/Aiki_markup_2 > >> > >> Comments and suggestions welcome. > >> > >> The ideal scenario is no markup is needed, but we decided to strike a > >> balance. There are also extensions and plugin system for those wanting > >> more. > >> > >> > * URLs like this one are crazy: > >> > > >> > > http://openclipart.org/style.php?site=default&widgets=181_14_21_16_1975_17_79_85_865_1903_601_463_1603_20_749 > >> > >> Yes agree. Its for pulling out CSS from the widgets. Open to better > >> suggestions. > >> > >> > * How do you find anything in Aiki? If you have 1000 widgets and > >> > need to find some certain tidbit of content to change a single > >> > mispelled word, how do know what widget any bit of content came > >> > from? > >> > >> This is a problem. We need better admin interface, a new one really, > >> which helps with this. > >> > >> > * If I make a change to a development site, is the only way to make > >> > that same change on the live site to cut and paste the change from > >> > the web interface? Really? Again, where does version control fit > >> > into this? > >> > >> Yes, this is another big problem. There are a couple of plans that > >> would help on this: > >> > >> * on-disk code is versioned, so that is obvious how to move from > >> testing to live setup > >> * we need that database dumping/versioning capability, so can reimport > >> test/dev site to live site > >> > >> The other approach, which there is infrastructure for, and which I > >> want in addition is: > >> > >> * multiple databases where can sync databases so can have a live and a > >> dev, or multiple databases, and can push and pull between them. This > >> also assumes that would also need same on-disk code. > >> > >> > I'm really struggling to find a single positive aspect of Aiki right > >> > now. Can you address some of the above issues and/or loop in others > >> > who can? Other than saying "it's all in the database!", please name > >> > for me a single really positive aspect of Aiki over other CMSs such > >> > as Drupal or WordPress. Loop in Bassel if you need to, or anyone > >> > else. I really need to understand Aiki and the rationale behind it, > >> > and I will not work with Aiki on a regular basis simply because > >> > "it's ours". > >> > > >> > >> Sure, looped in a few. I agree the setup is not ideal. It has come a > >> long way, and we want it to get better since we are running several > >> sites with it and its our platform. > >> > >> Are you on the mailing list? I just sent out a big plan for the next 6 > >> months along with priorities which should address these issues. > >> > >> Jon > >> > >> > >> > > > > -- > > Jakub Jankiewicz > > twitter: @jcubic > > www: http://jcubic.pl >
_______________________________________________ Mailing list: https://launchpad.net/~aikiframework-devel Post to : [email protected] Unsubscribe : https://launchpad.net/~aikiframework-devel More help : https://help.launchpad.net/ListHelp
