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

[Openinteract-dev] base_user

[<Ewa...@ap...>]

Hallo,
 
in the package base_user-1.47 the method 'is_in_group' doesn't work
correctly. 
 
If the $group_spec is an string, the return value is always true.
 
I change the row
    return 1 if ( $group->id == $check_group_id );
to
    return 1 if ( $group->id eq $check_group_id );
 
 
eh
 
                                                                  
Ewald Hinrichs 
Applied Software Technology GmbH 
A BERTELSMANN COMPANY 

[Openinteract-dev] Re: SPOPS 0.56 'make test' problems

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

On Tue, 2002-01-22 at 16:07, Ray Zimmerman wrote:
> Hi Chris,
> 
> Just wanted to report some trouble I'm having with some of the tests 
> in SPOPS-0.56.
> 
> In t/05_exception.t it's failing all of the '$@ stringified' tests. 
> The following patch makes it pass OK, but I haven't looked any deeper 
> to understand why it was failing. This is with perl 5.005_03 on Linux.

I got the same error a few days ago when doing a fresh install to a
separate machine. The fix is in CVS and bears a striking resemblence to
your patch :-)
 
Chris

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

[Openinteract-dev] SPOPS 0.56 'make test' problems

[Ray Z. <rz...@co...>]

Hi Chris,

Just wanted to report some trouble I'm having with some of the tests 
in SPOPS-0.56.

In t/05_exception.t it's failing all of the '$@ stringified' tests. 
The following patch makes it pass OK, but I haven't looked any deeper 
to understand why it was failing. This is with perl 5.005_03 on Linux.

22c22
<     is( "$@", $e_message, '$@ stringified' );
---
>      is( "$e", $e_message, '$@ stringified' );
46c46
<     is( "$@", $stringified, 'Security $@ stringified' );
---
>      is( "$s", $stringified, 'Security $@ stringified' );
76c76
<     is( "$@", $d_message, 'DBI $@ stringified' );
---
>      is( "$d", $d_message, 'DBI $@ stringified' );
109c109
<     is( "$@", $l_message, 'LDAP $@ stringified' );
---
>      is( "$l", $l_message, 'LDAP $@ stringified' );


Also, when I did 'perl Makefile.PL' it claimed it was going to skip 
the LDAP tests (since I don't have it installed), but it still 
attempted (unsuccessfully, obviously) to execute t/40_ldap.t.

-- 
  Ray Zimmerman  / e-mail: rz...@co... / 428-B Phillips Hall
   Sr Research  /   phone: (607) 255-9645  /  Cornell University
    Associate  /      FAX: (815) 377-3932 /   Ithaca, NY  14853

Re: AW: AW: [Openinteract-dev] Paged Results with CommonHandler

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

On Mon, 2002-01-21 at 09:39, Mar...@be... wrote:
> For each search id are two files present in our $website_dir/overflow.
> The files only named by the search id are looking like the following format:
> ...
>
> The files with the meta information are looking like this example here:
> ...

These look just like they're supposed to. As long as the permissions on
the files are ok (and I assume they are since the webserver created
them), we can conclude that something is wrong with the ResultsIterator
objects. So let me check out the results_manage package again and see
what's up.

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

AW: AW: [Openinteract-dev] Paged Results with CommonHandler

[<Mar...@be...>]

For each search id are two files present in our $website_dir/overflow.
The files only named by the search id are looking like the following =
format:

oit::MyClass-->3675
oit::MyClass-->3831
oit::MyClass-->3860
oit::MyClass-->3863

The files with the meta information are looking like this example here:

$VAR1 =3D {
          'num_extra' =3D> 0,
          'filename' =3D> undef,
          'extra_name' =3D> undef,
          'search_id' =3D> 'UIRFZUSBYAWEHQJODKSQ',
          'has_extra' =3D> undef,
          'num_records' =3D> 4,
          'results_dir' =3D> '/oit/overflow',
          'time' =3D> 1011616101,
          'record_class' =3D> 'oit::MyClass
        };

Marcus
> -----Urspr=FCngliche Nachricht-----
> Von:	Chris Winters [SMTP:ch...@cw...]
> Gesendet am:	Montag, 21. Januar 2002 15:25
> An:	Mar...@be...
> Cc:	ope...@li...
> Betreff:	Re: AW: [Openinteract-dev] Paged Results with CommonHandler
>=20
> On Mon, 2002-01-21 at 09:15, Mar...@be... wrote:
> > we are using OpenInteract 1.36 and CommonHandler 1.34.=20
> >=20
> > With the MY_SEARCH_RESULTS_PAGED option, the iterator which is =
returned
> by
> > ResultsManage has no entries. The get_next() call returns nothing.
> Calling
> > the has_next() method returns false, too.=20
> >=20
> > Without the MY_SEARCH_RESULTS_PAGED option the iterator returned by =
the
> > CommonHandler's _search_build_and_run method contains the proper
> results.
> > With get_next I can walk through my results.
> >=20
> > In both cases the query to search for was the same, the only =
difference
> was
> > given by MY_SEARCH_RESULTS_PAGED.=20
> >=20
> > The search results were properly saved by ResultsManage, so it =
seems
> > something goes wrong on retrieving the search results. Do you have =
an
> idea?
>=20
> This is very strange. When you say the search results were saved
> properly, do you mean that OI created the serialized search =
information
> files in the $WEBSITE_DIR/overflow directory? Can you check that
> directory and see if the files have any content?
>=20
> Chris
>=20
> --=20
> Chris Winters (ch...@cw...)
> Building enterprise-capable snack solutions since 1988.

Re: AW: [Openinteract-dev] Paged Results with CommonHandler

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

On Mon, 2002-01-21 at 09:15, Mar...@be... wrote:
> we are using OpenInteract 1.36 and CommonHandler 1.34. 
> 
> With the MY_SEARCH_RESULTS_PAGED option, the iterator which is returned by
> ResultsManage has no entries. The get_next() call returns nothing. Calling
> the has_next() method returns false, too. 
> 
> Without the MY_SEARCH_RESULTS_PAGED option the iterator returned by the
> CommonHandler's _search_build_and_run method contains the proper results.
> With get_next I can walk through my results.
> 
> In both cases the query to search for was the same, the only difference was
> given by MY_SEARCH_RESULTS_PAGED. 
> 
> The search results were properly saved by ResultsManage, so it seems
> something goes wrong on retrieving the search results. Do you have an idea?

This is very strange. When you say the search results were saved
properly, do you mean that OI created the serialized search information
files in the $WEBSITE_DIR/overflow directory? Can you check that
directory and see if the files have any content?

Chris

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

AW: [Openinteract-dev] Paged Results with CommonHandler

[<Mar...@be...>]

Hello Chris,

we are using OpenInteract 1.36 and CommonHandler 1.34.=20

With the MY_SEARCH_RESULTS_PAGED option, the iterator which is returned =
by
ResultsManage has no entries. The get_next() call returns nothing. =
Calling
the has_next() method returns false, too.=20

Without the MY_SEARCH_RESULTS_PAGED option the iterator returned by the
CommonHandler's _search_build_and_run method contains the proper =
results.
With get_next I can walk through my results.

In both cases the query to search for was the same, the only difference =
was
given by MY_SEARCH_RESULTS_PAGED.=20

The search results were properly saved by ResultsManage, so it seems
something goes wrong on retrieving the search results. Do you have an =
idea?

Thanks

Marcus

> -----Urspr=FCngliche Nachricht-----
> Von:	Chris Winters [SMTP:ch...@cw...]
> Gesendet am:	Mittwoch, 16. Januar 2002 17:42
> An:	Mar...@be...
> Cc:	ope...@li...
> Betreff:	Re: [Openinteract-dev] Paged Results with CommonHandler
>=20
> On Wed, 2002-01-16 at 08:44, Mar...@be... wrote:
> > Dear OI Developers,
> >=20
> > we've got some problems on showing paged results with =
CommonHandler. If
> we
> > use CommonHandler without MY_SEARCH_RESULTS_PAGED we get back an
> iterator
> > object that can easily proccessed by the template to display the
> results.
> > Everything works fine that way. With MY_SEARCH_RESULTS_PAGED we get =
back
> a
> > ResultsManage object with a list of object ids, and some other data =
like
> > num_records or the search id.=20
> >=20
> > Is there a possiblity to get back more data (e.g. the object data
> > represented by the object ids) for displaying in the template? Any
> > suggestions?
>=20
> Ok, I remember now :-)
>=20
> The ResultsIterator returned for the paged objects should with every
> 'get_next()' call return the object referred to by the ID/class for =
that
> entry.  If it's not then something isn't working properly.
>=20
> Chris
>=20
> --=20
> Chris Winters (ch...@cw...)
> Building enterprise-capable snack solutions since 1988.

[Openinteract-dev] New base_page package

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

There's a new base_page package on the SF site (and in CVS). The one
from 1.37 works ok. But if you click the 'Add file here' link from a
directory index and upload a file, the directory information given by
the client is still present. Functional, but ugly and confusing to
users.

Chris

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

Re: [Openinteract-dev] Paged Results with CommonHandler

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

On Wed, 2002-01-16 at 08:44, Mar...@be... wrote:
> Dear OI Developers,
> 
> we've got some problems on showing paged results with CommonHandler. If we
> use CommonHandler without MY_SEARCH_RESULTS_PAGED we get back an iterator
> object that can easily proccessed by the template to display the results.
> Everything works fine that way. With MY_SEARCH_RESULTS_PAGED we get back a
> ResultsManage object with a list of object ids, and some other data like
> num_records or the search id. 
> 
> Is there a possiblity to get back more data (e.g. the object data
> represented by the object ids) for displaying in the template? Any
> suggestions?

Ok, I remember now :-)

The ResultsIterator returned for the paged objects should with every
'get_next()' call return the object referred to by the ID/class for that
entry.  If it's not then something isn't working properly.

Chris

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

Re: [Openinteract-dev] Paged Results with CommonHandler

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

On Wed, 2002-01-16 at 08:44, Mar...@be... wrote:
> Dear OI Developers,
> 
> we've got some problems on showing paged results with CommonHandler. If we
> use CommonHandler without MY_SEARCH_RESULTS_PAGED we get back an iterator
> object that can easily proccessed by the template to display the results.
> Everything works fine that way. With MY_SEARCH_RESULTS_PAGED we get back a
> ResultsManage object with a list of object ids, and some other data like
> num_records or the search id. 
> 
> Is there a possiblity to get back more data (e.g. the object data
> represented by the object ids) for displaying in the template? Any
> suggestions?

Oh, that's not right at all. You should get back an iterator in both
instances. What version of OpenInteract and OpenInteract::CommonHandler
are you using?

Chris

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

[Openinteract-dev] Paged Results with CommonHandler

[<Mar...@be...>]

Dear OI Developers,

we've got some problems on showing paged results with CommonHandler. If we
use CommonHandler without MY_SEARCH_RESULTS_PAGED we get back an iterator
object that can easily proccessed by the template to display the results.
Everything works fine that way. With MY_SEARCH_RESULTS_PAGED we get back a
ResultsManage object with a list of object ids, and some other data like
num_records or the search id. 

Is there a possiblity to get back more data (e.g. the object data
represented by the object ids) for displaying in the template? Any
suggestions?

Thanks a lot

[Openinteract-dev] heads-up: mozilla, multipart forms and uploads

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

I ran into this earlier debugging the various base_page issues that have
come up and wanted to give a shout on it so people don't run into the
same thing and (more selfishly) don't spend time reporting this as a bug
in OI.  

