[Lazarus] fpWeb and static content

[Joost van der Sluis]

On Tue, 2011-05-24 at 18:17 -0400, Lee Jenkins wrote:
> On 5/24/2011 4:21 PM, Joost van der Sluis wrote:
> > On Mon, 2011-05-23 at 22:47 -0400, Lee Jenkins wrote:
> >> On 5/23/2011 9:29 PM, ABorka wrote:
> >>>> What is the typical strategy to server up static content with fpWeb? JS,
> >>>> css files, given that its handler centric.
> >>>>
> >>>> Create a default handler that checks for file extension in the .PathInfo?
> >>>>
> >>>> --
> >>>> Warm Regards,
> >>>>
> >>>> Lee
> >>>
> >>> Why would you need fpweb to serve static content? Your web server does that.
> >>> CGI/FCGI and apache modules (fpweb) are to generate dynamic content.
> >>>
> >>> AB
> >>>
> >>
> >> Good question.  I want to deploy as an embedded server without the need to
> >> install apache, etc for small workgroups and so the I need to allow the server
> >> to server up a few key files which could be from the file system or embedded in
> >> the executable file for instance.
> >>
> >> For the most part the static files that I'd like to server up are the index.html
> >> page (entry point) and it's dependent script and or css files.  All of the other
> >> html content will be served up through the templating system and injected into
> >> the initial index.html page through ajax or constructed client-side as a result
> >> of JSON data received from the server as well.  I figured instead of writing
> >> separate web modules/actions for each...
> >
> > I still do not understand why you didn't use 'fppkg install embweb' and
> > used that. That embedded webserver does all you want.
> >
> > Joost.
> 
> I am using windows snapshots and it doesn't work with the fpc version included. 

It should work with fpc 2.5.1, and you have to use this version anyway,
because this is the version that Michael does his additions to?

>   I think I tried manually copying the fpc files as well at some point.  I know 
> I need to setup source compiling on windows, but this is a bit of a side project 
> and time is tight lately.

This is important, because the whole idea of fppkg is to make situations
like this easier. Bad thing is that you are one of the first people who
can use it. So you'll encounter more problems.

In the end, something like fcl-web, especially all the variants included
with it, are not distributed with fpc anymore, but installed separately.
The great advantage of this is that the release-cycles of these packages
can become shorter. Without the user having to recompile fpc. (Well, in
fact this is what happens, but fppkg handles this)

> For testing and compiling on windows using current snapshots for now, I figured 
> I'd use FCGI since I already had a XAMPP install setup anyway and that way I can 
> debug it easily and test it in real time.  I've also been wanting to try getting 
> an fcgi app up and running with lazarus for a while now.
> 
> Btw, since the point of the framework is be backend agnostic as much as 
> possible, the need to serve up static files transparently in cases where there 
> is an embedded deployment may even be better addressed in the framework itself 
> at some point.  I know, I know.  Patches are welcome. :-)

It's completely the opposite. If the framework is backend agnostic, you
should not add your own static-file-handling. Because the backend
handles static files. Really, Apache and ISS are much better in handling
static fiels then you are. Or do you want to implement caching, proxy
support, error handling etc? Then you are basically implementing your
own web-server.

So, the backend should handle static files. In the case of an embedded
webserver, this embedded webserver should handle those. Also because you
will get into trouble with your URL's. For example:

http://www.lazarussupport.com/lazarus/sec1/sec2/sec3

'lazarus' is the name of the cgi-application. Sec1,sec2 and sec3 are the
parameters. 

http://www.lazarussupport.com/css/main.css

Here a static file is served. If you would do it your way, the
cgi-executable always has to be placed in the URL.

Joost

-- 
My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog