Hi all,

Some of you already know that I work on more web-components for Lazarus/Freepascal.

I've created a new package (zipfile) which contains several packages which adds extra web-functionality too Lazarus.

You can find the package here:
http://services.cnoc.nl/lazarus/index/fclweb

Offcourse you also need to install the FCL-web package which comes with Lazarus.

The packages are:

EmbWeb: Adds to possibility to FCL-Web to create webapplications with a build-in webserver, based in LNet which is also included. Usefull for debugging

Geckoport: Adds gecko (XULRunner/Firebird) components to Lazarus. Is a plain copy from Lazarus-CCR, included for convenience, since WebDesign on Windows needs it.

WebDesign: Adds a new 'form'-designer to Lazarus-trunk. It can be used to build websites. On Win32 there can be a live 'preview' of the website, when Gecko/XULRunner is installed on the system. For it to work the fcl-web_joost branch of Freepascal has to be used. (Or copy the files in packages/fcl-web onto your checkout of fpc-trunk)

jQuery: Adds some jQuery contentproducers (components) to Lazarus. Like a grid, tabpages, slider, and graphs.

There are also some examples, you can see those examples online on the link above.

The fcl-web_joost branch of fpc also adds some functionality for server side and client side event handlers. It adds the basic abstract methods for that and you can create plugins to handle them properly. The jQuery package adds a plugin for jQuery, but the idea is that the same functionality can also be added for other java-toolkits, like ExtJS. For some of the basic ideas I've I have some commercial sites up and running using this framework, it's still under active development and the framework-api can really change. But all comments and help are welcome.

Regards,

Joost van der Sluis.

Hello Lazarus-List,

Sunday, January 24, 2010, 5:21:50 PM, you wrote:

JvdS> Some of you already know that I work on more web-components for JvdS> Lazarus/Freepascal.
JvdS> I've created a new package (zipfile) which contains several packages JvdS> which adds extra web-functionality too Lazarus.

Oh! I'm currently working with current fcl-web components :) Fortunatly my project is only in test for design stage, so it is time to install your new goodies :)

Thank you.

So, does it now only work on windows? On other platforms, I'm interested to use it on Mac, is it possible to work?

another toolkit. I propose to use Qooxdoo. I'm interested to do this since I intend to build eyeos-like web os using fcl-web. What should I do to use Qooxdoo with fcl-web?

We coudn't get Gecko running on OS/X. That's because it needs a cocoa handle, and the cocoa-version of lazarus isn't what you call very stable... Maybe when the objc support is better.

But it also works with webkit, but then you have to build your ide for QT.

And in principle everything works, only the preview (in the ide) is not available.

Derrive a new TQooxdooWebController from TStandardWebController and a TQooxdooJavascriptStack from TJavaScriptStack.

Override TJavaScriptStack.CallServerEvent so that it uses Qooxdoo, and let TQooxdooWebController.InitializeJavaScriptStack return a TQooxdooJavaScriptStack.

That's about it. It will use Qooxdoo-calls for the server-events. You can add more, offcourse... (does Qooxdoo also use some sort of 'readyscript'?)

Just take a look at the jQueryElements unit.

Joost.

For it to work the fcl-web_joost branch of Freepascal has to be used. (Or copy the files in packages/fcl-web onto your checkout of fpc-trunk)

Can it be just merged with current fpc-trunk so we don't need to mess around with our svn copy? It could also be included as part of official fcl-web for the next fpc release.

Bee Jay wrote

Can it be just merged with current fpc-trunk so we don't need to mess around with our svn copy?

I doubt that, but the solution would have been so much simpler if we all used Git. ;-)

Regards,
- Graeme -

That has nothing to do with it. (With Git you would also have to use a local command to use this branch/part) You only use it as another lame excuse to bring this up again. While you always say you never do this. Besides that it is off-topic.

Joost.

It's been done in a separate branch to test things and to avoid breaking backwards-compatibility. It will be merged in the near future.

Joost.

Joost van der Sluis wrote

That has nothing to do with it. (With Git you would also have to use a local command to use this branch/part)

I was simply enlightening Bee that I know how he feels and that it would have been easier (less effort) to test various branches with a tool that supports branch workflow much better.