Mozilla 0.9.7 (and maybe earlier), along with software that uses the
Gecko engine (like Galeon) have an issue submitting forms with empty or
invalid file upload fields. The browser will just hang. And even if you
stop the action further requests to the same site (at least an OI site)
also hang. Irritating.

So if you're trying to edit a page using the newer base_page package, it
won't work using this browser unless you upload a valid file.

Apparently, this has already been fixed in CVS and will be included in
the next (0.9.8) release.  For more info, see:

http://bugzilla.mozilla.org/show_bug.cgi?id=116210

Chris

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

[Openinteract-dev] Re: Still base_page 0.58 (<- see that merlyn ;-) )

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

On Wed, 2002-01-09 at 12:11, And...@Be... wrote:
> .. a little different:
> 
> - when testing I just forgot to set the active flag
> - the file got uploaded OK and the record in the page table got written
> - so I recalled the page manually with /Page/show/ bla location=/test
> whatever and the record got retrieved OK
> - when I tried to switch the active flag to on now, and pressed modify, the
> handler told me, that the page was not active - which I already knew, since
> I wanted to change that ;-)

We actually do two active checks. The first is the 'is_active' flag. The
second uses the 'active_on' and 'expires_on' dates. It might be that
your database (mysql, right?) has set a default 'active_on' date to
something like '0000-00-00 00:00:00', or that the dates are set so that
you can't view the page.

I'll stick some debugging items in the date check to help out with
this...

Chris

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

[Openinteract-dev] Still base_page 0.58 (<- see that merlyn ;-) )

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

.. a little different:

- when testing I just forgot to set the active flag
- the file got uploaded OK and the record in the page table got written
- so I recalled the page manually with /Page/show/ bla location=3D/test
whatever and the record got retrieved OK
- when I tried to switch the active flag to on now, and pressed modify, =
the
handler told me, that the page was not active - which I already knew, =
since
I wanted to change that ;-)

later,

Andreas

-----Urspr=FCngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]
Gesendet am: Mittwoch, 9. Januar 2002 17:48
An: Nolte, Andreas, D22K-MSN
Cc: ope...@li...; Hanisch, Dietmar, D22-MSN
Betreff: Re: AW: AW: AW: AW: AW: [Openinteract-dev] base_page-0.58

On Wed, 2002-01-09 at 10:27, And...@Be... wrote:
> Hi Chris,
>=20
> now it works! Maybe I found a different bug, though: if you create a =
new
> page without checking the active checkbox, then you later cannot =
modify
the
> page to be active. Bug or feature ;-)

How do you mean? You mean that since the page isn't active an access to
it (so you get the box with the editing links) gives you a 'Not active'
error?

This is kind of a chicken-and-egg thing, and you can get around it by
using the search form (/Page/search_form/) and finding your page, or by
just clicking the 'List' link (/Page/directory_list/) and drilling down
to the directory.

I've just made a small update so that admins can set whether they want
to find active/inactive pages in a page search. That should ensure we
can be the chicken AND the egg :-) I'll stick the package up on SF
shortly, but it's in CVS.

Later,
=20
Chris

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

[Openinteract-dev] Mason or HTML::Template implementation of OpenInteract?

[Terrence B. <met...@ma...>]

It seems that HTML::Mason is getting very popular in industry. 
Could anyone comment on how much they would like a Mason version 
of OpenInteract? Or an HTML::Template version?

Re: AW: AW: AW: AW: AW: [Openinteract-dev] base_page-0.58

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

On Wed, 2002-01-09 at 10:27, And...@Be... wrote:
> Hi Chris,
> 
> now it works! Maybe I found a different bug, though: if you create a new
> page without checking the active checkbox, then you later cannot modify the
> page to be active. Bug or feature ;-)

How do you mean? You mean that since the page isn't active an access to
it (so you get the box with the editing links) gives you a 'Not active'
error?

