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-
> 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-
You will publish this in FPC, right?
Marcos Douglas
>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.
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