git checkout fcl-web_joost

That is all that would be required and the branch will be ready for use in 1-2 seconds. And then when I am done playing, I do 'git checkout master' and within 1-2 seconds I am back to the default Trunk development. No network access required.

Alternatively, if 'fcl-web_joost' branch was only on your system, I could import that branch into the rest of my Lazarus development by doing the following:

git pull git://<URL_to_Joost>

Git would automatically detect that somewhere back in history we had the same parent commit, and would then ONLY download the actual changes (commits) you made.

With SVN, I need to use a separate directory and download the WHOLE branch, even the files you didn't modify. Alternatively, I have to use 'svn switch' which means again it downloads the whole branch, but that also means I lost my "trunk" branch which I will have to download again at a later date after I played with your branch.

It's because of this screwed-up mentality of SVN branches that I never bother to try other developers branches. This leads to untested features and valuable feedback to the developer of that branch - something I think you will agree with. Just like Bee Jay said, it's too much effort (and a waist of internet bandwidth).

Joost, I did not mean to offend you or your work in any way, I'm simply wanted to point out what a more modern SCM tool can do, and with the hope that "maybe" (a big maybe I know) one day you guys will see the light - just like you did before when you guys moved from CVS to SubVersion. Times change, and so does software. What was the best tool for the job 7 years ago, is probably not the best tool today.

Regards,
- Graeme -

Joost van der Sluis wrote

EmbWeb: Adds to possibility to FCL-Web to create webapplications with a build-in webserver, based in LNet which is also included. Usefull for debugging

I'm very interested in this feature. I have been looking at nYume (web server implemented in less that 1000 lines of code) for a product we need to distribute and run from CD-ROM. nYume is implemented in Object Pascal (using FPC) and only adds 80KB to an executable.

Do you know how LNet's HTTP server compares to nYume?

Regards,
- Graeme -

[cut]

This may all be true (or not true, I leave that subject to discussion), but after some time, this blatant advocacy gets incredibly irritating.

If the FPC team decides to change the versioning system, they will do so, based on the needs of the team and after considering the available alternatives. Till then, any advocacy is just annoying and largely irrelevant.

We got the message meanwhile: we're blessed with some intelligence, I hope...

Michael.

Bull. Bee didn't want to change branches.

git checkout fcl-web_joost

svn switch http://svn.freepascal.org/svn/fpc/branches/fcl-web_joost/

And I don't need a degree in Information Technology to understand how to work with it. You do need it when you want to use Git, which is a pain. It's complexity leads to many unwanted and unneeded problems.

Joost.

No. (But lNet IS simple.)

Joost

lnet is event-driven, nYume is not. nYume is multithreaded, and
- to my taste - conceptually simpler.

You may also want to try the HTTPServ from synapse, nYume is conceptually similar to that.

Michael.

Thanks. I made a note of all these options and will evaluate all of them closer to the time.

Regards,
- Graeme -

That's about it. It will use Qooxdoo-calls for the server-events. You can add more, offcourse... (does Qooxdoo also use some sort of 'readyscript'?)

My main reason using ExtPascal and this new fcl-web is I'm too lazy to study JS programming and getting my hand dirty of it. Every JS framework out there, due the nature of JS, has its own OO concept and implementation that also need to be learned. If I really have to study them, I think it might be better and faster if I build the application directly in JS, instead of using ExtPascal or fcl-web which would double my work and slow down my application development. But I don't like it. So, obviously, I can't avoid this JS thingy in order to develop dynamic web application using pascal. It's a bit ironic, don't you think? :D

My main motivation in dynamic web application using pascal is I want to show some people that pascal is able to do that and would perform much better than those resource hog scripting languages.

I finally decided to bite the bullet, and to dump the idea of extpascal and the likes for the moment. All these conversion tools have the same problems:
- Always behind the latest versions of the corresponding JS toolkits.
- They only do a subset of what the JS toolkits support natively.
- For anything reasonably advanced, you need to write JavaScript anyway.

So, my development plan:
- Server in pascal.
- Client in JavaScript. (using ExtJS, but this could be anything) All is implemented in fcl-web, and I will put the result back in fcl-web.