This is kind of a chicken-and-egg thing, and you can get around it by
using the search form (/Page/search_form/) and finding your page, or by
just clicking the 'List' link (/Page/directory_list/) and drilling down
to the directory.

I've just made a small update so that admins can set whether they want
to find active/inactive pages in a page search. That should ensure we
can be the chicken AND the egg :-) I'll stick the package up on SF
shortly, but it's in CVS.

Later,
 
Chris

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

AW: AW: AW: AW: AW: [Openinteract-dev] base_page-0.58

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

Hi Chris,

now it works! Maybe I found a different bug, though: if you create a =
new
page without checking the active checkbox, then you later cannot modify =
the
page to be active. Bug or feature ;-)

later,

Andreas

-----Urspr=FCngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]
Gesendet am: Mittwoch, 9. Januar 2002 16:10
An: And...@Be...
Cc: ope...@li...;
Die...@Be...
Betreff: Re: AW: AW: AW: AW: [Openinteract-dev] base_page-0.58

On Wed, 2002-01-09 at 09:55, And...@Be... wrote:
> Hi Chris,
>=20
> we tested with CommonHandler 1.34 - no changes. If you call =
/Page/create/?
> or /Page/show/?edit=3D1 , which we think should work to get a new =
page, you
> get a not found message from the file_index dir handler.=20

Did you also upgrade to base_page version 0.62 (should be active on SF
by now, or from CVS)? It doesn't appear that you have from the logs.

C

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

AW: AW: AW: AW: AW: [Openinteract-dev] base_page-0.58

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

nope, since we thought you meant only CommonHandler 1.34 - we will =
check
-----Urspr=FCngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]
Gesendet am: Mittwoch, 9. Januar 2002 16:10
An: And...@Be...
Cc: ope...@li...;
Die...@Be...
Betreff: Re: AW: AW: AW: AW: [Openinteract-dev] base_page-0.58

On Wed, 2002-01-09 at 09:55, And...@Be... wrote:
> Hi Chris,
>=20
> we tested with CommonHandler 1.34 - no changes. If you call =
/Page/create/?
> or /Page/show/?edit=3D1 , which we think should work to get a new =
page, you
> get a not found message from the file_index dir handler.=20

Did you also upgrade to base_page version 0.62 (should be active on SF
by now, or from CVS)? It doesn't appear that you have from the logs.

C

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

Re: AW: AW: AW: AW: [Openinteract-dev] base_page-0.58

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

On Wed, 2002-01-09 at 09:55, And...@Be... wrote:
> Hi Chris,
> 
> we tested with CommonHandler 1.34 - no changes. If you call /Page/create/?
> or /Page/show/?edit=1 , which we think should work to get a new page, you
> get a not found message from the file_index dir handler. 

Did you also upgrade to base_page version 0.62 (should be active on SF
by now, or from CVS)? It doesn't appear that you have from the logs.

C

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

AW: AW: AW: AW: [Openinteract-dev] base_page-0.58

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

Hi Chris,

we tested with CommonHandler 1.34 - no changes. If you call /Page/create/?
or /Page/show/?edit=1 , which we think should work to get a new page, you
get a not found message from the file_index dir handler. 

here the logs...




OpenInteract::handler (34) >>

==============================
Request started: Wed Jan  9 16:08:51 2002
 path: ( /Page/create/ ) PID: (982)
