openinteract-help — For new and current users, we offer support, troubleshooting and assistance.

Re: [Openinteract-help] requiring a login to the site?

[Andrew H. <hu...@ll...>]

At 11:55 PM 8/11/2003 -0400, Chris Winters wrote:
>Andrew Hurst wrote:
>>   I was wondering if anyone has set up OI to require site users to log 
>> in before they can see anything at the site.  I've searched around a 
>> fair bit and haven't found anything yet.  What I would like would be if 
>> a user goes to a url like:
>>...
>
>This is a really good idea. I'll get this, or something remarkable 
>similar, in the next 1.x version (coming out by the end of the week), for 
>sure. Thanks!

Thank you!  And people say that open source programs come without 
support.  I'll be sure to champion this email around to prove them 
wrong.  Thanks again!

-Andrew


>Chris
>
>--
>Chris Winters (ch...@cw...)
>Building enterprise-capable snack solutions since 1988.
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>openinteract-help mailing list
>ope...@li...
>https://lists.sourceforge.net/lists/listinfo/openinteract-help

Re: [Openinteract-help] requiring a login to the site?

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

Andrew Hurst wrote:
>   I was wondering if anyone has set up OI to require site users to log 
> in before they can see anything at the site.  I've searched around a 
> fair bit and haven't found anything yet.  What I would like would be if 
> a user goes to a url like:
> ...

This is a really good idea. I'll get this, or something remarkable 
similar, in the next 1.x version (coming out by the end of the 
week), for sure. Thanks!

Chris

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

[Openinteract-help] requiring a login to the site?

[Andrew H. <hu...@ll...>]

Hello all,

   I was wondering if anyone has set up OI to require site users to log in 
before they can see anything at the site.  I've searched around a fair bit 
and haven't found anything yet.  What I would like would be if a user goes 
to a url like:

  http://www.example.com/News/show/?news_id=10

  for it to redirect them to /login.html or some other login screen with 
only a login box, then once they login bringing them back to the original 
url.  Is this possible currently?

   If it isn't, how would I go about writing the code to make it 
possible?  I've thought about it, and if I were to write it I would make it 
recognize directives in server.ini like the following:

[login main]
force_login      = 1
login_pagelist   = *
nologin_pagelist = [ /, /index.html, /Login, /help* ]
login_page       = /Login

or something similar.  That way you could specify which pages require 
login's, and which didn't.  In the example above /Login would show a login 
screen and redirect to the original page when finished.

So is this possible?  And if not, where should I start looking to implement 
this?  I think it would best be done as a simple 10 line or so check in the 
action handler, OpenInteract::Request, from what I've seen so far...

Thanks for the help
-Andrew

[Openinteract-help] How do I cache SPOPS objects outside of OI?

[Barry H. <ba...@tr...>]

I'm not using OpenInteract, but I am using SPOPS.

Normally with objects that don't hold the DBI within them I can just 
store objects I need to be cached in Cache::FileCache or MLDBM:Sync.

This doesn't seem to work with my SPOPS objects.  Under mod_perl I get 
problems where sometimes things load and sometimes they don't.

What is the best way to cache SPOPS objects that shouldn't be fetched 
from the DB on every request?


-- 
Barry Hoggard
Tristan Media LLC
e: ba...@tr...
w: www.tristanmedia.com
aim: hoggardb

AW: [Openinteract-help] Running Non OI mod_perl handlers in paral lel

[<And...@Be...>]

Hi Chris,

Thanks for that simple idea - the second vhost does all I needed. For =
the
order, we tried all possible combinations - did not get it done. But =
this
should give us a few clues.

Thanks,

Andreas

-----Urspr=FCngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]=20
Gesendet: Mittwoch, 23. Juli 2003 15:10
An: And...@Be...
Cc: ope...@li...
Betreff: Re: [Openinteract-help] Running Non OI mod_perl handlers in
parallel


And...@Be... wrote:
> Maybe I am too blind to read the manual right, maybe not, but in any
> case, I have a problem setting up additional mod_perl handlers in=20
> parallel to OI 1 within the same process. For example, we have an=20
> intranet site, which I would like to inspect closer to find a memory=20
> leak. For this I`d like to setup Apache::Vmonitor and Apache::Status, =

> which are mod_perl packages themselvers. I am running the=20
> frontend/backend httpd setup and try to add the following to my =
backend=20
> httpd.conf, which is close to the sample from the sources:
>=20
> <Location /system/vmonitor>
>         SetHandler perl-script
>         PerlHandler Apache::VMonitor
> </Location>
> ...

The only things I can think of are:

  a) Order might matter. It was a while ago, but I remember that the=20
order of the different <Location...> directives mattered to Apache.=20
Unfortunately I can't remember whether it should be=20
general-to-specific or the other way around.

  b) Try setting up another vhost with the VMonitor stuff in it.=20
Sometimes mod_perl's architecture of having one big namespace for=20
everything can work for you :-)

Chris

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

Re: [Openinteract-help] Running Non OI mod_perl handlers in parallel

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

And...@Be... wrote:
> Maybe I am too blind to read the manual right, maybe not, but in any 
> case, I have a problem setting up additional mod_perl handlers in 
> parallel to OI 1 within the same process. For example, we have an 
> intranet site, which I would like to inspect closer to find a memory 
> leak. For this I`d like to setup Apache::Vmonitor and Apache::Status, 
> which are mod_perl packages themselvers. I am running the 
> frontend/backend httpd setup and try to add the following to my backend 
> httpd.conf, which is close to the sample from the sources:
> 
> <Location /system/vmonitor>
>         SetHandler perl-script
>         PerlHandler Apache::VMonitor
> </Location>
> ...