I have the first server-side things ready, namely: the server-side interface to ExtJS's data API. It's a breeze in FPC, and lightning fast.

Next step is creating a SOAP bridge using WST and implement the ExtDirect API.

At a later stage the following will be added:
- Write the client in Pascal, but transformed to JS using a code converter. (as Morfik or GWT does)
I've contracted Mattias Gaertner to do the first step for the code converter. Sources will be donated to and released with FPC. I also wrote a JavaScript parser, which will be introduced in FPC's SVN shortly.

I also submitted some ideas to Mattias so the Lazarus IDE will be able to do code completion for Javascript (in fact for any language out there). Mattias has (if I'm correct) started work on that too.

Michael.

Hello Lazarus-List,

you wrote

> Do you know how LNet's HTTP server compares to nYume?

MVC> lnet is event-driven, nYume is not. nYume is multithreaded, and MVC> - to my taste - conceptually simpler.
MVC> You may also want to try the HTTPServ from synapse, nYume is conceptually MVC> similar to that.

Just for information I'm using a fpclightwebserver I think found in ExtPascal repository to check the fcl-web features. I think it is win32 "only" but it supporst SSL using "libeay32". I only had to fix one small problem at compile time I think. The code is 30 Ks .pp files and it is mutithread based in Synapse.

Very near. The merge is just done, r14808. Thus the webdesign package can be used with tonight's Lazarus snapshots.

Joost.

Yes! It happens to ExtPascal each time ExtJS releases a new version.

- For anything reasonably advanced, you need to write JavaScript anyway.

It's sad but true. While I believe it can be avoided for any common purposes, but in some advance optimization it just can't be. Just like the way we're using assembler in pascal. But it should be 1-5 percents of all cases.

I have the first server-side things ready, namely: the server-side interface to ExtJS's data API. It's a breeze in FPC, and lightning fast.

It would be better if the server side interface is plain and independent to any JS framework API. The interface result then could be "translated" to any client side API, or SOAP, or WST, or whatever is required format by the client side framework using some kind of API dictionary or something similar.

At a later stage the following will be added: - Write the client in Pascal, but transformed to JS using a code converter. (as Morfik or GWT does)

This is my dream. It would be better if the converter is able to provide library binding to any JS framework out there, at least the popular ones i.e. ExtJS, jQueryUI, qooxdoo, etc. So we don't need to code on our own JS UI widgets. This is one of major flaw of Morfik. Though I knew what I want, I have very limited time and skill to develop it by myself while the deadline for the demanded application can't be delayed. That's why I have to satisfy with any ready to use tools available for pascal now, which is ExtPascal. Now come the new one: fcl-web.

Many had tried it already i.e. Powtils, ExtPascal, but the development stucks somewhere. I'm looking forward to test it! Thank you for the effort.

For ExtPascal, it was true for every page I wanted to make, so that is far over 5% :(

That is how I am doing it. I'm just using ExtJS as a sample case for 1 implementation.

This is the idea.

fcl-web exists since a long time. It was never promoted or actively developed, but that will change now.

I'll try to make a sample application so everyone can see what can be done with very little work.

Michael.

W dniu 2010-01-26 09:30, Graeme Geldenhuys pisze:

I prefer HTTPServ from Synapse. It run on win32 and linux (ARM also) on my production program.
It has SSL too, what is important to me.
But if for some one is too slow, several changes should be added. Especially header parsing and generating (this from synapse is rather slow). And sometimes worth is compress request.

For ExtPascal, it was true for every page I wanted to make, so that is far over 5% :(

Yes, because ExtPascal is just a wrapper for ExtJS classes. What I meant in the previous email is the existence of a pascal to JS compiler, like Morfik's JST, will do the job. I prefer "compiler" term instead of "converter" because (I hope) it wouldn't just convert pascal code to JS code but also able to do compilation jobs (optimizing, etc).

fcl-web exists since a long time. It was never promoted or actively developed, but that will change now.

Yes, I heard of fcl-web since I was still using Powtils. Since its features aren't better nor new, I still kept using Powtils.

I'll try to make a sample application so everyone can see what can be done with very little work.

Please, keep us inform. Thanks.

Take a look at HaXe (haxe.org) - HaXe is a dynamic but type safe programming language, which is much better suited for Web programming than ExtPascal (in my opinion). Since HaXe has many targets (JavaScript, Flash, Neko bytecode, php, and C++) it's almost one language for all. And even if it is "C" derived language, it feels very pascalish. If you use HaXe with FlashDevelop you have code completion. It's fun to code against an API like Google Maps or JQuery, if you code completion - without it's a pain in the a.. And with HaXe you are sure, that your code works like intended, because it's type safe.

I use:
- pascal and HaXe/Neko for the server
- HaXe for the rest

Cheers,

Adrian.

Take a look at HaXe (haxe.org) - HaXe is a dynamic but type safe programming language, which is much better suited for Web programming than ExtPascal (in my opinion).

I've heard about it and wasn't interested since it doesn't support pascal. :P

Since HaXe has many targets (JavaScript, Flash, Neko bytecode, php, and C++) it's almost one language for all.

It's useless since it can't work with existing JS library i.e. ExtJS, etc. It's just like Morfik in this regard.

I use: - pascal and HaXe/Neko for the server - HaXe for the rest

Why should I learn another new language while I could do all those things in pascal? Except for using external existing JS library. That's why I'm very interested with what Michael, Joost and Mattias doing currently.

Thank you, but no thanks. :)

Interesting. I'm currently working on a project to do Adobe Flex through ObjectPascal and I've been working to generalize as much of the interface for widgets as possible so that it could be compatible with some JS framework later on as well, like OpenLazlo does in concept. Though honestly, I'm only interested in doing flex right now personally, but nice to have options :-).

Another thing that I've been careful to do and I think is important is abstracting the widget-framework away from any particular protocol or transport framework so I could easily compile it to stand alone, apache_mod or ISAPI using any of the technologies available to freepascal or Delphi.

I'm excited to see more work on the Lazarus web stuff and appreciate Joost's work on it as I'll be needing to use Lazarus for some of my server apps soon.

Great stuff.

Currently there is no ISAPI interface, but this is planned for the near future.

Michael.

Hi Michael. Actually I was referring to more of the Delphi side of things concerning ISAPI, but that is great news that ISAPI would be implemented in Lazarus/fpWeb at some point. Really exciting stuff.

OK, let me try and sum up this message thread. We have the following technologies/projects/options available:

* FCL-Web
* fpWeb
* jQuery
* Gecko/XULRunner
* ExtJS
* ExtPas
* ExtPascal <- not sure if this is the same as previous option
* Qooxdoo
* SOAP
* WST
* ExtDirect
* Morfik
* Morfik's JST
* Powtils
* Adobe Flex
* ISAPI
* HaXe
* FlashDevelop
* Neko
* JavaScript

I think I got them all, and these are just the ones mentioned in this message thread. I believe I now understand why I try and stay away from web development as far as possible!! :-)

Regards,
- Graeme -

They are the same thing. fpWeb is a unit in fcl-web.

Same.

* Qooxdoo * SOAP * WST

Not really web related ?

* ExtDirect

Part of ExtJS.

I wouldn't touch it with a stick if it was up to me, but I don't set the trends. After 1 day of testing the differences in IE and Firefox already drove me mad :(

My boss was actually very surprised that there are no standards in web development. It is not what he was told by other people :-)

Michael.

Michael Van Canneyt wrote

set the trends. After 1 day of testing the differences in IE and Firefox already drove me mad :(

Exactly my issue.

My boss was actually very surprised that there are no standards in web development. It is not what he was told by other people :-)

Gee wiz, where has he been for the last 10 years? :-)

