openinteract-dev — For OI developers, includes project coordination and technical discussion.

[Openinteract-dev] tiny oi2_manage bug

[forehead<for...@4r...>]

hi, openinteract-dev


oi2_manage, line 70:
    my $log_level = ( $OPT_debug == 1 ) ? $INFO : $DEBUG;

should be:
    my $log_level = ( $OPT_debug == 1 ) ? $DEBUG : $INFO;

 				
----------------------
forehead (Chun Sheng)
for...@4r...
2003-11-02

[Openinteract-dev] How to write OI like system's code when developing?

[forehead<for...@4r...>]

aGksIG9wZW5pbnRlcmFjdC1kZXYNCg0KY291bGQgeW91IGdpdmUgbWUgdGhlIHNjaGVtZSBob3cg
dG8gd3JpdGUgT0kgc3lzdGVtIHdoZW4gdGhlIHN5c3RlbSBwa2dzIG5vdCB5ZXQgDQpjb21lIGlu
dG8gc3RhYmxlLCBhbmQgZGVidWcgdGhlIHBrZydzIGNvZGVzIGFuZCB0aGUgc3lzdGVtIGNvcmUg
Y29kZXM/DQoNCnNpbmNlIHlvdXIgY29kZXMgbmVlZDogd3JpdGUgLCBpbnN0YWxsLCB0ZXN0LCBk
ZWJ1ZywgbW9kaWZ5KCBjb3JlIGNvZGUsIG9yIGluc3RhbGwgY29kZSwgb3IgcGtnIGNvZGUpDQph
bmQgZ28gdGhyb3VnaCBhbGwgdGhlIHN0ZXBzIGFnYWluIGFuZCBhZ2FpbiwgYW55IHNraWxscyBv
ciBpZGVhcyBmb3IgbW9yZSBlZmZlY3RpdmUgY29kaW5nPw0KDQpzaW5jZSBJIHdhbm5lciBkbyBz
b21lIGNoYW5nZSBmb3IgYWxsIHN5c3RlbSBiYXNlZCBvbiB5b3VyIE9JMiBjb2RlLg0KDQpFbnZl
cmlvbWVudDoNCkFwYWNoZSB3aXRoIG1vZGVfcGVybDogYWZ0ZXIgZWRpdCB0aGUgTW9kdWxlIGZp
bGUgKCoucG0pLGl0IHNlZW1zIHNob3VsZCByZXN0YXJ0IGFwYWNoZSB0byBsb2FkIHRoZQ0KbmV3
IC5wbSBmaWxlcywgdGhlbiB0ZXN0IHRoZSBjb2Rlcy4NCg0KQXBhY2hlIHdpdGhvdXQgbW9kX3Bl
cmw6IGp1c3QgY2dpIHJlZ3Vlc3QgdHlwZSwgSSBzdGlsbCBub3QgdW5kZXJzdGFuZCBob3cgdG8g
cmVxdWVzdCAvdXNlci9OZXdVc2VyIA0KZm9yIGNnaSBlbnYuIElzIGl0IGh0dHA6Ly9zaXRlL2Nn
aS1iaW4vdXNlci9OZXdVc2VyL29pMi5jZ2k/Zm9vPWJhciAgPyBvciBvdGhlcnM/DQoNClN0YW5k
YWxvbmU6IHNob3VsZCByZXN0YXJ0IHRoZSBkZWFtb24gPyBvciBqdXN0IGxlYXZlIGl0PyBJIG5v
dCB5ZXQgdGVzdCB0aHVzLCBzaW5jZSBJIHdhbm5lciBteSBjb2RlDQpydW4gdW5kZXIgYXBhY2hl
IHdpdGggbW9kX3BlcmwuDQoNCg0KDQogCQkJCQ0KDQqhoaGhoaGhoaGhoaGhoaGhZm9yZWhlYWQg
KENodW4gU2hlbmcpDQqhoaGhoaGhoaGhoaGhoaGhZm9yZWhlYWRANHJlZC5vcmcNCqGhoaGhoaGh
oaGhoaGhoaGhoaGhMjAwMy0xMS0wMQ0K

Re: [Openinteract-dev] OI2 i18n support

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

* Andrew Hurst (hur...@ll...) [031030 13:52]:
> The only possible problem I see, is that this could be solving a 
> non-existant problem.  It would be neat to be able to restrict 
> documents to users based on language, but how often would that be 
> needed?  Even on multi-language discussion boards, I don't see a 
> reason for not letting people know about the other boards...

Absolutely. I'm much better about keeping things simple than I used to
be, so I doubt I'd implement this until I had a good reason.

Chris

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

Re: [Openinteract-dev] OI2 i18n support

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

>Andrew Hurst wrote:
>...
>
>So the 'Optiron' in my example -- which is my day job :-) -- would 
>get interpolated into %1 when the message is placed.

Ah, makes sense now.

>....
>
>>I think it would be handy, if you could work some of that SPOPS 
>>magic and have SPOPS know how to handle added language fields.  So 
>>you could add a 'lang' key to the hash we'd pass to SPOPS, and it 
>>would know to restrict results to that language, but only if we 
>>configured it that way.  This would require the aforementioned 
>>field in each table, I would think.
>>
>>This would be beneficial in that it would act like the SPOPS 
>>security actions, where the other rows don't exist if you don't 
>>have access to them.
>
>Hmmm... very interesting. I could see adding this as a behavior as 
>well ('localizable' or something like that), which overrides 'fetch' 
>to use the given language as another criteria.


