I don't know about this one "Apps that have widgets are also defined as sites.", but maybe it will resolve issue how to ship apps since apps don't have stored widgets anywhere in aiki database. If the architecture of aiki will allow to have installable sites then we can use them.
But if apps are sites then what is the difference between them, I mean in database? If there is difference between them, then we should not expose this architecture to users, it will be internal only for developers. Right now it look like apps are only in our heads, and they are not yet implemented, and aiki have only sites, am I right? Because there is no aiki_apps there is only app_id in aiki_widgets but this is no foreign key, it's just a marker for admin panel to not show widgets with id != 0. And the whole infrastructure is around sites. I still think that Admin Panel and login should not be a site, but apps. On Mon, 9 Apr 2012 22:42:47 +0800 Jon Phillips <[email protected]> wrote: > Did we get this resolved? > > On Thu, Mar 15, 2012 at 11:38 PM, Jon Phillips <[email protected]> > wrote: > > I think as well, rg1024, you have looked at the current architecture > > the most. I'm not sure what is possible now versus, the future. > > > > Jakub, the config class that rg1024 built can handle these > > differences in sites now. > > > > I'm unclear about the distinctions overall, and why I made those > > wiki pages trying to compare what the differences are: > > > > http://aikiframework.org/wiki/Extending_Aiki > > > > I hope we can come to an agreement the differences, so the features > > can be implemented. > > > > Jon > > > > 2012/3/15 Jakub Jankiewicz <[email protected]>: > >> I think that sites should work for instance if on the same server > >> will be sharism, OFLB and OCAL they will have different users, > >> different domain and different widgets, they will need different > >> $config. > >> > >> So what benefit will we have when login can have "*". It look like > >> templates (that I propose) to me, if the only thing that you want > >> for them is display_url. If you want different widgets to belong > >> to the same entity then you have Apps. Sites should be something > >> bigger. > >> > >> And a question should all sites have the same admins, maybe there > >> will be one user root that will configure All sites and ModuleGODs > >> (or SiteAdmin) will have access to one site. > >> > >> > >> On Thu, 15 Mar 2012 15:15:59 +0100 > >> Roger Martín <[email protected]> wrote: > >> > >>> The two proposal can't be mixed. The problems is what is a site, > >>> or a multi-site. > >>> > >>> A site is only certain output from the SAME data. For example: you > >>> can have a frontpage, a backpage and > >>> a rss feed. If you consider these as sites developing is easier: > >>> you can use "*" in display_urls; a new widget in frontpage will > >>> not affects other sites. You can easily controls access, > >>> deactivate one site..,move sites, import, export. > >>> and shares apps between sites. > >>> > >>> When i think in sites i don't think in wordpress.org: different > >>> blog over the same hosting. That can be resolved with more money > >>> to contract other hosting. > >>> > >>> I think, that moving admin,login and welcome to sites we can solve > >>> some problems, but i don't want discuss again over this. Take a > >>> decision. > >> > >> -- > >> Jakub Jankiewicz > >> twitter: @jcubic > >> www: http://jcubic.pl > > > > > > > > -- > > Jon Phillips 王✳爻气 http://fabricatorz.com ✳ skype: kidproto ✳ > > irc: rejon +1.415.830.3884 (global) ✳ +86-187-1003-9974 (beijing) > > > -- 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
