Hi,

I don't seem to learn from my mistakes. Every now and again, I have the urge to upgrade my Lazarus IDE to the latest version. I really should stop doing that. I had a relatively good working IDE, then last Thursday I got a svn updated and already I found 5 regression bugs. Reported two and not bothering with the rest.

The reason for the Subject line:
With such constant regression bugs, I started my own IDE from scratch a few days ago to see how hard it really is. In +-9 hours (avg of 1 hour each evening) I already created an IDE that manages a project, has different build modes, has user defined macros (eg: ${FPGUIDIR} = '/opt/fpgui/'), has template projects, uses multiple threads for parsing, searching, compiling, etc. It works consistent under both Linux (32-bit & 64-bit) and Windows 32-bit (I don't have 64-bit Windows to test), and I don't break the IDE after each new feature. So thanks to Lazarus, I'll probably continue my own project. It seems the old saying of "why reinvent the wheel" doesn't apply to the Lazarus project - it benefits the developer to reinvent the wheel.

I guess I am to blame. It was my fault for subscribing to the mailing list again - simply to ask a question a few days ago. I think I better crawl back under my rock and mind my own business.

Regards,
- Graeme -

Hello Graeme, is good to see you again ;)

Do you have any download link?

Thanks,

Graeme Geldenhuys wrote

I had a relatively good working IDE, then last Thursday I got a svn updated and already I found 5 regression bugs. Reported two and not bothering with the rest.

Please report them, otherwise it doesn't seem to be fair, to blame the team about 3 "ghostly" bugs :)

Don't forget that you can update LCL without rebuild IDE itself.

So thanks to Lazarus, I'll probably continue my own project. It seems the old saying of "why reinvent the wheel" doesn't apply to the Lazarus project - it benefits the developer to reinvent the wheel.

Please add link to your IDE project here: http://wiki.freepascal.org/IDE

thanks,
dmitry

dmitry boyarintsev wrote

Please report them, otherwise it doesn't seem to be fair, to blame the team about 3 "ghostly" bugs :)

OK.

Don't forget that you can update LCL without rebuild IDE itself.

I don't use LCL for my apps, I only use the IDE. And to compile a new IDE, unfortunately I need to compile LCL too.

Please add link to your IDE project here: http://wiki.freepascal.org/IDE

As soon as I make it publicly available (after fpGUI v0.7 final release), then I will add it there. Thanks for the link.

Hi Graeme, It is easy to start a new project from scratch and for me i like to build my own IDE also, but the true after some years and after add a developers to your project, you will have the same problems that you complain the current one, for me again i prefer use the current and help and contrbuite to growing it, instead of start one that i (can not)/(hard to) continue with it.

Building small projects to customers not like build long life projects have many developers working over the world.

Thanks for reading my bad English :)

At some point in the past i would have blamed anyone for making a new FPC IDE especially one based on Lazarus or the LCL. Lazarus is now a mature project and much more stable but suffers from the same problem that many OpenSource projects suffer, an apparent lack of coordination and standards. It feels bloated because of the executable size but that's more of a compiler issue. It may not be the fastest IDE but it's certainly better than most (all) Java IDEs and probably VS and Mono too but i might be wrong. Lazarus could be so much better but because it inherits some old design issues would probably be better if it was redesigned, made more modular and follow some strict code writing rules. It needs a clear architecture so that anyone can find his/her way into the code without digging for days deeply into the sources.
Lazarus is still a great project but if we want more people to contribute, it needs standards of doing things just like VCL has, code must be intuitive if we want people to like doing what they do, also the team should not restrict the abilities of the LCL but extend them on all platforms if possible. Looking at other similar projects and borrowing ideas wold only help the project become more attractive. Lazarus must make it simple for people to write CrossPlatform code in a non-restrictive way, allowing people to port Delphi stuff with little modifications but not restrict itself to Delphi's abilities.
The mobile world is now a perfect place for Lazarus to "sink it's teeths into" if it knows how to occupy this space where there is little competition on the RAD side of things. On the web part after many years of Java slows apps, PHP code that let's you hit you fingers with a big hammer and ASP.NETtechnology that seems to be so hard to learn, Lazarus has a big change to
make something that integrates easily on the Server and the Client side, maybe using NaCL on the client to build safe apps or simply "compile" to JS, Flash and Silverlight.
Lazarus should be more like a cheetah following it's prey at high speed but now it just seems tired and hiding in the tall grass :) Large commercial projects succeed on the market because of coordination and standards, Lazarus needs this too, chatting and brainstorming sessions benefit everyone but OpenSource projects seem to have an "everybody for himself" attitude, maybe the Linux kernel would have failed too if it wasn't so strictly checked by the "benevolent" dictators ... Also not having a foundation or company to support the team only allows people to work in their spare time and that's not very productive, i know that this was discussed before (The Lazarus Project Foundation). Breaking stuff between versions is a bad ideea, if Delphi did this it would have died many years ago.

Now is the time to either write a new IDE (not the whole LCL) or redesign the existing one using all the best features LCL has to offer, the LCL itself could be made less object oriented on the API abstraction part, and maybe the RTTI system if it is responsible for the big executables. Lazarus could even replace technologies like Flash and Silverlight with the right approach on the client side, i think some people are trying to do just that with things like VGScene/DXScene.

Razvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100505/68260d6b/attachment.html>

Razvan Adrian Bogdan :

Great ideas!
I think the same and I agree completely.

Marcos Douglas

2010/5/3 Graeme Geldenhuys :

You sound like a very talented programmer. I don't understand why you cry instead of helping with Lazarus development.

Gustavo

Good documentation is expensive, at least for those people that should make it. The lack of a fixed concept can invalidate existing documentation at any time, when somebody found that things better have to be implemented differently, for some reason.

There exist so many different ways to design platform independent applications or GUI (fpgui), or multi-platform applications (LCL), or widgetset specific applications (Qt...). It's near impossible to fit all these models into one library. IMO the only general solution were a strictly decoupled GUI management, so that e.g. fpGui, LCL or Qt could be used, instead of only LCL. Then it would be possible to define some of theses models more precisely, and to develop the libraries according to these specifications - but the LCL most probably will never reach an stable state, that also could cover all future widgetsets or platforms; every new widgetset will add further incompatibilities, so that the set of everywhere available features will *shrink* all the time, and the widgetset specific differences will increase.

This would mean to have a "Lazarus for LCL", another "Lazarus for Silverlight" etc., like "Delphi for PHP". Nice to have, but essentially these are very different projects.

All these could become such new projects, perhaps based on the current IDE and parts of the widgetsets, but each with a new component library. As a very first new project we could refactor the IDE and the LCL binding (designers...), into a new base for use with very different component libraries. This should include project management additions, to allow for a separation between general application code, and any number of additional GUIs, that can be switched at design time.

A new designer for the application-GUI interface may be added, that will allow to specify the project specific interface between both parts, and that can provide means to create skeletons for both sides (like class completion does). This will be the place where Actions come into the play, which already allow to define an abstract interface from the GUI to application code. The opposite direction should be supported as well, i.e. how application code can access parts of the GUI (show forms, read entry values...).

Just some ideas...

DoDi

Gustavo Enrique Jimenez wrote

You sound like a very talented programmer. I don't understand why you cry instead of helping with Lazarus development.

Apparently you haven't read the infamous threads:
Is Lazarus project in a downward spiral?
and
This project needs help

Please don't continue the same discussion any more, anyone!

Now, I really think Graeme's new IDE is a good thing to have. It has different goals than Lazarus. It is built around only one widgetset, fpGui. It does not need to worry about Delphi compatibility. Those are the main challenges of Lazarus, supporting Delphi compatibility for many native widgetsets.

Given the design goals and Graeme's coding skills, I would estimate his IDE will be in good shape relatively quickly, in one or two years.

Juha

Yes, the project will get up to 85%.
Then only the real hard bugs will remain and some start's thinking of starting the whole thing. ;-)

Sam

>Juha

2010/5/6 Samuel Herzog

To complete such a big project you need "a few people with a lot of time instead of many people with little time" (PostgreSQL quote) How to work on the OpenSource project you like and enjoy doing, instead of commercial stuff that pays your bills an probably sux big time, that's the great dilemma, how can large companies do both and avoid project splitting and even death of great ideas and innovation.
Graeme has found a way to do both without having a foundation to pay his bills. Good luck Graeme. I really hope he succeeds in doing something great.

Razvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100506/dc6515a5/attachment.html>

Juha Manninen wrote

Please don't continue the same discussion any more, anyone!

Correct, and the reason why I replied to those posters in private.

Given the design goals and Graeme's coding skills, I would estimate his IDE will be in good shape relatively quickly, in one or two years.

And like I told someone in private, it will also serve as a showpiece for what fpGUI is capable of (unlike the existing small [feature specific] demos included with fpGUI).

Features already implemented (using +- 12 hours of my time):
* Project / unit management
* IDE macros
* User defined macros per project
* multi-threaded for compiling and searching functions, keeping the IDE and UI very responsive.
* multiple build modes
* very customizable compiler options and search directories. this works hand-in-glove with multiple build modes.
* project templates support
* External tools support
* Context sensitive help (by using offline help)
* Single Window (tabbed) design
* File Browser support
* Scratch Pad or Code Snippets window

I'm now working on the GDB front-end. Code will be made available in the fpGUI repository after the fpGUI v0.7 release.

2010/5/6 Razvan Adrian Bogdan:

To complete such a big project you need "a few people with a lot of time instead of many people with little time" (PostgreSQL quote)

One developer is all you need (and definitely not impossible). Just take a look at MSEide - all written by one guy.

Those two statements describe things very good: I started FPC in June 1993, in August 1993 simple projects could be compiled including units, however, it took till March/Apri 1995 for self hosting (spending little time on FPC during winter/spring/summer 1993/1994 due to final school examinations) and till July 2000 for version 1.0 (with the help of a lot of other people).