OpenInteract::setup_server_interface (127) >> Server hostname set to
www.mycompany.com
OpenInteract::setup_server_interface (130) >> Request coming from
172.29.3.249
OpenInteract::parse_uri (175) >> Original path: (/Page/create/)
OpenInteract::parse_uri (183) >> Items in the path:  Page // create
OpenInteract::parse_uri (196) >> Action found from URL: Page
OpenInteract::parse_uri (203) >> Original path/query string set to:
/Page/create/
OpenInteract::Request::lookup_conductor (225) >> Find conductor for action
(Page)
OpenInteract::Request::lookup_action (254) >> Find action corresponding to
(Page)
OpenInteract::Request::lookup_action (275) >> Found action info for (Page)
OpenInteract::find_action_handler (226) >> Found OpenInteract::UI::Main //
handler for conductor
OpenInteract::Session::DBI::_create_session (26) >> Trying to fetch session
0ab46d6355142a6eb2574f45c4c1e306
OpenInteract::Auth::user (21) >> Found session and uid (NOL08); fetching
user
OpenInteract::Auth::user (33) >> User found: NOL08
OpenInteract::Auth::group (222) >> Authenticated user exists; getting
groups.
OpenInteract::SPOPS::LDAP::global_datasource_handle (18) >> Trying to
retrieve handle for key (main) for:  oit::Group
OpenInteract::run_content_handler (325) >> Trying the conductor:
<<OpenInteract::UI::Main/handler>>
OpenInteract::Request::lookup_action (254) >> Find action corresponding to
(Page)
OpenInteract::Request::lookup_action (275) >> Found action info for (Page)
OpenInteract::UI::Main::handler (31) >> Action info: oit::Handler::Page /
handler
OpenInteract::Handler::GenericDispatcher::handler (31) >> Trying to run
oit::Handler::Page with create
oit::Page::page_by_location (37) >> Trying to retrieve object with location
(/page/create/)
oit::Page::page_by_location (48) >> Testing (/page/create/) as a
directory...
oit::PageDirectory::fetch_by_directory (27) >> Initial fetch:
(/page/create/)
oit::PageDirectory::fetch_by_directory (37) >> Found parents of ():
/page/create/;/page/;/
oit::Page::page_by_location (55) >> Directory object found. Returning
OpenInteract::Request::lookup_action (254) >> Find action corresponding to
(file_index)
OpenInteract::Request::lookup_action (275) >> Found action info for
(file_index)
oit::Handler::PageDirectoryIndex::file_index (97) >> Using the following for
index names:  index.html
oit::Handler::PageDirectoryIndex::file_index (103) >> Trying to fetch
location (/page/create/index.html)

OpenInteract::UI::Main::handler (61) >> Using template
(base_theme::base_main) for full page
OpenInteract::Template::Process::handler (122) >> Using template name
(base_theme::base_main) for processing
OpenInteract::Template::Process::initialize (25) >> Starting template
initialization process
OpenInteract::Template::Process::_package_template_config (177) >> Packages
for inspection by template initialization read ok
OpenInteract::Template::Process::_package_template_config (196) >> Found
template plugin  =>
OpenInteract::Template::Process::_package_template_config (196) >> Found
template plugin  =>
OpenInteract::Template::Process::_package_template_config (196) >> Found
template plugin  =>
OpenInteract::Template::Process::_package_template_config (196) >> Found
template plugin  =>
OpenInteract::Template::Process::_package_template_config (196) >> Found
template plugin  =>
OpenInteract::Template::Process::_package_template_config (196) >> Found
template plugin  =>
OpenInteract::Template::Process::_package_template_config (196) >> Found
template plugin  =>
oit::SiteTemplate::fetch_by_name (47) >> Trying to retrieve template for
name (base_main) and  package (base_theme)
OpenInteract::Template::Plugin::comp (95) >> Calling template component
(boxes)
OpenInteract::Request::lookup_action (254) >> Find action corresponding to
(boxes)
OpenInteract::Request::lookup_action (275) >> Found action info for (boxes)
OpenInteract::Handler::Component::handler (105) >> Calling component with
oit::Handler::Box->process_boxes
oit::Handler::SystemBoxes::handler (60) >> Generating box information for
user info box
OpenInteract::Request::lookup_action (254) >> Find action corresponding to
(user_info_box)
OpenInteract::Request::lookup_action (275) >> Found action info for
(user_info_box)
oit::Handler::Box::process_boxes (130) >> Putting box (user_info_box) onto
the stack with weight 1
OpenInteract::Request::lookup_action (254) >> Find action corresponding to
(user_info_box)
OpenInteract::Request::lookup_action (275) >> Found action info for
(user_info_box)
OpenInteract::Handler::Component::handler (90) >> Generic template action
with (base_box::user_info_box)
OpenInteract::Template::Process::handler (122) >> Using template name
(base_box::user_info_box) for processing
OpenInteract::Template::Process::handler (122) >> Using template name
(base_box::main_box_shell) for processing

