Hi Tim,

<< Is there anything in particular that stands out as something that might
prevent you from using the product ? >>

Definitely needs the grid you are working on.  For me, this will be one of the most used components.

<< Do you approve of the general direction/scope of the product ?  Where would
you like to see the product go from here ?>>

I really like the direction it's heading in.  I'd like to see the addition of:

* Menu/navigation bar component/s
* HTML Editor component (eg. similar to CK Editor, TinyMCE, etc)
* Drop-down calendar component
* Panel with visible, colour-definable borders
* Some AJAX like functionality for special effects
* Code completion features in the editor

<< Does the product fit your definition of "rapid application development" ? >>

Yes, developing a web app seems to be very quick - faster than the way I do it now with PHP.  The product has been really good so far.  Great work!

Steve

Hi Tim

Looks great so far - it's something I'll definitely use. With EWB and
FireMonkey I'm optimistic I'll be able to cover all platforms from a
single code base (with a few IFDEFs .

I agree with the other posters that a way of both (i) including external
Javascript files and (ii) wrapping existing Javascript components would
be a great benefit. I've recently downloaded ExtPascal - haven't had a
chance to look at it but it might provide a prototype for wrapping JS
components. Other features I'd like are:

1. Ability to change default code file extension to .pas.

2. Ability to reference external .pas files.

3. Ability to have an in-line Include of an external .pas file.

4. Chart control - probably a major piece of work so a 3rd party wrapper
might be the only feasible approach.

1 to 3 might be available already (I haven't had too much time to
investigate) but would help to keep a more common code base for my
non-visual classes. I'm looking at DSharp for MVVM in Delphi and
KnockOut for MVVM in Javascript with the aim of migrating the vast bulk
of my code to non-visual classes.

Looking good though - congratulations on a nice product.

Cheers, Bob

Thanks to everyone for their thoughts on the product.

Just a couple of comments on external JS:

External JS code:  The deployment option will have the ability to bundle in
external files that get included in the bootstrap HTML (it also might end up
as a "compilation" configuration item).  As far as interfacing with EWB,
check out the WebDOM.wbs framework source unit on how you define an
interface for external JS code.  Most of the code in there is either in the
DOM or in core JS itself, and it is the entire basis for how EWB's framework
interacts with the DOM in the browser.

External JS visual control:  This will most likely not happen, at least not
in a way that that actually displays the control contents at design-time.

In general:  the whole point of EWB is to avoid having to go down to the JS
level for a few reasons:

1) Core JS cannot "exclude" code that isn't referenced, EWB's compiler can.
Core JS is not necessarily compressed, EWB's emitted code can be.  If you
start adding a bunch of external JS files to a project, especially large
frameworks or libraries, you won't be happy with the resulting performance
and size and you'll reach critical mass pretty quickly.

2) Core JS is not type-checked at all, and is not checked for syntax errors
until it is compiled at runtime.  Including a lot of external JS is simply
going to eliminate one of the primary reasons for using the EWB compiler -
an assurance that your application will execute and behave properly once it
compiles successfully.  If all of your code is compiled via EWB, then the
only thing you're likely to see as a runtime error is a NULL/NAN issue, or
possibly a stack overflow if you have infinite recursion.  With external JS,
someone could easily overwrite a variable declaration, or even an object
property, in your application, and you would have to debug their JS code to
find out how/why.  EWB takes steps to ensure that this won't happen, due to
the way that it declares identifiers, but it is still something that could
happen.  JS is an "anything goes" language, especially in terms of code
scope.

3) jQuery and frameworks of that nature are nice for JS developers, but they
are not compatible with EWB for some very basic reasons.  jQuery works at
the DOM level primarily and could, possibly, alter some of the internal DOM
elements that are used in EWB's framework in a negative way.  If you want to
work directly with DOM elements, you can do so via the WebDOM unit.  You can
easily do the same things that you do in JQuery, but in Object Pascal code.
In general, JQuery is not complimentary to EWB because they are both trying
to do the same thing and there is way too much overlap for it to make sense
to use both.  The same is true for JS widget sets like ExtJS, etc.

4) The general idea is that custom controls, etc. be developed in Object
Pascal using EWB, not JS.  Although you can interface with external
functions/procedures and objects with EWB as a stop-gap measure, it will be
a lot easier to implement such controls directly in EWB.  If you spend some
time looking at WebCtrls.wbs, for example, you'll notice that it is a fairly
simple process to implement basic controls, and even what might be
considered more complex controls like charts.  It's going to take some time
for EWB to develop an ecosystem, but the controls will come pretty quickly
once things are solid on the IDE front.

So, to summarize - if you want to use a lot of JS and are more comfortable
with an all-JS environment and technologies, then you should use JS.  If you
want to code in Object Pascal and want all of the added benefits of the EWB
IDE, compiler, framework, themes, etc. then you should use EWB.

Thanks again,

--
Tim Young
Elevate Software
www.elevatesoft.com

Raul,

<< - mobile device support: my demo app runs fine on full browsers but for
now has issues with both ipad and (rim) playbook - ipad listview does not
get populated with items and on playboko button does not allow clicking. >>

Any browser that uses the IE, FF, or WebKit engines should work fine with
EWB applications.  I've been trying to avoid buying an I-whatever (damnit,
stop capitalizing stuff for me, spell/grammar checker because it ticks
me off that they don't allow you to develop for the platform on another OS,
but I may have to bite the bullet and buy an iPad.

<< Desktop auto-size option is too large on mobile devices so i need to go
and change it manually once the forms are done to avoid large grey
background with small form on limited screen size. >>

Yep, it happens on Android also.  In general, I'm going to have to do a
thorough review against the mobile browsers to make sure that things are
working correctly.  There are some issues with non-tabbable controls also -
for example, you can't "click" on the close button for forms.

<< Final reason why i'm very excited about this is that we have had a very
good track record with Elevate Soft products and support - both quality and
timeliness of response and resolution of issues and suggestions - so its as
much about picking a company and team behind it as it is about picking a
product. >>

Thanks for the kind words.

--
Tim Young
Elevate Software
www.elevatesoft.com

Steve,

<< * Some AJAX like functionality for special effects >>

TServerRequest/TServerRequestQueue *is* AJAX.  What did you have in
mind, in particular ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Ok that puts a different slant on things. I'm happy to wait for
components to come - the reasons you give here make sense.

What about the possibility of linking in external .pas files for
non-visual classes - is that something reasonable?

Apart from charts the other components important to me are:

1. Treeview
2. Dockable panel - e.g. like this:

http://dev.sencha.com/deploy/ext-4.0.2a/examples/portal/portal.html.

Cheers, Bob

About:
1) Core JS cannot "exclude" code that isn't referenced, EWB's compiler can.
Core JS is not necessarily compressed, EWB's emitted code can be.  If you
start adding a bunch of external JS files to a project, especially large
frameworks or libraries, you won't be happy with the resulting performance
and size and you'll reach critical mass pretty quickly.

: This is certainly true - but then, there are some JS libraries that do things really well and are wonderfully optimized - there are very big web sites working with these - so - like anything else - if you choose your stuff carefully - there are wonderful options out there.


About:
2) Core JS is not type-checked at all, and is not checked for syntax errors
until it is compiled at runtime.  Including a lot of external JS is simply
going to eliminate one of the primary reasons for using the EWB compiler -
an assurance that your application will execute and behave properly once it
compiles successfully.  If all of your code is compiled via EWB, then the
only thing you're likely to see as a runtime error is a NULL/NAN issue, or
possibly a stack overflow if you have infinite recursion.  With external JS,
someone could easily overwrite a variable declaration, or even an object
property, in your application, and you would have to debug their JS code to
find out how/why.  EWB takes steps to ensure that this won't happen, due to
the way that it declares identifiers, but it is still something that could
happen.  JS is an "anything goes" language, especially in terms of code
scope.

: Again - this is true, but if you use libraries that are properly using closures - this is a no-issue - as they limit the use of global scope variables and allow you to override it.

About:
3) jQuery and frameworks of that nature are nice for JS developers, but they
are not compatible with EWB for some very basic reasons.  jQuery works at
the DOM level primarily and could, possibly, alter some of the internal DOM
elements that are used in EWB's framework in a negative way.  If you want to
work directly with DOM elements, you can do so via the WebDOM unit.  You can
easily do the same things that you do in JQuery, but in Object Pascal code.
In general, JQuery is not complimentary to EWB because they are both trying
to do the same thing and there is way too much overlap for it to make sense
to use both.  The same is true for JS widget sets like ExtJS, etc.

: - I plan to look at this unit - but at the end of the day - they both create code that runs down to the same DOM managed by the browser - so if you pay attention to what you are doing - it should not matter.

About:
4) The general idea is that custom controls, etc. be developed in Object
Pascal using EWB, not JS.  Although you can interface with external
functions/procedures and objects with EWB as a stop-gap measure, it will be
a lot easier to implement such controls directly in EWB.  If you spend some
time looking at WebCtrls.wbs, for example, you'll notice that it is a fairly
simple process to implement basic controls, and even what might be
considered more complex controls like charts.  It's going to take some time
for EWB to develop an ecosystem, but the controls will come pretty quickly
once things are solid on the IDE front.

: Again - will look at this - but there are some world-class widget out there that it would be a shame if we can not use them - especially if the way they are instantiated is rather simple and can be done via code only.

All I am saying is that if there is a way for us to "escape" into javascript mode - when possible, it will allow some of us to take the tool to a higher level given our investment in other technologies.

I would really hope that something like the mentioned "javascript" block is made available - because it would be close to a trivial implementation on your side - and would be really useful for those of us that are willing to get our hands dirty.

Just like Delphi allows you to get into assembly code if you insist and you can call Win-API code from managed code in .NET...

As long as it comes with the caveat that "you are on your own" - I think it would be a useful addition.

Hi Tim,

<< Just a couple of comments on external JS: ..... >>

You've convinced me.  I think your plans for EWB are spot on.

<< TServerRequest/TServerRequestQueue *is* AJAX.  What did you have in mind, in particular ? >>

I was thinking along the lines of fades and that sort of thing.  Just UI types of special effects, but I consider these things as "nice to have".

One more control I thought of: a TPageControl would be nice.

Steve

What would also be nice is to be able to have an image for the desktop background, with the ability to tile it.

I suppose I could edit the project's stylesheet to do this.

Steve

Bob,

<< What about the possibility of linking in external .pas files for
non-visual classes - is that something reasonable? >>

You can do that now - you aren't just restricted to the framework source
(.wbs files) that comes with EWB.  Also, the reason for the .wbs file
extension is that the Object Pascal that is used is not entirely the same as
with normal Object Pascal, so to avoid any confusion or the possibility of
"normal" Delphi units getting picked up by accident by the compiler/search
paths I used a different file extension.

--
Tim Young
Elevate Software
www.elevatesoft.com