Without wanting to diminish your accomplishments:

These are the easy things. You created what basically amounts to an editor.

There are more things to Lazarus than just the editor, and it seems to me that people are forgetting this, taking many things for granted.

The hard things are
- Code tools. The code tools in Lazarus are HUGE.
- Extended designer. The fpGUI designer is rudimentary.
- On top of this: Designer-Code tools interaction.
- Package support. A huge domain by itself.
- IDE extension interfaces.
- Reporting tools.

These are the things that will require a lot of effort to get right.

But I will be watching closely at the progress you are making. If cooperation fails, then competition is OK, as long as it is in a healthy atmosphere.

Michael.

Michael Van Canneyt wrote

These are the easy things. You created what basically amounts to an editor.

Well with every new project you have to start somewhere! :) The fpGUI IDE can already manage the fpGUI Toolkit code and the fpGUI IDE project itself, and our company projects. With that it supports various macros and build modes based on platform, and compiler used (various versions are supported). So cross-compiling or switch between compilers versions is already a trivial thing it my IDE.

There are more things to Lazarus than just the editor, and it seems to me that people are forgetting this, taking many things for granted.

I definitely don't take the features for granted in Lazurus IDE. The fpGUI project taught me a lot. As I said, I needed to start somewhere. Managing a project and various build modes was the first thing on my list. To get that working without version control systems detecting project file changes the whole time (when switching platforms), I had to implement Macro support too. A simple step-by-step process to get to a end result.

The hard things are - Code tools. The code tools in Lazarus are HUGE.

...and the reason I asked about the fcl-passrc parser in recent posts.

- Extended designer. The fpGUI designer is rudimentary.

...simplicity by design. This allows it to do one thing and one thing well. I hate software that tries to be too clever. Code Completion in the Lazarus IDE is already stepping on my toes in some cases (and I believe on yours too based on your posts is the past), and I have to keep disabling those new "features" because they keep getting in the way. Simplicity is also a design. :)

- Package support. ?A huge domain by itself.

...and with it's own set of problems. I use non-visual (runtime only) packages a lot, and sometimes they cause problems too. Something simple compiler paths would have solved much easier. Take tiOPF as an example: We have tiopf.lpk, tiopffpgui.lpk / tiopflcl.lpk and then your project that uses tiOPF. If you want to change a persistence layer, you need to modify the compiler defines (LINK_xxx) for two packages and your project options, otherwise some code doesn't get recompiled. Simple compiler paths with a single global compiler define would solve this problem much easier.

... competition is OK, as long as it is in a healthy atmosphere.

That's the name of the game. Just look at the amount of cross-platform IDE's available for Java and C/C++. For Free Pascal, I know of three (FP Text IDE, Lazarus and MSEide). So more choice will probably be a good thing. We also learn from other projects mistakes.

That's the name of the game. Just look at the amount of cross-platform IDE's available for Java and C/C++.

But I consider none as being only somehow on par with Visual Studio :) Things like KDevelop are a laugh if one knows VS.

Thu, 6 May 2010 10:14:54 +0200
Graeme Geldenhuys ??????:

That's all sound good, and shows that fpGUI is capable to create some real apps. But for me the main missing feature of it is a lack of native look&feel. I want all applications look the same, giving me a feeling of a complete system on my PC. Yes, I know that fpGUI supports themes. But if I set, for example, some GTK theme with Murrine engine, with animated progress bars - fpGUI will not look the same, and that's really bad for me.
All my projects are targeted mostly to the home user, and this is the place where eyecandy goes first.

2010/5/6 ??????? ??????? :

It's even worse for users that have to set the themes or font sizes due to bad eyesight, disability etc. Widgetsets spend quite some effort on getting the accessibility issues right (see for instance http://projects.gnome.org/accessibility/). But then even lcl-gtk2 doesn't respond to font size change. I've tried to fix this but my lcl skills are lacking.

Henry

2010/5/6 ??????? ??????? :

But for me the main missing feature of it is a lack of native look&feel. I want all applications look the same, giving me a feeling of a complete system on my PC.

Again, this was a design goal of fpGUI, just like it was for MSEgui.

Yes, I know that fpGUI supports themes. But if I set, for example, some GTK theme with Murrine engine, with animated progress bars - fpGUI will not look the same, and that's really bad for me.

Just like GTK2 apps look crap under KDE desktop. Or Windows Media Player or Safari Web Browser looks crap under Windows. This is not just something related to fpGUI. Consistent look between fpGUI applications on various platforms was my design goal for fpGUI. Nothing more,
nothing less.

All my projects are targeted mostly to the home user, and this is the place where eyecandy goes first.

I can list 1000's of programs that don't adhere to the OS theme. Media players, Video editors, Photo editors, Office applications, CD burning software, Games, Development tools, Web Browser, web pages like web apps (Gmail, Facebook, Twitter,...) etc... Millions of home/office users use web apps every day, yet not a single web app looks like my/your OS theme, yet we all seem to manage just fine interacting with the web page/web app. Your point is simply irrelevant. But now we are getting completely off topic here so I'll stop this discussion.

A word of advice: make your editor multi-project enabled from the start. The project manager should be able to show multiple my part, this is the major missing thing in Lazarus.

> The hard things are - Code tools. The code tools in Lazarus are HUGE. ...and the reason I asked about the fcl-passrc parser in recent posts.

I guessed as much.

Here I must agree.

To my taste, the code tools got much worse lately; They were optimal about 2 years ago. The latest indenting/formatting features have almost caused me to go back to using joe for editing, because there is no way to disable them completely, causing more damage and anger than helping me code efficiently :/

Michael.

Michael Van Canneyt wrote

A word of advice: make your editor multi-project enabled from the start. The project manager should be able to show multiple projects at once. For my part, this is the major missing thing in Lazarus.

You mean like Delphi and Kylix has - Project Groups? Not sure if this is exactly what you meant, but Project Groups are definitely on my IDE todo list. Our company's main product exists of 7 separate projects all working together, and I would like to work on all of them easily in the IDE, and do a "build all projects" command. This will save me lots of time on release builds.

Another sought after feature for me is pre|post commands when doing a Build. Yes Lazarus IDE has it, but only one command per pre|post task, and it doesn't work in a cross platform way. For example: I generate before a build a new version.inc file, clear old *.ppu units etc. After the build, I update the translation files etc. I use pre_build.sh and post_build.sh scripts to allow multiple tasks, but as soon as I switch to Windows, Windows can't execute *.sh scripts and fails to do a build. So I have to disable those functions, which in turn modifies the project *.lpi file which I need to undo when I switch back to Linux again. A damn pain, and not consistent behavior between platforms.

To my taste, the code tools got much worse lately; They were optimal about 2 years ago. The latest indenting/formatting features have almost caused me to go back to using joe for editing, because there is no way to disable them completely, causing more damage and anger than helping me code efficiently

+1

sorry, for jumping in. But I don't like the current default indenting behavior too. For me, it is confusing to fiddle with the settings in "Environment/Codetools/Indentation" together with
"Environment/Editor/General/Indent and Tabs".

Maybe the option "Environment/Codetools/Indentation/On break line" should be disabled by default and go to
"Environment/Editor/General/Indent and Tabs".

Regards, Bernd.

Now we all hope for the due Lazarus 1.0 release :) :) :)

-Michael

I recently invested some time to investigate server-site programming with Lazarus.

There are several issues:

1) new __functional__ GUI-less Widget Type

A decent CGI-type of program should not have any linking to a GUI system (such as the Windows Graphical APIs or GTK). To do decent "Delphi-Language" programming, event driven programming and threading is essential. Currently, in the LCL the event queue, necessary for event driven programming, e.g. using TTimer or thread communication is not available unless you activate a GUI. (Currently only having worker threads notify the main thread via an event queue is used in any Lazarus or Delphi-Type programs is common, event queues for worker threads would be nice to have but seemingly never requested by anybody but me - even though MADSHI seems to provide this for Delphi.)

For decent GUI-less applications, a new "Widget Type" would be necessary (at least for Linux projects) that avoids GTK / QT binding but provides an event queue. I started to do this (see some other "CGI" or "noGUI" threads here), but I'm busy with other stuff right now. (I do know that this is possible: MSEIDE does provide this, but for Lazarus as much LCL code as possible should be reused for this issue.)

A prerequisite necessary to be done to the common (shared by several Widget-Types) LCL code would be moving the code necessary for doing the event queue for the main thread out of the "Forms*" files, that provide the basics of the GUI interface. that should be a quite doable task.

2) Silverlight / Moonlight

I feel that Silverlight / Moonlight is a great way to create multi-tier applications (working around the abysmal HTTP interface between the sites that is necessary to use due to the worldwide lack of competence in the IT departments, preventing decent bidirectional TCP/IP communication.)

Technically, on the server site, Silverlight / Moonlight is just (fast) CGI with some nice files on the server providing HTML pages, the CIL (".Net code") program to run on the Client, and some Java script and Java byte code for the Client to start the CIL program and have it communicate with the server.

To do this, it is __not__ necessary that the server part and the Client part are done in the same programming language. Moreover it is __not__ necessary that the server part is done in CIL (.NET/Mono) code. Moreover I think ASP.NET (as Microsoft defines it) is not necessary either.

Of course for Lazarus fans, it would be really nice to do the client part in an Object Pascal language, too. Currently there only is Delphi Prism that can do this. AFAIK, the compiler - other than the IDE - even is fee (as beer). Doing a CIL compiler for Lazarus seems to be far off right now.

For the server site, on top of the "functional" GUI-less Widget Type, Lazarus would need to provide an application or Widget Type that manages the communication with the Web server. I suppose, in Linux (Apache), this would be fast CGI, in Windows (when using IIS), this would be ISAPI (maybe using a "gateway" ISAPI dll converting the ISAPI traffic into fast-CGI, as debugging a dll could be very difficult to do).