The only things I can think of are:

  a) Order might matter. It was a while ago, but I remember that the 
order of the different <Location...> directives mattered to Apache. 
Unfortunately I can't remember whether it should be 
general-to-specific or the other way around.

  b) Try setting up another vhost with the VMonitor stuff in it. 
Sometimes mod_perl's architecture of having one big namespace for 
everything can work for you :-)

Chris

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

[Openinteract-help] Running Non OI mod_perl handlers in parallel

[<And...@Be...>]

Hello y`all !

Maybe I am too blind to read the manual right, maybe not, but in any =
case, I
have a problem setting up additional mod_perl handlers in parallel to =
OI 1
within the same process. For example, we have an intranet site, which I
would like to inspect closer to find a memory leak. For this I`d like =
to
setup Apache::Vmonitor and Apache::Status, which are mod_perl packages
themselvers. I am running the frontend/backend httpd setup and try to =
add
the following to my backend httpd.conf, which is close to the sample =
from
the sources:

<Location /system/vmonitor>
        SetHandler perl-script
        PerlHandler Apache::VMonitor
</Location>

<Perl>
use Apache::Leak;
use Apache::VMonitor();
$Apache::VMonitor::Config{BLINKING} =3D 1;
$Apache::VMonitor::Config{REFRESH}  =3D 0;
$Apache::VMonitor::Config{VERBOSE}  =3D 0;
$Apache::VMonitor::Config{SYSTEM}   =3D 1;
$Apache::VMonitor::Config{APACHE}   =3D 1;
$Apache::VMonitor::Config{PROCS}    =3D 1;
$Apache::VMonitor::Config{MOUNT}    =3D 1;
$Apache::VMonitor::Config{FS_USAGE} =3D 1;
$Apache::VMonitor::Config{SORT_BY}  =3D 'size';
$Apache::VMonitor::PROC_REGEX =3D join "\|", qw(httpd mysql squid);
</Perl>

What am I doing wrong ? Help please you mod_perl gurus you ;-)

Cheers,

Andreas Nolte
Leitung IT
-----------------------------------------------------------
arvato direct services=20
Olympiastra=DFe 1
26419 Schortens
Germany
http://www.arvato.com/ <http://www.arvato.com/>=20

and...@be...
Phone   +49 (0) 4421 - 76- 84002
Fax	+49 (0) 4421 - 76- 84111

RE: [Openinteract-help] subclassing/overriding perhaps?

[Chris M. <Chr...@te...>]

Thank you very much for the suggestions - 

I can seem to find any documentation on the object_link method - can you
point me to some explanation or example?

Thanks,

Chris

-----Original Message-----
From: Chris Winters [mailto:ch...@cw...]
Sent: July 9, 2003 4:40 PM
To: Andreas Nolte
Cc: Chris McDaniel; 'ope...@li...'
Subject: Re: [Openinteract-help] subclassing/overriding perhaps?