The only possible problem I see, is that this could be solving a 
non-existant problem.  It would be neat to be able to restrict 
documents to users based on language, but how often would that be 
needed?  Even on multi-language discussion boards, I don't see a 
reason for not letting people know about the other boards...

-Andrew


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

Re: [Openinteract-dev] New Idea about Session and Theme

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

forehead wrote:
> Maybe in the future, there will has ShopCart pkg in OI2 system.
> of course we need a new session to save the cart's info. and need a different 
> SESSION_COOKIE to set cookie and logout handler.

Actually there is a 'cart' package in the 'extra_packages'
directory of CVS. I haven't visited it in quite some time but it
should work ok. (I'll rewrite it for OI2 and actually release it
once OI2 is final.)

> so my new idea is split the SESSION_COOKIE value into a Session Name which indcate
> which session is to be handle.

I'm not sure I understand this. You can put anything you want in
the session, including a shopping cart object. (That might not be
smart for high-volume sites, in those cases you'll want to just
put a key and maybe frequently accessed data like number of items
in the cart.)

Anyway, you can do something like:

  my $cart = My::ShoppingCart->new();
  $cart->add( $product, 2 );
  $cart->add( $product_other, 1 );

  # OI 1.x:
  $R->{session}{cart} = $cart;

  # OI 2.x:
  my $request = CTX->request;
  $request->session->{cart} = $cart;

And then retrieve it later:

 # OI 1.x
 my $cart = $R->{session}{cart};

 # OI 2.x
 my $request = CTX->request;
 my $cart = $request->session->{cart};

 my $products = $cart->list_products;
 ...

> Another idea about the OI is, init conf with different $ENV{'HTTP_HOST'} , and load
> some site's own configure. that's like the apache's vitual host stuff. Since many
> sites maybe in almost the same.

Actually one of the reasons OI 1.x is a bit overengineered is to
accommodate this -- running multiple instances of OI inside a
single Apache server. The problem is that very few people
actually want to do this, and the engineering necessary to make
this happen (juggling namespaces, etc.) really gets in the way of
normal usage. So that's not around in OI 2.x.

> Another idea about Theme:
> and the template with theme maybe look like thus:
> 
> pkg
>  \-- [StyleName_1] \ templates\[some html template files]
>                    \ [SkinName_1]\[some images or flash or anything associate with this skin]	
>                    \ [SkinName_2]\[some images or flash or anything associate with this skin]	
>                    \ [SkinName_3]\[some images or flash or anything associate with this skin]	
> ...
>
> and in top level there is a theme object which defines which package use which Style and use
> which Skin for this style. 

This is interesting. So this allows you to change component
templates by theme as well as fetch resources (images, movies,
etc.) by theme. I'll have to noodle over this.

> futher more, we can build some global template widgets , for meet the pkg template use, eg:
> button, navigation, bar, box, tabbed_box, and so on, anything.

Right.

> and all the Style and Skin should be build as a little module or package and some tools could 
> manage them ( install, uninstall, upgrade, and so on)

There's already some support for standalone themes ('themeballs')
that you can manipulate with oi2_manage. (mostly untested of
course...)

> btw, every pkg's template may use some language define file to satisfy with multi-language sites.

This goes along with the separate i18n discussion going on right
now. I hadn't thought about this approach -- using an entirely
separate template instead of message tags....

Very useful, thanks.

Chris

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

Re: [Openinteract-dev] OI2 i18n support

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

Andrew Hurst wrote:
> No real direct experience, but we talked a lot about how to do this in 
> Scoop..  The general consensus was pretty much what you have below.  Key 
> phrases will be in a lookup table with keys and a column for each 
> language.   Then you could insert it into a template with
> 
> [% msg('company.welcome', 'Russian' ) %]
> 
> Which is what you have below, though I've not heard of the term Optiron 
> before...

Sorry, I wasn't clear. The extra arguments are for interpolation 
into the tag's message. Using the Java message bundle properties 
format you might have:

resources_en.properties
----------------------------------------
company.welcome = Welcome to %1

resources_es.properties
----------------------------------------
company.welcome = Bienvenido a %1

So the 'Optiron' in my example -- which is my day job :-) -- 
would get interpolated into %1 when the message is placed.

The correct bundle would be chosen based on the language grabbed 
from the user's browser, from a user selection (stored in a 
cookie or session), or from the user's 'language' preference (if 
the user is logged in). That decision on what language is valid 
for the current request will be overridable so you can choose 
your own.

> But regarding your other feature, with /ru, /es, or whatever based on 
> the language.  You talk about each language only having write access to 
> their own documents (if you set it up that way I would assume). How 

Right, you'd still have to use the normal security setup so that 
'/ru' would be writable by a group 'russian-editors' or something 
like that.

> would you tell what language a particular document stored in the db is 
> in?  Another field?  So now most base tables and most package tables 
> would need to handle another field and check for it?

Good question, I haven't thought about this. My initial intent 
with documents was to provide a transparent way to use a single 
URL to refer to multiple documents depending on the language. 
(You could also use '/ru/about/company.html' so you can send a 
particular URL to someone and get a predictable result.)

> I think it would be handy, if you could work some of that SPOPS magic 
> and have SPOPS know how to handle added language fields.  So you could 
> add a 'lang' key to the hash we'd pass to SPOPS, and it would know to 
> restrict results to that language, but only if we configured it that 
> way.  This would require the aforementioned field in each table, I would 
> think.
>
> This would be beneficial in that it would act like the SPOPS security 
> actions, where the other rows don't exist if you don't have access to them.