-----Ursprüngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]
Gesendet am: Mittwoch, 9. Januar 2002 14:51
An: Andreas Nolte
Cc: ope...@li...;
Die...@Be...
Betreff: Re: AW: AW: AW: [Openinteract-dev] base_page-0.58

On Wed, 2002-01-09 at 03:15, And...@Be... wrote:
> Hi Chris,
> 
> we are quite sure, that show is being called. But inside show you call
> _run_directory_handler and this is the page which gets displayed (
> file_index dir handler ).

Yeah, I understand what's happening. I've made some relatively small
updates to the package, tested it on my end and uploaded it to
sourceforge. If you use it, you'll need to grab the latest copy of
OpenInteract::CommonHandler from CVS: 

    OpenInteract/OpenInteract/CommonHandler.pm

The package also has some additional debugging messages which may help
with problems.

I'll probably be putting out a new release of OI later today with this
stuff included.

Thanks,

Chris

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

Re: AW: AW: AW: [Openinteract-dev] base_page-0.58

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

On Wed, 2002-01-09 at 03:15, And...@Be... wrote:
> Hi Chris,
> 
> we are quite sure, that show is being called. But inside show you call
> _run_directory_handler and this is the page which gets displayed (
> file_index dir handler ).

Yeah, I understand what's happening. I've made some relatively small
updates to the package, tested it on my end and uploaded it to
sourceforge. If you use it, you'll need to grab the latest copy of
OpenInteract::CommonHandler from CVS: 

    OpenInteract/OpenInteract/CommonHandler.pm

The package also has some additional debugging messages which may help
with problems.

I'll probably be putting out a new release of OI later today with this
stuff included.

Thanks,

Chris

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

AW: AW: AW: [Openinteract-dev] base_page-0.58

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

Hi Chris,

we are quite sure, that show is being called. But inside show you call
_run_directory_handler and this is the page which gets displayed (
file_index dir handler ).

later,


Andreas

-----Urspr=FCngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]
Gesendet am: Mittwoch, 9. Januar 2002 07:09
An: Andreas Nolte
Cc: ope...@li...;
Die...@Be...
Betreff: Re: AW: AW: [Openinteract-dev] base_page-0.58

On Tue, 2002-01-08 at 10:13, And...@Be... wrote:
> Hi Chris,
> it is OI 1.36 and CommonHandler 1.29. What we currently assume is, =
that if
> create or show are called without location=3Dwhatever specified, then
Page.pm
> runs the _run_directory_handler mothod and you never come to the =
point,
> where you get to create a new page. This only happens on sites, where =
we
> upgraded base_page from 0.42 to 0.58. You know, we are messing with
> directory handlers..

One problem is that we check to see if the action is 'Page'
(case-sensitive), so in Page->_get_task(), I changed:

    return 'show'  if ( $R->{path}{full}->[0] ne 'Page' );
to:
    return 'show'  if ( $R->{path}{full}->[0] !~ /^page$/i );

However, Dietmar said that you were using the URL '/Page/create/' (as
opposed to '/page/create/') and that actually works for me so I'm a
little dumbfounded. Can you set the server debug level to 1, restart
your server, request the page and send me (not the list, since it's
likely to be large) the log entry for that request?

Chris

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

Re: AW: AW: [Openinteract-dev] base_page-0.58

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