Moreover the "comet" technology needs to be supported to allow for the server application to notify the client asynchronously.

Of course a method to do an event-programming enabled fast CGI application framework (that allows for more standard events (TTimer, thread communication, etc.) and not _just_ the events triggered by the client, and that also supports "Comet" out of the box would be desirable for "normal" CGI projects, even before the stuff necessary to do Silverlight / Moonlight would be very desirable

3) Flash

A colleague of mine indeed did this (using Delphi, IIS, ISAPI, and RemObjects SDK on the server site and Flash Action Script on the client site, defining a communication based on SOAP). So this in fact is possible (RemObj SDK is commercially available in source code and certified for FPC, but you of course can do RemObjects work-alike stuff on your own).

He did this two years ago, as a (maybe) usable Silverlight SDK was only available as Alpha state. I suppose nowadays he would do the project using Silverlight and Delphi Prism.

4) IDE
To do sensible debugging for GUI-less programs support for decent viewing of the "Writeln" output while debugging.

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100506/baef4981/attachment.html>

As discussed many times before:

You don't need a full-blown widget type for this.

You simply need an event queue. You are trying to kill a fly with a cannon if you want a widget-set.

Michael.

That is exactly what I request (and what I already partly implemented): enhance the existing NoGUI Widget set (simply) by a event queue. Here it would be a good ide to reuse the proven event queue code provided by the GTK(2) Widget type. (Only same should be moved out of the forms* files into it's own ones to make it reusable without copying it.)

A greater challenge is to do (e.g.) the TTimer for this Widget set that will one of the components that provide events for that queue. Here I do have a working Linux example taken from MSEIDE (using a signal on the low-level (Linux only)

You are trying to kill a fly with a cannon if you want a widget-set.

What is wrong with killing a fly with a cannon, if you do it once and it makes designing many subsequent projects a lot easier to do...

-Michael

Zitat von Bernd Mueller :

The codetools indenting can be disabled completely.

Please create bug reports.

Mattias

2010/5/6 ??????? ???????

I don't see people complaining too much about Firefox, Chrome(ium), Opera, Thunderbird, etc. even MsOffice has a different theme from the OS. Windows support for themes is quite good and you can use it in any framework, i assume on Linux you have also good support, i don't know about OSX but i would be surprised if you couldn't reproduce the exact same interface. Java sucks at this and people still use it.

Razvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100507/2f69ec6e/attachment.html>

Web programming in Lazarus/Delphi can be done in 3 ways:
- Non persistent safe CGI, you have to do persistence yourself, this is ok, requires some work but is no the fastest way of doing things, you do get a free garbage collector <hint>Implement something like smart pointers in C++ using operator overloading ?</hint>, interfaces are too much overhead.
- Persistent building a module/plugin (not safe), or using FastCGI, SCGI or a small HTTP server behind a bigger one, i would probably try the HTTP backend (proxy) server behind the real server because FastCGI has poor support (very old apache module) and SCGI doesn't seem too well known.
- The full thing with whatever backend, everything managed by Lazarus just like a desktop app something like Morfik/Intraweb, this is probably the least efficient way of doing web stuff but it would be ok if you only input data and output reports without the need to customize anything, people seem to complain about ASP.NET for being too difficult to learn and customize.

I'm not sure if threading support is better now, last time i checked, there were still some issues with threads in FPC, the developer who wrote PWU complained a lot about threading support being a major obstacle in FPC, if you want a faster HTTP or FastCGI service instead of the slow but safe CGI you really need good/predictible threading and absolutely no leaks so the SmartPointer/ReferenceCounting would be really useful because in most projects there are other people that forget to free some stuff.

Razvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100507/4fc42642/attachment.html>

People who forget to free some stuff should not be encouraged. They should be taught to program right in the first place.

Michael.

Michael Van Canneyt wrote

People who forget to free some stuff should not be encouraged. They should be taught to program right in the first place.

The problem is nobody and nothing can force them to do things right, at least let's minimize their negative impact as much as possible, we simply can't choose our team members, someone else is doing it for us so we can do stuff ourselves and work with people who want to help or allow outside people with background in Java, C# and PHP come and make us look like "religious" dinosaurs who can't understand progress, in a manager's eyes technology is valued by trends and hype.

Razvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100507/40f4ac70/attachment.html>

Graeme Geldenhuys wrote

I can list 1000's of programs that don't adhere to the OS theme.

I don't even expect any new program I need to use to do that :).

-Michael

Razvan Adrian Bogdan wrote

Web programming in Lazarus/Delphi can be done in 3 ways: - Non persistent safe CGI,

AKA doing a Command Line tool: Hard to debug with Lazarus.

- Persistent building a module/plugin (not safe), or using FastCGI, SCGI or a small HTTP server behind a bigger one,

A built-in HTTP server is nice for testing (EXTP provides this).

FastCGI (communicating with pipes or TCPIP sockets with the WebServer) of course is the most "Linux standard" ways

I don't know about SCGI.

With Windows/IIS you additional have ISAPI. Here the SCI-program needs to be a DLL.

A colleague of mine did the ISAPI thing with Delphi, doing just a miniature DLL that communicates with some message system with a free running program that does the real work. Now this program can be debugged in the normal way. Something like this can be used to convert ISAPI or standard CGI to FastCGI.

i would probably try the HTTP backend (proxy) server behind the real server because FastCGI has poor support (very old apache module) and SCGI doesn't seem too well known.

Would you route the "normal" traffic between the clients and the web server though your program ?

-Michael

Michael Schnell wrote

> - Non persistent safe CGI, AKA doing a Command Line tool: Hard to debug with Lazarus.

Done this and works well in Delphi at work using PWU and custom HTML templates and handwritten JavaScript (nice language for client side), persistence is implemented using JSON as it's a common web format and our app is quite interactive, i found a way to debug this using breakpoints in Delphi doing a loop that is forced at the beginning and i change a variable using the debugger after "Attach to process", not optimal but it works just like services only for each user click you do this again, the debugger could be detected on Windows instead of changing the variable, also done this in Lazarus at home for a smaller project, logging was all i needed for the smaller project.

> - Persistent building a module/plugin (not safe), or using FastCGI, > SCGI or a small HTTP server behind a bigger one, A built-in HTTP server is nice for testing (EXTP provides this).

I don't mean building a full HTTP server just a "thin" HTTP server that serves the application page not the resources, more like a HTTP service just like FastCGI but without the extra complexities of FastCGI, do you really need FastCGI's authentication system ?
I think there is a healthy modproxy for doing this in Apache to link with your tiny app server.

FastCGI (communicating with pipes or TCPIP sockets with the WebServer) of course is the most "Linux standard" ways

It is OK but it is blamed for not having a updated Apache module.

I don't know about SCGI.

Just like FastCGI but claims to be simpler.

With Windows/IIS you additional have ISAPI. Here the SCI-program needs to be a DLL.

need to build them for every destination OS, 32/64 and each server you are planning to support, wouldn't just be simpler to build the HTTP service behind the real HTTP server and just run that, i understand that many Java apps do this.

Razvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100507/86179728/attachment.html>

2010/5/7 Razvan Adrian Bogdan :

What do you use?
Have you made any real app using some of these technologies and FPC? I would like to use FPC for my web apps, but I don't see many examples...

Does anyone uses FPC for real web applications?

Thanks
Marcos Douglas

Marcos Douglas wrote

Does anyone uses FPC for real web applications?

Definitely yes, we have 3 web applications in our company written with FPC+tiOPF+PWU. The IRC bot (FPCBot) is also implemented/compiled with FPC.

http://www.hu.freepascal.org/fpcircbot/cgifpcbot?channel=lazarus-ide

My personal home-grown wiki is also written/compiled with FPC. http://opensoft.homeip.net/wiki/wiki.cgi?p=Main-Page

Michael van Canneyt I believe also writes web apps for his company using FPC.

I wanted to do it exclusively in FPC and used only FPC compatible technologies (PWU) but was later forced to use ADO (bad choice but not my choice and what else for MSSQL), i wasn't sure if FPC supports ADO, still i did do a very serious app for a very serious company and it is done at the moment in Delphi but could be easily compiled with FPC if i could find a way to use ADO in FPC without making apps huge, ADO is already making them too large for CGI even in Delphi.

Razvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100507/1ddb9965/attachment.html>

Graeme Geldenhuys wrote

Definitely yes, we have 3 web applications in our company written with FPC+tiOPF+PWU. ?The IRC bot (FPCBot) is also implemented/compiled with FPC.

PWU = Powtils ?

Unfortunately, here in Brazil, most people/companies to not think so. The most companies think to use C# or Java. I think Pascal is more simple, small and fast. But I'm afraid when tell me nobody use Pascal any more... especially when we talk about web applications.

Thanks for the links. Are great examples of what FPC can do.

Michael van Canneyt I believe also writes web apps for his company using FPC.

I believe too. He participate of ExtPascal's list but he is gone... :(

Razvan Adrian Bogdan :

Good you say that about ADO.
In my company, we use MSSQLServer too. No way to change that for many reasons...
So, I would like to use FPC compiled on Linux, but is very important the conection with MSSQLServer... and that has to be fast.

Marcos Douglas

Correct. I dropped ExtPascal. I don't think it is the way to go: You still need know too much Javascript to be able to use it, and the project has some basic design flaws, which Wanderlan is unable/unwilling to fix.

So now:
- FastCGI (or whatever you feel comfortable with) for the server using FPC. I will be donating extra code for this to fcl-web in the next months.
- Javascript (ExtJS) for the client.

Michael.

El vie, 07-05-2010 a las 10:31 -0300, Marcos Douglas escribi?:

I use PWU for an CGI based web Control Panel application, in charge of CRUD and Config tasks for a legacy PHP app, and it works pretty nice. The server is a simple Linux-Apache-Mysql-PHP shared host, so I just have to replace my CGI in /cgi-bin directory every time I update the program.

When I started with this project, I used just VIM with a couple of shortcuts to compile and "deploy", that was my IDE. Then, a couple of weeks ago, I was really missing the Code Insight and code navigation features, then did a simple tests with Lazarus and it worked out of the box, so, from that time, it is the IDE of choice for this app.

In this particular case, yes, "Lazarus make me create better apps"!.

Can anyone in the know, comment on this? I've been using FPC for a couple of threaded TCP server applications since 2005 and haven't had any problems. Though admittedly, they are not what I'd call high traffic in terms of concurrent connections.

I'm working on a project now where I expect to have some fairly higher concurrent connections (maybe 300-600) so I hope (and assume) all is well for threaded apps on Linux servers :-)

Marcos Douglas wrote

PWU = Powtils ?

Yes. The same project (library) had various sames: PSP (Pascal Server Pages), Powtils, PWU etc. I don't actually know what is the official name any more. Go figure. :)

Thanks for the links. Are great examples of what FPC can do.

Those are very basic apps. Our company web apps to much more complex things and UI. Michael's web app was also very impressive (he gave me a sneak preview once).

Lee Jenkins wrote

Can anyone in the know, comment on this? ?I've been using FPC for a couple of threaded TCP server applications since 2005 and haven't had any problems.

Same here. We use threaded apps (web and desktop) under Linux without problems. So I don't really know what issues they are referring to.

El vie, 07-05-2010 a las 11:18 -0300, Marcos Douglas escribi?:

PWU = Powtils ?

Yes. Now it's called "Powerfull Web Utilities".

That's why I preffer not to work with software outsourcing customers, they allways try to force you to use the "buzzword of the day" instead of looking for a solution to a problem. On the other hand, is a pleasure to work with companies that sees value in small, fast and robust applications made in Delphi/FPC.

My company also uses Lazarus/FPC for the whole system we have (an internet affiliate network) that was originally written in Kylix. It is Linux/Apache/MySQL server based. Most development and testing happens under Windows, then the web server part recompiled and retested under Linux before uploaded to the live server.
The external utility programs are only used on Windows clients (customer service, system maintenance, etc.) using secure SSH tunnels to the web servers via Putty (to access the data on the MySQL databases, etc.). These could be compiled for Linux also, it is just most people are familiar with Windows better.

All web pages are using the fpTemplate unit to generate the HTML responses. The web design layer this way is totally separated from the server programming side. The HTML people can beautify their pages as they like while using the available HTML tags provided on the server side to display live data from the databases.
You can find some basic examples on using the fpTemplate unit and template tags under the Lazarus directory

/lazarus/components/fpweb/demo/fptemplate/

Works like a charm.

AB

Michael Van Canneyt :

I agree about some design flaws.
I thought you would create a fork of this projetc :)

So now: - FastCGI (or whatever you feel comfortable with) for the server using FPC. ?I will be donating extra code for this to fcl-web in the next months. - Javascript (ExtJS) for the client.

This is I want too.

Leonardo M. :

Hi Leonardo, do you also participate of ExtPascal's list, right? Thanks for your example... do you continue using ExtPascal?

Do you use CGI or FastCGI? What libs/frameworks?

Graeme Geldenhuys wrote

Yes. The same project (library) had various sames: PSP (Pascal Server Pages), Powtils, PWU etc. I don't actually know what is the official name any more. Go figure. :)

OK. What about the oficial site and sources, could you like tell?

Those are very basic apps. Our company web apps to much more complex things and UI. Michael's web app was also very impressive (he gave me a sneak preview once).

Show for us too! :)

