Here's jdoajax:
function jdoajax(ids,data,sentence,async) {
if(0!=rqstate) return; // previously - alert("busy - wait for previous
request to finish");
async= (!async)?false:async;
sentence=sentence||jevsentence;
data=data||"";
ids=ids||[];
rq= newrq();
if(async) rq.onreadystatechange= jdor;
rq.open("POST",jform.jlocale.value,async); // true for async call
jform.jdo.value= ('undefined'==typeof sentence)?jevsentence:sentence;
rq.send(jpostargs(ids)+"&jdata="+jencode(data)+"&jwid="+jencode(window.name
));
if(!async)jdor();
}
If I open up the javascript console in my jijx window and execute
jdoajax([],'','i.3')
I get to see i.3 entered in the jijx window (and its result).
If I instead do:
jdoajax([],'','i.3');jdoajax([],'','i.4');jdoajax([],'','i.5');
I get to see all three lines entered and their results displayed.
That said, if I turn on async:
jdoajax([],'','i.3',1);jdoajax([],'','i.4',1);jdoajax([],'','i.5',1);
only the first one gets executed.
Looking closer, in the first set of three, three http requests are posted
to the server. But when I pass the fourth "async" argument, the browser
only makes the first request.
Meanwhile, looking at your code, I think the problem is that jhrajax does
not belong in 'paint'. jhrajax belongs at the top level
So now the question is "what is the top level"?
When I look at the stack in place when paint executes for fd 20, it looks
like this:
paint
advance
fd
ev_command_enter
jev_tgsj_
The bottom two levels are pre-defined, in jhs. You could have fd be the top
level, but then it would not make sense to have other routines call fd.
(Because, if they did, it would violate our abstraction of considering fd
the "top level".)
You could override ev_command_enter, and that might be ok. Here's what it
looks like:
ev_command_enter_tgsj_
3 : '". s=. getv ''command'''
That feels a bit messy though. So maybe it would be better to define
ev_command_turtle_tgsj_ (I am presuming that the command argument to
jdoajax should be 'turtle' to make this work - but I've not tested it.).
Then you'd copy the line from ev_command_enter and add your jhrajax line
there.
Thanks,
--
Raul
On Sun, Mar 23, 2014 at 3:23 PM, Brian Schott <[email protected]>wrote:
> I'll try to reply below.
>
> On Sun, Mar 23, 2014 at 2:31 PM, Raul Miller <[email protected]>
> wrote:
>
> > Let's slow down a bit and try to think about what you are really trying
> to
> > do here.
> >
> > First, though, I have an issue here, with the concept of "in the server".
> > There is certainly a perspective where "only be one jhrajax in the server
> > for any jdoajax() sent by the client" is valid. It's an approximation -
> but
> > a good enough approximation if we manage our expectations properly.
> >
> >
> I'll take that as a qualified "Yes" answer to my question. There are
> multiple jhrajax's in my app, but only one that replies to the "command"
> input. Others reply to color changes and viewport choices. But, what I am
> trying to zero in on, is that the server cannot just "spray" several
> jhrajax responses to the client; the client has to initiated the request
> with a exactly one jdoajax(), right? So the client is not going to ever be
> able to accept extra jhrajax's that were not expressly requested. Or, if
> that is wrong, then I would like to be told about how it is done, because
> that may be the only solution to my problem.
>
>
> > Meanwhile when I look at your definition of paint in tgsjhs.ijs I see
> this
> > line:
> > drawpathlist =. {:DrawPathList
> >
> > In other words paint is currently implemented to only paint a part of the
> > picture. Why?
> >
> > No, paint produces turtle images (avatars?) as well as paths in the big
> for. loop. It is actually creating 3D points defining triangle corners and
> face normals.
>
>
> > On the other hand, when I look at tgsjhsutil.h I see you are using
> 'paint'
> > in a variety of places.
> >
> > That is the very issue for my problem: paint is ubiquitous and yet
> somehow
> all of those paints' (plural and possessive) results must be collected into
> one package, in their order of creation, to be sent back to the client.
>
>
> > I think if you just arranged to draw all of DrawPathList you'd get the
> > visual effect that I think you are looking for. Usually, that is - you
> are
> > counting on the browser to queue its requests in the order they were
> > generated, and that might glitch in some browsers. Still, it should work
> as
> > a first approximation, and I think that that would be a worthwhile
> > exercise.
> >
>
> I think this point might need some revision, now that you know the paints
> produce avatars, too.
>
>
> > Meanwhile, to achieve what I think you are trying to achieve (which is a
> > step-by-step style), ... actually I can think of a lot of ways to
> > accomplish that. One fun way involves using jQuery's deferred objects.
> This
> > allows you to lay out your javascript code so that the sequence-over-time
> > is laid out physically using a structure rather like if/then/else
> > statements (but it's really more like working with J gerunds, using the
> > "gerund-like-objects" to allow code to pick up and continue after
> receiving
> > a response from the server).
> >
> > Maybe this is exactly what I need.
>
> I found this example. http://jsfiddle.net/ehynds/Mrqf8/
> I opened my console, I think. So far this is what I see in the console.
>
> [Log] I fire once BOTH ajax requests have completed! (show, line 33)
> [Error] Failed to load resource: the server responded with a status of 500
> (Internal Server Error) (random.js, line 0)
>
> I don't get it. But the name "deferred objects" sounds good for my needs.
> Is it a way to overcome my expectation of the need for a 1-1 relationship
> between jhrajax's and jdoajax()'s ? I have no experience with Jsquery.
>
>
>
>
>
> > Maybe some of this helps?
> >
> >
> Absolutely, it helps. Do you still think deferred objects is the way to go,
> and there is no hope for accomplishing my goal using J features?
>
> Thanks, very much,
>
>
> > Thanks,
> >
> > --
> > Raul
> >
> >
> --
> (B=)
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
>
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
