Menu
▾
▴
openinteract-help
|
From: Ken Youens-C. <ky...@gm...> - 2005-04-14 20:09:30
|
Hi, I'm following along in this tutorial: http://search.cpan.org/~cwinters/OpenInteract-1.99_06/lib/ OpenInteract2/Manual/Tutorial.pod And I'm up to the "Translate searching tasks to common" section. I made the changes to move to the "CommonSearch" as defined in this section. When I restart my web server, I see this following message: Error This action encountered one or more errors: No template found in 'c_search_form_template' key. This template is mandatory for the task to function. Even though my "conf/action.ini" has the following: [book] class = OpenInteract2::Action::Book task_default = search_form is_secure = no c_object_type = book c_search_form_template = book::search_form c_search_results_template = book::search_results c_search_fields_like = title c_search_results_order = title And the template does exist. (FWIW, everything in the tutorial was working perfectly up to this point.) What am I missing? ky |
|
From: Chris W. <ch...@cw...> - 2005-04-14 21:18:09
|
* Ken Youens-Clark (ky...@gm...) [050414 16:27]: > ... > And I'm up to the "Translate searching tasks to common" section. I > made the changes to move to the "CommonSearch" as defined in this > section. When I restart my web server, I see this following message: >... > No template found in 'c_search_form_template' key. This template is > mandatory > for the task to function. > > Even though my "conf/action.ini" has the following: > > [book] > class = OpenInteract2::Action::Book > task_default = search_form > is_secure = no > c_object_type = book > c_search_form_template = book::search_form > c_search_results_template = book::search_results > c_search_fields_like = title > c_search_results_order = title > > And the template does exist. (FWIW, everything in the tutorial was > working perfectly up to this point.) It's probably that you're using an earlier version of the configuration. When you upgrade your package the action configuration is copied to, in your case: $WEBSITE_DIR/conf/book/action.ini If that file already exists and the files are different, we copy the new one to: $WEBSITE_DIR/conf/book/updates/action.ini-x.xx So see if you've got any updates there and if so, copy the latest over the working configuration and see what happens. Yeah, we should definitely stress that in the tutorial :-) I'm glad you brought this up because I'm now thinking that we might want to make package configuration overwriting an option for people who never change them from the default. Salve, what do you think? Chris -- Chris Winters (http://www.cwinters.com) Building enterprise-capable snack solutions since 1988 |
|
From: Ken Youens-C. <ky...@gm...> - 2005-04-14 21:33:30
|
On Apr 14, 2005, at 4:28 PM, Chris Winters wrote: > * Ken Youens-Clark (ky...@gm...) [050414 16:27]: >> ... >> And I'm up to the "Translate searching tasks to common" section. I >> made the changes to move to the "CommonSearch" as defined in this >> section. When I restart my web server, I see this following message: >> ... >> No template found in 'c_search_form_template' key. This template is >> mandatory >> for the task to function. >> >> Even though my "conf/action.ini" has the following: >> >> [book] >> class = OpenInteract2::Action::Book >> task_default = search_form >> is_secure = no >> c_object_type = book >> c_search_form_template = book::search_form >> c_search_results_template = book::search_results >> c_search_fields_like = title >> c_search_results_order = title >> >> And the template does exist. (FWIW, everything in the tutorial was >> working perfectly up to this point.) > > It's probably that you're using an earlier version of the > configuration. When you upgrade your package the action configuration > is copied to, in your case: > > $WEBSITE_DIR/conf/book/action.ini > > If that file already exists and the files are different, we copy the > new one to: > > $WEBSITE_DIR/conf/book/updates/action.ini-x.xx > > So see if you've got any updates there and if so, copy the latest over > the working configuration and see what happens. Unfortunately, I had already checked that the "action.ini" was kosher. I even upped the package.ini::version and installed a new package. Still the same error. I also tried deleting older versions of the package installed into $WEBSITE_DIR, starting/stopping. I should mention that I'm doing all this on a Intel Celeron/Debian Woody system that I just set up expressly for testing/learning OI2. I installed Perl 5.8.6 from source and all the modules are the latest from CPAN. I'm using the Apache/mod_perl (solo) setup. > Yeah, we should definitely stress that in the tutorial :-) > > I'm glad you brought this up because I'm now thinking that we might > want to make package configuration overwriting an option for people > who never change them from the default. Salve, what do you think? I would like "oi2_manage package_all" to automatically kill an existing .zip package of the same version, too. ky |
|
From: Chris W. <ch...@cw...> - 2005-04-15 12:14:42
|
On Apr 14, 2005, at 5:33 PM, Ken Youens-Clark wrote: > Unfortunately, I had already checked that the "action.ini" was kosher. > I even upped the package.ini::version and installed a new package. > Still the same error. I also tried deleting older versions of the > package installed into $WEBSITE_DIR, starting/stopping. I should > mention that I'm doing all this on a Intel Celeron/Debian Woody system > that I just set up expressly for testing/learning OI2. I installed > Perl 5.8.6 from source and all the modules are the latest from CPAN. > I'm using the Apache/mod_perl (solo) setup. Just to be clear: did you check the action.ini in the $WEBSITE_DIR/conf/book/action.ini was ok? The reason I'm emphasizing this is that there are two copies: one in the website directory and one in the package directory: Website: $WEBSITE_DIR/conf/book/action.ini Package: $WEBSITE_DIR/pkg/book-0.09/conf/action.ini The one in 'Package' is NOT used, the one in 'Website' is. (Sidenote: I'll create a new JIRA issue to automatically put a README in the 'Package' directory with this information.) If the one in 'Website' checks out ok we've got some more investigation to do. > ... > I would like "oi2_manage package_all" to automatically kill an > existing .zip package of the same version, too. You mean delete the files in the pkg/mypackage-old-x.xx directory? That's a valid option, and related to the earlier one where we delete the files from a 'remove_package': http://jira.openinteract.org/browse/OIN-158 I'll create an issue for this also. Thanks, Chris -- Chris Winters Creating enterprise-capable snack systems since 1988 |
|
From: Ken Youens-C. <ky...@gm...> - 2005-04-15 14:13:17
|
On Apr 15, 2005, at 7:14 AM, Chris Winters wrote: > On Apr 14, 2005, at 5:33 PM, Ken Youens-Clark wrote: >> Unfortunately, I had already checked that the "action.ini" was >> kosher. I even upped the package.ini::version and installed a new >> package. Still the same error. I also tried deleting older versions >> of the package installed into $WEBSITE_DIR, starting/stopping. I >> should mention that I'm doing all this on a Intel Celeron/Debian >> Woody system that I just set up expressly for testing/learning OI2. >> I installed Perl 5.8.6 from source and all the modules are the latest >> from CPAN. I'm using the Apache/mod_perl (solo) setup. > > Just to be clear: did you check the action.ini in the > $WEBSITE_DIR/conf/book/action.ini was ok? The reason I'm emphasizing > this is that there are two copies: one in the website directory and > one in the package directory: > > Website: $WEBSITE_DIR/conf/book/action.ini > Package: $WEBSITE_DIR/pkg/book-0.09/conf/action.ini > > The one in 'Package' is NOT used, the one in 'Website' is. > > (Sidenote: I'll create a new JIRA issue to automatically put a README > in the 'Package' directory with this information.) > > If the one in 'Website' checks out ok we've got some more > investigation to do. Ah, enlightenment! Yes, you are right. I changed the action.ini in the Website dir and it works now. >> ... >> I would like "oi2_manage package_all" to automatically kill an >> existing .zip package of the same version, too. > > You mean delete the files in the pkg/mypackage-old-x.xx directory? > That's a valid option, and related to the earlier one where we delete > the files from a 'remove_package': > > http://jira.openinteract.org/browse/OIN-158 OK, here's where I get really confused. I set my $ENV{'OPENINTERACT2'} = '/usr/local/openinteract' and then used "oi2_manage" to create the "book" package in my "$HOME/work/oi2/book." My understanding was that I would work on the package outside of the OI2 $WEBSITE_DIR (the "OPENINTERACT2" dir) and then use "oi2_manage package_all" to put my latest stuff from $HOME/work into the $WEBSITE_DIR. What I'm seeing with this setup are a couple issues: [1] My new stuff from $HOME/work doesn't always seem to get moved over, or at least not to where I think. Maybe I'm not understanding what the "$WEBSITE_DIR/pkg" dir is for because I was under the (now discredited) assumption that "$WEBSITE_DIR/pkg/book-xx/conf/action.ini" was used and didn't even know about "$WEBSITE_DIR/conf/book/action.ini." Also, I've read something that the libs in "$WEBSITE_DIR/pkg/book-xx/" aren't used but the ones in "$WEBSITE_DIR/tmplib" are. So, what is the purpose of the "$WEBSITE_DIR/pkg/book-xx" dir? And should I be working my package contents in my "/usr/local/openinteract" dir or my "$HOME/work" dir? Or maybe I'm not using the right command ("package_all") to move my working code into the $WEBSITE_DIR? Maybe if you could just share your general workflow for creating OI2 apps -- kind of a "best practices"? [2] Running the mod_perl_solo version runs into many permissions issues. I first started out the tutorial using the "oi2_daemon" and had no problems because it was running under my permissions, but moving to Apache running as "nobody" I find that httpd can't write to many directories ("logs," "error," "overflow," "cache") so I run around chmod'ing 777, which isn't so good, eh? Any advice? ------- I'm pretty excited by OI2. I looked at Ruby on Rails, Class::DBI, Maypole, Catalyst, etc., and OI2 was the first to really seem to work for me. If I can just figure out how to really get rolling, I think this is going to save me a lot of time and make my users happy (to see lots of solid interfaces produced quickly). Thanks, ky |
|
From: Chris W. <ch...@cw...> - 2005-04-15 19:30:18
|
* Ken Youens-Clark (ky...@gm...) [050415 10:26]: > > Ah, enlightenment! Yes, you are right. I changed the action.ini in > the Website dir and it works now. Excellent! > >>... > >>I would like "oi2_manage package_all" to automatically kill an > >>existing .zip package of the same version, too. > > > >You mean delete the files in the pkg/mypackage-old-x.xx directory? > >That's a valid option, and related to the earlier one where we delete > >the files from a 'remove_package': > > > > http://jira.openinteract.org/browse/OIN-158 > > OK, here's where I get really confused. I set my $ENV{'OPENINTERACT2'} > = '/usr/local/openinteract' and then used "oi2_manage" to create the > "book" package in my "$HOME/work/oi2/book." My understanding was that > I would work on the package outside of the OI2 $WEBSITE_DIR (the > "OPENINTERACT2" dir) and then use "oi2_manage package_all" to put my > latest stuff from $HOME/work into the $WEBSITE_DIR. That's how it's supposed to work. > What I'm seeing with this setup are a couple issues: > > [1] My new stuff from $HOME/work doesn't always seem to get moved over, > or at least not to where I think. Maybe I'm not understanding what the > "$WEBSITE_DIR/pkg" dir is for because I was under the (now discredited) > assumption that "$WEBSITE_DIR/pkg/book-xx/conf/action.ini" was used and > didn't even know about "$WEBSITE_DIR/conf/book/action.ini." Also, I've > read something that the libs in "$WEBSITE_DIR/pkg/book-xx/" aren't used > but the ones in "$WEBSITE_DIR/tmplib" are. That's a half-truth -- when you fire up the server the libs from pkg/book-xx/ are copied to tmplib/. We do this so we don't have 15+ directories on @INC. > ... Maybe > if you could just share your general workflow for creating OI2 apps -- > kind of a "best practices"? You're doing it the right way. The other useful workflow is to edit the live website files (especially for templates/HTML files) and once you're done run a 'update_package' command to sync your development package from the live package. > [2] Running the mod_perl_solo version runs into many permissions > issues. I first started out the tutorial using the "oi2_daemon" and > had no problems because it was running under my permissions, but moving > to Apache running as "nobody" I find that httpd can't write to many > directories ("logs," "error," "overflow," "cache") so I run around > chmod'ing 777, which isn't so good, eh? Any advice? It would probably be good to have a helper script for this that would need to be run as root; or if anyone knows a standard solution I'm all ears. > I'm pretty excited by OI2. I looked at Ruby on Rails, Class::DBI, > Maypole, Catalyst, etc., and OI2 was the first to really seem to work > for me. If I can just figure out how to really get rolling, I think > this is going to save me a lot of time and make my users happy (to see > lots of solid interfaces produced quickly). Thanks! I hope it continues. Reports like this are extremely useful and greatly appreciated. BTW, if you want/need to use Class::DBI in OI2 shoot me an email. I have a module to enable this but don't want to put it on CPAN until the next beta of OI2 is out since it relies on a feature in CVS. Chris -- Chris Winters (http://www.cwinters.com) Building enterprise-capable snack solutions since 1988 |
|
From: Ken Youens-C. <ky...@gm...> - 2005-04-17 03:10:35
|
On Apr 15, 2005, at 2:41 PM, Chris Winters wrote: >> [1] My new stuff from $HOME/work doesn't always seem to get moved >> over, >> or at least not to where I think. Maybe I'm not understanding what >> the >> "$WEBSITE_DIR/pkg" dir is for because I was under the (now >> discredited) >> assumption that "$WEBSITE_DIR/pkg/book-xx/conf/action.ini" was used >> and >> didn't even know about "$WEBSITE_DIR/conf/book/action.ini." Also, >> I've >> read something that the libs in "$WEBSITE_DIR/pkg/book-xx/" aren't >> used >> but the ones in "$WEBSITE_DIR/tmplib" are. > > That's a half-truth -- when you fire up the server the libs from > pkg/book-xx/ are copied to tmplib/. We do this so we don't have 15+ > directories on @INC. When you say "when [I] fire up the server," do you mean when using "oi2_daemon"? To try to understand this copying-to-tmplib part better, I tried altering in the "pkg" dir and starting both oi2_daemon and Apache, and I couldn't see how/when the copy was being made. > BTW, if you want/need to use Class::DBI in OI2 shoot me an email. I > have a module to enable this but don't want to put it on CPAN until > the next beta of OI2 is out since it relies on a feature in CVS. No, I think I like SPOPS better than Class::DBI. Thanks for the offer, though. ky |
|
From: Chris W. <ch...@cw...> - 2005-04-17 23:56:29
|
On Apr 16, 2005, at 11:10 PM, Ken Youens-Clark wrote: >> That's a half-truth -- when you fire up the server the libs from >> pkg/book-xx/ are copied to tmplib/. We do this so we don't have 15+ >> directories on @INC. > > When you say "when [I] fire up the server," do you mean when using > "oi2_daemon"? To try to understand this copying-to-tmplib part > better, I tried altering in the "pkg" dir and starting both oi2_daemon > and Apache, and I couldn't see how/when the copy was being made. It happens whether you start up the server from apache, standalone, cgi-bin, whatever sets up the OpenInteract2::Context object kicks off the process. However, what I left out from my earlier explanation (didn't think it was relevant) is that we don't do it every single time. It can be an expensive operation, especially if you're using network-mounted drives. So after the first time we only do the copying if the directory doesn't exist or if you've installed a new package. You can see the docs (and code) in OpenInteract2::Setup::CreateTemporaryLibraryDirectory for more. Chris -- Chris Winters Creating enterprise-capable snack systems since 1988 |
|
From: Ken Youens-C. <ky...@gm...> - 2005-04-18 22:01:13
|
On Apr 15, 2005, at 2:41 PM, Chris Winters wrote:
> You're doing it the right way. The other useful workflow is to edit
> the live website files (especially for templates/HTML files) and once
> you're done run a 'update_package' command to sync your development
> package from the live package.
I had trouble running the "update_package" command with
OpenInteract-1.99_06's "oi2_manage." It kept telling me I wasn't
providing a valid "package_dir." I traced the error to
"OpenInteract2::Manage::Website::UpdatePackageFromWebsite." It was
looking for the file "package.conf" in the "package_dir," but only
"package.ini" exists. Here's a diff:
$ diff -cu UpdatePackageFromWebsite.pm UpdatePackageFromWebsite.orig
diff: conflicting specifications of output style
--- UpdatePackageFromWebsite.pm Mon Apr 18 16:49:44 2005
+++ UpdatePackageFromWebsite.orig Mon Apr 18 16:49:28 2005
@@ -56,7 +56,7 @@
return "Must be a valid directory";
}
my $changelog = catfile( $param_value, 'Changes' );
- my $package_conf = catfile( $param_value, 'package.ini' );
+ my $package_conf = catfile( $param_value, 'package.conf' );
unless ( -f $changelog && -f $package_conf ) {
return "Does not appear to be a valid package directory";
}
And now it works. Schweet!
BTW, if I'm really trying to get going with OI2, should I be using the
"developer" version of 1.99 or should I downgrade to the 1.62 version?
If I should be bleeding-edge, should I be working with the CVS version
or stick to the CPAN developer release?
ky
|
|
From: Chris W. <ch...@cw...> - 2005-04-19 11:59:16
|
On Apr 18, 2005, at 6:01 PM, Ken Youens-Clark wrote: > I had trouble running the "update_package" command with > OpenInteract-1.99_06's "oi2_manage." It kept telling me I wasn't > providing a valid "package_dir." I traced the error to > "OpenInteract2::Manage::Website::UpdatePackageFromWebsite." It was > looking for the file "package.conf" in the "package_dir," but only > "package.ini" exists. Here's a diff: Whoops, missed that one when we did the conversion! Thanks for the catch, applied. > BTW, if I'm really trying to get going with OI2, should I be using the > "developer" version of 1.99 or should I downgrade to the 1.62 version? > If I should be bleeding-edge, should I be working with the CVS > version or stick to the CPAN developer release? I can provide a couple of tips: 1) Do not downgrade to 1.62; it is quite (!) different. It still works well, but you'll wind up rewriting a good deal when you upgrade to OI2 2) The released version (1.99_06) is pretty stable; I run my website on it (but that's not heavily trafficked). 3) Whether you use CVS is kind of up to you: if there's anything on the road map for 1.99_07 (which is considered 2.0 RC1) you think would be useful then it might be a good idea: http://jira.openinteract.org/secure/IssueNavigator.jspa? reset=true&pid=10010&fixfor=10040 Otherwise you should be able to develop with _06 and have to change little or nothing when _07 comes out. 2.0 final (after 1.99_07) is currently scheduled for mid-June. Hopefully we can keep to that. Chris -- Chris Winters Creating enterprise-capable snack systems since 1988 |
|
From: Salve J. N. <sal...@me...> - 2005-04-14 22:34:32
|
Chris Winters said: > > I'm glad you brought this up because I'm now thinking that we might want > to make package configuration overwriting an option for people who never > change them from the default. Salve, what do you think? You've already got the MD5 checksums there, so I can't see why not. I assumed you were thinking in those lines all the time... :) - Salve -- Salve J. Nilsen <salvejn at met dot no> / Systems Developer Norwegian Meteorological Institute http://met.no/ Information Technology Department / Section for Development |
|
From: Chris W. <ch...@cw...> - 2005-04-15 12:16:10
|
On Apr 14, 2005, at 6:34 PM, Salve J. Nilsen wrote: > Chris Winters said: >> >> I'm glad you brought this up because I'm now thinking that we might >> want >> to make package configuration overwriting an option for people who >> never >> change them from the default. Salve, what do you think? > > You've already got the MD5 checksums there, so I can't see why not. I > assumed you were thinking in those lines all the time... :) Nope. I was just using the MD5 checksums so that we don't create redundant files in the 'updates/' subdirectory. I hadn't thought about allowing a global setting so that we ALWAYS use the newest configurations. I'll create a JIRA issue for this one too. Chris -- Chris Winters Creating enterprise-capable snack systems since 1988 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X