Regards,
- Graeme -

To be clear, those are the same.

I think I got them all, and these are just the ones mentioned in this message thread. I believe I now understand why I try and stay away from web development as far as possible!! :-)

Do you want a list for all tools, extensions, packages for desktop-development? ;)

Joost.

there is pascal/neko wrapper written by me.

It's not like Morfik - to write an wrapper, for an existing JS library is a matter of one or two hours - I did it for Google-Maps and JQuery. The speed benefit in coding you have afterwards, compensates this a lot of times. And you have flash - all the code you write once, you can use for all the platforms - and have type safe communication between all the layers !

because Pascal is not as well suited for dynamic languages and environments - I use pascal since 30 years for my every day development and love it - but IMHO for web programming, it is more productive to have a dynamic language - it is the nature of websites. (Free)-Pascal has nothing comparable to type inference, or dynamic closures (only with some tricks, and you must know what you do) and garbage collection (please no flame war here, but there ARE circumstances where GC is useful - websites - and yes, you can use the Boehm GC with freepascal).

Thank you, but no thanks. :)

You are welcome - but never say never ;-)

Yes - I know its not well accepted to say in a pascal group, that another language is better suited for this and that - but to be fair - I write on the HaXe group, that pascal is better for this and that as well. It is not about religion - it is about experience and how to get the job done.

Cheers,

Adrian.

What do websites have to do with dynamic typing ?

Websites are text, numbers and images.
So I fail to see where dynamic typing comes into play.

Michael.

El jue, 28-01-2010 a las 13:56 +0100, Michael Van Canneyt escribi?:

I use pascal since 30 years for my every day development > and love it - but IMHO for web programming, it is more productive to > have a dynamic language - it is the nature of websites

That could be true (not in my case) if you are talking about pre Web 2.0 era, with the advent of Ajax, all the client side development is made using JavaScript (dynamic language) and CSS/HTML, on the server side, you need a fast-compiled application in charge of processing requests and respond with JSON or XML, and no one Dynamic Language can offer the performance that can be accomplished with FreePascal.

Adrian Veith wrote

environments - I use pascal since 30 years for my every day development and love it - but IMHO for web programming, it is more productive to have a dynamic language - it is the nature of websites. (Free)-Pascal

A matter of taste I guess. I use pure Object Pascal to write all our CGI applications. Our CGI apps do things PHP, JavaScript etc can only dream of! Not to mention I have the full RTL, lots of the FCL and other non-GUI frameworks at my disposal - and execution speed is probably magnitudes faster too.

But in the end I'll take desktop GUI apps any day over Web apps. ;-)

Regards,
- Graeme -

W dniu 2010-01-28 14:22, Graeme Geldenhuys pisze:

I fully agree. And add that Pascal are more suitable to maintain big application. There are few big projects dynamic languages comparable to Delphi. Existing application for CMS, shopping, bugzilla etc. are relative small.

But is big problem with distribution of such (pascal) programs. Boys from hostings firm believe more to PHP script (which has more holes than cheese) than binary executables.

But in the end I'll take desktop GUI apps any day over Web apps. ;-)

I have it today. 500+ forms works on desktop and web from the same source.

Adrian Veith wrote

because Pascal is not as well suited for dynamic languages and environments -

It has variant, dispatch interfaces, and can interface with such environments if need be. But the question is if that is really neccessary or applicable to webapps.

I use pascal since 30 years for my every day development and love it - but IMHO for web programming, it is more productive to have a dynamic language

Care to explain? I don't see the need for this at all.

it is the nature of websites.

I don't see this either.

I agree a safety net is a great good for webpages, but that doesn't have to be an in-language GC for everything.

One can use frameworks to avoid manual allocation, per thread heapmanagers with mark-sweep characteristics etc etc.

The hype for dynamic webpage etc is because many tools in this sector grew out simple preprocessors, or are reactions to them. There is IMHO nothing inheritly untyped or dynamically typed in webprogramming, save tradition.

Marco van de Voort wrote

On Thu, Jan 28, 2010 at 01:30:28PM +0100, Adrian Veith wrote: > because Pascal is not as well suited for dynamic languages and > environments -

Do you mean scripting languages like JavaScript? If this is the case than you should know that there are pascal based scripting utilities for server side scripting.

It has variant, dispatch interfaces, and can interface with such environments if need be. But the question is if that is really neccessary or applicable to webapps.

None if it is. I'm speaking from experience when I say all that is needed is good AJAX experience for designing the front-end. I don't see pascal overtaking JavaScript anytime soon as it's not needed. No need to re-invent the wheel. Javascript with Prototype does the job.

> I use pascal since 30 years for my every day development > and love it - but IMHO for web programming, it is more productive to > have a dynamic language

