It would be nice if EWB supported a project type of "Form Library". With this project type, there wouldn't be any Auto-Created forms. The generated JavaScript wouldn't contain the Component Library code. Applications created from Visual projects would be able to dynamically load "Form Library" JavaScript. The "Form Library" JavaScript would rely on the Component Library of the application that dynamically loaded the "Form Library" JavaScript.

This would allow someone to create a small application with only a login screen. If the user provides valid credentials, then the application could dynamically load other "Form Library"s, depending on the user's role(s), and use the forms in the library.

David Westbrook wrote:

> This would allow someone to create a small application with only a
> login screen. If the user provides valid credentials, then the
> application could dynamically load other "Form Library"s, depending
> on the user's role(s), and use the forms in the library.

It is a nice idea, but there is a drawback to your suggestion, and that
is that it defeats two things. First, the compression by elimination of
unused functions, which Tim has worked hard on to make sure that the
application is as small as possible. By "linking" to a master, you'd
have to make that much bigger. Second, the obfuscation would stop
working, as you would have to be able to link to the master using
defined names, and that would be a hole (not that it is perfect anyway
of course).

But there is actually nothing to stop you doing what you want today,
sort of. Write your login application, and if they log in okay, use
localStorage to store a token, and then tell the browser to load the
main application. The main application loads the token and uses that to
authenticate. If the token fails (too old or whatever) then it deletes
the token and reloads the login application. Otherwise it continues. Of
course the user can see the full application URL now, and thus get it
anyway, which brings us to why it doesn't really matter much as the
final verification that someone can do something should be done on the
server.

In my applications, I have a main window which is the parent of the
other forms (they don't usually look very form like, just content). If
not signed in, then the login form is shown. Once logged in, the
content forms are shown instead. So the content form is not available
if you are not logged in, unless of course you hack the javascript or
variables in some way, but that's getting quite advanced, and really
you just want to hack the server for such benefit.

Just my 2 cents. 8-)

--

Matthew Jones

On 10/27/2015 10:12 PM, David Westbrook wrote:
> It would be nice if EWB supported a project type of "Form Library". With this project type, there wouldn't be any Auto-Created forms. The generated JavaScript wouldn't contain the Component Library code. Applications created from Visual projects would be able to dynamically load "Form Library" JavaScript. The "Form Library" JavaScript would rely on the Component Library of the application that dynamically loaded the "Form Library" JavaScript.

I'm trying to understand the end goal better (the benefit)  ?

One does not need to auto-create any forms (other than 1st, but of
course they're still part of the application).

Are you looking at reducing the size of downloads (however now you need
to download more data as app runs and deal with any issues related to
that and delays associated).

Or are you looking at ways to easily partition a really large (in terms
of generated javascript) app that is logically multiple apps inside ?

Or are you looking at creating "app modules" that yo ucan then combine
to create various master apps ?

One issue i see with this approach is that EWB app is a compiled app and
component library is not really a separate piece (not to mention one can
use own components derived from library so this whole business needs to
be handled at compile time).

The number of issues would also get complex quickly -  basic versioning
issues alone (mismatch of form library vs loader app), missing
components and of course what Matthew also mentioned is that now you
always need to include FULL component library for everything (even hello
world app) since everything could be used by some loaded form library etc ).

Long term i EWB might need to look at some sort of a loader (get basic
UI down so user has has feedback and then download the main app) but
that is already doable in other ways and really only issue if app size
gets really massive so initial download and startup becomes a delay problem.

> This would allow someone to create a small application with only a login screen. If the user provides valid credentials, then the application could dynamically load other "Form Library"s, depending on the user's role(s), and use the forms in the library.

This IMHO can be accomplished today (see Matthews email with some
suggestions) by just using a couple of different back-end EWB apps.

EWB is object oriented so you can reuse the exact same forms and units
(and built-in as well as custom components) in all those apps and just
need couple of separate projects to compile and deploy them together.

Raul

Raul wrote:

> Long term i EWB might need to look at some sort of a loader (get
> basic UI down so user has has feedback and then download the main app)

Keep up at the back there! 8-)

Project, Options, Show load progress option.

--

Matthew Jones

On 10/28/2015 10:52 AM, Matthew Jones wrote:
> Keep up at the back there! 8-)
> Project, Options, Show load progress option.

That's progress for the app loading its forms and populating them -
really useful if your app startup does web queries or has compelx layout.

However this only shows once JS is already downloaded to client side
(it's the 2nd delay of app loading).

The 1st delay is browser getting the js in the first place.

Browser loads the html which has the JS references in the head section
so it will then request and load all JS files as well (and depending on
their size the actual parsing in js engine will add some delay also).

Not a big deal with smaller apps and LAN/fast connection but if you're
on a (slightly slower) connection and your JS hits 3-4 MB then there
will be a delay and would be nice to show some progress..

Anyways, not really an issue yet and browser caching helps a lot after
initial load

Raul

Raul wrote:

> The 1st delay is browser getting the js in the first place.

But you can just modify the web page for that, or put in a loader page
that redirects immediately to the "real" one. Not sure there is
anything more one could to in EWB that would help there.

--

Matthew Jones

On 10/28/2015 12:45 PM, Matthew Jones wrote:
> But you can just modify the web page for that, or put in a loader page
> that redirects immediately to the "real" one. Not sure there is
> anything more one could to in EWB that would help there.

I know and that's what i use - as i said before not an important feature
by any means at this point since we have workarounds.

I ran some tests awhile ago and a 1.2MB JS file took some 9 sec to load
on iPhone 5s over WiFi (hosted from amazon s3).

A "special" 6MB JS file (i added 5MB of comments so it should not affect
running but download and parsing) took 20+ sec.

I need to see how big does a "serious" app get first (most of these are
test and demo so far) - compression really helps but 5+MB app could
really benefit from some "chunking".

This is why i asked about clarification about the original OP. If one
could put up a login page while continuing to load more pieces it would
be super cool  (of course as part of same app - i know i can redirect
but then we're back to possibly long load times after).

Raul

Raul,

<< I ran some tests awhile ago and a 1.2MB JS file took some 9 sec to load on iPhone 5s over WiFi (hosted from amazon s3). >>

Yes, but you have to put in some work to get over 1-1.5MB of compressed JS for EWB.  The reason is pretty simple: because the EWB compiler does global namespace compression, you have to start coming up with some pretty long and unique names in order to get the compression to go over 2-3 bytes per identifier.  Take "color" for example:  regardless of what you do in your application, every single reference to that identifier, no matter where it resides, will result in only two bytes being output to the JS.  Same for "name", "height", "width", etc.  Of course, if you start putting a bunch of long string constants in your code, you can balloon things up pretty quickly....

Tim Young
Elevate Software
www.elevatesoft.com

David,

<< It would be nice if EWB supported a project type of "Form Library". With this project type, there wouldn't be any Auto-Created forms. The generated JavaScript wouldn't contain the Component Library code. Applications created from Visual projects would be able to dynamically load "Form Library" JavaScript. The "Form Library" JavaScript would rely on the Component Library of the application that dynamically loaded the "Form Library" JavaScript.

This would allow someone to create a small application with only a login screen. If the user provides valid credentials, then the application could dynamically load other "Form Library"s, depending on the user's role(s), and use the forms in the library. >>

I have the same questions as Raul, and Matthew covers the downsides pretty well.  These downsides are why minification is problematic with hand-coded JavaScript code:  there's no really efficient way to do minification and of code without needing to add an exported symbol layer that translates between the "normal" identifiers and the minified identifiers.

Tim Young
Elevate Software
www.elevatesoft.com

I'm wondering how large of an application can be built with EWB before the download size, startup time and memory usage becomes intolerable.

If "Form Libraries" can be swapped in and out as needed, then an application can be infinitely large.

I agree that a large application could be broken up into many small applications. For example, a login application could launch another application. But, then the component library code is loaded each time an application is started.