Graeme Geldenhuys wrote

Same here. We use threaded apps (web and desktop) under Linux without problems. So I don't really know what issues they are referring to.

But do you use threaded apps with CGI?
I think would use threads in FasCGI apps. if each CGI is a request for one to one, then why use threads?

2010/5/7 Leonardo M. :

I agree with you.
I always think to be my own boss and open a company... and use my favorite tools... but this is a large step for now :)

Thanks all... let's continue!

Marcos Douglas

This is my enviroment too... but I use SQLServer.

Thanks for your example. I will see the fpTemplate unit. What about the server app. Do you use CGI, FastCGI... some libs or frameworks? Everyone talk about PWU.

Thanks,
Marcos Douglas

El vie, 07-05-2010 a las 16:10 -0300, Marcos Douglas escribi?:

Hi Leonardo, do you also participate of ExtPascal's list, right?

Yes, I allways read the list, and some times I also ask some questions.

Thanks for your example... do you continue using ExtPascal?

Just for learning purpouses. For real apps, I preffer to use plain ExtJs and Apache or my own Synapse-based web server for the backend.

The server side was an Apache mod but now it is simply CGI. We did not see any speed increase/decrease for the visitor traffic volume we have in either case.

We might do it FCGI in the future, but it does not seem to be working on Windows (it was a few months ago so I do not exactly remember what was the problem, but I think it was something like many FCGI app instances got spawned and dragged the CPU like crazy all the time even between requests), so we probably need to move to Linux for the server development in case we try to do this again.

No frameworks or libs were used, it is a normal website with screens, reports, etc., people need to click on things to get new content. The request goes to the web server and an HTML page is generated using a template, replacing the template-tags with content from files/databases, etc.

AB

2010/5/7 Leonardo M. :

(...) Just for learning purpouses. For real apps, I preffer to use plain ExtJs and Apache or my own Synapse-based web server for the backend.

Yes. I think I will use ExtJS (or Qooxdoo <http://qooxdoo.org/>) and Apache. Did you made your own webserver? There is advantages instead of use Apache, e.g.?

ABorka wrote

The server side was an Apache mod but now it is simply CGI. We did not see any speed increase/decrease for the visitor traffic volume we have in either case.

Nobody has done a test like this.
This is a good information for CGI programmers...

In the ExtPascal's list they had some problems using FCGI on Windows. Exists some IFDEF's in ExtPascal code to work on IIS...

OK. This is very simple. I like that. Thank you.

Marcos Douglas

Marcos Douglas wrote

OK. What about the official site and sources, could you like tell?

The latest source code from the official repository did not even compile for us (a few months back). So what we still use is a slightly older version - and it compiles fine. :)

It can be download from here:
http://opensoft.homeip.net/~graemeg/pwu-1.6.0.2.tar.gz

I don't know the official download location any more. Here are some more links. The official site is the z505.com one.

http://z505.com/powtils/idx.shtml
http://z505.com/powtils/docs.shtml
http://wiki.freepascal.org/Powtils
http://code.google.com/p/powtils/

But do you use ?threaded apps with CGI? I think would use threads in FasCGI apps. if each CGI is a request for one to one, then why use threads?

Yes, we use threading in plain CGI apps, but only for logging/debugging purposes. Our
"log-to-[file|sysevents|screen|debugserver]" units all use threading and cached logging so it doesn't interfere with performance too much. Release builds have logging disabled. As you know, a standard CGI is similar to a Console app: It runs, does it's thing, then exits. Our desktop apps use lots of multi-threading though.

El vie, 07-05-2010 a las 17:26 -0300, Marcos Douglas escribi?:

Yes. I think I will use ExtJS (or Qooxdoo <http://qooxdoo.org/>) and Apache. Did you made your own webserver? There is advantages instead of use Apache, e.g.?

Easier installation, and in some cases, I need more than a web server, for example, one of our apps is a TCP server, that opens up two ports, one for Dicom connections (for medical imaging) and another one for HTTP, to serve the html/javascript/images that allow the user to see what's happening and do some configurations.

projects there are other people that forget to free some stuff.

We also develop web application. Better: its the same application as desktop: mid size enterprise ERP
from web side its work as FCGI or embedded server, also with ssl, can work on Linux or Win, as daemon or console application, Also both version, desktop and web coexists, some users work local, some via browser
Since several weeks it can work on ARM too (not whole, but monitoring part)

its consists small part AJAX, CSS and several base units writes for web, but rest code (95%) is shared between desktop and web,

From developer view:
In normal code is no HTML and no Javascript.
Its consists forms, grids, modal windows, popup menus, reports based on PDF, keyboard navigation, etc
Logically is very similar do LCL, VCL, with passing messages as in windows

if someone want to see: http://www.invoicer.pl/mobile (freeware part) For someone interesting I've prepare xweb library with source, with it simple web app can be build.

Now I understood about threads in your app.
Thanks for the PWU's links.

Our desktop apps use lots of multi-threading though.

Oh yes! In desktop apps I use multi-threading a lot.

2010/5/7 Leonardo M. :

Well... maybe to do just TCP server app and another CGI+[Apache | IIS | lighttp | etc] for reuse code these web servers... But I understood you.

Do you use FPC or Delphi?

Very interesting.
Can you put a link of source? Thanks.

Marcos Douglas

----- Original Message -----

Yes, offcourse.

Joost.

Joost van der Sluis wrote

> Does anyone uses FPC for real web applications? Yes, offcourse.

So, would you like your examples, please?

Marcos Douglas

I can't speak for other, but not *all* applications (web, desktop, console or otherwise) are always available to the public. That doesn't mean FPC is not being used.

Graeme Geldenhuys wrote

I can't speak for other, but not *all* applications (web, desktop, console or otherwise) are always available to the public. That doesn't mean FPC is not being used.

You right, of course. But is significant hear some use cases, don't?

Marcos Douglas

We are using it to give parents access to the information that schools have on their children. Schools have a client/server app, and the web front-end is used to display the information in the database.

We'll be extending the web-interface to allow teachers to enter information in the same database as well. (grades, absentees, remarks on behaviour etc.)

All this happens with FPC on the server (fcl-web and sqldb), and ExtJS for the client in the browser.

Michael.

FPC + ExtJS
This is the configuration I want to do. In the ExtPascal list, there are some people using the same approach.
But I continue with doubts about how to use separate *.js files. How you do that? Do you open *.js files in app, replace some tags/macros and sends to client?

Thanks,
Marcos Douglas

There have been some problems with threading in early 2.0.x times maybe. I think it is ancient history.

The only "problem" I know threads that created/run but that are not initialized via FPC threading system, but that is a problem for every language with threadvars afaik.

People are mostly used to browsers looking out-of-touch.

It is something else to have to deliver your apps like that.

If you can deal with Delphi, and can be substituted by PHP programmers, you are doing something wrong.

In a past job I've developed a https server using indy thttpserver. Worked fine.

The app was in Delphi, (this is pre-2.0.0 partially) but I later ran several of the unittests with FPC and they worked fine, and I have no doubt were I still there, the whole app would work fine too. (*)

(*) better even, since the MSXML related XML classes gave me quite a headache
then.

El jue, 13-05-2010 a las 17:38 -0300, Marcos Douglas escribi?:

Hi Marcos, .js files are opened by the web browser, not by your app. Inside the .js files are AJAX calls to the application also residing on the web server. The app could be an simple CGI or a WebServer itself, just like ExtPascal.

I have to point that the application doesn't have to know anything about HTML nor Javascript, it just receive and answer JSON data, that is parsed by the web browser.

Going a little further, what the FPC program does is very little, just answers with JSON to the ExtJs program running on the web browser. The simpliest example a can do is the one I published here: http://leonardorame.blogspot.com/2010/02/web-20-programming-with-object-pascal.html

In the example I didn't use an FPC program, just setted up an Apache Server containing an HTML file, the ExtJs package and a .Js file with a grid. When the browser points to the server, the files are loaded, processed and it asks for JSON data, also in a file inside the web browser.

I hope I clarified some concepts.

I know, but I stopped using ExtPascal. I don't believe in it's approach any more, one still has to know JavaScript in order to write decent client apps.

But I continue with doubts about how to use separate *.js files. How you do that? Do you open *.js files in app, replace some tags/macros and sends to client?

Till now, there has been no need to do that. The .js files don't need tags/macros. All configuration values are fetched from the FPC server using Ext.Direct (I created some FPC components to handle Ext.Direct requests, they will be donated to FPC).

If I would need macros/tags, I would simply use fpTemplate, it was designed for that.

Michael.

Hi Leonardo,

2010/5/13 Leonardo M. :

You clarified! Thanks... I was confusing the concepts.

Marcos Douglas

Michael Van Canneyt wrote

I know, but I stopped using ExtPascal. I don't believe in it's approach any more, one still has to know JavaScript in order to write decent client apps.

Yes, I know about you left...
I also do not believe in ExtPascal approach. How did you say we still have to know JavaScript and, some cases, put JavaScript inside Pascal code. They are completely different technologies and, therefore, should remain separate.

Till now, there has been no need to do that. The .js files don't need tags/macros. All configuration values are fetched from the FPC server using Ext.Direct (I created some FPC components to handle Ext.Direct requests, they will be donated to FPC).

I think many developers will benefit from its components FPC.

If I would need macros/tags, I would simply use fpTemplate, it was designed for that.

For simple programs? Okay, one more option.

Thanks,
Marcos Douglas

Well, the problem is that I am bound to some confidentially agreement for the real applications.

But if you search this list on my name and 'fcl-web' you'll find link to some examples and the used framework.

See also this website:
http://services.cnoc.nl/lazarus/index/fclweb

And one example:
http://services.cnoc.nl/lazarus/fclweb/examples/jqueryelementsexample/jQueryElementsExample.psp?action=HighCharts

Joost.

Hi Joost,

Joost van der Sluis wrote

Well, the problem is that I am bound to some confidentially agreement for the real applications.

No problem. The important is I know this is possible make better apps with FPC on the Web and there are people doing this... if I need help, they can help me.

Thanks. I found links a lot:
http://www.google.com.br/#hl=pt-BR&q=site%3Ahttp%3A%2F%2Flists.lazarus.freepascal.org%2Fpipermail%2Flazarus%2F+%22fcl-web%22+%22Joost+van+der+Sluis%22++++++++&aq=&aqi=&aql=&oq=&gs_rfai=&fp=947aa678a375d04b

Marcos Douglas

Hello Lazarus-List,

Saturday, May 15, 2010, 2:13:54 PM, you wrote:

JvdS> Well, the problem is that I am bound to some confidentially agreement JvdS> for the real applications.
JvdS> But if you search this list on my name and 'fcl-web' you'll find link to JvdS> some examples and the used framework.
JvdS> See also this website:
JvdS> http://services.cnoc.nl/lazarus/index/fclweb

I would like to test your web framework, but your branch is unable to compile recent Lazarus versions due some IFDEF 2_5 in source code. Do you plan to update your branch or update the trunk shortly. If the answer is no I must install some Lazarus 0.9.28.x in parallel which is not a
Best regards,
Jos?

(v2.5.1) I'll update the info on that page.

Regards,

Joost.

Over the past few days I have tried creating and editing new records with the TSQLQuery component. I succeeded, but with quite a workaround.

As stated in bug report 0016076 (not authored by me) TSQLQuery gives errors if you try to create a new record and think TSQLQuery would all handle it. The issue addressed in the bug report is that all databases address making new records in different ways. The suggestion is to provide additional SQL lines to gain control over that process. Here I would like to discuss (and hopefully learn) about other things I found.

1) TSQLQuery doesn't really create a new record at insert or append. Instead, the only thing that is done is adding a row in the dataset [InsertInternal doesn't do anything]. The insert is not done and at ApplyUpdates the insert is lost because the dataset doesn't know the difference between updates and inserts. The insert is lost, because the new row is used to try to update a record that doesn't exist result in a fail. However, the InsertSQL line is executed which leads to a new record and the next observation.

2) The InsertSQL is executed, but since these are fixed strings I cannot put my new values into the strings. Trying to change the InsertSQL leads to an error because you cannot change the InsertSQL on an active dataset (rightfully so). So, the InsertSQL can create a new record but not with the right values. What I would like to see here is a insert statement with parameters and a possibility to provide parameters. Is that already there?

3) At ApplyUpdates the dataset is forwarded to the database as a list of updates. Which doesn't necessarily have to be true. What I would suggest here is an implementation of the Unit of Work pattern ( http://martinfowler.com/eaaCatalog/unitOfWork.html). Using the Unit of Work pattern you can make a difference between update, insert and delete actions. The pattern also allows to make the processing of the dataset one compact unit with some favorable effects on atomicity and concurrency.

4) Creating an ID for a new record can be done at two moments a) at the moment you want the new record b) at the moment you really save the new record. With (a) you can use the ID in references immediately without too much complexity, with (b) you don't waist IDs at the moment you are not sure you will ever save the record. So, it would be nice to have a property to choose when the InsertSQL is executed.

Of course, I am not experienced enough (with FreePascal) to implement this or even try to. But I hope my suggestions will help the development of TSQLQuery. I noticed there is quite a bit of discussion about the database components lately, but I don't know the development plans. Also, if I have overlooked anything I am happy to learn.

Regards,
Albert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100516/b81aa5bc/attachment.html>

It always amazes me how people can have huge problems with the most simple things. It probably means that there has to be something wrong, somewhere. (Documentation?) Are you familiar with datasets in Delphi?

The cited bug report is only slightly related to your problem, I think. The bug-report is about autoincrement fields. Those weren't detected properly. The problem that's not solved yet is that the generated number is not set in the current dataset, only when the dataset is fetched again.

If this doesn't work, you have to provide an example in which case it doesn't. Normally it does.

This contradicts the first point? In your first point InsertSQL wasn't executed?

And you are right offcourse that a InsertSQL property would be useless without parameters.

If you want to provide your own InsertSQL (instead the one generated by sqldb) try: 'insert into table(field1,field2) values (:field1,:field2)'

Updatesql:
'update table set field=:field, field2=:field2 where (field1=:old_field1) and (field2=:old_field2)'

A delete statement should be easy now.

That's in principle how it is working. Only heavily optimized for the job at hand (cached-updates in a dataset) and with a lot of extra functionality and flexibility.

What's more flexible then letting you call ApplyUpdates whenever you want?

It also depends on the used database-engine if you can use a or b. And a is always the best option. But there are a few database-engines from which the developers weren't that good at database design when they made their first implementation. (Access, MS SQL, MySQL) So they added the b design. But nowadays they all can use a also. (Except for Access, but, hey, that's not a serious database, and they don't pretend to be one too.)

Nice thing with the TSQLQuery design is that you can use both. But option b needs some extra code in some cases. (Unless we can think about some way to do this automatically, see the bug report you started with)

There is always discussion about the database components. That will never stop. ;) But you didn't add any new information to the discussion. (Most people don't) Unless maybe that the first step didn't work for you, but I think that you did something wrong there.

Joost.

Marco van de Voort wrote

If you can deal with Delphi, and can be substituted by PHP programmers, you are doing something wrong.

What is wrong about web programming in Delphi/FPC ? Of course it can be substituted, PHP is older and many people know it already, but there's too few Delphi/FPC developers out there, at least that's what my boss always tells me, if it wasn't so we wouldn't have to get people with C-ish background into our team.
Of course PHP can't replace Delphi but on the web side of things. that's another story.

Razvan

would like to discuss (and hopefully learn) about other things I found.

It always amazes me how people can have huge problems with the most simple things. It probably means that there has to be something wrong, somewhere. (Documentation?) Are you familiar with datasets in Delphi?

