Re: Pengine ask and success template

On 02/10/2014 12:10 AM, Torbj�rn Lager wrote:

>> Yes :-) that still means you must access the data using the somewhat
>> hard to interpret data[0].args[0] and data[0].args[1] if my memory suits
>> me well. Right?
>
> No, hangon, that is not the way that it used to work! It used to be
> done like this, i.e. in the way that you write below:
>
>           data[0].X and data[0].Y
>
> So hopefully your memory does NOT suit you right. :-)

Great.  I didn't change anything :-)  It does raise the question what is
the point of the template for the JavaScript client in the first place?
Seems like selecting variables, no?  What about using the toplevel 
convention if you enable

:- set_prolog_flag(toplevel_print_anon, false).

This causes all _X variables (i.e., the convention you use for
`named singletons') to be ignored in the result.

>> P.s.    Should we also allow for a new Pengine() that already involves
>>          the create/ask (and thus is discarded after the query).  So, we
>>          can do this for the simple cases, which will iterate over all
>>          solutions of q(X,Y)?  Here, onsolution calls the output function
>>          and next() and finally destroy?  It may automatically chunk and
>>          call the onsolution function for each returned value?
>>
>>          new Pengine({ goal:"q(X,Y)",
>>                        onsolution: function(data) { ... }
>>                      });
>
> I agree that something like this should be possible. I have been
> playing with two ideas here:
>
> 1) Introduce an ask(Query) option and a template(Term) option for
> pengine_create/1. This would allow us to return the first solution
> already with the create event. It saves us making an extra network
> round-trip.

That would be nice, in particular for pengines you only use ones.  If
you plan to query the pengine many times anyway, this one extra query
won't kill you. If you use it only for one query, it halves the network
messages.

> 2) Introduce an option that means "this pengine will only be used for
> making ONE query, so let's kill it when we are done with one" (Don't
> know how to name it.)
>
> 1) and 2) appears to be orthogonal to each other, and the combination
> seems to do what you suggest (unless I misunderstand you). And I don't
> see the need for a new handler such as 'onsolution'.

Yes. If you give ask:Goal, it will simply come back with success, fail
or error and the Pengine is destroyed on deterministic success, fail or
error. Ideally, we should tell the pengine itself about this, so we do
not need an explicit destroy from the browser. That means that the
simple case is simply one request and response.

wrt. onsolution, this is orthogonal too.  Possibly it is a good idea
to allow for an alternative for onsuccess that, if present loops over
the data in the success set.  That avoids the need for a loop in the
client and/or using data[0].  I guess the problem is that you cannot
decide after each answer between next, stop or destroy.  Unsure ...

>> P.s.    Should ask() now be allowed to specify new handlers?  I'd assume
>>          that if a page create a handler to ask multiple queries, it wants
>>          different handlers for the various queries?
>
> I tend to think in terms of statemachines here and that
> pengine_event_loop/1 can be seen as running a single-state
> statemachine with transistions triggered by events (in combo with
> conditions) and executing actions (e.g. executing a command such as
> pengine_ask/3.
>
> If we in order to complement pengine_event_loop/1 also had
> pengine_statemachine/1, we could easily define a statemachine
> (expressed in some nice notation and maybe even partly by drawing it)
> that would in essence be able to change from one system of handlers
> into another when changing states. I think that would work.

Torbj�rn and state machines ... there is a small bias :-)  I'm more
thinking about usage scenarios.  I can see you want to create a
Pengine, run one query in it to fill some part of your page and
then another to fill some other part of the page.  I guess one
way is to use:

funtion handleSuccess(data)
{ if ( data[0].Person ) ...
   else if ( data[0].Town ) ...

and than make the various ask operations use different variables,
but this seems a bit awkward to me.

	Cheers --- Jan

_______________________________________________
SWI-Prolog mailing list
[email protected]
https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog