Hi Thorsten,

> > Instead, it might be easier to print directly, e.g.:
> >
> >    (prinl "<script type=\"text/javascript\" src=\"lib.css\"></script>"))
> I used this
> #+begin_src picolisp
>   (prinl
>      (pack
>         "<script type=\"text/javascript\" src=\""
>          (path "@")
>          "lib.css"
>          "\"></script>" ) )

Yes, 'path' is a good idea! Note that you might directly write

   (path "@lib.css")

> where the 'src=' is a working link to the lib.css file of the local
> installation. It still has no effect on the html-page appearence, the
> tabs and menu are still style-less.

It is the server actually serving the final pages that has to find
the resources.

> #+begin_src picolisp
>   (<ul> "@lib.css"
> are not really expanded, but exported verbatim to html.
> ...
> <ul class="@lib.css">
> ...
> Is that correct?

Yes, for the above reason. The browser finds "@lib.css" in the HTML
source, and asks the server for it. The PicoLisp server sees "@lib.css",
and thus knows where to find it (i.e. in the PicoLisp installation

> Another problem with my embedded PicoLisp code is that the hrefs
> produced are incomplete. This
> ...
> Thus only one link 
> points to the test.l file as it should, the others not.

This is because the submenus are not "opened". The state of the menu is
controlled via the '*Menu' global variable. Each bit refers to a
submenu. So if you set '*Menu' to a number with as many 1-bits as there
are submenus, you should be safe, e.g (setq *Menu (dec (** 2 24))).

♪♫ Alex
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Reply via email to