It always amazes me how sharp developers/owners/creators react to innocent, dumb and (in the light of your reaction) arrogant emails. When will I ever learn to hit the right tone in my emails?

And you are right offcourse that a InsertSQL property would be useless without parameters.

If you want to provide your own InsertSQL (instead the one generated by sqldb) try: 'insert into table(field1,field2) values (:field1,:field2)' Updatesql:
'update table set field=:field, field2=:field2 where (field1=:old_field1) and (field2=:old_field2)'
A delete statement should be easy now.

IT WORKS! I definitively vote for documentation. Now, documentation is where I can do something. I cannot add anything to the development of TSQLQuery itself, so much is made more than clear. But, I am happy that the component works the way I expected it to work.

Thanks,
Albert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100517/ec0e6750/attachment-0001.html>

Razvan wrote

On Thu, May 13, 2010 at 2:41 PM, Marco van de Voort

> > If you can deal with Delphi, and can be substituted by PHP

programmers, you

Agreed. PHP is a 'staple' in web development, and is benefited by a large number of mature frameworks supporting multiple design patterns, IDEs in large deployments (ie. Eclipse, Netbeans, etc.) and a huge community. I certainly wouldn't use it for desktop software development, but speaking as an ISV we are not getting phone calls from prospective clients wanting desktop software developed these days - they all seem to want a web hosted application solution.

Personally I'd far prefer to be developing in Delphi/FPC for these applications but the time it would take me to compensate for the rich number of frameworks, etc. in the PHP world would make the development timeframe for large scale business app development that we do, cost prohibitive for the client.

However with that said, we are about to embark of developing much of our shipped application software in FPC/Lazarus simply because there is no way to protect our source code when provided to a client for them to host on their own servers. This is a big weakness of PHP in general - sure there are obfuscation solutions out there, but I'm yet to find anything that I would be 100% happy with that my source is protected entirely. Plus the performance degredation for PHP apps (if PHP wasn't slow enough in its default installation) affects my client's productivity.

I think there is a really good place for BOTH FPC/Lazarus/Delphi web apps AND PHP apps. I don't see them as mutually exclusive here. Many of our clients want to tweak the web pages that we serve and by using tools like Smarty, etc. in PHP I can give them access to the app and let them loose on their own sites without too much fear of disaster. Of course, never say never....

Myles

Myles Wakeham wrote

Agreed. PHP is a 'staple' in web development, and is benefited by a large number of mature frameworks supporting multiple design patterns, IDEs in large deployments (ie. Eclipse, Netbeans, etc.) and a huge community.

Well... with pascal you got Lazarus or Delphi, VCL or LCL, and also both community.

However with that said, we are about to embark of developing much of our shipped application software in FPC/Lazarus simply because there is no way to protect our source code when provided to a client for them to host on their own servers. This is a big weakness of PHP in general - sure there are obfuscation solutions out there, but I'm yet to find anything that I would be 100% happy with that my source is protected entirely. Plus the performance degredation for PHP apps (if PHP wasn't slow enough in its default installation) affects my client's productivity.

Use pascal then. You just need to learn JS UI framework, my advice: ExtJS or Qooxdoo, for a while, perhaps about 1-2 weeks. Combine it with pascal on the server side. It would save you lots of time and work, especially since you already got the desktop version running well.

I think there is a really good place for BOTH FPC/Lazarus/Delphi web apps AND PHP apps. I don't see them as mutually exclusive here. Many of our clients want to tweak the web pages that we serve and by using tools like Smarty, etc. in PHP I can give them access to the app and let them loose on their own sites without too much fear of disaster. Of course, never say never....

I've made several web apps using pascal. Never need to use PHP. :)

-Bee-

I think the traditional barrier has been the deployment issue which probably made pascal based web application or servers more common to workgroup/intranet applications.

With VPS servers, that's all changing.

Some are extremely cheap, depending on the level of service you want: http://www.webkeepers.com/vps/vps_lite.html

The problem I think has also been lack of a central and openly available (open source?) framework to rally around for web development in pascal in order to foster an eco-system like we see with traditional 3rd party components and libraries.

I've been playing with javascript (particularly the dojo framework) a lot lately and its really not that bad once you get used to the loosey goosey weak typing and creating function objects on the fly as parameters to functions, etc.

Lee Jenkins wrote

I think the traditional barrier has been the deployment issue which probably made pascal based web application or servers more common to workgroup/intranet applications.

Yes, though binary CGI support is also very common.

The problem I think has also been lack of a central and openly available (open source?) framework to rally around for web development in pascal in order to foster an eco-system like we see with traditional 3rd party components and libraries.

What framework do you need to build web apps using pascal? Web apps is just about read browser request and reply to it. A custom simple communication class (to encapsulate the request-reply process) should be sufficient.

I've been playing with javascript (particularly the dojo framework) a lot lately and its really not that bad once you get used to the loosey goosey weak typing and creating function objects on the fly as parameters to functions, etc.

Making web pages using pascal is a bit tedious work due to HTML and CSS thingy. But for web apps, especially RIA, with the help of good JS UI framework, you just simply need to learn JS and a bit of JSON. For people who had been working for years with pascal and need to move to web app development, code reuse is a HUGE advantage. Code reuse isn't just about copy-paste the code, but also the testability and stability, which you need to do it again from start if you rewritten in another language.

-Bee-

Bee Jay wrote

Well... with pascal you got Lazarus or Delphi, VCL or LCL, and also both community.

in fact for Pascal you can use (at least):
- Delphi-IDE, Delphi Compiler, VCL (Windows only, but I recently learned that the latest version can compile for Linux)
- Lazarus-IDE, Free Pascal Compiler, LCL (Plus FPCGUI) (Windows, Linux, Mac, multiple CPU archs)
- MSEIDE, Free Pascal Compiler, MSEGUI (Windows, Linux, Mac, multiple CPU archs)
- Delphi-Prism) Visual Studio-IDE, ?, ? (for CIL Frameworks ".NET", Mono, ....)
- PASCOCOA (I did not take a deeper look at this) (Mac, but I learned that Free Pascal can do this, too)
- Kylix (obsolete)

-Michael

Lee Jenkins wrote

The problem I think has also been lack of a central and openly available (open source?) framework to rally around for web development in pascal in order to foster an eco-system like we see with traditional 3rd party components and libraries.

Did you take a look at doing Silverlight applications using Delphi Prism ? IMHO this is the most promising "modern" way to do complex web applications.

I don't know if/how you can run them on a Linux server (using Mono). (Linux client (Moonlight) should be supported.

-Michael

Michael Schnell wrote

> in fact for Pascal you can use (at least):

And when you used Object Pascal for web apps, you can use anything in the RTL, FCL, database components, Object Persistent Frameworks (eg: tiOPF) etc... ANY non-visual component - all out of the box functionality available.

THIS is way we (our company) opted to use Object Pascal for our web apps instead of PHP (which for the latter is *much* slower too).

Not to mention that it is inherently much safer than PHP.

Michael.

+1 both for Graeme and Michael. Or, should I say +2? :D

A thing that is being used everywhere never means it's the best. ;)

-Bee-

Bee Jay wrote

A thing that is being used everywhere never means it's the best. ;)

+1
Yup, just look at Windows, SubVersion etc.... [Graeme runs and hides behind his desk] :)

Agreed. I've made several CGI apps, mostly with powtils. Though certainly possible, not good for interactive Web Apps using Ajax techniques that need connection pooling, rich session storage, etc.

A framework like fpWeb or something similar some years ago that takes care of all the boiler plate code necessary to produce web content would have been nice.

Right. All that code that we've written, collected, modified and maintained and proven over the years is right there, at our beck and call to use whenever we want with the added bonus of not having to relearn new libraries or frameworks to do things. LazReport is a good example I think.

Even without legacy code at our disposal, pascal still has compelling reasons to be used in web applications.

I don't think the problem is with the back-end server, but the front-end 'smart clients' that are coming out that don't support it. iPads, for example, along with iPhones, etc. won't support this on the browser and they are starting to become a significant obstacle with client development. If I was to embark on a new web project today, I'd definitely only want to do the client work in Javascript and HTML5 and avoid any proprietary offering like Flash & Silverlight on the client.

Myles

-----------------------------
Myles Wakeham
Director of Engineering
Tech Solutions USA, Inc.
www.techsolusa.com
Phone +1-480-451-7440

Bee wrote

What framework do you need to build web apps using pascal? Web apps is

just

about read browser request and reply to it. A custom simple communication class (to encapsulate the request-reply process) should be sufficient.

Maybe for a web application with a small number of pages/options, sure. But not for larger scale business type web solutions. Here's the problem - there is a distinct distance between doing what is 'right' (ie. developing in Laz/FPC for web apps) and doing what is 'environmentally & economically compatible'. I'm in the USA, and here it is about being able to offer development services competitively on price and time. I've had numerous clients come to me that paid a very small amount of money to have some hack developer write a MS Access solution for their small business, and then they open a 2nd office in another state, or expand the number of users on the application beyond the limits of Access and want to have the application re-developed as a web application. These are typically high data throughput business database applications, with 50+ major data entities, etc.

I've been struggling to find a way to compete in this market with development environments like FPC/Lazarus, simply because although I want do it in those technologies, the lack of tools, frameworks, etc. means that I lose out bidding for those projects against other more established frameworks (ie. ASP.NET developers, PHP, Ruby, etc.). Simple things like session management, cookies, WYSIWYG HTML development, etc all seems to require so much time to establish first before I can start to craft the application, that I'm immediately uncompetitive against others - particularly when the client has the option to offshore outsource the development against a production line 'farm' of developers in other countries.