Hmmm... very interesting. I could see adding this as a behavior 
as well ('localizable' or something like that), which overrides 
'fetch' to use the given language as another criteria.

Later,

Chris

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

Re: [Openinteract-dev] OI2 i18n support

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

No real direct experience, but we talked a lot about how to do this 
in Scoop..  The general consensus was pretty much what you have 
below.  Key phrases will be in a lookup table with keys and a column 
for each language.   Then you could insert it into a template with

[% msg('company.welcome', 'Russian' ) %]

Which is what you have below, though I've not heard of the term 
Optiron before...

But regarding your other feature, with /ru, /es, or whatever based on 
the language.  You talk about each language only having write access 
to their own documents (if you set it up that way I would assume). 
How would you tell what language a particular document stored in the 
db is in?  Another field?  So now most base tables and most package 
tables would need to handle another field and check for it?

I think it would be handy, if you could work some of that SPOPS magic 
and have SPOPS know how to handle added language fields.  So you 
could add a 'lang' key to the hash we'd pass to SPOPS, and it would 
know to restrict results to that language, but only if we configured 
it that way.  This would require the aforementioned field in each 
table, I would think.

This would be beneficial in that it would act like the SPOPS security 
actions, where the other rows don't exist if you don't have access to 
them.

Well, that's enough pre-coffee rambling for this morning.  Sounds 
like a neat setup.
-Andrew


>...
>
>  * message bundle-type functionality so you can setup a file (or 
>database table, or whatever) of keys for substitution in your 
>templates:
>
>  # use a key with variable substitution
>  <h1>[% msg( 'company.welcome', 'Optiron' ) %]
>
>  # use a key by itself
>  <p>[% msg( 'company.intro' ) %]</p>
>
>If you've got experience in this area please chime in with ideas.
>
>Later,
>
>Chris
>
>--
>Chris Winters (ch...@cw...)
>Building enterprise-capable snack solutions since 1988.
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.
>Does SourceForge.net help you be more productive?  Does it
>help you create better code?   SHARE THE LOVE, and help us help
>YOU!  Click Here: http://sourceforge.net/donate/
>_______________________________________________
>openinteract-dev mailing list
>ope...@li...
>https://lists.sourceforge.net/lists/listinfo/openinteract-dev

[Openinteract-dev] OI2 i18n support

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

As I recently mentioned on the -help list I hope to be doing some 
work in the near future to give i18n support to OI2. This would 
come in two fashions:

  * be able to navigate to a particular page in the document tree 
based on language. So you'd have something like:

    /en/about/company.html
    /ru/about/company.html

And a user requesting:

   http://mysite/about/company.html

would get directed to the right page based on browser or session 
or user settings. One of the reasons I think the '/lang/...' 
setup is useful is security -- you can setup the '/ru/...' tree 
so your Russian folks can have WRITE access only to their docs, 
the '/es/...' tree so your Spanish folks can do their thing, etc.

  * message bundle-type functionality so you can setup a file (or 
database table, or whatever) of keys for substitution in your 
templates:

  # use a key with variable substitution
  <h1>[% msg( 'company.welcome', 'Optiron' ) %]

  # use a key by itself
  <p>[% msg( 'company.intro' ) %]</p>

If you've got experience in this area please chime in with ideas.

Later,

Chris

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

Re: [Openinteract-dev] Bug in base_page module

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

Teemu wrote:
> page actions -> directory index has a bug. "map new directory handler" which
> seems to be create action for PageDirectory doesn't work. If you enter a new
> directory over there and press Modify, you get "Error: Object modification
> failed. Error found:". I looked at it a little bit and noticed that a new
> page is not created if old_directory parameter is empty (currently a hidden
> field on the Create New Directory Handler-page). If I forge the URL to be
> something like:
> 
> /PageDirectory/create/?old_directory=/whatever
> 
> .. and then type the directory name I want, it will work and create a new
> directory.
> 
> If you edit some directory, you can also change the Directory location, 
> resulting in a new directory handler. This obviously doesn't sound like 
> editing but creating a new one. Maybe in edit mode editing the directory 
> location should be restricted.

You know what's even weirder? I re-created this bug and got the same 
error as you, but when I tried to immediately re-run the same action it 
worked! What's even stranger is that the first time I see the following 
in the log:

OpenInteract::Handler::GenericDispatcher::handler (32) >> Trying to run
    [MySite::Handler::PageDirectory] with [edit]
OpenInteract::CommonHandler::_edit_assign_fields (593) >> Object edit:
    (page_directory) (directory) ()
OpenInteract::CommonHandler::_edit_assign_fields (593) >> Object edit:
    (page_directory) (action) ()
OpenInteract::CommonHandler::_edit_assign_fields (601) >> Object edit
    toggle: (page_directory) (subdirs_inherit) (no)

Those second and third sets of lines are what concern me -- it looks 
like the data aren't being passed back properly or something.... Here's 
what it should look like (what I got on the next attempt):

OpenInteract::Handler::GenericDispatcher::handler (32) >> Trying to run
    [MySite::Handler::PageDirectory] with [edit]
OpenInteract::CommonHandler::_edit_assign_fields (593) >> Object edit:
    (page_directory) (directory) (/foo)
OpenInteract::CommonHandler::_edit_assign_fields (593) >> Object edit:
    (page_directory) (action) (simple_index)
OpenInteract::CommonHandler::_edit_assign_fields (601) >> Object edit
    toggle: (page_directory) (subdirs_inherit) (yes)

More investigation is clearly required here...

> Also, another bug I found occurs when you create a page in location
> /test/test.html and then try to create a page in location /test.
> 
> /test will be created but the content you enter doesn't display at all and it
> acts strangely and it's impossible to remove /test after creating it unless 
> you do it manually (if you do search page and go to /test you can modify it, 
> but if you press remove it displays an empty page instead of removing it).

More on this soon...

Chris

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

[Openinteract-dev] New Idea about Session and Theme

[forehead<for...@4r...>]

aGksIG9wZW5pbnRlcmFjdC1kZXYNCg0KTWF5YmUgaW4gdGhlIGZ1dHVyZSwgdGhlcmUgd2lsbCBo
YXMgU2hvcENhcnQgcGtnIGluIE9JMiBzeXN0ZW0uDQpvZiBjb3Vyc2Ugd2UgbmVlZCBhIG5ldyBz
ZXNzaW9uIHRvIHNhdmUgdGhlIGNhcnQncyBpbmZvLiBhbmQgbmVlZCBhIGRpZmZlcmVudCANClNF
U1NJT05fQ09PS0lFIHRvIHNldCBjb29raWUgYW5kIGxvZ291dCBoYW5kbGVyLg0KDQpzbyBteSBu
ZXcgaWRlYSBpcyBzcGxpdCB0aGUgU0VTU0lPTl9DT09LSUUgdmFsdWUgaW50byBhIFNlc3Npb24g
TmFtZSB3aGljaCBpbmRjYXRlDQp3aGljaCBzZXNzaW9uIGlzIHRvIGJlIGhhbmRsZS4NCg0KQW5v
dGhlciBpZGVhIGFib3V0IHRoZSBPSSBpcywgaW5pdCBjb25mIHdpdGggZGlmZmVyZW50ICRFTlZ7
J0hUVFBfSE9TVCd9ICwgYW5kIGxvYWQNCnNvbWUgc2l0ZSdzIG93biBjb25maWd1cmUuIHRoYXQn
cyBsaWtlIHRoZSBhcGFjaGUncyB2aXR1YWwgaG9zdCBzdHVmZi4gU2luY2UgbWFueQ0Kc2l0ZXMg
bWF5YmUgaW4gYWxtb3N0IHRoZSBzYW1lLg0KDQpBbm90aGVyIGlkZWEgYWJvdXQgVGhlbWU6DQph
bmQgdGhlIHRlbXBsYXRlIHdpdGggdGhlbWUgbWF5YmUgbG9vayBsaWtlIHRodXM6DQoNCnBrZw0K
IFwtLSBbU3R5bGVOYW1lXzFdIFwgdGVtcGxhdGVzXFtzb21lIGh0bWwgdGVtcGxhdGUgZmlsZXNd
DQogICAgICAgICAgICAgICAgICAgXCBbU2tpbk5hbWVfMV1cW3NvbWUgaW1hZ2VzIG9yIGZsYXNo
IG9yIGFueXRoaW5nIGFzc29jaWF0ZSB3aXRoIHRoaXMgc2tpbl0JDQogICAgICAgICAgICAgICAg
ICAgXCBbU2tpbk5hbWVfMl1cW3NvbWUgaW1hZ2VzIG9yIGZsYXNoIG9yIGFueXRoaW5nIGFzc29j
aWF0ZSB3aXRoIHRoaXMgc2tpbl0JDQogICAgICAgICAgICAgICAgICAgXCBbU2tpbk5hbWVfM11c
W3NvbWUgaW1hZ2VzIG9yIGZsYXNoIG9yIGFueXRoaW5nIGFzc29jaWF0ZSB3aXRoIHRoaXMgc2tp
bl0JDQogXC0tIFtTdHlsZU5hbWVfMl0gXCB0ZW1wbGF0ZXNcW3NvbWUgaHRtbCB0ZW1wbGF0ZSBm
aWxlc10NCiAgICAgICAgICAgICAgICAgICBcIFtTa2luTmFtZV8xXVxbc29tZSBpbWFnZXMgb3Ig
Zmxhc2ggb3IgYW55dGhpbmcgYXNzb2NpYXRlIHdpdGggdGhpcyBza2luXQkNCiAgICAgICAgICAg
ICAgICAgICBcIFtTa2luTmFtZV8yXVxbc29tZSBpbWFnZXMgb3IgZmxhc2ggb3IgYW55dGhpbmcg
YXNzb2NpYXRlIHdpdGggdGhpcyBza2luXQkNCiAgICAgICAgICAgICAgICAgICBcIFtTa2luTmFt
ZV8zXVxbc29tZSBpbWFnZXMgb3IgZmxhc2ggb3IgYW55dGhpbmcgYXNzb2NpYXRlIHdpdGggdGhp
cyBza2luXQkNCg0KDQphbmQgaW4gdG9wIGxldmVsIHRoZXJlIGlzIGEgdGhlbWUgb2JqZWN0IHdo
aWNoIGRlZmluZXMgd2hpY2ggcGFja2FnZSB1c2Ugd2hpY2ggU3R5bGUgYW5kIHVzZQ0Kd2hpY2gg
U2tpbiBmb3IgdGhpcyBzdHlsZS4gDQoNCmZ1dGhlciBtb3JlLCB3ZSBjYW4gYnVpbGQgc29tZSBn
bG9iYWwgdGVtcGxhdGUgd2lkZ2V0cyAsIGZvciBtZWV0IHRoZSBwa2cgdGVtcGxhdGUgdXNlLCBl
ZzoNCmJ1dHRvbiwgbmF2aWdhdGlvbiwgYmFyLCBib3gsIHRhYmJlZF9ib3gsIGFuZCBzbyBvbiwg
YW55dGhpbmcuDQoNCmFuZCBhbGwgdGhlIFN0eWxlIGFuZCBTa2luIHNob3VsZCBiZSBidWlsZCBh
cyBhIGxpdHRsZSBtb2R1bGUgb3IgcGFja2FnZSBhbmQgc29tZSB0b29scyBjb3VsZCANCm1hbmFn
ZSB0aGVtICggaW5zdGFsbCwgdW5pbnN0YWxsLCB1cGdyYWRlLCBhbmQgc28gb24pDQoNCmJ0dywg
ZXZlcnkgcGtnJ3MgdGVtcGxhdGUgbWF5IHVzZSBzb21lIGxhbmd1YWdlIGRlZmluZSBmaWxlIHRv
IHNhdGlzZnkgd2l0aCBtdWx0aS1sYW5ndWFnZSBzaXRlcy4NCg0KIAkJCQkNCg0KoaGhoaGhoaGh
oaGhoaGhoWZvcmVoZWFkIChDaHVuIFNoZW5nKQ0KoaGhoaGhoaGhoaGhoaGhoWZvcmVoZWFkQDRy
ZWQub3JnDQqhoaGhoaGhoaGhoaGhoaGhoaGhoTIwMDMtMTAtMzANCg==

