On Sun, 29 Jan 2012 19:03:13 +0800
Jon Phillips <[email protected]> wrote:
> I totally agree. Ok, you want to move out that captcha, or you want
> me to do it?
No I will do this because it need to rewriten, (I mean registration)
because server side captcha need to be put into extension.
So Registration app should have 2 widgets recapcha server side as
extension and widget with form for registration, it need to be styled
like new installation script. And should be installed by default. So
maybe we don't need to put it into separated repository.
>
> Can you capture your thoughts up on the apps page on the wiki. I
> totally agree with you.
>
> Should aiki app id be unique? Should we generate some unique hash for
> an app like we do on sharism.org for shared url to a file?
>
Aiki App id will be a value in database (integer primary key) that point
into widgets and will be accessed from Admin Panel Aiki also should
store files that are installed by apps
aiki_apps 1-----------N aiki_widgets
1
|
N
aiki_apps_files
> jon
>
> 2012/1/29 Jakub Jankiewicz <[email protected]>:
> > Captcha is not an app is nearly an extension and it should not
> > exists on it's own, I check recatpcha code and the essence of it is
> > registration app (there is no code that can be extracted for
> > captcha app)
> >
> > Installation and Update is not an app ether because they exists
> > outside of aiki. And all aiki apps should be registered in
> > database, there is app_id in aiki_widget table but there is not
> > aiki_apps that store them all. And Admin Interface should have a
> > tool like Software Center in Ubuntu that manage apps. And other
> > thing that all apps should have version number and Software Center
> > should handle allow to upgrade version of app like in Ubuntu.
> >
> > On Sun, 29 Jan 2012 12:39:45 +0800
> > Jon Phillips <[email protected]> wrote:
> >
> >> Time to get radical myself! I'm calling bullshit big time on aiki
> >> apps. Basically an app is just a bunch of code in a file, and
> >> something you Bassel convinced us all to call Apps. On disk, the
> >> word app is meaningless. They are a more like ASS, not an APP.
> >> However, I want to see that changed. We need to make a clear spec
> >> on what an APP is, and figure out how to fix them now.
> >>
> >> I'm challenging all to make better, but Bassel, I'm challenging
> >> you to document the code in apps and help make this better.
> >>
> >> http://aikiframework.org/wiki/Apps (I updated the wiki)
> >>
> >> >
> >> >>
> >> >> And for images is it even documented?
> >> >
> >> >
> >> > no, but I'll do that
> >>
> >> Challenged!
> >>
> >> Ok, these are supposed to be aiki apps:
> >> http://aikiframework.org/wiki/Apps#Current_Apps
> >>
> >> What would be great is to get them documented on in the code and
> >> then also make it clear how an app is to exist as a spec on disk
> >> and in the database. That would be a great service!
> >>
> >>
> >> Now, on aiki forms. They really do suck. And, I don't have any good
> >> solutions for them right now. I need to think about them more, or
> >> find some solution to them. They are the single biggest slowdown in
> >> developing a new aiki site. What value is aiki if its super hard
> >> for HUMANS to be able to input, manipulate and export data? Right
> >> now, commandline is by far the easiest interface to manipulating
> >> data in Aiki, and that sucks and doesn't work for humans. You
> >> currently cannot look at aiki forms interface in the current admin
> >> panel and understand how to create aiki forms, there no normal
> >> human can do this. And, there is little documentation on the wiki
> >> about this.
> >>
> >>
> >> >> > > If you think out something put it here
> >> >> > > http://aikiframework.org/wiki/Aiki_forms_2
> >> >> > >
> >> >> > > We can remove aiki_forms table and put forms into a widget
> >> >> > >
> >> >> > > (form( add {
> >> >> > > "table": "aiki_users",
> >> >> > > "pkey": "userid",
> >> >> > > "username": {"label": "Your Name:", "field": "username"},
> >> >> > > "password": {"label": "Your Password:", "field":
> >> >> > > "username"}, "confirm_password": {"label": "Confirm
> >> >> > > Password", <<< HOW TO
> >> >> > > REF>>}, "recaptcha": { ??? }
> >> >> > > })form)
> >> >> > >
> >> >> > > maybe instead of "form" "database", but if we have
> >> >> > > UPDATE/DELETE/INSERT in (sql( who will need those? If users
> >> >> > > know SQL why force them to use such a beast?
> >> >> > >
> >> >> > > I think that only thing is needed in forms it it's server
> >> >> > > side part the html forms users can do themself.
> >> >> > >
> >> >> >
> >> >> > well, the whole reason of why aiki started in the beginning
> >> >> > is to simplify this task and stop creating html forms, users
> >> >> > can also build there own CMS from scratch.
> >> >> > current aiki forms need improvement but not removal. why aiki
> >> >> > then? remove forms and images, what left? the widget
> >> >> > structure? replace with
> >>
> >> Ok, it is not simplifying the task, it makes it harder. Lets think
> >> higher level, and fix the problem.
> >>
> >> >> The reason I wanted templates is that is a pain if you have 10
> >> >> widgets which is responsible for layout of your page and you
> >> >> need to add another widget with the same widget structure, you
> >> >> need to manually edit 10 widgets and add new url to them. This
> >> >> suppose to be simple task.
> >> >>
> >> >
> >> > yes the current admin panel doesn't provide such functionality
> >> > but it can be added, in a new admin panel with less javascript
> >> > and smarter way of handling requests this can be done by drag
> >> > and drop. and I'm thinking of a way to simplify this task, yeah
> >> > totally agree on this.
> >>
> >> Need to think about it. We need a higher level plan so there can be
> >> multiple ways of making UI for this if we want. The idea needs to
> >> be more solid before we rush into this battle.
> >>
> >> Here, please spec it out! Jakub, your idea is good, but we need to
> >> think even more high level about database design and having a solid
> >> api in the code:
> >>
> >> http://aikiframework.org/wiki/Aiki_forms_2
> >>
> >> My thoughts for now. I am thinking about it a lot. If our goal is
> >> to reach humans, then we need to make a super great interface.
> >> Ideally, one can create forms directly from aiki admin interface
> >> which will manipulate and create default CRUD forms, and
> >> manipulate mysql database easily. To me, that is the bare minimum
> >> that default aiki forms should handle. Right now, there are only
> >> like two people who understand aiki forms, Bassel and Brad.
> >> Christopher just avoided them completely and creates forms by
> >> hand, which creates its own problem because other people then have
> >> to learn not only aiki, but Christopher's system.
> >>
> >> Bassel, if you can help on this problem, we would all be greatful.
> >> Jakub, if you have a high level plan, would love to see on that
> >> wiki page.
> >>
> >> I'm going to think more about it.
> >>
> >> Ideally, the system would be like:
> >>
> >> * design data design/db (need some way for humans to help with
> >> this)
> >> * this allows for creating mysql commands, and some basic forms
> >> * aiki generates the forms onto widgets, which can then be
> >> customized
> >>
> >> Anyone else have ideas or thoughts?
> >>
> >> Jon
> >
> > --
> > Jakub Jankiewicz
> > twitter: @jcubic
> > www: http://jcubic.pl
>
>
>
--
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
