uniGUI Application Framework

[Farshad]

Hi all,

This project started back in mid 2008. The main goal of this framework
was to unify user GUI experience for both desktop and web. It means
that a single Delphi VCL project can be deployed either as a desktop
application or a web application. It helps developers to focus on
application logic rather than focusing on GUI front end. It also
maximizes code reuse as your source is portable to web or desktop with
almost no modification.

The initial version of project was based on Delphi's built-in "VCL for
the Web" aka Intraweb library. Below you'll find first public
discussion about this project and a couple of demos. Demos below uses
Intraweb based version of uniGUI.

https://forums.embarcadero.com/thread.jspa?threadID=22987

As you can see, in above thread Phil made me aware of ExtPascal and
its capabilities. He assured me that ExtJS and ExtPascal can work
perfectly with uniGUI. Fortunately, I listened to him and started
replacing the Intraweb backend with ExtPascal. Well, it was not that
easy. Intraweb comes with a full set of visual components and lots of
other features which uniGUI couldn't exist without them.

The most difficult task was to implement a thread-safe Web Component
infrastructure, session modules and server manager; similar to
Intraweb, all from scratch. Fortunately, everything went fine and only
in a few weeks I could develop my alpha version of uniGUI completely
based on ExtJS and ExtPascal.

What makes uniGUI unique among other web application frameworks is its
ability to morph itself either as a desktop application or a web
application. You longer need to create a separate version for web
deployment. Of course, you can use it to create only web
applications.

Here is my first demo that I shared with Phil and Delphi community a
few months ago:
http://prime.fmsoft.net/out/dbdemo.dll

My second online demo is available here. It demonstrates most of
implemented components and capabilities available in uniGUI:

http://prime.fmsoft.net/demo/mdemo.dll

Regards,
Farshad Mohajeri
FMSoft

[Wanderlan]

Hi Farshad,

When uniGUI will be released?
The license will be commercial or opensource?
Some trial/beta download?

TIA,
Wanderlan

[ssamayoa]

As Wanderlan asks, Im Interested also.
Regards.

[Bee Jay]

Hi Farshad,

On 11 Jun 2010, at 20:09, Farshad wrote:

> My second online demo is available here. It demonstrates most of
> implemented components and capabilities available in uniGUI:
> http://prime.fmsoft.net/demo/mdemo.dll

Very nice demo indeed, Farshad! I'll spread this over other Pascal/Delphi communities. :)

However, there's some enhancements in ExtPascal that I think need to be considered to make it the true web desktop application framework for Delphi/Pascal. Here they are:

1. Lack of built-in desktop/window manager. There's a main application which would act as the "OS" and host all child ExtPascal applications. As child app, ExtPascal app can be "un/installed" through the "OS", just like a desktop app on desktop OS. This way we could provide many apps to our clients from single URL. For example you may look at eyeOS.org.

2. Lack of browser side event handler. No matter how good ExtPascal app emulates desktop-like experience, it's still a web app. There many things and use cases where some process better be done on browser side. It also offers some advantages i.e. less client-server roundtrip, less server overhead, more responsive UI, etc. I think every ExtPascal should provide two kinds of event on its every control/widget: browser side event and server side event.

3. ExtJS is a very good JS UI framework, even the best in feature completeness, I suppose. However, due to its license scheme, there are some kind of apps that are unable to use it i.e. freeware closed-source apps. I think it'd be good if ExtPascal also offer other JS UI framework that close to ExtJS so ExtPascal users could have another option. I propose Qooxdoo.org.

Ok, I know my above suggestions are not easy things to do and have some risks and consequences. But in long term, I believe they'd do nothing but good for ExtPascal future.

What do you think?

-Bee-

[Farshad]

Hi Wanderlan,

Unfortunately I'm busy with other tasks right now and can't give
enough attention to this project. I try to give it a higher priority
soon. so I can't give a exact date. It is currently beta and I have
already used it in some of my own projects. Most probably it will be a
commercial product. I will setup a site for demo purpose and beta
downloads.

regards

[Farshad]

