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
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