I agree. A widely adopted scripting language (JavaScript) is required for real-time web applications. But let's not confuse back-end development with front-end applications over the Internet - which will always require some sort of interpreting and/or dynamic code execution.

Care to explain? I don't see the need for this at all. > it is the nature of websites. I don't see this either.

For my back end I use a Social computing platform that supports serves the back-end and provides the client side with feature rich applications over the Internet using HTTP. Front-Ends are provided to web-browser utilizing javascript and the app makes calls back to the server that processes via compiled "core" objects. Each core object executes with minimal interpretation.

Feature rich client-server application over the Web requires many different technologies. And FPC will never be a catch all one shot solution... unless it builds an execution environment, and that is extremely out of the scope of anything I've seen so far.

SNIP >>>> There is IMHO nothing inheritly untyped or dynamically typed in webprogramming, save tradition.

The only insight I have to offer is to refer you to see JavaScript prototyping.

Not my line.

The Ajax and JS is already embedded in the widgets you use serverside. No need to do that manually.

1. while needed for functioning of webapps, it might not need to be written (see e.g. general ASP.NET use) by maker of webapps. Just like you don't need to know the gore of assembler when programming pascal.
2. Javascripts sole point is that it is standarised in browsers. Nothing more. Any sandboxable language is suitable for that.

But let's not confuse back-enda development with front-end applications over the Internet - which will always require some sort of interpreting and/or dynamic code execution.

Do not confuse javascript being the only more or less guaranteed browser language to a need to actually churn out javascript as part of a standard webapp. There are examples enough that prove otherwise for the majority of the application, where components hook into a standard JS library, without programmer intervention.

This is comparable with the fact that CPUs only execute machinecode. Yet there are other languages available for PC. The fact that JS is the only language available browserside doesn't mean you always have to deal with it.

Feature rich client-server application over the Web requires many different technologies. And FPC will never be a catch all one shot solution... unless it builds an execution environment, and that is extremely out of the scope of anything I've seen so far.

A FPC based framework that for the browser side parts of its widgets hooks into existing javascript helper libs would be enough.

I think this is the way where webdevelopment is going.

> SNIP >>>> There is IMHO nothing inheritly untyped or dynamically typed in webprogramming, save tradition. The only insight I have to offer is to refer you to see JavaScript prototyping.

Explain.

Michael Van Canneyt wrote

My boss was actually very surprised that there are no standards in web development. It is not what he was told by other people :-)

There are standards from W3C and even a validator: http://validator.w3.org/

But the only website which I extensively developed ( http://www.braillevirtual.fe.usp.br/ ) does not validate in it, because when I changed it to validade, it stoped working in Internet Explorer =) Similarly if you fix some stuff to work in IE it may break Firefox ...

Don't you get annoyed putting the HTML inside function calls? This is what has put me off from cgi ... I usually have a lot more HTML then code, so I actually would like to have a HTML document where I put some Pascal inside, like PHP. With all my huge amount of HTML inside function calls it get's very poluted and hard to read the HTML =(

El jue, 28-01-2010 a las 13:37 -0200, Felipe Monteiro de Carvalho escribi?:

You don't need to. Some CGI frameworks, like PowTils, allows you to use Templates that reside apart from the CGI app, those templates are parsed on the fly every time a request is made. Also you can let the CGI app to produce JSON or XML to be parsed by the JavaScript Client's engine, like ExtJs, JQuery and others.

He meant the development itself. The resulting HTML is of course standardized. But it's not exactly as if there is 1 tool to create webpages.

Exactly my experience :-)

Michael.

The latter is what I'm doing now. I'll be committing some stuff to SVN soon.

Michael.

It's not like Morfik - to write an wrapper, for an existing JS library is a matter of one or two hours - I did it for Google-Maps and JQuery.

Have you tried to write a wrapper for ExtJS or any other advanced JS library that provides advanced UI widgets with server side data binding, not just DOM helper and manipulator?

Because I don't need flash or other non standard browser plugins/ addons. I like the Morfik approach that keep away from third party browser extensions, just work with the native browser features (HTML, CSS, and JS). Besides, I'm too lazy to learn yet another language while I believe I could write anything in pascal.

It's a myth! I've been using pascal to write many web applications. I found myself as productive as when I write desktop applications. I even could reuse my legacy pascal code in new web applications. It means I save times for coding and bug hunting.

You are welcome - but never say never ;-)