On Jun 11, 6:31 pm, Bee Jay <bee.ogra...@gmail.com> wrote:
> Hi Farshad,
>
> On 11 Jun 2010, at 20:09, Farshad wrote:
>
> > My second online demo is available here. It demonstrates most of
> > implemented components and capabilities available in uniGUI:
> >http://prime.fmsoft.net/demo/mdemo.dll
>
> Very nice demo indeed, Farshad! I'll spread this over other Pascal/Delphi communities. :)
>

Thanks :)

> However, there's some enhancements in ExtPascal that I think need to be considered to make it the true web desktop application framework for Delphi/Pascal. Here they are:
>
> 1. Lack of built-in desktop/window manager. There's a main application which would act as the "OS" and host all child ExtPascal applications. As child app, ExtPascal app can be "un/installed" through the "OS", just like a desktop app on desktop OS. This way we could provide many apps to our clients from single URL. For example you may look at eyeOS.org.
>

It could be interesting. I know that Ext JS supports this feature.
Problem here is that each application is a separate module. A
mechanism to call multiple modules in same browser window is needed.

> 2. Lack of browser side event handler. No matter how good ExtPascal app emulates desktop-like experience, it's still a web app. There many things and use cases where some process better be done on browser side. It also offers some advantages i.e. less client-server roundtrip, less server overhead, more responsive UI, etc. I think every ExtPascal should provide two kinds of event on its every control/widget: browser side event and server side event.
>

You can code browser side events in ExtPascal. Of course you must do
this manually but I think actual need for browser side events is very
application dependent and most applications don't need it at all. In a
fast network, server-side event handling is good enough. In ExtJS Ajax
calls are very short and efficient so round trips are not a big deal.

> 3. ExtJS is a very good JS UI framework, even the best in feature completeness, I suppose. However, due to its license scheme, there are some kind of apps that are unable to use it i.e. freeware closed-source apps. I think it'd be good if ExtPascal also offer other JS UI framework that close to ExtJS so ExtPascal users could have another option. I propose Qooxdoo.org.
>

Automatic translation of ExtJS objects to Pascal objects is what makes
ExtPascal unique. Other JS frameworks should be fully OO and well
documented enough to allow such a automatic translation.

[Bee Jay]

On 12 Jun 2010, at 02:38, Farshad wrote:

> It could be interesting. I know that Ext JS supports this feature.
> Problem here is that each application is a separate module. A
> mechanism to call multiple modules in same browser window is needed.

Of course. It could be provided through similar mechanism as CGI gateway/proxy. There is a main FCGI app (provided the "OS" environment) that received request and forwarded it to appropriate another FCGI app and return back the response to browser. Well... I know it's not as easy as it sounds but I think it's very doable.

> You can code browser side events in ExtPascal. Of course you must do
> this manually but I think actual need for browser side events is very
> application dependent and most applications don't need it at all. In a
> fast network, server-side event handling is good enough. In ExtJS Ajax
> calls are very short and efficient so round trips are not a big deal.

For intranet app, the round trips isn't a big deal, yes. But for public internet app, the slugginess is very noticable.

> Automatic translation of ExtJS objects to Pascal objects is what makes
> ExtPascal unique. Other JS frameworks should be fully OO and well
> documented enough to allow such a automatic translation.

IMO, the OO of Qooxdoo is very good. It's even better than ExtJS to some points. The Qooxdoo API doc is also very good and provided as JSON, so it's easier to parse. The problem with Qooxdoo is its feature and widget aren't as rich as ExtJS, but it should be enough for common RIA apps. eyeOS is using Qooxdoo.

-Bee-

[Michael Van Canneyt]

> > 2. Lack of browser side event handler. No matter how good ExtPascal app emulates desktop-like experience, it's still a web app. There many things and use cases where some process better be done on browser side. It also offers some advantages i.e. less client-server roundtrip, less server overhead, more responsive UI, etc. I think every ExtPascal should provide two kinds of event on its every control/widget: browser side event and server side event.
>
> You can code browser side events in ExtPascal. Of course you must do
> this manually but I think actual need for browser side events is very
> application dependent and most applications don't need it at all. In a
> fast network, server-side event handling is good enough. In ExtJS Ajax
> calls are very short and efficient so round trips are not a big deal.

