Re: pengines extension to html_requires

>It that true?  Why would you want to embed a Prolog script, just to
have the pengine it sending back to you?  The text/x-prolog fragments
just provide a space for real predicates to avoid over complicated
expressions in ask. 

I see your point, but keeping the code specific to a page with the page is an advantage.
What prompted the question was generating a page that had some x-prolog fragments
but needed to be dynamically generated for other portions of the page.

> You can just as easily provide these in Prolog
itself and make them available to the module pengine_sandbox.  The
current way to do so is to write a module exporting this infrastructure
and using :- use_module(pengine_sandbox:my_api_file).

I"m afraid I'm not getting this pengine_sandbox module. I'm a bit baffled how
one can qualify a module name like this?

>That might not be ideal from a modularity point of view.  The other
way is to write in some module 'xx' of your server:

:- public my_api/2.

my_api(A, B) :- ...

    ...
    {|javascript||
        ...
        <calling xx:my_api(X,Y)> <-- =8cO hey, thats javascript!
     |}
    
The nice architecture probably combines this: make generally useful
APIs accessible using a module imported into the sandbox and use the
above for page specific code.

>Does that make sense?

Sorry, not making sense of this example



>> You may want to mix the two, generating a page from the server and
>> using
> pengines to provide AJAX functionality to the page.
>
> Precisely the situation I'm in. Weblog will do most of the page
> generation for me, and there's lots of repetitive elements, so it
> makes sense to have the server generate the page. But then the map's
> markers change dynamically as the game's played - an obvious ajax
> task.

Thanks for the feedback.  These are really useful interactions to
fix issues and prepare for a tutorial that explains how the framework
can best be used.

For example, we could consider adding a directive like this to replace
the simple public directive:

:- pengine_api
    my_api_1(<types/modes>) [is safe],
    ...

which could wrap the predicate with type/mode checking to improve the
security.   It would also make it easy to locate the pengine API in
an application.
    
That feels more meta-analysis friendly.
It's also probably a good move for security. Anything that puts in big bold letters ANYBODY ON THE NET CAN CALL THIS is a good idea.

Years ago I fiddled around with this same idea of code as query in Clojure. I made use of Clojure's meta syntax to mark public api's. Since keywords start with : in Clojure that gave scope to my smiley obsession - :oD  was the public API marker.