Re: [Openinteract-dev] "PerlSendHeader On"

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

forehead wrote:
>> Do you mean you should *remove* this line? OI2 should take
>> care of all the headers for you -- it's one of the last
>> things done in OI2::Response::Apache->send().
> 
> I meadn *add* this line into Location container.
> 
> default as your sample, OI's http header will print on
> browser's screen, then the cookie can not properly set. add
> the line, everything is ok.
> 
> env: apache + mod_perl

Oh, I see. We're telling Apache that we'll be sending the
headers. What's confusing me is that we don't have to do this
(add PerlSendHeader) for OI 1.x. That is, in OI 1.x we have:

OpenInteract.pm:
----------------------------------------
sub send_html {
    my ( $class, $apache, $content, $R ) = @_;
...
    my $content_type = $R->{page}{content_type} ||
                       $apache->content_type ||
                       'text/html';
    $content_type = ( $content_type eq 'httpd/unix-directory' )
                      ? 'text/html' : $content_type;
    $apache->send_http_header( $content_type );
    $apache->print( $content );
}
----------------------------------------

And in OI 2.x we have:

OpenInteract2::Response::Apache:
----------------------------------------
sub send {
...
    $self->send_header( $apache );
    $apache->print( $self->content );
}

sub send_header {
    my ( $self, $apache ) = @_;
    unless ( $self->content_type ) {
        $self->content_type( 'text/html' );
    }
    unless ( $self->status ) {
        $self->status( RC_OK );
    }
    if ( CTX->server_config->{promote_oi} eq 'yes' ) {
        $apache->headers_out->add(
            'X-Powered-By', "OpenInteract " . CTX->version );
    }
    $apache->send_http_header( $self->content_type );
}
----------------------------------------

These are pretty much the same thing. So I'm puzzled.

Chris

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

Re: [Openinteract-dev] base_user bug: send mail

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

forehead wrote:
> OpenInteract2/Action/NewUser.pm line 33: $self->_send_user_email (
> ... )
> 
> and the below is _send_new_user_email , so cannot send mail for a new
> user.

Fixed, thanks.

Chris

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

Re: [Openinteract-dev] "PerlSendHeader On"

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

forehead wrote:
> in my OpenIteract2 test site's apache httpd.conf, should append this
> line:
> 
> PerlSendHeader On
> 
> in <Location />
> 
> otherwise apache output itself header and OI2's header turn to be the
> body and show on screen.

Do you mean you should *remove* this line? OI2 should take care of all
the headers for you -- it's one of the last things done in
OI2::Response::Apache->send().

I haven't tested the Apache version much yet -- when I test (manually so
far) I usually use the standalone version. Thanks for the report!

Chris

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

[Openinteract-dev] "PerlSendHeader On"

[forehead<for...@4r...>]

aGksIG9wZW5pbnRlcmFjdC1kZXYNCg0KaW4gbXkgT3Blbkl0ZXJhY3QyIHRlc3Qgc2l0ZSdzIGFw
YWNoZSBodHRwZC5jb25mLCBzaG91bGQgYXBwZW5kIHRoaXMgbGluZToNCg0KUGVybFNlbmRIZWFk
ZXIgT24NCg0KaW4gPExvY2F0aW9uIC8+IAkJCQkNCg0Kb3RoZXJ3aXNlIGFwYWNoZSBvdXRwdXQg
aXRzZWxmIGhlYWRlciBhbmQgT0kyJ3MgaGVhZGVyIHR1cm4gdG8gYmUgdGhlIGJvZHkgYW5kIHNo
b3cgb24gc2NyZWVuLg0KDQoNCg0KoaGhoaGhoaGhoaGhoaGhoWZvcmVoZWFkIChDaHVuIFNoZW5n
KQ0KoaGhoaGhoaGhoaGhoaGhoWZvcmVoZWFkQDRyZWQub3JnDQqhoaGhoaGhoaGhoaGhoaGhoaGh
oTIwMDMtMTAtMjkNCg==

[Openinteract-dev] base_user bug: send mail

[forehead<for...@4r...>]

aGksIG9wZW5pbnRlcmFjdC1kZXYNCg0KDQoJT3BlbkludGVyYWN0Mi9BY3Rpb24vTmV3VXNlci5w
bSBsaW5lIDMzOiAkc2VsZi0+X3NlbmRfdXNlcl9lbWFpbCAoIC4uLiApDQoNCmFuZCB0aGUgYmVs
b3cgaXMgX3NlbmRfbmV3X3VzZXJfZW1haWwgLCBzbyBjYW5ub3Qgc2VuZCBtYWlsIGZvciBhIG5l
dyB1c2VyLiANCiAJCQkJDQoNCqGhoaGhoaGhoaGhoaGhoaFmb3JlaGVhZCAoQ2h1biBTaGVuZykN
CqGhoaGhoaGhoaGhoaGhoaFmb3JlaGVhZEA0cmVkLm9yZw0KoaGhoaGhoaGhoaGhoaGhoaGhoaEy
MDAzLTEwLTI5DQo=

[Openinteract-dev] Bug in base_page module

[Teemu <te...@io...>]

Hi,

page actions -> directory index has a bug. "map new directory handler" which
seems to be create action for PageDirectory doesn't work. If you enter a new
directory over there and press Modify, you get "Error: Object modification
failed. Error found:". I looked at it a little bit and noticed that a new
page is not created if old_directory parameter is empty (currently a hidden
field on the Create New Directory Handler-page). If I forge the URL to be
something like:

/PageDirectory/create/?old_directory=/whatever

.. and then type the directory name I want, it will work and create a new
directory.

If you edit some directory, you can also change the Directory location, 
resulting in a new directory handler. This obviously doesn't sound like 
editing but creating a new one. Maybe in edit mode editing the directory 
location should be restricted.

Also, another bug I found occurs when you create a page in location
/test/test.html and then try to create a page in location /test.

/test will be created but the content you enter doesn't display at all and it
acts strangely and it's impossible to remove /test after creating it unless 
you do it manually (if you do search page and go to /test you can modify it, 
but if you press remove it displays an empty page instead of removing it).

I'm using OI 1.58 and 1.60 with Mozilla 1.4

Teemu Arina
MimerDesk.org

Re: [Openinteract-dev] Memory Leak in CommonHandler?

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

And...@Be... wrote:
> We use the OpenInteract::CommonHandler quite a lot, because it is so 
> easy to use. But: we currently suspect there is a lurking general mem 
> leak in there.
> ...

That's no good at all. Did the leak happen *all* the time or only 
under certain conditions?

Chris

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

[Openinteract-dev] Memory Leak in CommonHandler?

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

Hey List !

We use the OpenInteract::CommonHandler quite a lot, because it is so =
easy to
use. But: we currently suspect there is a lurking general mem leak in =
there.

What we did:
- to find out, which handler is suspicous after we saw a major mem leak
through looking at the httpd processes, we did the following
- steal idea from Apache::Leak and fold this into this mod_perl =
handler:

--- snip ----
package Apache::MemLogger;

use strict;
use DynaLoader ();
use GTop();


sub handler {
    my $r =3D shift;
    my $uri =3D $r->uri;
    my $gtop =3D GTop->new;
    my $proc =3D $gtop->proc_mem($$);
    my $size_before =3D $gtop->proc_mem($$)->size();

    $r->push_handlers(PerlLogHandler =3D> sub {
        my $size_after =3D $gtop->proc_mem($$)->size();
        my $diff =3D $size_after - $size_before;
        warn "MEM_LOG:$$:$uri:$size_before:$size_after:$diff\n";

    });
    0;
}

1;
__END__

- then activate this in the httpd.conf of the backend oi apache server =
like
this:
PerlModule Apache::MemLogger;
PerlInitHandler Apache::MemLogger

- now you can grep for MEM_LOG in the error_log_modperl and look for
interesting things e.g. with this shell command:
grep MEM_ error_log_modperl|perl -F: -ane 'print "$F[2],$F[5]\n" if =
$F[5] >
6567680;'

Doing this, we found that the search and show methods ( at least ) =
appear to
have a mem leak in them. Since we in most cases really use the basic
"Common" method, we suspect there might be a bug.

Could please anyone try this out to find this problem ?

Thanks and 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

[Openinteract-dev] caching and OI1...

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

Hello,

   I'm trying to set up a cache for my document objects following this page:
http://openinteract.sourceforge.net/docs/caching.shtml

   I've followed all the instructions and checked my work, but I keep 
getting the following error:
  --EXITED WITH ERROR from main handler eval block
Error: Subclass must define initialize()

   Its dying on line 127 of OpenInteract::Cache.pm.  I didn't see any 
mention of having to override methods to get the cache to work in the 
documentation.  Nor in News.pm.  Though I did see where it says you need to 
override these in OpenInteract::Cache.  Any thoughts?  Am I using it wrong?

Thanks for all the help.
-Andrew

Re: [Openinteract-dev] odd values in new template field

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

