Re: pengines extension to html_requires

On 02/07/2014 06:19 PM, Anne Ogborn wrote:
>
>
> On 02/07/2014 03:34 AM, Anne Ogborn wrote:
>
>> It'd be delightful if pengine code worked with the resources stuff
>> so we could use with html generation.
>
> That was in Torbjörn's version by declaring html//1 as safe.  As
> html//1 does
>
> You're misunderstanding me.

I see ...

> I mean, currently if I'm using html_write and html//1 to generate
> pages, I have to do \[...] trickery to insert
>
> <script type="text/x-prolog">
>
> q(X) :- p(X),pengine_server:taco(X).
>
> p(a). p(b). p(c). p(d). p(e). p(f). p(g).
>
> </script>
>
>
>> If you want to do server-side page generation, why not do it the
>> way
> it is described in your tutorial, i.e., just by extending the
> server? What do pengines add to this picture.
>
> Just that there's a new sort of thing to include. So it should be
> supported by quasiquotes, resource management, there should be a
> pscript equivalent to jscript, and other good things.

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.  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).

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)>
	 |}
	
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?

>> 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.
	
	Cheers --- Jan