In order to compete in this environment, I've had to spend years developing my own frameworks for this, and then you get the client wanting to deploy the application. We are (for the most part) a Linux shop here, so we can host their apps for them. But some of the larger clients (ie. corporate, govt, etc.) want to use their own data centers for this, and therefore I have to find a way to deploy on their platforms. There's clearly advantages in Laz/FPC for this part, but convincing the IT managers that your code is ok on their servers when its not written in something they commonly encounter (ie. ASP.NET, PHP, etc.) is an obstacle. They are wary of CGIs because they don't understand what is going on there, and this is yet another obstacle to overcome.

We chose PHP for doing this because it allowed us the maximum deployment options, was compatible with inexpensive shared hosting solutions, and we could adapt frameworks like CodeIgnitier (www.codeigniter.com) to remove/reduce the amount of grind programming work required to develop any web solution.

It does work, and I can be somewhat competitive this way, but it still has its challenges:

1. Code that we produce is 'in the open' and totally able to be copied and hacked by the client regardless of whether they are licensed to do this or not, and

2. Performance is really poor. We built a small FPC native Linux solution for doing multi-million row set processing and found a 25x speed improvement with it doing its work vs. PHP native. There is no doubt that FPC is a better option for the end code here.

The challenge, therefore, is finding a way to do this faster and get around any client objections to the deployment. I've been following this thread intently because I believe there are some solutions in the FPC/Laz world that might just bring this closer to reality.

But being competitive is hard. I have other developers offering coding work at about 50% of the price that we do the work for, and I'm a 25+ year experienced software engineer so you'd think that I could do the work in half the time of a less experienced developer. But the problem is simply that using Visual Studio/ASP is a 'quick & dirty' way to get the job done and many of these clients, particularly small businesses, seem to be willing to accept that since they really have no internal knowledge of software development and rely on the consultants to tell them what is best for them. They ultimately judge the options on price & time to develop. Also in the Microsoft world, often the programming work is done at cost or a loss, but they make their money up on systems maintenance, server licensing, hardware, etc. since it requires such a beast to run the app on, and constant security monitoring, anti-virus, etc. which can be charged to the client on an ongoing basis. I don't agree with this approach since I feel the client should have a single up-front cost for the development and possibly ongoing enhancement/maintenance costs to the app throughout its lifespan. If they want to outsource hosting, sure - I'll charge per month for this like anyone else, but not at the higher level 'managed hosting' fees that I've seen practiced constantly in the Windows server management world.

There is a sense that web development work feels like writing mainframe apps in the early 1980s. Its slower, more cumbersome and you have to feel like there must be a better way to do this. The ability to craft a PC application quickly due to great IDEs, WYSIWYG tools, etc. has enabled development to be done quickly for the desktop environment. I guess we're all just waiting for the day when web development can be done as fast. I feel we are still a long way off, but it does mean that whoever can achieve this will ultimately dominate the web development space. I look back to what it took to write the same application in 1985 in, say, Turbo Pascal, vs. embracing something like Delphi/Laz/FPC today, and its night & day. But despite advances in software engineering practices such as object oriented, design frameworks, etc. writing web apps today is still more like a TP app development project in 1985 than a Delphi desktop windows app in 2010.

I live in hope that tools will improve to get us closer and am monitoring this thread with great interest as I feel that the solutions at this level will likely come out of open source if there are enough devs like me out there dealing with these challenges in our 'real world'.

Myles

Exactly. I'm working on a small framework myself and had all but finished the Flex front end when all the hoopla with Apple and Adobe came to a head. The customer did not want flash based GUI and I agreed. Fortunately, the UI layer was loosely coupled so I'm writing a new layer based on dojo and refactoring some existing stuff while particular, this application requires supporting mobile interfaces and the costs and effort of having a separate Android/Win7/iPhone version of these interfaces was not practical when HTML5 is already available with mature JavaScript UI toolkits and the one thing that these devices seem to have in common is the browser.

Great points.

Glad to hear. But if you're not doing something strange, it should also work with the default queries.
Any idea why that doesn't work?

Joost.

Maybe you should tell them that if they want to grow even further, or want to change something. It's more profitable to let you do that work then the php-party they want to work on now.

The IT managers that you can convince, can show better results to their bosses in the end.

Tell your clients that most IT-projects fail. When finished they don't do what was promised in the beginning, simply because the requirements were not ok. There are a lot of methods out there to handle such cases.

But whatever project-management-method you use here. If you write proper, structured, code, the result is more flexible and you can change your program according to your (new) client wishes. This improves the changes of success (a web application that is satisfactory to your users) a lot.

When you use php/VS/ASP as you explained above. Just click-click-click ready, it won't be flexible. That's what you have to win the competition with.

Joost.

Myles Wakeham wrote

... <skipped> ...

Agree with all what you have said. We've been facing the exact same problem as yours. We're also a Linux shop here and completely not providing Windows solution due the money factor. Our solution for building huge enterprise-scale web app is using PHP (scripting), Java (managed), and Pascal (native) altogether combining each best advantages. For the same reasons, we avoid to use any company-dependend technologies such as Flash, .Net, or Silverlight for the browser side and choose the open standard alternatives (HTML, CSS, and JS).

