Re: [Openinteract-help] Launched my site, development process.

[Chris W. <ch...@cw...>]

On Tue, 2001-12-18 at 18:53, Victor Piterbarg wrote:
> I launched the first phase of the site I've been working on
> http://www.nasaproracing.com. It's all done w/ OpenInteract. If you have an
> interest, take a look.

------------------------------
[cwinters@genesee work]$ HEAD www.nasaproracing.com
200 OK
Cache-Control: max-age=0
...
Title: Welcome to NASAProRacing.com!
X-Powered-By: OpenInteract 1.36
------------------------------

Excellent work!

I'm going to need to create a page on the openinteract.org site for
sites using OI....

> Seems to be running good so far. :-)
> I haven't put up the shopping cart yet, still not sure what I want. Also, I
> fixed my problem with the dynamic pages getting cached by recompiling apache
> with mod_expires and setting the default expiration for text/html docs to 0.
> Seems to be working.

That's great it's working. Did the section in the mod_perl guide not
work properly? (I'm curious just in case someone else asks about
this...)
 
> Some comments about the dev. process. This has been mentioned before, but I
> did find the remove,export,install,apply cycle fairly tedious. I did write a
> couple of shell scripts that made my life a lot easier, 

Send them over and I'll stick them in the distribution!

> however, it would
> definitely be a good idea to include some more developer-friendly
> functionality in oi_manage. 

I am very open to suggestions on this. I tend to be a little myopic
about the process (since I wrote it), and there are so many other things
to do, etc. This may even require a rethinking as to the necessity of a
base installation directory, since that was inspired by circumstances
that don't seem to hold much sway anymore.
 
> I also noticed that there is no nice way to yank
> the package out of the root openinteract directory, in order to re-install
> it. All it amounts to is taking the entry for your package out of
> package_repository.perl and deleting the directory, so I just had my scripts
> do it.

What circumstances required you to re-install a package? That's the
thing we should probably fix first :-)

> The second thing was the security. I kept bumping into it and spending hours
> figuring out what is wrong, only to discover that it's an object security
> issue. That was primarily because I didn't really understand the structure
> at first. So my advice is -- figure out the security scheme before
> inheriting from SPOPS::Secure :-).

Good point -- I'll remember to put this in the docs.

> Third was importing data. I had about 8000 user profile records to import. I
> imported everything fine into the DB, however then I had to create entries
> for all of them in the sys_security table. Since every user record has to be
> "owned" by the individual user, I wrote my own script to go through the user
> profile table, and create security entry for each row.

Ouch. There's a script to do this in the base_security package already.
Oh well.

> This is all well and
> good, but it took me an hour to realize that it's a security issue, because
> I didn't know that fetch_group() just skips the objects the current user has
> no permissions for, without saying much. So I was pulling my hair for a
> while.

If you pass in a level for DEBUG you can get some additional feedback on
SPOPS actions:

  my $list = $object_class->fetch_group({ DEBUG => 2 });

That said, the error handling is something I'm planning to modify before
we get to SPOPS 1.0.

Thanks for the update!

Chris
 
-- 
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.