This is a common misconception. On slow networks or very busy servers,
they are a big deal.

I have servers with many hundreds of simultaneous users, and if every
GUI change/action required
a server call, the sheer number of calls would severely slow down the
response time.
This is demonstrated easily enough.

Also, programming like this requires you to maintain a mirror image of
the web page on the server
for any kind of decent GUI. That does not scale very well.

I'm afraid I must agree with Bee: client-side programming is important
if you want to create complex programs
with a rich and responsive GUI. Have a look at Morfik; it's really
very good at that (but has other issues)

[Farshad]

On Jun 12, 10:52 am, Michael Van Canneyt <mich...@freepascal.org>
wrote:

> This is a common misconception. On slow networks or very busy servers,
> they are a big deal.
>

On fast networks it is not noticeable by the user, but of course, I
agree that handling every event adds some extra load to the server.
Whether it is a big deal or not, highly depends on your particular
design. In uniGUI, lots of GUI events such as window resize or window
move are handled in small portions of code. It adds some load to the
server but we can't say it is good or bad unless we sit and calculate
the "real added overhead" for a particular application. GUI events are
triggered by the users and we can limit the way users can interact
with the GUI. For example, in ExtJS you can disable keyboard
navigation in grids.

> I have servers with many hundreds of simultaneous users, and if every
> GUI change/action required
> a server call, the sheer number of calls would severely slow down the
> response time.
> This is demonstrated easily enough.
>

Again, a detailed profiling is needed to see what's going on inside a
particular server application. Here, we're dealing with pure AJAX
apps, where calls have very little overhead. Compare it with classical
html non-AJAX web pages where each call refreshes who page. With AJAX
we have some luxury to allow server process more and more client
events. That said, I agree with you that server shouldn't be kept busy
with unnecessary client events. It's a matter of smart design.

> Also, programming like this requires you to maintain a mirror image of
> the web page on the server
> for any kind of decent GUI. That does not scale very well.
>

Correct, but this is fate of a "stateful" web application. In a
stateful app we keep all the state info on the server side, so every
change should be reflected back to the server. Server is where
application resides, browser is only a mirror of what is running on
the server. I agree that stateful web applications don't scale well.
Careful design is needed to free resources as soon as they're no
longer needed. In uniGUI, by default, forms are freed when you close
them.

> I'm afraid I must agree with Bee: client-side programming is important
> if you want to create complex programs
> with a rich and responsive GUI.

Not necessarily. You can design your app in a way where need for
client-side programming is minimized. Again, as I told above, it
depends on your particular app. There are cases where client side
event handling is certainly needed.

[Michael Van Canneyt]

On Jun 12, 10:58 am, Farshad <farshad.mohaj...@gmail.com> wrote:
> On Jun 12, 10:52 am, Michael Van Canneyt <mich...@freepascal.org>
> wrote:
>
> > This is a common misconception. On slow networks or very busy servers,
> > they are a big deal.
>
> On fast networks it is not noticeable by the user, but of course,  I
> agree that handling every event adds some extra load to the server.
> Whether it is a big deal or not, highly depends on your particular
> design. In uniGUI, lots of GUI events such as window resize or window
> move are handled in small portions of code. It adds some load to the
> server but we can't say it is good or bad unless we sit and calculate
> the "real added overhead" for a particular application. GUI events are
> triggered by the users and we can limit the way users can interact
> with the GUI. For example, in ExtJS you can disable keyboard
> navigation in grids.

Yes, but this contradicts with the 'rich' in "rich internet
applications".
I don't want these restrictions. Or, more accurate: our clients don't
want these restrictions.

I tried some very simple ExtPascal application, at the request of my
employer.
For a extremely simple (to our standards) page, I had to add already
10
event handlers for various very simple GUI actions. Actions of the
type
'disable one control when a checkbox is checked/unchecked'.

Actions of this kind should not invoke a server round-trip.
a) it is slow. (we're not on an intranet)
b) it requires you to keep an instance of the control on the server to
be able to set it's state.

I know you can do them in ExtPascal with client-side Javascript, but
not all handlers were this trivial.

