Hi Michael,
Michael Van Canneyt schrieb:
This is always so in Client/Server. Global variables are a big no-no.
Of course. I just tried to identify potential problems when converting a
desktop application to a web application.
The widgets itself are not the problem; They are the easiest.
Ok it's still work to implement them, but it's possible at least.
The problem is the user code.
Only performance-wise I think.
For example: Emulating something OnDrawCell. This _cannot_ be done on
the server. Technically yes, but the performance...
This approach surely would work quite well -- but it would be quite slow,
dependent on the exact application.
Like Intraweb.
...and several other web toolkits as well...
Btw, what we could do is to support Microsofts Silverlight; if this plugin is
installed, create all widgets using Silverlight, where you can use _all_
widgets which .NET's Windows.Forms support.
Nono, no dependency on Microsoft-Only technologies or plugins.
That is definitely out. The browser, and only the browser:
Standards based implementations only.
I want the code to run on Linux as well and silverlight for instance does not.
Btw, the Mono project is implementing Silverlight on Linux (called
Moonlight). But this would be just an option, of course. It won't
replace the JavaScript stuff (at SL uses JS as well), but could make
widgets more responsive. This is really just an option for the future.
Perhaps as a Flash based solution would be; but I don't know Flash good
enough to tell if this would be a viable solution.
You might just as well code in flash or Java.
Hm. Java SWT as frontend? ;)
But back to JS/DHTML. To improve performance, I see only one way, the way that
Google's Web Toolkit is going: Analyze the source code and try to convert
single methods to JavaScript wherever possible, using some kind of JS version
of the FPC RTL. By time, this library would get bigger and bigger, improving
the performance step by step. But of course the source analyzer has to be
extremely careful about keeping the application state in sync between client
and server.
That is exactly what Morfik does not need to do, because it converts ALL form
logic
to Javascript, and is hence much easier to code. It's the only correct way,
IMHO,
all the rest is patching-up.
I don't think so. But it depends what you want. My approach would ensure
that existing projects can switch to web techniques with a minimum
amount of changes necessary. (Of course, some serious issues remain,
such as printing. But to be honest, in most cases this are the usual
areas where it gets difficult to switch a Delphi app to Lazarus, or
multi-platform issues anyway... and, btw, where Delphi often breaks
downwards compatiblity. I'm talking about this 'nice' libraries such as
QuickReport.)
But since we are nowhere near that, we'll have to do as you suggest.
okay...
Maybe webrad is a good candidate to start with as suggested elsewhere;
It seems like it's been abandoned since 5 years, and maybe we could
take it over.
I'm not sure. As I can see WebRAD is an extension to Delphi which
introduces special components for web development. This has nothing to
do with our goal of a 'LCL web target'.
So, what to do? My suggestion is to start with a framework for dynamic
web content creation, somewhat similar to that what VCL for PHP is
doing. Putting the LCL implementation on top of such a library would
enable us to write specialized components easily, before the quite hard
to do optimizations work (there are not only existing projects, but also
new ones, which could use special (faster) widgets.)
And, btw, as a long-term goal I see this as a starting point for a real
good content-management-system-style software. Real high-level
components. But for this we need frame support in Lazarus first (with
having HTML IFrames as a quite good equivalent :) ), which hopefully
will be finished in the not so far future.
Other loose ideas and topics:
- What about some investigation in plugin systems.
- Writing XML and CSS directly, or using the DOM units? DOM is good when
you cannot create XML in a linear fashion (as it is the case in fpDoc,
for example), but of course it needs much more memory and is slower that
a linear writer.
- We need a good caching system. Especially if we decide to use DOM,
which _might_ be better for plugin systems. Each component must know in
a way if its XHTML or CSS content changed since the last cache
generation. Additional it would be good to know which parts of the
output can be cached at all, and which ones don't. Maybe this can only
be done in a good way using the code analyzer used for JS translation
(later).
- Sebastian
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