On Tue, 2002-01-08 at 10:13, And...@Be... wrote:
> Hi Chris,
> it is OI 1.36 and CommonHandler 1.29. What we currently assume is, that if
> create or show are called without location=whatever specified, then Page.pm
> runs the _run_directory_handler mothod and you never come to the point,
> where you get to create a new page. This only happens on sites, where we
> upgraded base_page from 0.42 to 0.58. You know, we are messing with
> directory handlers..

One problem is that we check to see if the action is 'Page'
(case-sensitive), so in Page->_get_task(), I changed:

    return 'show'  if ( $R->{path}{full}->[0] ne 'Page' );
to:
    return 'show'  if ( $R->{path}{full}->[0] !~ /^page$/i );

However, Dietmar said that you were using the URL '/Page/create/' (as
opposed to '/page/create/') and that actually works for me so I'm a
little dumbfounded. Can you set the server debug level to 1, restart
your server, request the page and send me (not the list, since it's
likely to be large) the log entry for that request?

Chris

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

Re: AW: AW: [Openinteract-dev] base_page-0.58

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

On Tue, 2002-01-08 at 10:13, And...@Be... wrote:
> Hi Chris,
> it is OI 1.36 and CommonHandler 1.29. What we currently assume is, that if
> create or show are called without location=whatever specified, then Page.pm
> runs the _run_directory_handler mothod and you never come to the point,
> where you get to create a new page. This only happens on sites, where we
> upgraded base_page from 0.42 to 0.58. You know, we are messing with
> directory handlers..

Ah, I see... you could be right. I'll look into this later today or this
evening and get back to the list.

Chris

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

AW: AW: [Openinteract-dev] base_page-0.58

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

Hi Chris,
it is OI 1.36 and CommonHandler 1.29. What we currently assume is, that =
if
create or show are called without location=3Dwhatever specified, then =
Page.pm
runs the _run_directory_handler mothod and you never come to the point,
where you get to create a new page. This only happens on sites, where =
we
upgraded base_page from 0.42 to 0.58. You know, we are messing with
directory handlers..

later,

Andreas

-----Urspr=FCngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]
Gesendet am: Dienstag, 8. Januar 2002 16:15
An: Die...@Be...
Cc: ope...@li...
Betreff: Re: AW: [Openinteract-dev] base_page-0.58

On Tue, 2002-01-08 at 10:02, Die...@Be... wrote:
> Hi Chris,
>=20
> 	We're editing documents like this:
> /Page/show/?location=3D/my/location;edit=3D1
> 	and we have the entry =20
> 	'page' =3D> {
> 	     'class'           =3D> 'OpenInteract::Handler::Page',
> 	     'security'        =3D> 'yes',
> 	 } in our action.perl

Hm, this is interesting. What version of OI are you using? In
particular, what results if you run:

 $ perl -MOpenInteract::CommonHandler \
        -e 'print OpenInteract::CommonHandler->VERSION'

> 	so here is what oi_manage --website_dir=3D/mysite list_actions says:
> 	(I guess something is not working ...)
>=20
> 	Running list_actions...
> 	=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D
>=20
> 	OpenInteract::Startup::require_module (336) >>  --require error:
> OpenInteract::Handler::Component        : Can't locate
> OpenInteract/Handler/Component.pm in @INC (@INC contains:
> /usr/lib/perl5/5.6.0/i386-linux /usr/lib/perl5/5.6.0
> /usr/lib/perl5/site_perl/5.6.0/i386-linux =
/usr/lib/perl5/site_perl/5.6.0
> /usr/lib/perl5/site_perl . /msn/oit) at (eval 38) line 3, <MOD> line =
1.

Ack, right. This is fixed in CVS. I'll put out a new OI version shortly
(like tonight) that has this fix and a few other little items as well.

Chris

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


_______________________________________________
openinteract-dev mailing list
ope...@li...
https://lists.sourceforge.net/lists/listinfo/openinteract-dev