Hi Erik,
> I've been spending a lot of time with the wiki, working on the
> new website (more on that in the coming weeks). Along the way,
> I've found myself desiring a couple features. Notably, the
> ability to attach arbitrary CSS to particular wiki documents.
A good idea!
> I imagine attaching a CSS file to a document, much like we can
> already attach various media. Then (with some markup extensions)
> we could access the classes/id's from that file. Maybe something
> like:
>
> 1.myClass{My Header styled with 'myClass'}
>
> 1.myClass.myOtherClass{Another Styled Header}
>
> 1#myId{Header with id 'myId'}
>
>
> or added to the end...
>
> 1{My Header styled with 'myClass'}.myClass
>
>
> or as "metadata" inside the braces...
>
> 1{(.myClass .myOtherClass) My Styled Header}
Not sure. The drawback is that it breaks a little bit the logic of the
markup parser, which expects a single char plus a '{'.
Perhaps a separate markup, with a dedicated character, is better? Let's
use 'x' for now (though I try to avoid alphabetic characters, because
they conflict more easily with the document's text itself):
x{myStyle
bla
/{text}
}
This would probably expand to a <span>, right?
What character should be used for the 'x'?
> I'm sure many syntax possiblities exist. That led to me
> wondering what other things might be possible using a wiki-like
> markup, which, taken to its logical extreme, was 'Well couldn't
> we write entire GUI's using a markup syntax?'
> ...
> [+TextField 40]
>
> [+Able +PwField '(not *Login) 10
> "Password" ]
>
> [+E/R +NumField '(nr : home obj) 8]
>
> [+Button "My Stylish Button" '(doSomething)].stylish
I'm rather reluctant about this. It is always tempting to have a
simplification like that.
The problem with abstractions, however, is that a soon as you need to go
down to lower levels, they are in the way, and things get ugly.
Basically, the current GUI is already a kind of markup
(gui '(+TextField) 40)
This is not so much more, but has the advantage of being 100% Lisp code.
Everything is fully evaluated, and you can use any expression you like.
Also, using brackets is problematic, because then the Lisp reader cannot
be used, and some preprocessing would be required. This again limits
usability.
> Some variation of the wiki could then be used as a CMS. It
> could allow to create PicoLisp DB architectures graphically, as
> well as provide the means to build the user facing pages for
> manipulating the DB. In a nutshell, it would be a PicoLisp app
> for creating PicoLisp apps, with a powerful markup language to
> intuitively build dynamic content with little "actual code".
Yes, cool! Ambitious ;)
> I guess the point of all this would be to further abstract the
> application development details. No need to worry about
> 'action', 'html', or 'form'. Maybe no need to worry about
> "coding" at all.
True, but again it holds what I said about too much abstraction. I've
shot myself into the food this way many times. In the beginning it looks
cool, but as soon as you encounter a slightly different situation, which
is not covered by the abstraction, you have first to find you how to do
it on the lower levels, and then find a way to break out of the
abstraction.
Having said this, however, we don't know how it would feel like unless
somebody really tries it :)
> I wanted to share this, if only so I could stop thinking
> about it :) Chime in if you find it interesting!
Sure! Let's keep an open mind on that!
♪♫ Alex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