>
> > I have servers with many hundreds of simultaneous users, and if every
> > GUI change/action required
> > a server call, the sheer number of calls would severely slow down the
> > response time.
> > This is demonstrated easily enough.
>
> Again, a detailed profiling is needed to see what's going on inside a
> particular server application. Here, we're dealing with pure AJAX
> apps, where calls have very little overhead. Compare it with classical
> html non-AJAX web pages where each call refreshes who page. With AJAX
> we have some luxury to allow server process more and more client
> events. That said, I agree with you that server shouldn't be kept busy
> with unnecessary client events. It's a matter of smart design.

Some pages are hard to handle 'smart'. Our clients expect the
functionality
of a desktop application - in a web browser.

>
> > Also, programming like this requires you to maintain a mirror image of
> > the web page on the server
> > for any kind of decent GUI. That does not scale very well.
>
> Correct, but this is fate of a "stateful" web application.  In a
> stateful app we keep all the state info on the server side, so every
> change should be reflected back to the server. Server is where
> application resides, browser is only a mirror of what is running on
> the server. I agree that stateful web applications don't scale well.
> Careful design is needed to free resources as soon as they're no
> longer needed. In uniGUI, by default, forms are freed when you close
> them.

Glad to hear that you take it into account :)

>
> > I'm afraid I must agree with Bee: client-side programming is important
> > if you want to create complex programs
> > with a rich and responsive GUI.
>
> Not necessarily. You can design your app in a way where need for
> client-side programming is minimized. Again, as I told above, it
> depends on your particular app. There are cases where client side
> event handling is certainly needed.

Yes, unfortunately, I am in this case. Our clients demand a rich and
responsive
client (as they have in our traditional N-tier client/server apps),
which implies
quite some client-side processing.

It is one area where I hope Extpascal will still improve.

Anyway, this is a side-track. None of what I said is meant to diminish
your results:
uniGUI and ExtPascal are both wonderful achievements.

[Bones]

That is seriously seriously impressive farshad.

I would love to get involved in the beta testing for this and the vcl
for web incarnation.

Can I post my pre-order now ? where do I sign ?

[Farshad]

On Jun 12, 12:35 pm, Michael Van Canneyt <mich...@freepascal.org>
wrote:

> Yes, unfortunately, I am in this case. Our clients demand a rich and
> responsive
> client (as they have in our traditional N-tier client/server apps),
> which implies
> quite some client-side processing.
>
> It is one area where I hope Extpascal will still improve.

Biggest problem here is that there is no automatic way of code
generation for client-side scripts. In RAD approach, users design
forms and write event handlers which are likely to run on server side.
Re-writing event handlers for client-side requires manual intervention
for each and every form. Also, it needs a fair knowledge of client
side scripting language, ExtJS in our case. Another question here is
that how and when the client side "new state" is going to be posted to
the server. For example, in uniGUI all anchoring calculations are done
on server side. One reason for this it that ExtJS's built in Anchoring
capabilities are a subset of Delphi's Anchoring capabilities. Another
reason is even if I implement all anchoring capabilities in Java
Script, how and when am I going to refresh the new anchored Control
positions on the server?

All of these concerns forces uniGUI to be a server-centered framework.
I know that this limits the areas where uniGUI can be used. It is not
a good choice for slow internet where ping time is above 200ms, but it
can be a good solution for intranet and fast internet. Number of
active sessions is another problem. uniGUI keeps all sessions in
memory until they're terminated or timed out. A session which consumes
a lot of memory may force the server to run out of memory when a fair
amount of sessions, say 500, are active. So, scalability can be
another problem.

[Farshad]

On Jun 13, 8:36 pm, Bones <jr...@yahoo.com> wrote:
> That is seriously seriously impressive farshad.
>
> I would love to get involved in the beta testing for this and the vcl
> for web incarnation.
>

Thanks.

> Can I post my pre-order now ? where do I sign ?

I plan to release a public or private beta soon. I'll keep you
informed.

I think the biggest problem here is that 90% of the project takes 10%
of total time. The remaining 90% of time time is dedicated to the
never ending 10%. :)

[Michael Van Canneyt]

