 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / Perl / March 2007CGI to OS X?
You all know I've been on this list for a long time, and I've asked the most stupid questions of anyone here, so keep that in mind when reading the following (I have a reputation to keep ;) I've been wondering about this for quite awhile and thought I'd finally bring it, I'll try to explain as best as I can... I have a web based app that I've developed on my MacOS X desktop (and iBook) using perl and some modules I've installed. To test it I use the built-in apache web server and Safari web browser pointed at "http://localhost/cgi-bin/myApp.cgi". Right now I'm playing with re-factoring it to use a web app framework like "CGI::Prototype" or "CGI::Application". It works pretty good. I mean, it's pretty fast, stable, and now I'm adding some "Web 2.0" stuff that adds some pretty cool features like auto completing forms, dynamic content, and even some cool visual effects. So, I keep coming back to these questions... First, how hard is it to create an "Mac OS X Installer" that can set this up on any mac to run without an internet connection? I played around with this a little a long time ago, but had trouble getting file permissions set-up right and turning on apache, and never even tried to install perl modules. Second, is it possible create a way to run my content in a native MacOS X Window instead of the web browser? If this could be done, and I could connect the window and "main menu bar" at the top of the screen to my perl CGI script, then I'd almost have a native Mac OS X "Look and Feel" with little additional effort. I guess I envision something similar to the "Help" application that I can manipulate with my perl CGI scripts... It seems that maybe Sherm's stuff (CamelBones and FatCamel) might already provide much of what is need to do these things. Finally, Does this make any sense to anyone else (or does my reputation grow yet larger)? Kindest Regards, -- Bill Stephenson >I have a web based app that I've developed on my MacOS X desktop >(and iBook) using perl and some modules I've installed. To test it I [quoted text clipped - 5 lines] >pretty cool features like auto completing forms, dynamic content, >and even some cool visual effects. So, I keep coming back to these questions... Depending on the nature of your application, you might look at Catalyst as well. I've been playing with it recently, and it's pretty nice. It also builds a standalone server for you, for lightweight use (like running on a local machine). >First, how hard is it to create an "Mac OS X Installer" that can set >this up on any mac to run without an internet connection? I played >around with this a little a long time ago, but had trouble getting >file permissions set-up right and turning on apache, and never even >tried to install perl modules. I can't comment on this. >Second, is it possible create a way to run my content in a native >MacOS X Window instead of the web browser? If this could be done, [quoted text clipped - 3 lines] >something similar to the "Help" application that I can manipulate >with my perl CGI scripts... Here's the difficulty... You basically need a browser to display and render HTML.. Now, granted, the Help Application is in a lot of ways a browser. What you're kind of talking about is what's known as a "Rich Client", a browser that has additional features for presenting more "traditional" application type controls and handlers. I don't know of any particular (and particularly Perl oriented) Rich Clients that are specific to the Mac - but Eclipse is working on a generic Rich Client that can be used from anything... but you might have to mix in some Java at this point. But then again, I haven't looked for any Mac specific Rich Clients. >It seems that maybe Sherm's stuff (CamelBones and FatCamel) might >already provide much of what is need to do these things. Except for you'd probably have to rebuild your views to use Cocoa instead of HTML. This might be a lot more work than it seems up front. >Finally, Does this make any sense to anyone else (or does my >reputation grow yet larger)? Again, it kind of depends. Web based applications are usually different in scope and usage patterns than standalone applications. If your app really makes more sense as a standalone desktop app, then you should probably go to the trouble to refactor it to use CamelBones. If it makes more sense as a web app, you should maybe look into distributing it in a "hosting" manner, rather than an installer manner. This also changes if you're planning on selling this, or merely making it available. -jeff > Again, it kind of depends. Web based applications are usually > different in scope and usage patterns than standalone applications. [quoted text clipped - 6 lines] > This also changes if you're planning on selling this, or merely making > it available. Let me move the focus a little... If there were a perl module that could let perl CGI scripts interact with a native Mac OS X window, that displayed web formated content like Safari (or perhaps a hacked FireFox), but also gave you access to the "Main Menu", then any web programmer could port their work to a native Mac OS X (like) application with little effort. Now, if you consider the different aspects of current web apps and the features that you can use now on OS X with the built-in Apache, like MySQL, DHTML, CSS, AJAX, Graphics Libraries (GD), accessing local or remote data for use in your application, you have a rich collection of APIs that leverage a huge base of existing programmers skills to create Native Mac OS X apps, for sale, or free. If they could just package it. It's just something that feels so close... -- Bill Stephenson > If there were a perl module that could let perl CGI scripts > interact with a native Mac OS X window, that displayed web formated > content like Safari (or perhaps a hacked FireFox), but also gave > you access to the "Main Menu", then any web programmer could port > their work to a native Mac OS X (like) application with little effort. Sounds perfectly horrible, to be honest. None of the smooth interactivity of a real GUI, none of the benefits that a real client- server web app gives, and written by someone who's either incapable or unwilling to learn how to build a real GUI app. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org > Sounds perfectly horrible, to be honest. None of the smooth > interactivity of a real GUI, With the capabilities included with the Mozilla DOM and CSS and extended by the "Prototype JavaScript Framework" (http://prototype.conio.net/) (and cool additional features found at "http://script.aculo.us/"), I'd argue that the gap is closing on this. There is cool stuff happening, and I expect it will get better. > none of the benefits that a real client-server web app gives Why that's just silly. You have all of the benefits of a "real client-server web app". What server you're app (client) chooses to access (local or remote or both) is up to you. > and written by someone who's either incapable or unwilling to learn > how to build a real GUI app. That describes me pretty well, but that doesn't mean I can't create something useful that runs on a desktop using the methods described above. Kindest Regards, -- Bill > If there were a perl module that could let perl CGI scripts interact > with a native Mac OS X window, that displayed web formated content [quoted text clipped - 11 lines] > > It's just something that feels so close... Hmm... Looks like Adobe is doing something very much like this now. Check out Adobe's "Apollo". "Apollo is the code name for a cross-operating system runtime being developed by Adobe that allows developers to leverage their existing web development skills (Flash, Flex, HTML, JavaScript, Ajax) to build and deploy Rich Internet Applications (RIAs) to the desktop." (source: http://labs.adobe.com/wiki/index.php/Apollo:DeveloperFAQ) It looks like a perl/cgi script might be used to provide local or remote data and other files to Apollo applications but the API is not yet complete (according to Adobe's web site) and I haven't had a chance to read the docs in detail or play with the dev kit. I think it's worth finding out more about how Apple's built-in perl might interact with Apollo though. It sure brings up many interesting (and even some "perfectly horrible" ;) possibilities. Kindest Regards, -- Bill Stephenson > First, how hard is it to create an "Mac OS X Installer" that can > set this up on any mac to run without an internet connection? I > played around with this a little a long time ago, but had trouble > getting file permissions set-up right and turning on apache, and > never even tried to install perl modules. It's not all that hard - although Apple's PackageMaker.app ain't the greatest. I prefer Stéphane Sudre's Iceberg: <http://s.sudre.free.fr/Software/Iceberg.html> The trick to making installers for Perl modules is separating out the files that belong to the module you want to install. One easy way to do that is to start with a "clean" /Library/Perl directory, install everything your app needs, and then make an installer package that installs the whole shebang. A finer-grained method, supported by Perl 5.8.x and newer, is to use the "DESTDIR" option when installing. You need to download and build the modules by hand, beginning with the normal recipe - "perl Makefile.PL; make; make test". But, for the last step include an additional parameter that specifies a location under which the files will be installed: "make install DESTDIR=/tmp/foo" for instance. This directory will be prepended to the actual file path, so if a file's real location is supposed to be / Library/Perl/foo.txt, using this example it would be copied to /tmp/ foo/Library/Perl/foo.txt. If your Perl modules depend on external libraries, you'll need to be sure to include those, one way or another - either build static libraries and link against those, or include the dynamic libraries with your installer. The DESTDIR option for "make install" is worth trying for libraries that build with the common "configure; make" sequence - it's widely supported. Whether Apache is started is governed by the WEBSERVER entry in /etc/ hostconfig. You could edit that in a postflight script included in your installer package, and then run "apachectl start" to start Apache. > Second, is it possible create a way to run my content in a native > MacOS X Window instead of the web browser? If this could be done, > and I could connect the window and "main menu bar" at the top of > the screen to my perl CGI script, then I'd almost have a native Mac > OS X "Look and Feel" with little additional effort. I'm not sure I agree with the premise that a web form with an app wrapper around it would have a native l&f... but whatever. One possibility - Include an Apache config file in your app bundle that configures Apache to listen to a "high" port - i.e. >1024. Have your app start its own copy of httpd, using the -f option to tell it to use your custom config file. Because your app might get moved, don't hard-code the path to the included CGIs - instead, use NSBundle methods to get the location of the bundle, and use that with the -C option to httpd. The other half of the equation, a web browser container to connect to your embedded server, is simple to do with WebKit. > It seems that maybe Sherm's stuff (CamelBones and FatCamel) might > already provide much of what is need to do these things. Maybe... maybe not. FatCamel is old, and I don't plan to update it - Apple is doing better now about keeping up with reasonably current Perls, and for folks who want pre-compiled binary modules, there's ActivePerl. Your CGI stuff is in Perl, but you probably wouldn't be using CamelBones for that. The WebKit "container" app could be written in Perl using CamelBones, but there's no particular reason you'd *need* to write that in Perl, and not much benefit in terms of easier maintenance, code reuse, etc. in doing so. CamelBones would be most helpful if you want to refactor your app into an MVC design. You could re-use your model classes in both the web and GUI versions of your app, with different view and controller layers for each. > Finally, Does this make any sense to anyone else In general, I'm fairly skeptical about the current trend to "webify" everything in sight. Web forms just aren't well-suited to some kinds of tasks. Take Google Groups for instance - as a search engine it's great, but as a general news reader it's horrid. I'd take Unison, Thoth, or Gnus over that, any day. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org * Sherm Pendley <sherm@dot-app.org> > A finer-grained method, supported by Perl 5.8.x and newer, is to use > the "DESTDIR" option when installing. You need to download and build > the modules by hand, beginning with the normal recipe - "perl > Makefile.PL; make; make test". Why hand install modules when the Perl CPAN or CPANPLUS modules can install to alternate locations for you? http://sial.org/howto/perl/life-with-cpan/#s7 > * Sherm Pendley <sherm@dot-app.org> >> A finer-grained method, supported by Perl 5.8.x and newer, is to use [quoted text clipped - 4 lines] > Why hand install modules when the Perl CPAN or CPANPLUS modules can > install to alternate locations for you? That's not the same thing. I'm not talking about configuring them to install in an alternate location, I'm talking about copying the files somewhere other than their installation location they were configured for. It's not a technique that's unique to Mac OS X, or to Perl - it's very widely used to make packages for Fink, DarwinPorts, Solaris, and a variety of BSD & Linux distros. Google for "making packages DESTDIR". sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org * Sherm Pendley <sherm@dot-app.org> > A finer-grained method, supported by Perl 5.8.x and newer, is to use > the "DESTDIR" option when installing. You need to download and build > the modules by hand, beginning with the normal recipe - "perl > Makefile.PL; make; make test". There is no need to hand install modules. Using the CPAN module, the DESTDIR option can be set as a 'make_install_arg' argument in the CPAN configuration file, for example: $ grep DESTDIR ~/.cpan/CPAN/MyConfig.pm 'make_install_arg' => q[DESTDIR=/var/tmp], However! With modules being installed under /var/tmp/<PREFIX>, building prerequisite modules will be tricky, unless these modules are first installed onto the system, or @INC updated to include the custom install path. > * Sherm Pendley <sherm@dot-app.org> >> A finer-grained method, supported by Perl 5.8.x and newer, is to use [quoted text clipped - 13 lines] > prerequisite modules will be tricky, unless these modules are first > installed onto the system That's why I suggested building them by hand. CPAN is quite useful most of the time, but in my experience putting together the FatCamel packages, it was mostly more trouble than it was worth. Although, I'm prepared to believe that FatCamel could be an exception to the rule - it was a complete Perl installation, and several dozen modules, and the C libraries that the XS modules depended on. TMTOWTDI. YMMV. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org > I have a web based app that I've developed on my MacOS X desktop > <snip> I was poking around and found this: http://developer.mozilla.org/en/docs/XUL Very interesting.... Kindest Regards, -- Bill |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.