of course Jon, we are going to work together, now still discussing which is
the best approach, now let's try to think out of the box, here is a quote
from
stackoverflow.com/questions/3723752/where-do-i-start-when-writing-a-new-scripting-language

but PHP is a "basic scripting/templating engine". Why reinvent the wheel?
> Just use regexes to strip the disallowed constructs from the source code
> and eval() it.


hmmm why not? instead of extensions and then markup that will not have
everything and will waste processing power and regexes. why not just do
that? maybe not eval() it but need to think of how to make use of what
exists already in php, just allow normal php in a way that can't be
dangerous. and make sure that php doesn't get processed if pulled from from
query inside the widget... what others think?

--
Bassel Safadi | http://bassel.ws
Skype: i.know.sy | Global: +1-323-545-3855


On Sat, Feb 4, 2012 at 4:25 AM, Jon Phillips <j...@fabricatorz.com> wrote:

> Please work together. Power to the committer
>
> On Sat, Feb 4, 2012 at 7:28 AM, Bassel Safadi <bassel.saf...@gmail.com>
> wrote:
> >
> > On Fri, Feb 3, 2012 at 9:40 PM, Jakub Jankiewicz <jcu...@onet.pl> wrote:
> >>
> >>
> >> On Fri, 3 Feb 2012 17:54:52 +0200
> >> Bassel Safadi <bassel.saf...@gmail.com> wrote:
> >>
> >> > hey guys, soooooo on http://aikiframework.org/wiki/Aiki_markup_2
> >> > I don't agree on this markup at all, using (for( )for) just because
> >> > it's easier to process than for () doesn't make since.
> >> Is not because it's easier to process but because it look like
> >> ((table_filed)) which in my opinion is the best syntax in current Aiki.
> >> I try to make all look like that.
> >>
> >> > we should keep the original plan that was something like:
> >> > <aiki
> >> > for (){
> >> >
> >> > }
> >> > aiki>
> >>
> >> Propose complex syntax for this:
> >> http://aikiframework.org/wiki/Aiki_markup_2#Complex_example
> >> and tell me that this will be easier to parse then current Aiki markup.
> >>
> >> I want to work things like:
> >> 1. using extension in "if" statement
> >> 2. extension or aiki function inside loop.
> >> 3. sql "INSERT INTO" inside if statement so you can make conditional
> >>   insert.
> >> 4. variable "covering" (when nested statement introduce new ((filed)) it
> >>   will overwrite ((field)) from parent statement.
> >>   (so you will have one filed instead of two like right now)
> >
> >
> > I think this is sooooo comlicated:
> >
> >
> >  (for( $aiki->utils->fn() as id {
> >    (sql( SELECT * FROM table WHERE id = ((id)) {
> >       (if( $aiki->utls->fn( ((some_filed)) ) {
> >          (*here id will be from first sql not from for loop*)
> >          (sql( SELECT * FROM other_table WHERE ((other_id)) = ((id)) {
> >             (if( $aiki->membership->username == '[username]' ||
> >                  $aiki->membership->permission == 'librarian'{
> >                (*here id will be from last sql not from for loop nor
> first
> > sql *)
> >                (widget:delete_row( "other_table", ((id)) )widget)
> >             })if)
> >          })sql)
> >       })if)
> >    })sql)
> >  })for)
> >
> >
> > instead it should and my implementation will make it look like this, and
> > although I don't know why are you using all those queries here. if you
> can
> > explain your example a bit more will write you the final markup. here
> it's
> > not clear where those queires are used.
> >
> >
> >  <aiki
> >   for( $aiki->utils->fn() ) as id {
> >    $query =  SELECT * FROM table WHERE id = ((id)) {
> >       if( $aiki->utls->fn( ((some_filed)) ) {
> >          (*here id will be from first sql not from for loop*)
> >          $query = SELECT * FROM other_table WHERE ((other_id)) = ((id)) {
> >             if( $aiki->membership->username == '[username]' ||
> >                  $aiki->membership->permission == 'librarian'{
> >                (*here id will be from last sql not from for loop nor
> first
> > sql *)
> >                (widget:delete_row( "other_table", ((id)) )widget)
> >             })
> >          })
> >       })
> >    })
> >  })
> >
> >
> >
> >>
> >> >
> >> > of course this looks less new markup and more like php and since aiki
> >> > is written in php I don't see why we need to invent yet another new
> >> > markup while the point of rewriteing the parser was not inventing new
> >> > markup.
> >>
> >> Aiki suppose to hide php from users so they can use sql, html and
> >> javascript.
> >>
> >> And I thought that we need to write parser because Aiki don't have one.
> >> http://en.wikipedia.org/wiki/Parsing#Parser
> >
> >
> > yes, and if we wrote a new parser then we should not reinvent the wheel
> with
> > totally new language, I don't understand how Jon calls the markup easier,
> > it's totally not understandable dude, if we to have markup it should be
> > closer to php than to new complicated markup, and we should not have
> > (something( )something) all over the place
> >
> >>
> >>
> >>
> >> >
> >> > sooooo and I'm making progress on making
> >> > <aiki
> >> > stuff like in php
> >> > aiki>
> >>
> >> As I post in different tread tell me how you want to look complex
> >> example like this: (and Aiki should allow for more complicated things
> >> as well)
> >> http://aikiframework.org/wiki/Aiki_markup_2#Complex_example
> >>
> >> And remember that there can be javascript inside, and other html.
> >>
> >> >
> >> > I don't think the proposal on
> >> > http://aikiframework.org/wiki/Aiki_markup_2will make aiki markup
> >> > easier instead more complicated.
> >> >
> >>
> >> And this is simple because all markup look the same, and there is very
> >> few constructs.
> >>
> >> take Python for example, python is simple, but it doesn't mean that is
> >> not powerful.
> >>
> >> If you write simple things, Aiki should be simple, but it should allow
> >> you to do complicated stuff too. And markup will be complicated only if
> >> user want to do complicated things. You can't make very complicated
> >> thing to look simple.
> >>
> >> And they should do as much as possible from Aiki using Aiki markup not
> >> to create extensions in php.
> >>
> >> > --
> >> > Bassel Safadi | http://bassel.ws
> >> > Skype: i.know.sy | Global: +1-323-545-3855
> >> >
> >> >
> >> > 2012/2/3 Jakub Jankiewicz <jcu...@onet.pl>
> >> >
> >> > > We can keep it till 1.0 but there should be switch they should
> >> > > not coexist together IMO, we don't need to do things like languages
> >> > > (python or php), we can add to $config 'use_old_syntax' and we can
> >> > > have code that will detect old markup and show error that they use
> >> > > old markup with new Aiki with link to new documentation and that
> >> > > they should use new markup and if they really want to use old one
> >> > > they can turn it on. But if they do it new markup feature will not
> >> > > work. So those few that use old markup will be encourage to use new
> >> > > markup, and we will be able to remove that code in 1.0.
> >> > >
> >> > > There should not be in the code stuff like check for two different
> >> > > markup. Like there is with inherit right now.
> >> > >
> >> > > On Fri, 3 Feb 2012 10:31:19 +0800
> >> > > Jon Phillips <j...@fabricatorz.com> wrote:
> >> > >
> >> > > > I agree. And, one thing we should keep in mind is that there are
> >> > > > still few aiki-based sites, so we have to consider:
> >> > > >
> >> > > > * do we keep support for the old markup
> >> > > > * keep it for a while
> >> > > > * or just replace it with a well thought out solution
> >> > > > * or a combination of the above
> >> > > >
> >> > > > I would lean towards abstracting the old markup if possible, and
> >> > > > maintaining support for a while, but working on the more thorough
> >> > > > plan and implement it.
> >> > > >
> >> > > > Jon
> >> > > >
> >> > > > On Fri, Feb 3, 2012 at 1:29 AM, Jakub Jankiewicz <jcu...@onet.pl>
> >> > > > wrote:
> >> > > > > Sorry, I already suggest markup
> >> > > > > http://aikiframework.org/wiki/Aiki_markup_2
> >> > > > >
> >> > > > > and I registered a blueprint for things I want to remove
> >> > > > >
> >> > > > >
> https://blueprints.launchpad.net/aikiframework/+spec/remove-from-aiki
> >> > > > >
> >> > > > > There was no response either from you or from others,
> >> > > > > only Jon agree with me (in response on this list not
> >> > > > > whiteboard), so I assume that this markup I propose to remove
> >> > > > > are not in use, and everybody agree with that. So I was
> >> > > > > surprise that users use it.
> >> > > > >
> >> > > > > I assume that all that markup that is not in use will go to
> >> > > > > trash, sorry if I offended you by calling it shitty. You've
> >> > > > > done great work with Aiki, I just want to make it better.
> >> > > > >
> >> > > > > If you don't agree with me about those things I want to change,
> >> > > > > then just comment that blueprint and modify that proposal.
> >> > > > >
> >> > > > >
> >> > > > > On Thu, 2 Feb 2012 17:21:39 +0200
> >> > > > > Bassel Safadi <bassel.saf...@gmail.com> wrote:
> >> > > > >
> >> > > > >> Jakub: this markup is used a lot and very useful. and so that
> >> > > > >> you know, I don't like the word shitty to be used that much
> >> > > > >> about my code. if you think it look bad, fine go ahead and
> >> > > > >> suggest better markup. but you can't just say shit about
> >> > > > >> others work!
> >> > > > >>
> >> > > > >>
> >> > > > >> On Thu, Feb 2, 2012 at 12:46 PM, Jakub Jankiewicz
> >> > > > >> <jcu...@onet.pl> wrote:
> >> > > > >>
> >> > > > >> > Do you use those shity markup I wanted to remove it from
> >> > > > >> > Aiki?
> >> > > > >> >
> >> > > > >> > And I think that this is the proper behaviour
> >> > > > >> >
> >> > > > >> > if ((post_content)) is
> >> > > > >> >
> >> > > > >> > ===0
> >> > > > >> > this is paragraph one
> >> > > > >> >
> >> > > > >> > This is paragraph 2
> >> > > > >> > ===0
> >> > > > >> >
> >> > > > >> > and you put it in blockquote
> >> > > > >> >
> >> > > > >> > <blockquote>[p[ ((post_content)) ]p]</blockquote>
> >> > > > >> >
> >> > > > >> > You will have what you want. this is text sensitive not xml
> >> > > > >> > sensitive.
> >> > > > >> >
> >> > > > >> > What about if you have this
> >> > > > >> >
> >> > > > >> > ===0
> >> > > > >> > <blockquote>this is <span>paragraph one
> >> > > > >> >
> >> > > > >> > This is</span> paragraph 2</blockquote>
> >> > > > >> > ===0
> >> > > > >> >
> >> > > > >> > You will end with (if it work as you want):
> >> > > > >> >
> >> > > > >> > ===0
> >> > > > >> > <blockquote><p>this is <span>paragraph one</p>
> >> > > > >> >
> >> > > > >> > <p>This is</span> paragraph 2</p></blockquote>
> >> > > > >> > ===0
> >> > > > >> >
> >> > > > >> > which will be invalid xml too. How this simple text sensitive
> >> > > > >> > replacement should know how to handle this?
> >> > > > >> >
> >> > > > >> >
> >> > > > >> > On Thu, 02 Feb 2012 09:46:23 -0000
> >> > > > >> > Christopher Adams <ch...@raysend.com> wrote:
> >> > > > >> >
> >> > > > >> > > Public bug reported:
> >> > > > >> > >
> >> > > > >> > > I noticed this while creating an RSS feed in Aiki:
> >> > > > >> > >
> >> > > > >> > > Let's say my ((post_content)) looks like this:
> >> > > > >> > >
> >> > > > >> > > ===0
> >> > > > >> > > <blockquote>this is paragraph one
> >> > > > >> > >
> >> > > > >> > > This is paragraph 2</blockquote>
> >> > > > >> > > ===0
> >> > > > >> > >
> >> > > > >> > > Then the output of [p[ ((post_content)) ]p] will be
> >> > > > >> > >
> >> > > > >> > > ====
> >> > > > >> > > <p>
> >> > > > >> > > <blockquote>this is paragraph one</p><p>
> >> > > > >> > > This is paragraph 2</blockquote></p><p>
> >> > > > >> > > ====
> >> > > > >> > >
> >> > > > >> > > You see how the </p><p> is located INISDE the <blockquote>?
> >> > > > >> > >
> >> > > > >> > > This will generate an invalid XML warning:
> >> > > > >> > >
> >> > > > >> > > Opening and ending tag mismatch: blockquote line 0 and p
> >> > > > >> > >
> >> > > > >> > > My temporary fix is to use [br[ instead of [p[
> >> > > > >> > >
> >> > > > >> > > But it would be nice if [p[ doesn't ever produce invalid
> >> > > > >> > > markup!
> >> > > > >> > >
> >> > > > >> > > ** Affects: aikiframework
> >> > > > >> > >      Importance: Undecided
> >> > > > >> > >          Status: New
> >> > > > >> > >
> >> > > > >> >
> >> > > > >> > --
> >> > > > >> > 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
> >> > > > >> >
> >> > > > >
> >> > > > > --
> >> > > > > 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
> >> > > >
> >> > > >
> >> > > >
> >> > >
> >> > > --
> >> > > Jakub Jankiewicz
> >> > > twitter: @jcubic
> >> > > www: http://jcubic.pl
> >> > >
> >>
> >> --
> >> 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)
>
_______________________________________________
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

Reply via email to