Tim:
In a previous thread (http://bit.ly/2jgHsth) you mentioned:

<< ...the latest ECMAScript (7), there are now things like the "await" keyword that I'll be surfacing in EWB.  They will allow you to do things like this:

await Database.LoadRows(MyDataSet);
...Do some other stuff *after* the rows are loaded...

IOW, no more callback spaghetti.>>


Is there a fix you can share to surface the 'await' keyword in EWB? The requisite callback spaghetti without it is a tremendous source of development frustration as an app gets more complicated.

Also, Echo Support to the Transaction Commits. I am really hoping it made it into the 2.06 update as word was it would have been in 2.03 or 2.04.

On 1/8/2017 3:23 AM, Trinione wrote:
> << ...the latest ECMAScript (7), there are now things like the "await" keyword that I'll be surfacing in EWB.  They will allow you to do things like this:
> await Database.LoadRows(MyDataSet);
> ..Do some other stuff *after* the rows are loaded...
> Is there a fix you can share to surface the 'await' keyword in EWB? The requisite callback spaghetti without it is a tremendous source of development frustration as an app gets more complicated.

This is only part of latest ES7 so browser support is very limited at
this time - basically only chrome (v55+) and Opera (v42+) support it at
this time.

Firefox has it in dev builds and IE,Edge,Safari have no support at all
at this time.

See : http://caniuse.com/#search=await


Raul

Trinione wrote:

> Also, Echo Support to the Transaction Commits. I am really hoping it made it into the 2.06 update as word was it would have been in 2.03 or 2.04.

Oi! Stop adding more to it!   8-)

--

Matthew Jones

Raul wrote:

> This is only part of latest ES7 so browser support is very limited at this time

Presumably though, it could actually be done purely by the EWB compiler? Not sure that would be a good use of time, but theoretically...

--

Matthew Jones

The items I raised are based on Tim's statements in this forum on these two issues.

The callback spaghetti is extremely very time consuming and challenging especially as an app gets more involved.

Tim would know best how to achieve the echoing of transaction commits. EWB doing this rather than any workaround techniques would be the best solution.

I am hopeful of a positive feedback from Tim on this as these two areas have proven to be most challenging in my development and enhancement of EWB projects thus far.

I do appreciate that there are fiddly things in the coding of these things - callbacks are common. But I was primarily joking on the "stop adding", hence the smiley. Obviously it would be good for Tim to ship what he has now, and go into another phase of development if this is not already in. One thing we know is that Tim doesn't ship half-done product, and that takes time. I'm happy to wait for the quality, even if it is sometimes uncomfortable. That's separate to the await keyword, which would indeed be nice in all sorts of places. That said, if the asynchronous nature of browser programming is hidden too much, we will find that it ends up causing all sorts of unexpected delays that we can't understand.


--

Matthew Jones

Matthew:
Don't get me wrong, I completely understand all that you are saying. My questions are not intended to delay 2.06.

What I pointed out with the Echo has been raised in 2015 and may have slipped Tim as other matters popped up and consumed his time. However, as we in Jan 2017 it is not unfair to ask for an update on this as it was earmarked for release 2.03 or 2.04.

Regarding the 'await', from what I understand this can change the programming approach significantly and save hours of development and maintenance time and in situations where users can use modern browsers will aid in reducing development time, costs and quality of resulting application.

On 1/9/2017 4:18 AM, Matthew Jones wrote:
> Presumably though, it could actually be done purely by the EWB compiler? Not sure that would be a good use of time, but theoretically...

Sure - it's just code

I think this comes down to browser support also - on one hand  i expect
major modern browsers (Chrome, FF) to support this natively later this
year if not already so question will be around things like IE/Edge,
Safari and of course mobile.

To roll your own : I'm no JS expert but looks like it's reasonably
doable in EWB compiler if browser supports ES6 - only ones that do not
appear to be IE11 (Edge is OK).


Raul

On 1/9/2017 9:05 AM, Trinione wrote:
> What I pointed out with the Echo has been raised in 2015 and may have slipped Tim as other matters popped up and consumed his time. However, as we in Jan 2017 it is not unfair to ask for an update on this as it was earmarked for release 2.03 or 2.04.

It's never unfair to ask.

One reason it's likely taking longer (my opinion only) is that this I
believe represents a fairly major breaking change (on both back-end and
EWB framework level). Both to make sure everything still works but also
then to surface all the results for EWB apps.

> Regarding the 'await', from what I understand this can change the programming approach significantly and save hours of development and maintenance time and in situations where users can use modern browsers will aid in reducing development time, costs and quality of resulting application.

Unfortunately in EWB this would have to work with all supported browsers
- EWB cannot only support some of them. Hence this again would represent
major amount of work for example to get this to work with IE11 for
example or mobile browsers.

I have no doubt Tim has these designed and likely even implemented to
some degree and likely ran into further complications.

Raul

<< Is there a fix you can share to surface the 'await' keyword in EWB? The requisite callback spaghetti without it is a tremendous source of development frustration as an app gets more complicated. >>

No.  I've already looked into it extensively, and it will require a major re-work of the way that the compiler emits the JS (at least for functions that use await).   Essentially, every line in a function after a given await call needs to be chained to the original function as a closure so that it captures the current stack, but won't get executed until after the first call returns.  But, that's not really even the hard part - the hard part is how to design the functions that need to be waited on, especially in terms of things like server requests.  Because, then you start getting into the need for promise objects and other things that are going to be hard to design into EWB as it currently exists.  In other words, the re-writing of the *calling* functions is the easy part, the hard part is how callbacks from server requests get translated into triggering the await to stop waiting and continue on with the next "line" after the await line.

<< Also, Echo Support to the Transaction Commits. I am really hoping it made it into the 2.06 update as word was it would have been in 2.03 or 2.04. >>

The dataset updates are going to need some re-architecting to accomplish the echo support, hence the delays.  The problem isn't EDB and DBISAM, it's ADO database access to engines like SQL Server that don't provide proper support for echoing values from an insert without resorting to scripting like this:

INSERT INTO xxxx;
SET :ID = SCOPE_IDENTITY();

in order to set the output parameters from an insert.  This is going to result in EWB not building the INSERT, etc. statements dynamically, but rather forcing the developer to specify them for each dataset so that engine-specific constructs like this can be implemented without me trying to figure out every combination of every ADO database engine's requirements for emitting output/result parameters.

Tim Young
Elevate Software
www.elevatesoft.com