Andrew Hurst wrote:
>>  [% DEFAULT theme = OI.theme_fetch( mysite_theme_id,
>>                                     use_main => 'yes' ) %]
> 
> So, just to be clear, with that directive above, everything returned to 
> the user will be generated within the constraints of the theme 
> mysite_theme_id (i.e. use its main_template).  Whereas if use_main 
> wasn't set or was set to 'no' then only those templates called from that 
> template would get the theme mysite_theme_id.

I was thinking it would be *everything* in this template along. 
Other components (like boxes, the main template itself, etc.) would 
use the normal theme.

But we can add another flag ('set_global' or something) to change 
the theme for the whole request as well. OR maybe just a single flag 
  ('set_for_request' or something) to tell OI to use this theme for 
the rest of *this* request, which includes the main template.

> The next request that comes in that doesn't use that template would get 
> the standard theme.

Right.

> My only nitpick would be that it should be set_main, instead of 
> use_main.  Makes a little more sense imho, as you're not using the main 
> template, but you're setting the main template for that processing.  
> Maybe even set_main_this_request though thats a little unwieldy ;)  
> set_main is fine...

That makes sense.

Later,

Chris

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

Re: [Openinteract-dev] odd values in new template field

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

>...
>The 'making it use a different main template' is the slippery part because 
>non-main pages may want to use a different theme and leave the main 
>template the way it is. How about a syntax like:
>
>  [% DEFAULT theme = OI.theme_fetch( mysite_theme_id,
>                                     use_main => 'yes' ) %]
>
>which would do the main template switcheroo behind the scenes but do what 
>it says for everyone else?

So, just to be clear, with that directive above, everything returned to the 
user will be generated within the constraints of the theme mysite_theme_id 
(i.e. use its main_template).  Whereas if use_main wasn't set or was set to 
'no' then only those templates called from that template would get the 
theme mysite_theme_id.

The next request that comes in that doesn't use that template would get the 
standard theme.

My only nitpick would be that it should be set_main, instead of 
use_main.  Makes a little more sense imho, as you're not using the main 
template, but you're setting the main template for that processing.  Maybe 
even set_main_this_request though thats a little unwieldy ;)  set_main is 
fine...



>(Even more sugar: instead of needing to remember an ID for 
>'mysite_theme_id' you can specify a name which is then looked up in the 
>'default_objects' server configuration section...)

That would be good.

For now then I'll just change the theme of the whole site to match for 
those particular pages, and create a special admin.html page that gives me 
all the admin links I need.

Thanks.
-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-dev mailing list
>ope...@li...
>https://lists.sourceforge.net/lists/listinfo/openinteract-dev

Re: [Openinteract-dev] odd values in new template field

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

Andrew Hurst wrote:
> TT version 2.10.

Ok, I'll check it out.

> In other news, how could I go about changing the theme from within a 
> template?  I want to have most of the pages generated by /Document and 
> /DocumentPages to use a different main template...

Ahh.. interesting. This isn't hard to do, but I don't think there's 
a way to do it right now. The only tricky part is this:
 >...
> ## in the document::document_detail template, this should show with the 
> new theme
> [%  OI.box_add( 'document_tools_box', document = document );
>     OI.box_add( 'object_modify_box', object = document );
>     DEFAULT theme = OI.theme( mysite_theme );   # <-- specify the theme 
> for the returned page here,
>                                                 # hopefully making it 
> use a different main template as well

The 'making it use a different main template' is the slippery part 
because non-main pages may want to use a different theme and leave 
the main template the way it is. How about a syntax like:

  [% DEFAULT theme = OI.theme_fetch( mysite_theme_id,
                                     use_main => 'yes' ) %]

which would do the main template switcheroo behind the scenes but do 
what it says for everyone else?

(Even more sugar: instead of needing to remember an ID for 
'mysite_theme_id' you can specify a name which is then looked up in 
the 'default_objects' server configuration section...)

Chris

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

Re: [Openinteract-dev] odd values in new template field

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

TT version 2.10.

In other news, how could I go about changing the theme from within a 
template?  I want to have most of the pages generated by /Document and 
/DocumentPages to use a different main template.  It has to fit in with 
another sites' design.  So what I thought I would do is create a new theme, 
and set a different main_template.  Then, in each template that I wanted to 
show with the new site design, I would set the template with the OI 
object.  For example::

## in the document::document_detail template, this should show with the new 
theme
[%  OI.box_add( 'document_tools_box', document = document );
     OI.box_add( 'object_modify_box', object = document );
     DEFAULT theme = OI.theme( mysite_theme );   # <-- specify the theme 
for the returned page here,
                                                 # hopefully making it use 
a different main template as well
     PROCESS error_message;
     PROCESS status_message; -%]

Is this possible?  Am I going about it the wrong way?  I read the message a 
while back where the user wanted pages pulled from the filesystem to be in 
a different main template than pages from the database.  I don't think this 
is exactly the same, and thus didn't try those solutions.

Is there another way to do what I want to do?

Thanks a ton,
-Andrew


At 02:31 PM 8/5/2003 -0400, Chris Winters wrote:
>Andrew Hurst wrote:
>>This might be a bug, not sure though.  When I try to create a new 
>>template, the Template data is already filled in for me.  With what?  A 
>>directory listing of / !  This only happens on this new server I 
>>installed it on, with every browser I've tested (mozilla on win, safari 
>>on osx).  The data from the textarea is at the bottom of the message.
>
>Whoa! Very strange. What version of TT are you using?
>
>I'll try and replicate it this evening -- I need to upgrade my server to 
>the new Apache/mod_perl so it'll be a good testbed...
>
>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/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>openinteract-dev mailing list
>ope...@li...
>https://lists.sourceforge.net/lists/listinfo/openinteract-dev

