Hi all,

I saw fpWeb has potential to be known as a good web framework for pascal language. But, I also saw it's too heavily tighted with FPC infrastructure. Can we make it more independend so it can also be used by Delphi? I think it could make pascal more known to the web developers crowd out there.

-Bee-

I don't think we will do this. It will require too many changes.

Michael.

:(

Marcos Douglas

El jue, 27-05-2010 a las 09:44 -0300, Marcos Douglas escribi?:

Well, is not that sad, the code is in the repositories, anyone can adapt it to Delphi, it just requires time and brain!.

2010/5/27 Leonardo M. :

Well, is not that sad, the code is in the repositories, anyone can adapt it to Delphi, it just requires time and brain!.

But if the Michael Van Canneyt, developer of fpWeb, said "require too many changes" I think it is not so easy do that.

Marcos Douglas

Michael Van Canneyt wrote

I don't think we will do this. It will require too many changes.

Plus, Delphi includes it's own web developer tools already. Adding fpWeb will just be duplication of what they have and paid for.

Bee Jay wrote

Can we make it more independend so it can also be used by Delphi? I think it could make pascal more known to the web developers crowd out there.

Making an open source project's components easy for others to extract and use on competing platforms seems counter productive to me. FPC offers operating system independence... Delphi does not.

Most if not all community efforts should be placed on developing and securing our own platform. Not others - especially closed platforms like Delphi.

I agree but the Bee's thought "it could make pascal more known to the web developers" it is right too.
if Delphi developers could use fpWeb on Delphi they would approach the FPC as well.

Marcos Douglas

I agree but the Bee's thought "it could make pascal more known to the web developers" it is right too. if Delphi developers could use fpWeb on Delphi they would approach the FPC as well.

True. But the real boost will be in projects using FPC/Lazarus. Word of mouth testimony from projects is key. Having one or two successful (widely adopted) open source projects that require FPC/Lazarus will most likely clinch it.

Moreover Delphi is a versioned. I don't think picking whatever single version (say oldest or D7) will make everybody happy.

True.

Marco van de Voort wrote

Moreover Delphi is a versioned. I don't think picking whatever single version (say oldest or D7) will make everybody happy.

True.

Both are correct.

Marcos Douglas

No, they will still use Delphi, because the advantage of fpc (in this case fpWeb) is gone, because Delphi also supports it.

Fpc is free, you can use it anywhere. I see no reason to support Delphi.

Joost.

Marcos Douglas wrote

if Delphi developers could use fpWeb on Delphi they would approach the FPC as well.

Why? It it works in Delphi they don't need to switch from Delphi. :-/

FPC already tries its damnedest to be Delphi compatible - maybe it's time Delphi tries to be FPC compatible. Let them do the work for a change.

Hi, just updated my fpc from svn and noted a bunch of new examples were added to packages/fcl-web/examples/webdata. I can't build none of them.

For example, the first, in directory demo has a unit called "wmusers.pp" which uses "fpwebdata, fpextjs,extjsjson,extjsxml". Where can I find these units?.

Also, in demo6, a package named LazWebdata is needed, I don't have it :(.

FPC already tries its damnedest to be Delphi compatible - maybe it's time Delphi tries to be FPC compatible. Let them do the work for a change.

A couple of things may have escaped the conversation...

As of the current shipping version of Delphi, its Windows only. Sure, there is something in the works out there for cross-compiler, etc. but its not here yet. Its one thing to have a web enabled application, but its another thing to host it. And with the vast majority of the cheap web hosting companies out there running on Linux, FPC is really the only option for this. Delphi developers know this - if they want to deploy their web based solution cheaply, FPC is the best way to go for them.

The problem, however, isn't about trying to bring Delphi peeps over to FPC because of fpWeb. They'll get that. The problem is finding Web Hosting companies that will let you deploy CGIs on their servers, without forcing you into the VPS product line. VPS are coming down in price, but the success of languages like PHP really comes down to willing and available low priced web hosting companies and I don't think you are going to be able to offer a solution competitive with PHP that can run on a $5 a month host. If there is an option for this, we need to promote that to the Delphi folk (and the existing FPC community), but I haven't found one yet that doesn't require a Linux sysadmin level of user to work with, or is seriously restricted in bandwidth/disk, etc.

So big thumbs up to FPC for having a Linux based option to deploy solid web solutions. But find a web hosting solution you can deploy it on might be a more important challenge to overcome than bringing more Delphi people over who will find the exact same business issue when they get here.

Myles

These units are all in fcl-web/src/webdata. Just add that to your path.

Also, in demo6, a package named LazWebdata is needed, I don't have it :(.

I am currently considering how to do this.

Normally, the lazweb package should be extended with these units. But this means the lazweb package is only usable with subversion fpc 2.5.1.

The alternative is to keep the Lazwebdata package, and submit that to the Lazarus team. But I would rather avoid this: there is no good reason to keep it in a separate package, as it is an integral part of fcl-web.

It would be good to have support for enabling/disabling features in packages :(

For the time being: add the fcl-web/src/webdata directory to the project units dir, and delete the dependency on lazwebdata.

That's what you get for wanting to test cutting-edge development, it's still a bit rough around the edges ;-)

Michael.

El jue, 27-05-2010 a las 17:10 +0200, Michael Van Canneyt escribi?:

These units are all in fcl-web/src/webdata. Just add that to your path

Sure? I don't have this directory, I only have fcl-web/src/base. I'm updating from trunk, fpc 2.5.1.

The issue is independent of Delphi/Free Pascal.

There is no solution for this using any compiled technology. Not even .NET code will help you with this, if the hosting company only offers PHP.

Michael.

Sorry,

forgot a commit :/

Fixed in rev 15334.

Michael.

Same holds for the webdesign packages. But I decided to keep them out of the fpc-repository. The fppkg package manager can help here in the future.

Joost

El jue, 27-05-2010 a las 17:22 +0200, Michael Van Canneyt escribi?:

Thanks.

For .NET is more easy found low cost servers... maybe because have a VM with GC so, more "security" for the server.

Marcos Douglas.

make clean all does not compile fpc 2.5.1 anymore ... it gives some error while cleaning the new folders (fcl-web)

Horacio

El 27/05/2010 12:22, Michael Van Canneyt escribi?:

This was reported, fixed and Committed in revision 15335 ?

If the error persists, let me know.

Michael.

Now I get:

Fatal: Can't find unit ssockets used by fcgigate
Fatal: Compilation aborted
make[5]: *** [fcgigate.ppu] Error 1
make[5]: Leaving directory `E:/lazarus/freepascal/packages/fcl-web/src/base' make[4]: *** [fpc_smart] Error 2
make[4]: Leaving directory `E:/lazarus/freepascal/packages/fcl-web/src/base' make[3]: *** [src/base_smart] Error 2
make[3]: Leaving directory `E:/lazarus/freepascal/packages/fcl-web' make[2]: *** [fcl-web_smart] Error 2
make[2]: Leaving directory `E:/lazarus/freepascal/packages' make[1]: *** [packages_smart] Error 2
make[1]: Leaving directory `E:/lazarus/freepascal' make: *** [build-stamp.i386-win32] Error 2

Horacio

El 27/05/2010 13:10, Michael Van Canneyt escribi?:

Marcos Douglas wrote

For .NET is more easy found low cost servers... maybe because have a VM with GC so, more "security" for the server.

I don't see how how it could be true. The largest brazilian web hosting, Locaweb, offers CGI support for it's cheapest plan, which is 29 reais / month for an unlimited storage space:

http://www.locaweb.com.br/produtos/hospedagem/comparacao-planos.html

http://www.locaweb.com.br/produtos/hospedagem.html

Myles Wakeham wrote

The problem is finding Web Hosting companies that will let you deploy CGIs on their servers, without forcing you into the VPS product line.

Locaweb supports CGI for 16 dollars a month. Considering the cost of developing a website I really can't see how the extra 11 dollars per month would be meaningful.

Should be fixed now in rev 15336.
(ssockets is in fcl-net, and not in fcl-base :/ )

Michael.

El jue, 27-05-2010 a las 18:57 +0200, Felipe Monteiro de Carvalho escribi?:

The same here in Argentina, HostRentable.com.ar offers an ar$ 5.00/month plan (1 euro approx) with CGI support.

El jue, 27-05-2010 a las 19:00 +0200, Michael Van Canneyt escribi?:

Michael, I'm on 15336 and the error is still here. I completely removed my FPC sources, and id a new checkout, make all, but the error persists.

+1. I agree with you.

I use FPC-Lazarus on Linux, i.e, Delphi never make me foolishly. :P

Marcos Douglas wrote

I agree but the Bee's thought "it could make pascal more known to the web developers" it is right too. if Delphi developers could use fpWeb on Delphi they would approach the FPC as well.

Or not. Who could guarantee that the Embarcadero not copy and close the source? Unless you want to do a project closed. (a m$-fpweb-non-free :P )

Marcos Douglas

I agree. Is already conquered. See the sum of downloads of Lazarus at Source Forge. If there is a way, see how many acesses in the SVN of Lazarus.

Joost van der Sluis wrote

No, they will still use Delphi, because the advantage of fpc (in this case fpWeb) is gone, because Delphi also supports it. Fpc is free, you can use it anywhere. I see no reason to support Delphi.

+1.

Joost.

Yes! :)

Imagine fpWeb with code for Delphi. This will only augment the project.

The people of Delphi that will make a way for them, and do not trying to change the FPC. :P

Hi,

I added the dependency apparently in the wrong directory. It's hopefully OK in rev. 15338?

Michael.

El jue, 27-05-2010 a las 22:40 +0200, Michael Van Canneyt escribi?:

Yes, it works now. Thanks!.

Hello Lazarus-List,

you wrote

> FPC already tries its damnedest to be Delphi compatible - maybe it's > time Delphi tries to be FPC compatible. Let them do the work for a > change.

s> Yes! :)
s> Imagine fpWeb with code for Delphi. This will only augment the project. s> The people of Delphi that will make a way for them, and do not trying to s> change the FPC. :P

The better that you could get is a completly incompatible spin-off in 1,2 months.

The fpWeb (and the rest od the fcl) license does not allow that.

Joost

It can I think. If it only distributes binaries, that is allowed per copying.fpc

It is just that if they distribute the (modified) sourcecode (e.g. in the sources installed with Delphi), people can just freely redistribute that sourcecode. (but that is a I think, not a fact)

Michael Van Canneyt wrote

I don't think we will do this. It will require too many changes.

Yes, I've seen the code. fpWeb has a very tight dependency to other fcl packages. Poor Delphi people. ;)

-Bee-

serve's'em right... what's that old saying? ya get what ya pay for? i think getting a whole lot more for free is much better... wonder what it costs to get the full sources to delphi? :lol: :P

Joost van der Sluis wrote

The fpWeb (and the rest od the fcl) license does not allow that. Joost

Oof ^^'

Note that one can always port a certain package from time to time. I do this with many FPC packages that I use at work (lazarus' XML e.g.)

where everybody gets the idea that Delphi does not provide web frameworks, I don't get. Websnap, other frameworks, standard Apache mod projecttypes (templates) for 1.3, 2.0 and 2.2, CGI...

and that was just in D7 already!

God (and Delphi 2010 buyers) know(s) what they have in there nowadays!

On the other hand, why anybody would want to develop new webapps (on new db's) in delphi or fpc for that matter seems a bit like a one-tool-in-my-toolbox mindset. "If all you have/know is a hammer, every problem looks like a nail."

There are other languages far more suited for webdevelopment! PHP, Perl, Ruby(-on-rails), java, silverlight.net, ... Especially when the client(s)/user(s) use small webhosting. While you may find that they offer php AND CGI, you may not find out the (processor)architecture or flavor of linux so that you even CAN compile your CGI, let alone run it safely on the hosting provider's machine(s). You only sometimes have (a somewhat limited) shell access to their machine anyway. And as for a "product", you need to use the greatest common denominator anyway. So that pretty much leaves you with php anyway ;-)

And there IS a Delphi4PHP out there (from Embarcadero/CodeGears/Borland/Inprise/...). It is a graphical designer like Delphi (the IDE, not the object pascal language) that allows you to make RAD like a php application with a frontend in javascript, based on the Qooxdoo open source framework. In fact, they have re?mplemented a large part of the VCL in javascript so that you can transfer your skills in Delphi VCL (the objectpascal framework) to there without knowing much javascript.

ps: sorry for the response to multiple mails over the last couple of days ps2: and since i read digests, this mail will occur out-of-thread, sorry for that too :-(

Dimitri Smits

Dimitri Smits wrote

and that was just in D7 already!

Does it support Linux? Kylix? What about 64 bit servers? :P

God (and Delphi 2010 buyers) know(s) what they have in there nowadays!

Are they using those tools? No? Why?

On the other hand, why anybody would want to develop new webapps (on new db's) in delphi or fpc for that matter seems a bit like a one-tool-in-my-toolbox mindset. "If all you have/know is a hammer, every problem looks like a nail."

I don't think so. If I need to migrate desktop apps -many of them with thousands if not millions LOC- into web apps, why should I rewrite them in a another language from scratch? So I need to retest the whole thing over again from the beginning? While I could simply change the desktop form into web page and keep the app logic untouched, well... at least most of them. Even if I need to write to a new fresh web app, why should I learn new language and framework while I could write it in pascal (more effective and efficient thus more productive) using existing and my well-tested pascal frameworks and skills? Learning a new syntax is easy but finding its tidbits does need times.

There are other languages far more suited for webdevelopment! PHP, Perl, Ruby(-on-rails), java, silverlight.net, ...

Why are they more suited? Because most of them are scripting and managed/VM with poor performance? Why do you think pascal isn't suited for web app development?

Especially when the client(s)/user(s) use small webhosting. While you may find that they offer php AND CGI, you may not find out the (processor)architecture or flavor of linux so that you even CAN compile your CGI, let alone run it safely on the hosting provider's machine(s).

It's not hard to ask the provider about those informations, or even maybe they're already mentioned somewhere in the docs.

You only sometimes have (a somewhat limited) shell access to their machine anyway. And as for a "product", you need to use the greatest common denominator anyway. So that pretty much leaves you with php anyway ;-)

To deploy a CGI app is simply upload it to cgi-bin folder, nothing fancy. CGI support is standard feature on common web hosting anyway.

And there IS a Delphi4PHP out there (from Embarcadero/CodeGears/Borland/Inprise/...). It is a graphical designer like Delphi (the IDE, not the object pascal language) that allows you to make RAD like a php application with a frontend in javascript, based on the Qooxdoo open source framework. In fact, they have re?mplemented a large part of the VCL in javascript so that you can transfer your skills in Delphi VCL (the objectpascal framework) to there without knowing much javascript.

Spend more dollars for an unfinished product? :P I don't mind spending my money on a dev tool. But it doesn't count a out-dated buggy ones.

Frontend UI is just a part of web app. Using advance JS UI framework i.e. qooxdoo, extjs, isn't hard too. You just need to learn how to use it to build your UI, no need to learn all JS programming aspects. In some ways, they're just replacement of .dfm/.lfm files.

-Bee-

Dimitri Smits wrote

where everybody gets the idea that Delphi does not provide web frameworks, I don't get. Websnap, other frameworks, standard Apache mod projecttypes (templates) for 1.3, 2.0 and 2.2, CGI... and that was just in D7 already!

No Linux support. No FreeBSD support. No 64-bit support!

There are other languages far more suited for webdevelopment! PHP, Perl, Ruby(-on-rails), java, silverlight.net, ...

I have to disagree here. Object Pascal seems like a much more suited language for web development. I can use anything from the RTL, FCL, OPF frameworks and Object Pascal language features like inheritance, interfaces etc. - exactly the same as I can in my desktop counterparts. I can reuse the skills of all my developers without having to retrain them in Java, PHP (which version) etc.. We have years and years of Object Pascal code in our toolbox that we can now reuse for the web apps.

Oh, and lets not forget that a binary CGI apps runs circles around PHP apps when it comes to speed.

Usually only in the more expensive editions. I'd have to fork out EUR1000 or so to update my radstudio pro for that one web-related project once in a while.

But there is a point that there are 3rd party vendors. I've used them in the past. They are good, cheaper and more flexible.

On the other hand, why anybody would want to develop new webapps (on new db's) in delphi or fpc for that matter seems a bit like a one-tool-in-my-toolbox mindset. "If all you have/know is a hammer, every problem looks like a nail."

One could also say the same about PHP.

There are other languages far more suited for webdevelopment! PHP, Perl, Ruby(-on-rails), java, silverlight.net, ... Especially when the client(s)/user(s) use small webhosting.

Java, silverlight.net on small hosting? Less than CGI?

Ruby is even more an white elephant. NEver saw a commercial hoster offer RoR. (sure if I go to the Ruby site I find a few), but it is not THAT mainsteram.

< While you may find that they offer php AND CGI, you may not find out the (processor)architecture or flavor of linux so that you even CAN compile your CGI, let alone run it safely on the hosting provider's machine(s).

The chance that the hoster's CPU is FPC compatible, the hoster allows CGI is vastly higher than a small hoster supporting silverlight.net, even fullblow Java J2EE, Perl or Ruby.

That leaves PHP. Which is good for small stuff, but I wouldn't like having it write to mission critical databases. PHP is only used for small potatoe and frontends. (leaving a service to do the real work).

Therefore I think Delphi/FPC is more a competitor for C#/Java application servers on larger hosting offerings. But if you are doing it already, why not use it for small stuff too?

You only sometimes have (a somewhat limited) shell access to their machine anyway. And as for a "product", you need to use the greatest common denominator anyway. So that pretty much leaves you with php anyway ;-)

It leaves you with an account not suitable for any development, only for hosting existing PHP packages with minor extensions. But that is a different discussion (PHP is counted as web development language while often only existing packages are installed)

And there IS a Delphi4PHP out there (from Embarcadero/CodeGears/Borland/Inprise/...).

So? Totally unrelated product.

the Qooxdoo open source framework. In fact, they have re??mplemented a large part of the VCL in javascript so that you can transfer your skills in Delphi VCL (the objectpascal framework) to there without knowing much javascript.

What I have seen from it, if you have a need THAT leve of similarity, you were never a Delphi programmer to begin with :-)

It's trivial. Even the other ugly ducking in the stable, Oxygene/Prism is more elegant and compatible. (and that says a lot coming from me)

Intranet, which existed in D5 days already.

The idea that this has anything to do with the language is a fallacy.

There are no inherent concepts in Ruby, Python PHP that make them inherently better than pascal, other than that they are a) interpreted.
b) are delivered by default with the OS.
and these have nothing to do with the language by itself.

I know (Object) Pascal for 25 years. I solve problems in no time using this language, because over 25 years my toolbox is well stacked, and I continuously improve mysel.

The web is just another a problem I also wish to tackle using this toolbox.

If I had to buy a new toolbox for every new problem, I would have been bancrupt a long time ago.

Michael.

I know (Object) Pascal for 25 years. I solve problems in no time using this language, because over 25 years my toolbox is well stacked, and I continuously improve mysel.

Yes. Why start from scratch over and over again with new languages if it's possible to use a well known language?

Michael Van Canneyt wrote

If I had to buy a new toolbox for every new problem, I would have been bancrupt a long time ago.

Most non-developers people usually think that something that is sooo popular, then it must be the best. Which is another fallacy, I suppose. Unfortunately, some developers think that way as well. ;)

-Bee-

Bee Jay wrote

On 30 Mei 2010, at 07:30, Dimitri Smits wrote: > On the other hand, why anybody would want to develop new webapps (on new db's) in delphi or fpc for that matter seems a bit like a one-tool-in-my-toolbox mindset. "If all you have/know is a hammer, every problem looks like a nail." I don't think so. If I need to migrate desktop apps -many of them with thousands if not millions LOC- into web apps, why should I rewrite them in a another language from scratch? So I need to retest the whole thing over again from the beginning? While I could simply change the desktop form into web page and keep the app logic untouched, well... at least most of them. Even if I need to write to a new fresh web app, why should I learn new language and framework while I could write it in pascal (more effective and efficient thus more productive) using existing and my well-tested pascal frameworks and skills? Learning a new syntax is easy but finding its tidbits does need times.

this is especially important when it comes to things like properly filtering user input, too... in many (most? all?) cases, this has already been done and properly handled in a binary app... in fact, properly handling user input been one of the biggest problems with many apps, period... surely no one really names their child '); DROP TABLE Master; ;)

> There are other languages far more suited for webdevelopment! PHP, Perl, Ruby(-on-rails), java, silverlight.net, ... Why are they more suited? Because most of them are scripting and managed/VM with poor performance? Why do you think pascal isn't suited for web app development?

i don't know of any reason why it isn't suited... it isn't any different, really, than those other languages... it has surely been vetted a lot more and over a longer time than they ;)

> Especially when the client(s)/user(s) use small webhosting. While you may find that they offer php AND CGI, you may not find out the (processor)architecture or flavor of linux so that you even CAN compile your CGI, let alone run it safely on the hosting provider's machine(s). It's not hard to ask the provider about those informations, or even maybe they're already mentioned somewhere in the docs.

not to mention how easy it is to go to another provider or even just host it yourself ;) :P

Hi, just ugraded FPC to rev 15347 and found this:

In Lazarus, when I start a new CGI App, and double click on the web module to invoke the OnCreate editor, this error appears:

main.pas(8,79) Error: source not found:
unit /usr/local/lib/fpc/2.5.1/units/x86_64-linux/fcl-web/fpweb.ppu

But the file is there, maybe it is referencing another unit inside fpweb.ppu?

El dom, 30-05-2010 a las 12:30 -0300, Leonardo M. Ram? escribi?:

BTW, a workaround is to point the project search path to the fcl-web/src/base dir.

The files have moved. Do a 'Rescan FPC directory' from the 'Environment' menu, that should fix it.

Michael.

The other day I was showing Lazarus to an friend (a Delphi fanatic) to let him know how it was improved since the last time he looked at it, he spend the whole afternoon working with it, and he was amazed. The only thing he didn't like about it was this:

"When I place a control over a form or datamodule, the focus is automatically changed to the editor window.".

I can't reproduce it in the last revision, but I remember I faced the same issue in a Windows box (now I'm on linux).

Is this a configurable option?, a bug?.

Marco wrote

That leaves PHP. Which is good for small stuff, but I wouldn't like having

it write to mission critical databases. PHP is only used for small potatoe and frontends. (leaving a service to do the real work).

Huh? Ever heard of Facebook? Or SugarCRM? They are PHP apps. And PHP is not a front-end solution. It runs on the server, not the client. I think you are confusing it with Javascript/HTML/AJAX, etc. all of which work with any back-end code (PHP, Perl, ASP, or FPC CGIs).

I have PHP applications in production with large user communities (ie. > 1,000) and they perform exceptionally well. I do also have FPC CGI's running for doing intensive file handling alongside of them and yes, it does outperform for those applications. But by the time I lose all my PHP extensions, frameworks, Smarty, etc. it would take me 3-4x the development effort to construct a web solution in FPC than in PHP.

There's a place for both technologies and they can work exceptionally well together, but please don't underestimate what PHP can (and has done) in web development circles.

Myles

plus it has its own problems and foibles... the first i ran headlong into was which server to use... i use apache but RoR wants to use its own server... it was ok while i dabbled with it during developing a few minor things to see how it would go but i was unable to then move those apps to my apache server and get them operational in a "deployed" environment...

the task i was looking at should easily be handled with a RAD environment... heck, it was only hooking into a database with several tables linked by a couple of "ID codes" (what i know of as a relational database) and a minor bit of math on a few of the numbers... the worst part would be the handling of transactions and inventory moving in and out... i couldn't even get started on it in RoR... since i have a pascal background, a friend pointed me at Lazarus and FPC... i still haven't gotten that app doshed up due to the various problems i ran into with connecting to a database, trying to use the tabbed notebook (i like the look and feel of it), and other sundry problems that a console only coder runs into when attempting to move to a GUI environment... groking the OOP stuff isn't that bad for me since i was exposed to it when it first appeared back in TP/BP 6 but it is still "new" to me since i stayed with purely procedural coding all these years...

we won't even touch on whether or not to do a binary interface or a web interface or both... i definitely don't want to be junking up the works with a bunch of java, javascript, flash, sliverlight, or any of that other stuff that enlarges the surface area that may be attacked and compromised... as a security minded admin and coding geek, that's definitely something that i keep in mind all the time... indeed, it is why i refuse to run any of the popular CMS' for example... there's just too much that can and does go wrong...

additionally, i won't even mention that i've only been able to update to a newer version of Laz/FPC twice since i first took a look at it... why? because there's only been two releases since then... yes, i know why and i don't have a problem with it... i'm just thankful that there's something available besides delphi and that this something is cross-platform capable because that is very important... but i also eagerly await the next release with all these bug fixes and new features that i read about daily in this list...

And it could be that these files are copied, not moved. So that you have two versions of them, one in fcl-web/src and one in fcl-web/src/base (I had that problem)

Joost.

When I put the cursor on any word and type F1 then I always get an error like

"No help found for "..." at (18,18)"

I installed multiple versions of Lazarus in the past. Any ideas on how to fix this would be appreciated

Forget it. I already found it. I had to download the help files separately and set the path to them in the settings.

After I compiled a CGI app using fpWeb from fpc rev 15347 on Linux x86-64 I got this error message on the browser:

The application encountered the following error:
* Error: Could not determine HTTP module for request "cgi-bin"
* Stack trace:
$00000000004929D2
$00000000004932C0
$000000000045D04F

Any hint?

Such a bug was fixed a few days ago.

Mattias

El dom, 30-05-2010 a las 19:26 +0200, Mattias Gaertner escribi?:

Thanks! I'll tell to my friend.

I think don't forget about it. Simply putting some additional info to that messagebox that says "make sure you have the appropriate help files installed" maybe also giving some download url would make it faster to find the solution in such cases. Or say, make lazarus more user friendly :)

2010/5/30 J?rgen Hestermann

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100530/75af8279/attachment.html>

Yes, comment line 408 and 409 in custcgi.pp.

But maybe you could revert to a revision before r15322. There's changed a lot in that revision and it can have more regressions.

When you are new to fpWeb it's better to use a more or less stable revision. The current head of trunk isn't, imho.

Joost..

El dom, 30-05-2010 a las 20:21 +0200, Joost van der Sluis escribi?:

Yes, comment line 408 and 409 in custcgi.pp.

Could you show me what do you see in those lines? here in 408 is an "end;" and 409 is empty. Line 408 marks the end of this method:

Function TCGIRequest.GetFieldValue(Index : Integer) : String;

    25 : begin
         Result:=Decodevar(5); // Property PathInfo
//         If (Result='') then
//           Result:=Decodevar(34); // Property Request URI
         end;

Joost.

I think don't forget about it. Simply putting some additional info to that messagebox that says "make sure you have the appropriate help files installed" maybe also giving some download url would make it faster to find the solution in such cases. Or say, make lazarus more user friendly :)

Currently I have almost the same problem. Help for installing Help should be part of the distribution (exe or txt file), in case the help system is not yet also should have local IDE help sources, for every lazarus version. Just the IDE changed so much in the past, that help is either unavailable, incomplete or inappropriate (see Help on Project Options). The web resources are of little use, because they can cover only one (older) version, and searching in the wiki doesn't reveal much really useful, and related to the question :-(

DoDi

When your language is a kick ass swiss army knife on steroids for everything else under the sun, its easy to look first to what you already know and have at hand for the solution.

Is it more convenient with interpreted/jited languages to deploy your application? Sure. Would I like FPC apps to be that easy to deploy? Sure. Does it make a difference? Depends on the application I guess. If you're writing a shopping cart to sell to end users, I'd say yes. If you're writing an application in house or substantive enough to deserve a VPS account starting at $20.00 or a dedicated rack box for what, $100? I'd wager that a good portion of end user's web applications will stay on a inexpensive VPS of varying prices/horsepower as use goes up well before a dedicated rack server is required. If/when a rack server becomes necessary, I'd wager it will be a most welcome expense for you/your customer. Please remember to donate to worthy causes :-)

For micro customers:
http://www.webkeepers.com/vps/vps_compare.html

LinNode. Some gave me this link here or delphi groups: http://www.linode.com/faq.cfm

Dedicated:
http://www.hostingsource.com/advanced_server_plans.php

Hans-Peter Diettrich wrote

We also should have local IDE help sources, for every lazarus version.

I hope to release the final fpGUI v0.7 in a few days. At the same time I'll release pre-compiled INF help files for RTL, LCL, FCL, fpGUI and the FPC Language Reference. Included will be a Linux or Windows binary of fpGUI DocView (INF help viewer).

Integrating DocView with Lazarus (or MSEide) is a 30 second job - simply setting up a new External Tools item. No need to compile extra packages and recompile the IDE itself. DocView gives offline help and allows context sensitive help on units, classes etc or Object Pascal language syntax. DocView will search all help files (rtl, lcl, fcl, etc)in a directory in under a second - it's VERY fast.

I'll make an announcement of it's availability in the various mailing lists in a few days.

Myles Wakeham wrote

together, but please don't underestimate what PHP can (and has done) in web development circles.

In the same breath: Don't underestimate what FPC can (and has done) in web development circles. :)

Just because we don't brag (make noise or whatever you want to call it) about FPC as much as PHP developers, doesn't mean FPC CGI apps don't exist and are not deployed in large scale.

But do they write to mission critical databases? Where a wrong write will get you sued?

And PHP is not a front-end solution. It runs on the server, not the client. I think you are confusing it with Javascript/HTML/AJAX, etc. all of which work with any back-end code (PHP, Perl, ASP, or FPC CGIs).

No I don't. Frontend of the application server solution. Frontend is typically the customer facing part. It depends on what you take as customer, the person or the browser what exactly makes up the frontend.

does outperform for those applications. But by the time I lose all my PHP extensions, frameworks, Smarty, etc. it would take me 3-4x the development effort to construct a web solution in FPC than in PHP.

Fine. But you don't answer the question: do they handle (write) mission critical information directly to the database?

Myles Wakeham wrote

Huh? Ever heard of Facebook? Or SugarCRM? They are PHP apps.

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

Even facebook developers know that native app will outperform scripting on any cases. They ended up rewriting PHP RTL, extension, etc. They wouldn't need to invent HipHop if they created facebook using native solution since the beginning. ;)

-Bee-

Hah ! :-)

Bee, you didn't just make my day, you made my week. Thanks a lot !! :-)

Work on fcl-web will definitely continue with double effort :-)

Michael.

Michael Van Canneyt wrote

Hah ! :-)

LOL :D You had never heard of it, haven't you? :P

Bee, you didn't just make my day, you made my week. Thanks a lot !! :-)

You're welcome.

Work on fcl-web will definitely continue with double effort :-)

Glad to hear that. Let's make fpWeb a famous web development framework! ;)

Well... since the first day I knew web programming, I never believe scripting web app would perform equally, yet better, than native web app. It seems that I'm still correct. :) Pity facebook developers, they learned the lesson in a very hard way.

I never underestimate PHP role in web development though. But as Marco said, it's only good for small-to-medium web apps that doing nothing critical. Unless, you want to spend more money to upgrade your server machine. As Facebook had done before they started to invent HipHop. ;)

-Bee-

It is not that help that is the problem, it is the context sensitive help which is currently done by wiki.

Marco van de Voort wrote

It is not that help that is the problem, it is the context sensitive help which is currently done by wiki.

But with DocView and INF help files, I have solved the context sensitive help for Language Syntax, LCL, FCL, RTL etc.. The only help I don't have is for the various dialogs in the IDE itself (maybe this is what you mean?). That help unfortunately sits in a very crappy format and in the wiki only. Maybe one day we will have an export wiki to XXX format, where XXX is something more usable, like the XML format of fpdoc. Then just like fpdoc, we can write conversion units form XXX to CHM, INF, HTML, PDF, Man pages etc. which will allow end-users to have off-line help for everything.

Yes.

I guess 99% of the wiki text uses only 9 attributes (bold, italic, delphi, command, title 1-4, link, image, bullet and ordered list). That should be easy to parse. Of course you have to parse the source, not the html output.
Tables and translations could be tricky.

Mattias

All current help systems do that. But there is no source for the content.

Something like that. But first a decision must be taken how the data is kept (e.g. wiki or svn) etc, and if wiki, how to download it (the old helper app which used to dl wiki is currently no longer functional due to anti-spam software installed in the wiki)

(which means no crossreferencing to outside the wiki? What about the keys?)

That should be easy to parse. Of course you have to parse the source, not the html output. Tables and translations could be tricky.

How to obtain it? The helper app that Vincent showed me both didn't work, and V. said it was due to antispam measures installed on the wiki.

Is it possible from the inside (scenergy/idefix?)