Andreas Nolte wrote:
> I saw Chris Winters already sketched a solution for a subclassing
> solution implementing an ISA relationship. 
> Maybe you should consider also using a HAS A relationship. You would
> define a new SPOPS class with ISA Telus::User, maybe has some extra
> stored attributes but then HAS A base_user. There are multiple ways in
> SPOPS to do this with the has_a, links_to and object_link things. I like
> object_link the most because I think it` s the most flexible.
> 
> Using this approach, you do not need to worry much about the base
> packages and upgrading is a snap.

This is an excellent suggestion for SPOPS objects. As the GoF says: 
"Favor object composition over class inheritance." :-)

Chris

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

[Openinteract-help] SPOPS namespaces?

[Chris M. <Chr...@te...>]

Hello,

I'm wondering what would happen if you had two packages (for example, Pkg1,
Pkg2) within a site that each had an object in them with the same base
object alias (for example 'news') referring to different code classes (for
example, WebSite::NewsPkg1 and WebSite::NewsPkg2).  So if I called
$R->news->new;  in the Handler for Pkg1, would it know to call
WebSite::NewsPkg1 or does this type of configuration make SPOPS explode?

Thanks,

Chris McDaniel

Re: [Openinteract-help] How do I keep a "private" non-DB field in an SPOPS object?

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

Barry Hoggard wrote:
> I'm using SPOPS on a new project, and there are times where I want to 
> check whether an object has a certain value in a links_to list.  Because 
> I don't want to cycle through all of if to check each time, I wanted to 
> create a private value, like
> 
> $self->{_feature_hash}
 > ...

Try prefixing the value you want to store with 'tmp_', e.g., 
'tmp_feature_hash'.

Chris

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

[Openinteract-help] How do I keep a "private" non-DB field in an SPOPS object?

[Barry H. <ba...@tr...>]

I'm using SPOPS on a new project, and there are times where I want to 
check whether an object has a certain value in a links_to list.  Because 
I don't want to cycle through all of if to check each time, I wanted to 
create a private value, like

$self->{_feature_hash}

to store a hash for easy checking, but that doesn't work.  (I was doing 
it in post_fetch_action).  It gets cleared out, so that I can't use it.

I'm using SPOPS::Tool::DBI::DiscoverField to set up the fields in the 
database, and I set strict_field => 0 while I was testing.

What's the best way to do something like this?  Use Class::Accessor?






Barry Hoggard
Tristan Media LLC
e: ba...@tr...
w: www.tristanmedia.com
aim: hoggardb

Re: [Openinteract-help] Re: AW: OI1 - page_directives

[joe s. <jo...@mo...>]

>> Another question.
>> 
>> I will create a new package. This package should have it's
>> own base_template. Is that possible?
>
>Not directly from one place. You can set the main template in a 
>template:
>
>  [% OI.use_main_template( 'mypkg::main_template' );
>
>Or you can set it from code:
>
>  $R->{page}{_template_name_} = 'mypkg::main_template';
>
true, but maybe look at virtual host redirection.  Maybe you could create a separate installation, update base_template for the main theme to be your template instaead of the provided one, and redirect somebody to a new apache virtual host running the second oi (with your package being it's sole reason).  Would require two installations, but it would meet your objective.

_____________________________________________________________
Can you survive the horror? http://www.morbidmortuary.com

_____________________________________________________________
Select your own custom email address for FREE! Get yo...@yo..., No Ads, 6MB, IMAP, POP, SMTP & more! http://www.everyone.net/selectmail?campaign=tag

[Openinteract-help] Re: AW: OI1 - page_directives

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

(cc'd to -help)

Ewa...@Be... wrote:
> Thanks, it works.
> 
> Another question.
> 
> I will create a new package. This package should have it's
> own base_template. Is that possible?

Not directly from one place. You can set the main template in a 
template:

  [% OI.use_main_template( 'mypkg::main_template' );

Or you can set it from code:

  $R->{page}{_template_name_} = 'mypkg::main_template';

Chris

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

[Openinteract-help] Re: OI1 - page_directives

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

(cc'd to -help)

Ewa...@Be... wrote:
> I create a new page directive (NoHead) in the server.ini. 
> 
> [page_directives]
> Popup      = simple_template
> NoTemplate = 1
> NoTmpl     = 1
> NoHead     = no_head_template
> 
> I have create a new template (base_no_head.tmpl). 
> 
> How can I tell OI where it find the template (base_no_head.tmpl) 
> when I use the directive NoHead.

'no_head_template' refers to a key in your theme, so set the key 
'no_head_template' in your 'main' theme to the actual template name 
and you should be good.

Later,

Chris

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

Re: [Openinteract-help] subclassing/overriding perhaps?

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

Andreas Nolte wrote:
> I saw Chris Winters already sketched a solution for a subclassing
> solution implementing an ISA relationship. 
> Maybe you should consider also using a HAS A relationship. You would
> define a new SPOPS class with ISA Telus::User, maybe has some extra
> stored attributes but then HAS A base_user. There are multiple ways in
> SPOPS to do this with the has_a, links_to and object_link things. I like
> object_link the most because I think it` s the most flexible.
> 
> Using this approach, you do not need to worry much about the base
> packages and upgrading is a snap.

This is an excellent suggestion for SPOPS objects. As the GoF says: 
"Favor object composition over class inheritance." :-)

Chris

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

Re: [Openinteract-help] subclassing/overriding perhaps?

[Andreas N. <an...@kl...>]

On Wed, 2003-07-09 at 15:58, Chris McDaniel wrote:
> I make a good number of changes to the some of the base packages (esp. user)
> but I'm wondering whether just mucking around in the base packages is the
> best way to go about it.  It does make upgrading a bit painful.  My problem
> is that I'm not sure what the "right way" would be, and my other problem is
> that I have never (intentionally, anyway) subclassed or overridden anything.
> So, if anyone has some ideas about how to implement modifications in the
> base packages in some intelligent way (as opposed to my way) or pointers to
> some docs I should read, I'd appreciate it.

Hi Chris,