Re: [Openinteract-dev] odd values in new template field

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

Andrew Hurst wrote:
> This might be a bug, not sure though.  When I try to create a new 
> template, the Template data is already filled in for me.  With what?  A 
> directory listing of / !  This only happens on this new server I 
> installed it on, with every browser I've tested (mozilla on win, safari 
> on osx).  The data from the textarea is at the bottom of the message.

Whoa! Very strange. What version of TT are you using?

I'll try and replicate it this evening -- I need to upgrade my 
server to the new Apache/mod_perl so it'll be a good testbed...

Later,

Chris

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

[Openinteract-dev] odd values in new template field

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

Hello all...

This might be a bug, not sure though.  When I try to create a new template, 
the Template data is already filled in for me.  With what?  A directory 
listing of / !  This only happens on this new server I installed it on, 
with every browser I've tested (mozilla on win, safari on osx).  The data 
from the textarea is at the bottom of the message.

Any ideas why this could be happening?  Here are the server stats:

apache 1.3.28
mod_perl 1.28
OpenInteract 1.58

root@myserver /# uname -a
SunOS myserver 5.6 Generic_105181-29 sun4u sparc SUNW,Ultra-80
root@myserver /# perl -v

This is perl, v5.8.0 built for sun4-solaris

...

root@myserver /# oi_manage list_packages 
--website_dir=/data/WWW/OpenInteract/sites/mysite
Running list_packages...
=========================

Available packages in the website directory:
Package:   base-1.72
Installed: 2003-08-01 17:08:46
Directory: /data/WWW/OpenInteract/sites/mysite/pkg/base-1.72

Package:   base_box-1.05
Installed: 2003-08-01 17:08:47
Directory: /data/WWW/OpenInteract/sites/mysite/pkg/base_box-1.05

Package:   base_error-1.45
Installed: 2003-08-01 17:08:48
Directory: /data/WWW/OpenInteract/sites/mysite/pkg/base_error-1.45

Package:   base_group-1.38
Installed: 2003-08-01 17:08:49
Directory: /data/WWW/OpenInteract/sites/mysite/pkg/base_group-1.38

Package:   base_page-1.24
Installed: 2003-08-01 17:08:49
Directory: /data/WWW/OpenInteract/sites/mysite/pkg/base_page-1.24

Package:   base_security-1.60
Installed: 2003-08-01 17:08:51
Directory: /data/WWW/OpenInteract/sites/mysite/pkg/base_security-1.60

Package:   base_template-2.23
Installed: 2003-08-01 17:08:52
Directory: /data/WWW/OpenInteract/sites/mysite/pkg/base_template-2.23

Package:   base_theme-1.36
Installed: 2003-08-01 17:08:53
Directory: /data/WWW/OpenInteract/sites/mysite/pkg/base_theme-1.36

Package:   base_user-1.64
Installed: 2003-08-01 17:08:54
Directory: /data/WWW/OpenInteract/sites/mysite/pkg/base_user-1.64

Package:   lookup-1.01
Installed: 2003-08-01 17:08:55
Directory: /data/WWW/OpenInteract/sites/mysite/pkg/lookup-1.01

Package:   object_activity-1.04
Installed: 2003-08-01 17:08:55
Directory: /data/WWW/OpenInteract/sites/mysite/pkg/object_activity-1.04

Package:   results_manage-1.02
Installed: 2003-08-01 17:08:58
Directory: /data/WWW/OpenInteract/sites/mysite/pkg/results_manage-1.02

Package:   system_doc-1.33
Installed: 2003-08-01 17:08:58
Directory: /data/WWW/OpenInteract/sites/mysite/pkg/system_doc-1.33


=========================
Finished listing packages!
root@myserver /#


Thanks
-Andrew

Its messy, but here it is...

�����.��������..�
������
lost+found����E���usr���E��var���E�&
#0;data���������export�������opt�&
#0;�E��platform������� 
��etc����&#
0;�bin���E 
��dev���E��devices���E1�&#1
6;�kernel�����L��lib���E9��mnt���E:�&
#0;proc������E;��sbin������E=��tmp��&#0
;�t��net���2��home������n��xfn&#
0;��s��vol���G��.new�������f��
.cpr_config���t��.dt���}��
.dtprofile����~��TT_DB�����Gƒ��.hotjava��&#
0;���G��.Xauthority���GŒ��cdrom�����G&#145
;�� 
.netscape�����G¾��datatmp���Gá��&#6
;nsmail����ø��.rhosts���Gõ��.ssh2���&
#0;�Gþ��.ssh������I��.TTauthority�����
�É��.cshrc����GŽ��d1����H™�&#
0;.fm���Hš��.wastebasket������H¢��^M.pwrchute_t
mp�������data5�������.history&#0
;�����‹��.logout���Ž��.login���&#0
;E��1���n.npr:0�����.desksetdefaults���&#
0;����.OWdefaults�����.rnd������HS
� 
�sparc-sun-solaris2.6������F��^M.bash_history�����
Ï��.mysql_history����.TTauthority-c�������d�&#1
4;.TTauthority-l�������L�.TTauthority-n�����������&#0
;����������������������������&#
0;�������������