Yes, but now I don't see hexa could fit into my requirements.

Exactly! It's not about religion, it's about how to get the job done. I just don't think with my skill and knowledge of hexa would get the job done better and faster compare to if I stick with pascal and the available tools (despite some lacks of them).

It's not the problem of pascal nor cgi, it's the problem of your coding style and management. Use templates, MVC or MVP, separate logic from UI, etc. I think you should have known all those things. :)

On 28 January 2010 17:37, Felipe Monteiro de Carvalho wrote:
...snip...

what has put me off from cgi ... I usually have a lot more HTML then code, so I actually would like to have a HTML document where I put

In our case it is the opposite. We have a LOT more OP code in the background than HTML. We actually have 3 CGI applications, and they all share OP code via include files for smaller parts and full units for larger parts. So this reduces our work a lot to.

A lot of the code in the CGI applications actually come from our desktop GUI applications. I'm still trying to work on a solution to completely remove the CGI apps, but currently we can't manage and control Adobe Flash inside fpGUI or LCL applications. I did some work in this regard a few years back called Mozilla Plugin Panel, where I used Mozilla plugins as-is, but the custom written panel component for LCL applications faked the web browser API the plugins expected. This worked on Windows, and partially under Linux.

That's what prevented us from using desktop apps for all parts of our project, so I had to resort to CGI apps. :-(

More details on Mozilla Plugin Panel:
http://opensoft.homeip.net/wiki/wiki.cgi?p=mozilla-plugin-panel

Bee Jay wrote

It's not the problem of pascal nor cgi, it's the problem of your coding style and management. Use templates, MVC or MVP, separate logic from UI, etc. I think you should have known all those things. :)

100% correct. We have a couple hundred business classes and all business rules and data persistence code are shared between our GUI desktop apps and CGI apps. No chance in hell I am rewriting all those business classes an rules in JavaScript! :-)

I think you exaggerate it a bit.

* FCL-Web * fpWeb

Both are same thing: fcl-web = fpweb

* ExtPas * ExtPascal <- not sure if this is the same as previous option

Again, both are same thing.

* Morfik * Morfik's JST

JST is an integrated part or Morfik.

I think I got them all, and these are just the ones mentioned in this message thread. I believe I now understand why I try and stay away from web development as far as possible!! :-)

I don't understand what's your point. I think it's a good thing to have more options rather than limited options so we could have many alternative solutions. You seemed to think that developing dynamic web applications is hard and complicated, while in fact it's not. It could be as easy as or as hard as developing desktop applications. You (and the world you currently live in) may not need web applications. But, just try to look around, web applications is a very huge business.

You might scare people off from web application development using pascal (especially FPC). This isn't good, both for them and for FPC. :)

> My boss was actually very surprised that there are no standards > in web development. It is not what he was told by other people :-)

Standards does exist. It's the problem of the implementator, especially the browser makers, who each thinks a smart a** and ignore those standards.

Gee wiz, where has he been for the last 10 years? :-)

Well, actually this doesn't happen only on web development, it happens almost on all things, especially in the software world. Is there any standard upon window managers (gtk1, gtk2, qt, etc)? Isn't it the main reason why you wrote fpGUI in the first place? Is SQL standard completely obeyed by all database engines? Even directory stuctures are different among Linux distros! I could go on with more examples, but you should get the idea.

I don't think it's fair to bash web development while in fact it also happens on desktop development. I'm just trying to be fair and objective. :)

Bee Jay wrote

I don't think it's fair to bash web development while in fact it also happens on desktop development. I'm just trying to be fair and objective. :)

Point taken. I hope you noticed the smiley face too, in my reply where I listed all the web technologies? This message thread uses technology acronyms almost as bad as Microsoft does. But nobody can beat Microsoft! :-)

Regards,
- Graeme -

Something like this (very early stage) example:

http://www.datatrakpos.com/misc/test_flex_delphi.htm