I saw Chris Winters already sketched a solution for a subclassing
solution implementing an ISA relationship. 
Maybe you should consider also using a HAS A relationship. You would
define a new SPOPS class with ISA Telus::User, maybe has some extra
stored attributes but then HAS A base_user. There are multiple ways in
SPOPS to do this with the has_a, links_to and object_link things. I like
object_link the most because I think it` s the most flexible.

Using this approach, you do not need to worry much about the base
packages and upgrading is a snap.

later,

Andreas

Re: [Openinteract-help] subclassing/overriding perhaps?

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

Chris McDaniel wrote:
> I make a good number of changes to the some of the base packages (esp. user)
> but I'm wondering whether just mucking around in the base packages is the
> best way to go about it.  It does make upgrading a bit painful.  My problem
> is that I'm not sure what the "right way" would be, and my other problem is
> that I have never (intentionally, anyway) subclassed or overridden anything.
> So, if anyone has some ideas about how to implement modifications in the
> base packages in some intelligent way (as opposed to my way) or pointers to
> some docs I should read, I'd appreciate it.

This is a interesting point. Off the top of my head I can think of:

  - create a *new* package with my modifications (e.g., 'telus_user' 
instead of 'base_user'). This should include ALL the functionality 
of the original package and then any additions you have
  - uninstall the original package
  - whenever I upgrade to a new version either skip my custom 
counterparts in the upgrade or let them get installed and then 
immediately uninstall.

You could also keep the old package and subclass what you need. (I'd 
create a new package for this as well so you're insulated from 
upgrades.) However you'll run into a mapping problem. That is, the 
'user' action is mapped to OpenInteract::Handler::User and not 
OpenInteract::Handler::MyUserSubclass. So you may have to do some 
editing of configuration files either directly or through the global 
overrides.

Chris

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

Re: [Openinteract-help] subclassing/overriding perhaps?

[Mark S. <ma...@su...>]

On Wed, Jul 09, 2003 at 07:58:30AM -0600, Chris McDaniel wrote:
> 
> Hello,
> 
> I make a good number of changes to the some of the base packages (esp. user)
> but I'm wondering whether just mucking around in the base packages is the
> best way to go about it.  It does make upgrading a bit painful.  My problem
> is that I'm not sure what the "right way" would be, and my other problem is
> that I have never (intentionally, anyway) subclassed or overridden anything.
> So, if anyone has some ideas about how to implement modifications in the
> base packages in some intelligent way (as opposed to my way) or pointers to
> some docs I should read, I'd appreciate it.

Chris,

I think subclassing/overriding is a good way to go. This is a common
technique among users of the CGI::Application package. 

I have never needed to do anything special when upgrading CGI::App while
using this technique.

The syntax should be be:

package My::SubClass; 
use base 'CGI::Application';

... and then just add your override methods and new methods.
Scripts using the functionality may now need to refer to
My::SubClass instead. I don't how painful that naming chage would be.

	Mark

-- 
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
   ma...@su...     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .

[Openinteract-help] subclassing/overriding perhaps?

[Chris M. <Chr...@te...>]

Hello,

I make a good number of changes to the some of the base packages (esp. user)
but I'm wondering whether just mucking around in the base packages is the
best way to go about it.  It does make upgrading a bit painful.  My problem
is that I'm not sure what the "right way" would be, and my other problem is
that I have never (intentionally, anyway) subclassed or overridden anything.
So, if anyone has some ideas about how to implement modifications in the
base packages in some intelligent way (as opposed to my way) or pointers to
some docs I should read, I'd appreciate it.

Thanks,

Chris McDaniel
          

Re: [Openinteract-help] [Q] How could I fix the following error?

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

Sang Chul Choi wrote:
> Dear OpenInteract Guru:
> 
> I have my own package, Textview. It works at usual time. But, sometime the web
> page writes to me:
> 
> ========================================================================
> Fundamental part of OpenInteract (themes) not functioning; please contact the system administrator 
> ========================================================================
> 
> Then, the apache error log is:
> 
> It is said that it could not create session. How could I fix it? Did I write wrongly
> my pakcage, Textview?

The fact that it works most of the time means that some service is
failing from time to time. Does your site get a lot of traffic? From
the logs it looks like the database handle is timing out; this
happens to sites that don't get much traffic.

The next version of OI 1.x (1.59) won't fix this, but it should take
care of it happening again and again since it will expire any Apache
child whose database handle is unavailable.

Thanks,

Chris

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

[Openinteract-help] [Q] How could I fix the following error?

[Sang C. C. <go...@ha...>]

RGVhciBPcGVuSW50ZXJhY3QgR3VydToNCg0KSSBoYXZlIG15IG93biBwYWNrYWdlLCBUZXh0dmll
dy4gSXQgd29ya3MgYXQgdXN1YWwgdGltZS4gQnV0LCBzb21ldGltZSB0aGUgd2ViDQpwYWdlIHdy
aXRlcyB0byBtZToNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpGdW5kYW1lbnRhbCBwYXJ0IG9mIE9wZW5J
bnRlcmFjdCAodGhlbWVzKSBub3QgZnVuY3Rpb25pbmc7IHBsZWFzZSBjb250YWN0IHRoZSBzeXN0
ZW0gYWRtaW5pc3RyYXRvciANCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQpUaGVuLCB0aGUgYXBhY2hlIGVy
cm9yIGxvZyBpczoNCg0KSXQgaXMgc2FpZCB0aGF0IGl0IGNvdWxkIG5vdCBjcmVhdGUgc2Vzc2lv
bi4gSG93IGNvdWxkIEkgZml4IGl0PyBEaWQgSSB3cml0ZSB3cm9uZ2x5DQpteSBwYWtjYWdlLCBU
ZXh0dmlldz8NCg0KU2luY2VyZWx5IHlvdXMsDQoNClNhbmcgQ2h1bCBDaG9pDQoNCj09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PQ0KT3BlbkludGVyYWN0OjpFcnJvcjo6U3lzdGVtOjpjYW5ub3RfY3JlYXRlX3Nlc3Np
b24gKDMzNSkgPj4gQ2Fubm90IGNyZWF0ZSBzZXNzaW9uIC0tIHNvbWVvbmUgaXMgcHJvYmFibHkg
dXNpbmcgYSAgZGVmdW5jdCBrZXkNCiBvciBzb21ldGhpbmcuDQo+PiBFcnJvciB3aXRoIGNvZGUg
MzEwIHRocm93bi4gSW5mbzogREJEOjpteXNxbDo6c3QgZXhlY3V0ZSBmYWlsZWQ6IFRhYmxlICdt
eXNxbC5zZXNzaW9ucycgZG9lc24ndCBleGlzdCBhdCAvdXNyL2xvY2FsL2xpYi9wZQ0Kcmw1L3Np
dGVfcGVybC81LjguMC9BcGFjaGUvU2Vzc2lvbi9TdG9yZS9EQkkucG0gbGluZSA4Ni4NCiAgICAg
ICAgT3BlbkludGVyYWN0OjpFcnJvcjo6U3lzdGVtOjpsb2dfYW5kX3JldHVybignQkFDOjpFcnJv
ck9iamVjdD1IQVNIKDB4OThkNmMyOCknKSBjYWxsZWQgYXQgL3Vzci9sb2NhbC9saWIvcGVybDUv
c2l0ZV9wDQplcmwvNS44LjAvT3BlbkludGVyYWN0L0Vycm9yL1N5c3RlbS5wbSBsaW5lIDM0Mg0K
ICAgICAgICBPcGVuSW50ZXJhY3Q6OkVycm9yOjpTeXN0ZW06OmNhbm5vdF9jcmVhdGVfc2Vzc2lv
bignQkFDOjpFcnJvck9iamVjdD1IQVNIKDB4OThkNmMyOCknKSBjYWxsZWQgYXQgL3Vzci9sb2Nh
bC9saWIvcGVybDUNCi9zaXRlX3BlcmwvNS44LjAvT3BlbkludGVyYWN0L0Vycm9yL01haW4ucG0g
bGluZSAzOA0KICAgICAgICBPcGVuSW50ZXJhY3Q6OkVycm9yOjpNYWluOjpjYXRjaCgnT3Blbklu
dGVyYWN0OjpFcnJvcjo6TWFpbicsJ0JBQzo6RXJyb3JPYmplY3Q9SEFTSCgweDk4ZDZjMjgpJykg
Y2FsbGVkIGF0IChldmFsIDQ3NSkNCiBsaW5lIDM5DQogICAgICAgIEJBQzo6RXJyb3JPYmplY3Q6
OnRocm93KCdCQUM6OkVycm9yT2JqZWN0JywnSEFTSCgweDk4YmJmOTApJykgY2FsbGVkIGF0IC91
c3IvbG9jYWwvbGliL3Blcmw1L3NpdGVfcGVybC81LjguMC9PcGVuSW50ZQ0KcmFjdC9FcnJvci5w
bSBsaW5lIDk0DQogICAgICAgIE9wZW5JbnRlcmFjdDo6RXJyb3I6OnRocm93KCdPcGVuSW50ZXJh
Y3Q6OkVycm9yJywnSEFTSCgweDk4YmJmOTApJykgY2FsbGVkIGF0IC91c3IvbG9jYWwvbGliL3Bl
cmw1L3NpdGVfcGVybC81LjguMC9PcA0KZW5JbnRlcmFjdC9SZXF1ZXN0LnBtIGxpbmUgMTIzDQog
ICAgICAgIE9wZW5JbnRlcmFjdDo6UmVxdWVzdDo6dGhyb3coJ09wZW5JbnRlcmFjdDo6UmVxdWVz
dD1IQVNIKDB4ODljYjk2OCknLCdIQVNIKDB4OThiYmY5MCknKSBjYWxsZWQgYXQgL3Vzci9sb2Nh
bC9saWIvcGVybA0KNS9zaXRlX3BlcmwvNS44LjAvT3BlbkludGVyYWN0L1Nlc3Npb24vREJJLnBt
IGxpbmUgMzENCiAgICAgICAgT3BlbkludGVyYWN0OjpTZXNzaW9uOjpEQkk6Ol9jcmVhdGVfc2Vz
c2lvbignT3BlbkludGVyYWN0OjpTZXNzaW9uOjpEQkknLCcwNDE3NjllYTc2ZDJkNmI2ZTkzZmU5
NTY5ZTg2ZWMyOCcpIGNhbGxlZCBhDQp0IC91c3IvbG9jYWwvbGliL3Blcmw1L3NpdGVfcGVybC81
LjguMC9PcGVuSW50ZXJhY3QvU2Vzc2lvbi5wbSBsaW5lIDI2DQogICAgICAgIE9wZW5JbnRlcmFj
dDo6U2Vzc2lvbjo6cGFyc2UoJ09wZW5JbnRlcmFjdDo6U2Vzc2lvbjo6REJJJykgY2FsbGVkIGF0
IC91c3IvbG9jYWwvbGliL3Blcmw1L3NpdGVfcGVybC81LjguMC9PcGVuSW50ZXJhYw0KdC5wbSBs
aW5lIDI2MQ0KICAgICAgICBldmFsIHsuLi59IGNhbGxlZCBhdCAvdXNyL2xvY2FsL2xpYi9wZXJs
NS9zaXRlX3BlcmwvNS44LjAvT3BlbkludGVyYWN0LnBtIGxpbmUgMjU2DQogICAgICAgIE9wZW5J
bnRlcmFjdDo6c2V0dXBfY29va2llc19hbmRfc2Vzc2lvbignT3BlbkludGVyYWN0JywnT3Blbklu
dGVyYWN0OjpSZXF1ZXN0PUhBU0goMHg4OWNiOTY4KScpIGNhbGxlZCBhdCAvdXNyL2xvY2FsLw0K
bGliL3Blcmw1L3NpdGVfcGVybC81LjguMC9PcGVuSW50ZXJhY3QucG0gbGluZSA1MA0KICAgICAg
ICBldmFsIHsuLi59IGNhbGxlZCBhdCAvdXNyL2xvY2FsL2xpYi9wZXJsNS9zaXRlX3BlcmwvNS44
LjAvT3BlbkludGVyYWN0LnBtIGxpbmUgNDQNCiAgICAgICAgT3BlbkludGVyYWN0OjpoYW5kbGVy
KCdPcGVuSW50ZXJhY3QnLCdBcGFjaGU9U0NBTEFSKDB4ODU3YjhiOCknKSBjYWxsZWQgYXQgL2Rl
di9udWxsIGxpbmUgMA0KDQouLi4uLi4NCg0KU0VMRUNUICogRlJPTSBzeXNfZXJyb3IgV0hFUkUg
MSA9IDAgYXQgL3Vzci9sb2NhbC9saWIvcGVybDUvc2l0ZV9wZXJsLzUuOC4wL09wZW5JbnRlcmFj
dC9FcnJvci9TeXN0ZW0ucG0gbGluZSAzOTQNCj4+IEVycm9yIHRocm93biBmb3Igbm90IGJlaW5n
IGFibGUgdG8gZmV0Y2ggYW4gb2JqZWN0LiBNc2c6IERCRDo6bXlzcWw6OnN0IGV4ZWN1dGUgZmFp
bGVkOiBUYWJsZSAnbXlzcWwuc3lzX3NlY3VyaXR5JyBkb2Vzbid0DQogZXhpc3QgYXQgL3Vzci9s
b2NhbC9saWIvcGVybDUvc2l0ZV9wZXJsLzUuOC4wL1NQT1BTL1NRTEludGVyZmFjZS5wbSBsaW5l
IDEyMi4NCiAgICAgICAgT3BlbkludGVyYWN0OjpFcnJvcjo6U3lzdGVtOjpjYW5ub3RfZmV0Y2go
J0JBQzo6RXJyb3JPYmplY3Q9SEFTSCgweDk5MTQ2NGMpJykgY2FsbGVkIGF0IC91c3IvbG9jYWwv
bGliL3Blcmw1L3NpdGVfcGVyDQpsLzUuOC4wL09wZW5JbnRlcmFjdC9FcnJvci9NYWluLnBtIGxp
bmUgMzgNCiAgICAgICAgT3BlbkludGVyYWN0OjpFcnJvcjo6TWFpbjo6Y2F0Y2goJ09wZW5JbnRl
cmFjdDo6RXJyb3I6Ok1haW4nLCdCQUM6OkVycm9yT2JqZWN0PUhBU0goMHg5OTE0NjRjKScpIGNh
bGxlZCBhdCAoZXZhbCA0NzUpDQogbGluZSAzOQ0KICAgICAgICBCQUM6OkVycm9yT2JqZWN0Ojp0
aHJvdygnQkFDOjpFcnJvck9iamVjdCcsJ0hBU0goMHg5OTExMTI0KScpIGNhbGxlZCBhdCAvdXNy
L2xvY2FsL2xpYi9wZXJsNS9zaXRlX3BlcmwvNS44LjAvT3BlbkludGUNCnJhY3QvRXJyb3IucG0g
bGluZSA5NA0KICAgICAgICBPcGVuSW50ZXJhY3Q6OkVycm9yOjp0aHJvdygnT3BlbkludGVyYWN0
OjpFcnJvcicsJ0hBU0goMHg5OTExMTI0KScpIGNhbGxlZCBhdCAvdXNyL2xvY2FsL2xpYi9wZXJs
NS9zaXRlX3BlcmwvNS44LjAvT3ANCmVuSW50ZXJhY3QvUmVxdWVzdC5wbSBsaW5lIDEyMw0KICAg
ICAgICBPcGVuSW50ZXJhY3Q6OlJlcXVlc3Q6OnRocm93KCdPcGVuSW50ZXJhY3Q6OlJlcXVlc3Q9
SEFTSCgweDg5Y2I5NjgpJywnSEFTSCgweDk5MTExMjQpJykgY2FsbGVkIGF0IC91c3IvbG9jYWwv
bGliL3BlcmwNCjUvc2l0ZV9wZXJsLzUuOC4wL09wZW5JbnRlcmFjdC5wbSBsaW5lIDMzOQ0KICAg
ICAgICBPcGVuSW50ZXJhY3Q6OnNldHVwX3RoZW1lKCdPcGVuSW50ZXJhY3QnLCdPcGVuSW50ZXJh
Y3Q6OlJlcXVlc3Q9SEFTSCgweDg5Y2I5NjgpJykgY2FsbGVkIGF0IC91c3IvbG9jYWwvbGliL3Bl
cmw1L3NpdGUNCl9wZXJsLzUuOC4wL09wZW5JbnRlcmFjdC5wbSBsaW5lIDUyDQogICAgICAgIGV2
YWwgey4uLn0gY2FsbGVkIGF0IC91c3IvbG9jYWwvbGliL3Blcmw1L3NpdGVfcGVybC81LjguMC9P
cGVuSW50ZXJhY3QucG0gbGluZSA0NA0KICAgICAgICBPcGVuSW50ZXJhY3Q6OmhhbmRsZXIoJ09w
ZW5JbnRlcmFjdCcsJ0FwYWNoZT1TQ0FMQVIoMHg4NTdiOGI4KScpIGNhbGxlZCBhdCAvZGV2L251
bGwgbGluZSAwDQogICAgICAgIGV2YWwgey4uLn0gY2FsbGVkIGF0IC9kZXYvbnVsbCBsaW5lIDAN
CiBDYW5ub3Qgc2F2ZSBlcnJvciA0MDQ6IERCRDo6bXlzcWw6OnN0IGV4ZWN1dGUgZmFpbGVkOiBU
YWJsZSAnbXlzcWwuc3lzX2Vycm9yJyBkb2Vzbid0IGV4aXN0IGF0IC91c3IvbG9jYWwvbGliL3Bl
cmw1L3NpdGVfcGVyDQpsLzUuOC4wL1NQT1BTL0RCSS9UeXBlSW5mby5wbSBsaW5lIDE0NC4NCg0K
U0VMRUNUICogRlJPTSBzeXNfZXJyb3IgV0hFUkUgMSA9IDAgYXQgL3Vzci9sb2NhbC9saWIvcGVy
bDUvc2l0ZV9wZXJsLzUuOC4wL09wZW5JbnRlcmFjdC9FcnJvci9TeXN0ZW0ucG0gbGluZSAzOTQN
Ck9wZW5JbnRlcmFjdDo6c2V0dXBfdGhlbWUgKDM0MCkgPj4gRXJyb3IhIENhbm5vdCByZXRyaWV2
ZSB0aGVtZSEgKCBDbGFzczogIEJBQzo6VGhlbWUgKSB3aXRoIGVycm9yIChEQkQ6Om15c3FsOjpz
dCBleGVjdXRlIGZhDQppbGVkOiBUYWJsZSAnbXlzcWwuc3lzX2Vycm9yJyBkb2Vzbid0IGV4aXN0
IGF0IC91c3IvbG9jYWwvbGliL3Blcmw1L3NpdGVfcGVybC81LjguMC9TUE9QUy9EQkkvVHlwZUlu
Zm8ucG0gbGluZSAxNDQuDQoNClNFTEVDVCAqIEZST00gc3lzX2Vycm9yIFdIRVJFIDEgPSAwIC8g
REJEOjpteXNxbDo6c3QgZXhlY3V0ZSBmYWlsZWQ6IFRhYmxlICdteXNxbC5zeXNfc2VjdXJpdHkn
IGRvZXNuJ3QgZXhpc3QgYXQgL3Vzci9sb2NhbC9sDQppYi9wZXJsNS9zaXRlX3BlcmwvNS44LjAv
U1BPUFMvU1FMSW50ZXJmYWNlLnBtIGxpbmUgMTIyLg0KKSBIZWxwIQ0KIC0tRVhJVEVEIFdJVEgg
RVJST1IgZnJvbSBtYWluIGhhbmRsZXIgZXZhbCBibG9jaw0KRXJyb3I6IDANCj09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PQ==

Re: [Openinteract-help] oi2 installation

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

Cole Keirsey wrote:
> Using the full path got me one step forward.  I then edited server.ini
> according to the docs.  I used the ID/pwd for my MySQL database that works
> for my OI site. I created a new database, then ran oi_manage ... test_db
> It errors out with:
> 
> The key db_info in your configuration must be a hashref.
> No connection attempted.

Did you run 'oi_manage' or 'oi2_manage'? That message is from 
oi_manage (from OI 1.x). Also changed between 1.x and 2.x is the 
environment variable used:

1.x
Environment: OIWEBSITE
Script:      oi_manage

2.x
Environment: OPENINTERACT2
Script:      oi2_manage

Hope this helps,

Chris

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

RE: [Openinteract-help] oi2 installation

[Cole K. <cke...@vi...>]

Using the full path got me one step forward.  I then edited server.ini
according to the docs.  I used the ID/pwd for my MySQL database that works
for my OI site. I created a new database, then ran oi_manage ... test_db
It errors out with:

The key db_info in your configuration must be a hashref.
No connection attempted.

I can't find reference to such a key in server.ini.  Any ideas?

Thanks in advance,
Cole

-----Original Message-----
From: ope...@li...
[mailto:ope...@li...]On Behalf Of Chris
Winters
Sent: Tuesday, July 01, 2003 11:30 AM
To: Cole Keirsey
Cc: ope...@li...
Subject: Re: [Openinteract-help] oi2 installation


...

Try using the full path (/usr/local/OpenInteract-1.99_00) instead of
  the relative (.). This has to do with how the packages get
installed -- they don't deal with relative pathnames well. IIRC
there's a brief note in the intro docs about this and I hope to fix
it shortly.

Later,

Chris

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



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
openinteract-help mailing list
ope...@li...
https://lists.sourceforge.net/lists/listinfo/openinteract-help

Re: [Openinteract-help] oi2 installation

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

Cole Keirsey wrote:
> Turns out SQLite was installed, but I needed Apache::Session::SQLite.
> Installing that got rid of the related failed tests during 'make test', but
> the failure related to manage_create_website remained.

That's good.

> I still have the same problem with installing the web site. I'm running
> oi2_manage as root from within /usr/local/OpenInteract-1.99_00, where I
> unpacked the distribution.  I'm using --source_dir=. as the instructions say
> to.  The website dir is /home/cole/oi2, in my home directory when I'm not
> root. Everything else (template files, etc.) gets created there without
> problem.  (By the way, the INSTALL.website file created there refers to
> oi_manage rather than oi2_manage.  Is that correct?)
> OpenInteract-1.99_00/pkg exists and contains the .zip files.  I changed
> permissions to allow anyone to read & execute those zip files.  Still have
> the same problem...
> ??

Try using the full path (/usr/local/OpenInteract-1.99_00) instead of 
  the relative (.). This has to do with how the packages get 
installed -- they don't deal with relative pathnames well. IIRC 
there's a brief note in the intro docs about this and I hope to fix 
it shortly.

Later,

Chris

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

RE: [Openinteract-help] oi2 installation

[Cole K. <cke...@vi...>]

Turns out SQLite was installed, but I needed Apache::Session::SQLite.
Installing that got rid of the related failed tests during 'make test', but
the failure related to manage_create_website remained.

I still have the same problem with installing the web site. I'm running
oi2_manage as root from within /usr/local/OpenInteract-1.99_00, where I
unpacked the distribution.  I'm using --source_dir=. as the instructions say
to.  The website dir is /home/cole/oi2, in my home directory when I'm not
root. Everything else (template files, etc.) gets created there without
problem.  (By the way, the INSTALL.website file created there refers to
oi_manage rather than oi2_manage.  Is that correct?)
OpenInteract-1.99_00/pkg exists and contains the .zip files.  I changed
permissions to allow anyone to read & execute those zip files.  Still have
the same problem...
??

-----Original Message-----
From: Chris Winters [mailto:ch...@cw...]
Sent: Tuesday, July 01, 2003 10:07 AM
To: Cole Keirsey
Cc: ope...@li...
Subject: Re: [Openinteract-help] oi2 installation


Cole Keirsey wrote:
> During openinteract install, make test produces a couple of errors related
> to SQLite (which I'm not using anyway) and the error:
> t/manage_create_website NOK got 3 expected 2

The tests use SQLite to create a website, store data, etc. If you
could install the module it would be a help.

> When I try to install a web site, all package installations fail with
> messages like:
> cannot unpack distribution into its final directory
> cannot extract archive from pkg/base-box-2.01.zip
> invalid file

That's odd... when you create the website what is your source
directory set to? That is, you should have something like this:

# OI2 distribution unpacked to /path/to/build/OpenInteract-1.99_00

  /path/to/build/OpenInteract-1.99_00/pkg/...
  /path/to/build/OpenInteract-1.99_00/sample/...

$ oi2_manage create_website \
      --website_dir=/path/to/mysite \
      --source_dir=/path/to/build/OpenInteract-1.99_00

And /path/to/build/OpenInteract-1.99_00 must be readable by the user
executing the command and have 'pkg/base_box-2.01.zip' and all the
other files.

The next beta (1.99_01) should be out by Wednesday evening and will
have (among other things) a 'create_source_dir' task so you don't
have to keep using the distribution directory (which is often
unpacked by root in /root or some other inaccessible place).

Later,

Chris

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