[Lazarus] fpWeb and static content

[Lee Jenkins]

On 5/25/2011 4:16 AM, Joost van der Sluis wrote:
> 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.

I definitely agree.  I'll have to find some time to get source compiling on my 
windows box going.  I did it once, a couple of years ago, I remember that it was 
frustrating.  Not over complex, but lots of bits and pieces that need to be 
set/tweaked/edited, etc.

> 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)
>

Like RPM's and such or Eclipse/Netbeans IDE plug in managers.  I like it.  3rd 
party components and libraries are easier to offer and install, less complicated 
(and smaller) initial installs of the main IDE/compiler, etc.  Very nice indeed.

I think the holy grail would be maybe some kind of lazarus integration with 
package manager that allowed you to recompile lazarus out of the box using svn, 
etc.  Lazarus and fpc development are so nicely fluid...

>> 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.

Right.  Support for serving static files has to be implemented at some point for 
a functional embedded server so why not just make it switched based so that it's 
on by default for embedded apps.  If I want to use it also in my larger, yet 
still self-contained web application I can use it there too.

I agree that for most applications you will build, the statics should probably 
be served by the webserver, especially if your cgi/fcgi handler is part of a 
larger website or web application.  On the other hand, if your lazarus/fpc app 
/IS/ the whole application then its convenient.

Also, this could make it easier to implement MVC using the front-controller and 
router patterns so popular in other web frameworks (php, ruby, etc) across the 
board where the entire application is accessed through a single bootstrapped 
entry point.

> 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.
>

I know, its a pain.  Right now I have a class that handles the application's 
OnGetModule event and branches off to a specialized webmodule for requests that 
have a file extension and are not the name of a registered webmodule.

I also have to maintain a list of mimetypes and physical docroot path and a 
function which parses PathInfo and figures out physical paths, etc and I still 
have to write file date changes for browser caching, etc.  But once I have 
worked out the quirks, I can treat all installations almost exactly the same. 
Bear in mind that much of the kind of applications I do are task based worker 
bee applications that should be customer installable in many cases so I may be 
"shoehorning" a bit.

The prospect of replacing many of the fat client type products I work on with 
HTML5 based applications using Object Pascal is very attractive to me.  Point of 
sale for one.  No real GUI requirements that HTML5 can't handle and just a lot 
of repetitive functions over and over again.  One single installation, one 
single point of upgrade is nice.  Most of my customers in POS were 3-4 client 
workstation customers with some that were 40 client workstations with the kind 
of transactional traffic or security protocols that would required apache/iis as 
opposed to an embedded server.  Either way, configuration was needed to be as 
simple as possible.  8 years ago, it was all sold, supported and maintained by 
knowledgeable local pos dealers, nowadays a large percentage of POS 
installations are done by restaurant owners themselves with the help of a techie 
family member or local IT consultant.

--
Warm Regards,

Lee