On Jun 14, 10:10 pm, Farshad <farshad.mohaj...@gmail.com> wrote:
> On Jun 12, 12:35 pm, Michael Van Canneyt <mich...@freepascal.org>
> wrote:
>
> > Yes, unfortunately, I am in this case. Our clients demand a rich and
> > responsive
> > client (as they have in our traditional N-tier client/server apps),
> > which implies
> > quite some client-side processing.
>
> > It is one area where I hope Extpascal will still improve.
>
> Biggest problem here is that there is no automatic way of code
> generation for client-side scripts. In RAD approach, users design
> forms and write event handlers which are likely to run on server side.

Well, see Morfik. They do it since years. (www.morfik.com)

I am working to reproduce that in Free Pascal.
I have the pascal parser and Javascript parser ready.
Now I just need to convert the syntax trees and write out the
javascript.

[Marcos Douglas]

You will publish this in FPC, right?

Marcos Douglas

[Wanderlan]

Oi Farshad,

> A session which consumes
> a lot of memory may force the server to run out of memory when a fair
> amount of sessions, say 500, are active. So, scalability can be
> another problem.

How many bytes, 500 users consume?
You have an estimate?

Att
Wanderlan

[Farshad]

It depends on your app. A session with an empty form may occupy only a
few kilobytes. But if in each session you have a TClientDataSet which
holds 2 MB of data then 500 sessions mean 1 GB of memory!

[Wanderlan Santos dos Anjos]

Hi Farshad,

1 GB is short memory for a server. My netbook has 2GB.
The current real servers have 32 GB or more...

Att,

Wanderlan

[Farshad]

On Jun 15, 12:17 am, Wanderlan Santos dos Anjos

Well, Delphi has a 32-bit compiler. :)
With 64-Bit Delphi or FPC port of uniGUI memory shouldn't pose a real
problem.

[Michael Van Canneyt]

This is the intention, yes.

[Michael Van Canneyt]

On Jun 14, 11:08 pm, Farshad <farshad.mohaj...@gmail.com> wrote:
> It depends on your app. A session with an empty form may occupy only a
> few kilobytes. But if in each session you have a TClientDataSet which
> holds 2 MB of data then 500 sessions mean 1 GB of memory!

Well, most of my forms have 2 or more clientdatasets,
Having 5-10 client datasets is not an exception.
some have up to 40 clientdatasets.

And a user can open multiple forms in 1 session.
Now count the memory use :-)

It would be good to be able to track the memory use of a form.
A simple algorithm is to track all components on a form, adding
InstanceSize
and adding the lengths of all published string properties of all
components,
tpersistents and collections (can be done with RTTI).
That gives the absolute minimum of memory a form needs. For client
datasets, you can
then add the sizes of all fields (datasize) and then multiply this
with the number of records.
This will give you a very rough estimate, the real size will be even
higher.

[bdgr...@mailbolt.com]

At 05:06 PM 6/14/2010, you wrote:

>On Jun 14, 11:08 pm, Farshad <farshad.mohaj...@gmail.com> wrote:
> > It depends on your app. A session with an empty form may occupy only a
> > few kilobytes. But if in each session you have a TClientDataSet which
> > holds 2 MB of data then 500 sessions mean 1 GB of memory!
>
>Well, most of my forms have 2 or more clientdatasets,
>Having 5-10 client datasets is not an exception.
>some have up to 40 clientdatasets.
>
>And a user can open multiple forms in 1 session.
>Now count the memory use :-)

Can you not keep the data in a local JSON in the form and just open a
TClientDataset whenever the local data is saved or refreshed? This keeps
the data connection open for a fraction of a second and connection pooling
limits the number of active connections.

Brent

>It would be good to be able to track the memory use of a form.
>A simple algorithm is to track all components on a form, adding
>InstanceSize
>and adding the lengths of all published string properties of all
>components,
>tpersistents and collections (can be done with RTTI).
>That gives the absolute minimum of memory a form needs. For client
>datasets, you can
>then add the sizes of all fields (datasize) and then multiply this
>with the number of records.
>This will give you a very rough estimate, the real size will be even
>higher.
>

>--
>You received this message because you are subscribed to the Google Groups
>"ExtPascal" group.
>To post to this group, send email to extp...@googlegroups.com.
>To unsubscribe from this group, send email to
>extpascal+...@googlegroups.com.
>For more options, visit this group at
>http://groups.google.com/group/extpascal?hl=en.

[Michael Van Canneyt]

On Jun 15, 8:28 pm, bdgri...@mailbolt.com wrote:
> At 05:06 PM 6/14/2010, you wrote:
>
> >On Jun 14, 11:08 pm, Farshad <farshad.mohaj...@gmail.com> wrote:
> > > It depends on your app. A session with an empty form may occupy only a
> > > few kilobytes. But if in each session you have a TClientDataSet which
> > > holds 2 MB of data then 500 sessions mean 1 GB of memory!
>
> >Well, most of my forms have 2 or more clientdatasets,
> >Having 5-10 client datasets is not an exception.
> >some have up to 40 clientdatasets.
>
> >And a user can open multiple forms in 1 session.
> >Now count the memory use :-)
>
> Can you not keep the data in a local JSON in the form and just open a
> TClientDataset whenever the local data is saved or refreshed? This keeps
> the data connection open for a fraction of a second and connection pooling
> limits the number of active connections.

Well, if uniGUI would allow this, then, yes, obviously.
That's how I do it now with plain extJS. The data exists only in the
browser.

Michael.

[Farshad]

Hi,

uniGUI has its site now:

http://www.unigui.com

Contents are being added. A demo download will be available soon.

Regards,
Farshad

[IcebergDelphi]

Wonderful, i gonna spread the news to : http://www.delphiaccess.com

Greetings

[IcebergDelphi]

On 23 jul, 04:59, Farshad <farshad.mohaj...@gmail.com> wrote:

Hi Again, let me ask you something, Does your project gonna be Free or
Comercial?

Thank You Again.

[Farshad]

Early to tell but commercial is the closest bet. We can have a low
cost but feature-limited version too.

[Ilja Shushin]

Nice job!
Thanks!

[Eduardo Alcântara]

Hi Farshad,

I congratulate you for doing UniGUI.

That was the last stuff Delphi need to enter the main stream. 

I suggest you to look for investor, or sell it to Embarcadero, or try to licence it in future architect distributions, or maybe make it open-source.

Any way or other you will be very famous and Delphi will rise up again in development community!

P.S.: You should consider a less expensive license for Educational Groups and Governments.

Em sexta-feira, 11 de junho de 2010 10:11:38 UTC-3, Farshad Mohajeri escreveu:

Hi all,

This project started back in mid 2008. The main goal of this framework
was to unify user GUI experience for both desktop and web. It means
that a single Delphi VCL project can be deployed either as a desktop
application or a web application. It helps developers to focus on
application logic rather than focusing on GUI front end. It also
maximizes code reuse as your source is portable to web or desktop with
almost no modification.

The initial version of project was based on Delphi's built-in "VCL for
the Web" aka Intraweb library. Below you'll find first public
discussion about this project and a couple of demos. Demos below uses
Intraweb based version of uniGUI.

https://forums.embarcadero.com/thread.jspa?threadID=22987

As you can see, in above thread Phil made me aware of ExtPascal and
its capabilities. He assured me that ExtJS and ExtPascal can work
perfectly with uniGUI. Fortunately, I listened to him and started
replacing the Intraweb backend with ExtPascal. Well, it was not that
easy. Intraweb comes with a full set of visual components and lots of
other features which uniGUI couldn't exist without them.

The most difficult task was to implement a thread-safe Web Component
infrastructure, session modules and server manager; similar to
Intraweb, all from scratch. Fortunately, everything went fine and only
in a few weeks I could develop my alpha version of uniGUI completely
based on ExtJS and ExtPascal.

What makes uniGUI unique among other web application frameworks is its
ability to morph itself either as a desktop application or a web
application. You longer need to create a separate version for web
deployment. Of course, you can use it to create only web
applications.

Here is my first demo that I shared with Phil and Delphi community a
few months ago:
http://prime.fmsoft.net/out/dbdemo.dll

My second online demo is available here. It demonstrates most of
implemented components and capabilities available in uniGUI:

http://prime.fmsoft.net/demo/mdemo.dll

Regards,
Farshad Mohajeri
FMSoft