Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 31 total
Thread Suggestion: New Project Type - Form Library
Tue, Oct 27 2015 10:12 PMPermanent Link

David Westbrook

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.
Wed, Oct 28 2015 5:59 AMPermanent Link

Matthew Jones

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
Wed, Oct 28 2015 9:20 AMPermanent Link

Raul

Team Elevate Team Elevate

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
Wed, Oct 28 2015 10:52 AMPermanent Link

Matthew Jones

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
Wed, Oct 28 2015 11:41 AMPermanent Link

Raul

Team Elevate Team Elevate

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

Wed, Oct 28 2015 12:45 PMPermanent Link

Matthew Jones

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
Wed, Oct 28 2015 1:22 PMPermanent Link

Raul

Team Elevate Team Elevate

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
Wed, Oct 28 2015 3:18 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

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.... Smile

Tim Young
Elevate Software
www.elevatesoft.com
Wed, Oct 28 2015 3:21 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@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
Wed, Oct 28 2015 6:11 PMPermanent Link

David Westbrook

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.
Page 1 of 4Next Page »
Jump to Page:  1 2 3 4
Image