We must realize and admit that Pascal still lacks of tools for web app development. :(

There is a sense that web development work feels like writing mainframe apps in the early 1980s. Its slower, more cumbersome and you have to feel like there must be a better way to do this. The ability to craft a PC application quickly due to great IDEs, WYSIWYG tools, etc. has enabled development to be done quickly for the desktop environment. I guess we're all just waiting for the day when web development can be done as fast. I feel we are still a long way off, but it does mean that whoever can achieve this will ultimately dominate the web development space. I look back to what it took to write the same application in 1985 in, say, Turbo Pascal, vs. embracing something like Delphi/Laz/FPC today, and its night & day. But despite advances in software engineering practices such as object oriented, design frameworks, etc. writing web apps today is still more like a TP app development project in 1985 than a Delphi desktop windows app in 2010.

EXACTLY! That's why I hate web app development in the first place. After more than 10 years being spoiled by Delphi and then Lazarus, writing web app today is like back to those TP days. Morfik had been trying to solve this very issue, but I don't think it's ready for the prime time yet. Somehow I feel that Morfik's solution is still incomplete. There's must be something missing, though I don't know for sure what it is.

Another effort is ExtPascal, but I think it's still in its fetus phase, looong way before it's ready for serious web app development tool and compete with the big boys' toys. If we're really serious about this, we should join the project and help the development.

-Bee-

Michael Van Canneyt wrote

Not to mention that it is inherently much safer than PHP.

In what sense?
I prefer ObjectPascal, of course! But I want understand your point.

Marcos Douglas

Oh my goodness yes! Eclipse and NetBeans...I'd rather swap out my 2-ply for 20 grain sandpaper. Big, bloated, resource intensive IDE's. When I was working on the Flex UI for my framework, I had to use FlexBuilder (now FlashBuilder) and while it wasn't the worst of the Eclipse plugins I've used, it did take like 200 MB of memory just sitting there.

Personally a good IDE for me would consist of a good editor. I've tried some out there like Notepad++ which is ok, but settled down to using PSPad on Windows. Lazarus might be a good candidate if there was an easy way to plug in suggestion/autocomplete datas specific to JS frameworks.

My vision is to have an IDE with a great editor and editor features but also visual designer like GLADE# where its more like a View Builder and produces views which are decoupled from any model.

I agree. This is one reason for working with Pascal.

Marcos Douglas

Bee Jay wrote

(...) EXACTLY! That's why I hate web app development in the first place. After more than 10 years being spoiled by Delphi and then Lazarus, writing web app today is like back to those TP days. Morfik had been trying to solve this very issue, but I don't think it's ready for the prime time yet. Somehow I feel that Morfik's solution is still incomplete. There's must be something missing, though I don't know for sure what it is.

+1!

Marcos Douglas

El mar, 18-05-2010 a las 12:37 -0400, Lee Jenkins escribi?:

Lazarus might be a good candidate if there was an easy way to plug in suggestion/autocomplete datas specific to JS frameworks.

Mmm, no, not for me. If you need to mix Pascal and JS there's something wrong in your design.

My vision is to have an IDE with a great editor and editor features but also visual designer like GLADE# where its more like a View Builder and produces views which are decoupled from any model.

For ExtJs you can use Ext Designer, very similar to what GLADE does. Then hook you server side logic by using JSON created on the fly by your Delphi/Lazarus/FPC application.

Lee Jenkins wrote

Personally a good IDE for me would consist of a good editor. I've tried some out there like Notepad++ which is ok, but settled down to using PSPad on Windows.

Did you try http://spket.com/ ?

Luiz

2010/5/18 Luiz Americo Pereira Camara :

Hi

I think Geany is a very good editor too (it is almost multiplatform). As good as Notepad++. Also, you could try Notepad++ /wine on GNU/Linux.

Gustavo

ps: We (Lazarus/Freepascal users) can say with pride that our apps are REALLY multiplatform. All along the stack, from desktop GUI to web apps.

No, but I'll check it out. Thank you.

If its java based, I can probably rule it out already...

W dniu 2010-05-18 18:10, Bee Jay pisze:

I can say quite different. I like web development. From back side of program working with web and desktop is equal, thats doesn't matter. But front makes me happy: When I need new widget for special purpose, I must: write new descent class (several lines in pascal), 2-4 line of html (several divs), then add several lines to CSS and add some png and thats all. I dont need fight with any pixels, rendering, etc, all this work has done in browser, debugging can be done online (with firebug)

Well...
After it properly worked (inserted a ApplyUpdates and a Refresh), I removed the SQL I created myself. And yes, it works. What I think happened is that because the id wasn't shown, my impression was that things didn't work. I also want the new record to show in a form. I found information on using SQL statements, which set me on the wrong path. Eventually I found the bug report and saw in it the confirmation that I wasn't the only one with the problem. Making the new autoincrement id visible immediately after inserting or appending a record, would solve confusion. However, I.understand the difficulty in implementing that.

Albert

Nothing, I've done so in 2 of my 3 fulltime jobs.

The point was that when doing it, if you have problems competing with PHP, then I suggest you need to change your angle.

Examples:

in the first job I did a webfrontend (using indyhttpserver +SSL) multi dimensionally analysing realtime data.

in the second job, for a vendor of webbased auction systems, it was paramount that never outdated data was shown, so caching of any critical data was not allowed unless you could guarantee it was up to date. (used component and scripting/templating system: webhub, www.href.com)

IMHO PHP can't compete with Delphi (or e.g. C#/ASP.NET) on the website either. It is the bottom segment only.

I knew that these people

http://href.com/webhub:2126869336

were working on a FPC port a year back. IIRC they support both IIS and Apache.

Also have a look at similar Delphi products (there must be at least a handful) that might have developed a FPC port meanwhile.

2. Performance is really poor. We built a small FPC native Linux solution for doing multi-million row set processing and found a 25x speed improvement with it doing its work vs. PHP native. There is no doubt that FPC is a better option for the end code here.

That is very strange.

and/or migration option than PHP.

Once NativeClient (http://code.google.com/p/nativeclient/) gains its popularity (and all browsers would have NativeClient) All scripting languages would be outdated, leaving its place for native compilers, like FPC (gcc and etc).

The interesting thing is FPC is NativeClient ready (since x86 and ARM) platforms are supported. However RTL needs to be prepared for NaCl.

thanks,
dmitry

If I read this, nativeclient seems to be more RIA oriented than web oriented.

Google is the only one pushing it, and it is mostly its own browser on 3 OSes on two and an half architectures.

Doesn't sound as it ever is going to be ubiquitous enough to challenge e.g. javascripts position.

However RTL needs to be prepared for NaCl.

A salted RTL? ;-)

DoDi

Marco van de Voort wrote

If I read this, nativeclient seems to be more RIA oriented than web oriented.

What is RIA?

thanks,

Rich Internet Application.
http://en.wikipedia.org/wiki/Rich_Internet_application

Marcos Douglas

Hi Felipe,

"Rich Internet Application"

http://en.wikipedia.org/wiki/Rich_Internet_application

All the kids are doing it.

This has huge potential and is something we are super interested in working with if there is the ability to construct a native application in FPC that can run in native client.

Is anyone working on this at the moment? I think Dmitry is completely right - something like this removes much of the need of hacking the browser with AJAX if native code can execute within the browser. The Google videos are really great to demonstrate performance and how this all fits in.

Of course its unlikely it will run on iPads or iPhones, but I suspect I can live with that. We have a client who is asking us to develop some vertical apps specific to an application where users carry around such a device, but it needs native support and I'm not willing to take on developing for iPads based on Apple's current management practices.

Myles

The problem is not competing with it, the lack of Delphi developers forces company owners to find other employees, as PHP sounds trendy, to them it doesn't matter if you can do things better if they can't replace you easily, most of my colleagues are Delphi programmers but when it comes to web stuff none of them would do anything web related and if they must do it they would probably chose PHP, i was fortunate enough to be able to write a major app in Delphi and initially compiled with FPC too but then they forced the project to use MSSQL and we were stuck on windows.

Well our project was a web interface with the same functionality as the self-serving kiosks from a well known fast-food company. The project was a real success but at the moment political decisions reduced the level of allowed implementation but allowed us to deploy more kiosks (go figure). Because i was the only Delphi developer who would use it for a serious web project, minor parts had to be done by another colleague in PHP. Since then all web projects (smaller reporting type) were made in PHP because there was nobody available to do them in Delphi.

IMHO PHP can't compete with Delphi (or e.g. C#/ASP.NET) on the website either. It is the bottom segment only.

Yes PHP is not a strong language and doesn't have a strong toolkit but there are so many PHP developers and many 3'rd party tookits for it and some of them can be used with any language. Most company owners only care about getting things done, i was lucky and nobody ever forced me to do anything serious in PHP, i did work with JS, Flash and SwishMax all three are almost the same thing and much nicer than PHP but i wouldn't use any of these for anything serious unless i was forced to.

Razvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100520/5a0f21e1/attachment-0001.html>

This is a really good point, and I wanted to add to it. Web applications typically have an extremely small 'shelf-life'. Although there are plenty of PC desktop apps developed in the 1990s that have been maintained, updated, etc. and are still in wide use today, there are not too many examples of web applications that share this. Most either died a natural death, or were completely re-developed, or had major facelift changes, etc.

Because web applications are highly visual media, then trends in graphics design, social culture, etc. all affect what is a 'cool' web app in ways far different to PC applications. If you, for example, are looking to purchase something online and you go to a site that looks like it was developed in 1995, there is a natural reservation of how serious the company is. Web apps expose not only technology to the end user, but a sense of commitment that the developer has to current technologies, etc. And since its a highly competitive environment, companies are constantly spending big bucks to update their websites, web applications, etc. assuming that they might get 1-2 years of use out of that development phase before having to do the whole thing all over again.

In this world, investing in rock-solid, fast performing tech has to be compared with limited return on investment, and fast changing technologies that the end users are using to view it. In this regard, PHP has a lot to be said for it. Sure, its not as 'sexy' a development environment as Delphi/FPC, etc. but the end result of a web application is typically a short lifespan, so investing heavily in both time & $ to get the site done 'right' often has limited return on investment.

Now that isn't to say that you should abandon all hope of doing web application development in FPC. Quite the contrary, but using languages like PHP in partnership with FPC seems, to me, to be the best fusion. FPC on the back-end, but working with PHP/HTML5 on the front-end. High availability of developers in PHP, so you can handle turn-over easily. And generally shorter development cycles.

Thoughts?

Myles

2010/5/20 Razvan Adrian Bogdan :

That is my problem too... and, maybe, a lot of developers around in the world.

Marcos Douglas

But PHP is back-end too.
I do not think a mix of languages is the best way. Theoretically, PHP and FPC do the same things so, why I use 2 languages? Who connects to the DBMS, e.g. ?

Maybe use a language for other thing, like configurations, layouts, etc. A script language has advantages for that. I think Lua[1] language is a great option.

[1] lua.org, keplerproject.org

Marcos Douglas

Marco van de Voort wrote

If I read this, nativeclient seems to be more RIA oriented than web oriented.

Yes, horsepower and safety, 2 in 1 just like your shampoo and other cleaning products. (Ajax, Comet, anyone ?)

Google is the only one pushing it, and it is mostly its own browser on 3 OSes on two and an half architectures.

Not really, Mozilla is working hard to add support for NaCl, i accidentally stumbled upon a document describing how it should be implemented, i assume everyone would love this and Firefox is already a powerful and respected browser, they even have some mobile version (forgot the name).

Doesn't sound as it ever is going to be ubiquitous enough to challenge e.g. javascripts position.

Sooner than we think, even sooner than WebGL, O3D and other funky technologies meant to replace Flash and Silverlight. It needs a nice language and compiler before it becomes popular, i think few people would write web apps using gcc, probably only game companies.

Razvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100520/3a052527/attachment.html>

PHP connect without problems to FPC and any other web technology, we had to do it in our project, PHP can run executables and return values, it's easy to redirect from on technology to another passing parameters between them.

Maybe use a language for other thing, like configurations, layouts, etc. A script language has advantages for that. I think Lua[1] language is a great option.

LUA is becoming more popular and it's syntax is closer to Pascal, i even think Pascal could learn a few things from LUA (like making begin optional :)
LUA is getting large frameworks but it has too many differences between versions 5.0 - 5.1

Razvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100520/e90a99d3/attachment.html>

I don't think FPC is well known for doing web stuff, whereas PHP is. If i didn't already know about Delphi/FPC I would never have chosen it for the web. web hosts advertise that you can use PHP/ASP/Perl/Ruby or CGI - no mention of Pascal, C, etc.

It's also very easy to get a website running with Drupal or Wordpress - which webhosts also advertise.
What we need is a Drupal/Joomla/Wordpress built in FPC - PascalCMS :) What would the 'killer app' of it be though??? speed? reliability? community?

Personally, I use Drupal for full websites. You start off with enough for a blog, and can disable and enable modules easily. Something similar with pascal would be nice - but theres a lot of catching up to do. In fact, I'd recommend starting from Drupal, and replacing the slow bits with Pascal first (much like Linus/GNU replaced UNIX piece by piece. Would we reinvent TinyMCE, FCKEditor, phpBB?

But I've came back to Pascal for a few small things because I needed to process csv files with millions of rows, and wanted it done FAST.

A VERY important element of this would be that you DO NOT share binaries - you MUST share .pas files. when installing/enabling a module PascalCMS calls fpc to compile it. That way webhosts start encouraging use of Pascal as well as PascalCMS - and the code gets compiled for the processor the host is running.

We also need to make use of the many freely available themes/templates out there (drupal, wordpress, joomla, etc themes) - pretty looking PascalCMS websites will attract the masses :) Artisteer is theme making software, i don't really like its themes that much, but we should still be compatible with it too.

Just my thoughts :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100520/97c0c436/attachment.html>

2010/5/20 Razvan Adrian Bogdan :

PHP connect without problems to FPC and any other web technology, we had to do it in our project, PHP can run executables and return values, it's easy to redirect from on technology to another passing parameters between them.

Well... I do not knew PHP connects so easy at other tecnologies. I did not use PHP so much... but I still do not like it :P

LUA is becoming more popular and it's syntax is closer to Pascal, i even think Pascal could learn a few things from LUA (like making begin optional :)

Yeah! I agree :)

LUA is getting large frameworks but it has too many differences between versions 5.0 - 5.1

Differences between versions will always exists.

BTW, the correct name is Lua, not LUA ;)
PS: Lua is a word in Portuguese that mean Moon in English. Is not an acronym.

Marcos Douglas