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

Re: WG: [Openinteract-help] base_main

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

* Tho...@be... (Tho...@be...) [011214 03:37]:
> But I deleted the base_main from the DB manualy. Refresh_widget said
> "copying ok" but never the less it isn't copied to the db.
> 
> How can I dump the template to the db ?

I haven't made any provisions yet to keep the site templates (aka
widgets) in the database -- or more specifically, editable via the
browser. This is coming relatively soon.

To figure out where OI thinks your base_main template is you'd
normally go into the theme editor and find out. But since your
base_main template has been blown away you won't be able to do that.

So you'll need to go into your database and execute the following
query:

 SELECT value FROM theme_prop WHERE prop = 'main_template'

If the value is 'base_main' then change it to 'base_theme::base_main':

 UPDATE theme_prop SET value = 'base_theme::base_main' 
  WHERE prop = 'main_template'

then copy the template from:

  $WEBSITE_DIR/template/base_main

to:

  $WEBSITE_DIR/pkg/base_theme-x.xx/template/base_main.tmpl

Copy the following text to:

  $WEBSITE_DIR/pkg/base_theme-x.xx/template/base_main.meta

--------------------snip--------------------
name: base_main
title: Main template
package: base_theme
--------------------snip--------------------

And then run:

 $ export OIWEBSITE=/path/to/mysite
 $ oi_manage install_template --package base_theme

That should do it.

Chris

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

WG: [Openinteract-help] base_main

[<Tho...@be...>]

Hi.

But I deleted the base_main from the DB manualy. Refresh_widget said
"copying ok" but never the less it isn't copied to the db.

How can I dump the template to the db ?

-----Urspr=FCngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]
Gesendet: Donnerstag, 13. Dezember 2001 17:49
An: Tho...@be...
Cc: ope...@li...
Betreff: Re: [Openinteract-help] base_main


* Tho...@be... (Tho...@be...) [011213
10:32]:
> No sorry, I tried this, but base_main is only installed directly in
> the website_dir/template :-(

Ah, then you can just do:

 $ cp $BASE_INSTALL_DIR/template/base_main $WEBSITE_DIR/template

You can also accomplish this with newer versions using:

 $ oi_manage refresh_widget

Note that you might need to edit the file:

 $WEBSITE_DIR/template/.no_overwrite

And comment out 'base_main' -- otherwise oi_manage will refuse to copy
another file over the existing one.

Chris

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

AW: [Openinteract-help] OI with GEMINI

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

up to 800 Users will be using the site. Currently there are maybe 400, =
about
50 of which use our NATS ticket system, which is the app where we use
sys_security with JOINs for statistical overview lists, because we have
about 15 clients in this system ( each department is a separat client =
for us
) and sort the db entries out through security. For these lists we now =
only
have around 1/5 of the running time compared to the normal security
mechanism. But as I wrote earlier: this is one specific usage where we
wanted to do without the usual client_id row in each table..

Back to the users: the others are using simple table editor style apps =
or
just read manuals or else.=20

But this is only our intranet... Next we will do a we based order =
system
including credit card charges and SAP based product shippment for one =
of our
external clients ( german mobile phone company ), an extranet for our
service center customers, so they can e.g. view their callcenter =
reports
online, replace access / vb frontend to our CRM systems, etc..


later,

Andreas

-----Urspr=FCngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]
Gesendet: Donnerstag, 13. Dezember 2001 14:20
An: And...@Be...
Cc: ope...@li...
Betreff: Re: [Openinteract-help] OI with GEMINI


* Andreas Nolte (And...@Be...) [011213 03:50]:
> Hey,
>=20
> as promised, I`d like to comment on using other mysql table handlers
> with OI:
> ...
> InnoDB:
> - so far no problems at all!
> - only drawback: no fulltext indexes at the moment
> - concurrency issues sure have improved

This is good news. Are you still using the sys_security JOIN method
you mentioned before?

BTW, I'm curious: how many people are using the site overall and at a
single time?

> - conversion of tables from MYISAM to INNODB back and forth works
> without any problems (tested with sys_security and >200.000 records)

Great -- painless conversions are always good.

Thanks for writing this up.

Chris

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

Re: [Openinteract-help] base_main

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

* Tho...@be... (Tho...@be...) [011213 10:32]:
> No sorry, I tried this, but base_main is only installed directly in
> the website_dir/template :-(

Ah, then you can just do:

 $ cp $BASE_INSTALL_DIR/template/base_main $WEBSITE_DIR/template

You can also accomplish this with newer versions using:

 $ oi_manage refresh_widget

Note that you might need to edit the file:

 $WEBSITE_DIR/template/.no_overwrite

And comment out 'base_main' -- otherwise oi_manage will refuse to copy
another file over the existing one.

Chris

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

AW: [Openinteract-help] base_main

[<Tho...@be...>]

No sorry, I tried this, but base_main is only installed directly in the
website_dir/template :-(

-----Urspr=FCngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]
Gesendet: Donnerstag, 13. Dezember 2001 16:37
An: Tho...@be...
Cc: ope...@li...
Betreff: Re: [Openinteract-help] base_main


* Tho...@be... (Tho...@be...) [011213
09:56]:
> I destroyed the base_main in the database. How can I reinstall the
> base_main from the filesystem into the database ?

If you're using a version of OI that has the base_main template in the
base_theme package, you should be able to run:

 $ oi_manage install_template --package=3Dbase_theme

Before you run it, you might want to run:

 $ oi_manage dump_template --package=3Dbase_theme

Just so you have a backup available, This command should dump the
existing templates to the filesystem at:

 $WEBSITE_DIR/pkg/base_theme-x.xx/template/dump

I confess that I haven't used either of these for a while since I keep
all the templates in the filesystem now. But this should work.

Chris

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

Re: [Openinteract-help] base_main

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

* Tho...@be... (Tho...@be...) [011213 09:56]:
> I destroyed the base_main in the database. How can I reinstall the
> base_main from the filesystem into the database ?

If you're using a version of OI that has the base_main template in the
base_theme package, you should be able to run:

 $ oi_manage install_template --package=base_theme

Before you run it, you might want to run:

 $ oi_manage dump_template --package=base_theme

Just so you have a backup available, This command should dump the
existing templates to the filesystem at:

 $WEBSITE_DIR/pkg/base_theme-x.xx/template/dump

I confess that I haven't used either of these for a while since I keep
all the templates in the filesystem now. But this should work.

Chris

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

[Openinteract-help] base_main

[<Tho...@be...>]

Hello.

I destroyed the base_main in the database. How can I reinstall the base_main
from the filesystem into the database ?

Greets
Thomas

Re: [Openinteract-help] OI with GEMINI

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

* Andreas Nolte (And...@Be...) [011213 03:50]:
> Hey,
> 
> as promised, I`d like to comment on using other mysql table handlers
> with OI:
> ...
> InnoDB:
> - so far no problems at all!
> - only drawback: no fulltext indexes at the moment
> - concurrency issues sure have improved

This is good news. Are you still using the sys_security JOIN method
you mentioned before?

BTW, I'm curious: how many people are using the site overall and at a
single time?

> - conversion of tables from MYISAM to INNODB back and forth works
> without any problems (tested with sys_security and >200.000 records)

Great -- painless conversions are always good.

Thanks for writing this up.

Chris

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

AW: [Openinteract-help] OI with GEMINI

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

Hey,

as promised, I`d like to comment on using other mysql table handlers =
with
OI:

GEMINI:

- I did NOT get a running site converted to GEMINI !
- I suspect, that it has to do with auto_increment columns
- I did not test a fresh site with GEMINI
- the legal status of GEMINI to me is quite unclear
- MySQL AB and Nusphere seem to be at war, which leads me to rule this
option out anyway

InnoDB:
- so far no problems at all!
- only drawback: no fulltext indexes at the moment
- concurrency issues sure have improved
- conversion of tables from MYISAM to INNODB back and forth works =
without
any problems ( tested with sys_security and >200.000 records )


later,

Andreas

-----Urspr=FCngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]
Gesendet: Samstag, 8. Dezember 2001 16:27
An: And...@Be...
Cc: ope...@li...
Betreff: Re: [Openinteract-help] OI with GEMINI


* Andreas Nolte (And...@Be...) [011206 08:07]:
> .. hard to tell on a test site - it seems, it does. But we shall see
> on the production site...

What?! You mean you didn't just run it on your production site? :-)

> BTW: recently I posted our idea of using sys_security with
> skip_security as a join to boost performance: this works great and
> speeds things up noticebly with our critical requests, that is
> those, where the actual request returns a lot of records, of which
> most are kicked out by the security mechanism ( with one fetch for
> each record ! ).

Nice -- I'll have to look at incorporating this in the future.

Chris

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

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

RE: [Openinteract-help] Security in CommonHandler

[Victor P. <ope...@ha...>]

Hi,

I think you can do this by overriding _show_customize().
You can see an example in the Weblink handler. Basically, you set
MY_OBJECT_FORM_TEMPLATE to return the un-editable template, then in
_show_customize() compare the access levels. If the user has the proper
access level
(>=3DSEC_LEVEL_WRITE), set the $params->{template_name} to be the editabl=
e
template.

But the code is worth a thousand words, check out the Weblink package.

-Victor


> -----Original Message-----
> From: ope...@li...
> [mailto:ope...@li...]On Behalf
> Of Tho...@be...
> Sent: Wednesday, December 12, 2001 11:09 PM
> To: ch...@cw...
> Cc: ope...@li...
> Subject: AW: [Openinteract-help] Security in CommonHandler
>
>
> Yeah thats right, but the form security does not work.
>
> If I set security level at edit to write, user who have read level can =
see
> the form ! Only after clicking "Modify" the message "Task is forbidden"
> appears.
>
> I saw I have to set "show" to write but then all is secure, the
> user should
> only see the Detailform not the editform, so that
>
> /Classified/show/?edit must be writelevel and
> /Classified/show/?classified_id=3Dxx must be level read.
>
> is that possible ?
>
> greets.
> THomas
>
>
> -----Urspr=FCngliche Nachricht-----
> Von: Chris Winters [mailto:ch...@cw...]
> Gesendet: Dienstag, 11. Dezember 2001 17:23
> An: Tho...@be...
> Cc: ope...@li...
> Betreff: Re: [Openinteract-help] Security in CommonHandler
>
>
> * Tho...@be... (Tho...@be...) [011211
> 10:57]:
> > Is it possible to set the other forms secure like the search_form as
> > done below ?
>
> Sure thing -- each 'task' can be listed in the package 'security' hash
> of your handler and assigned a minimum security level. So the
> following security specification:
>
>  %OpenInteract::Handler::Classified::security =3D (
>   search_form =3D> SEC_LEVEL_READ,
>   search      =3D> SEC_LEVEL_READ,
>   show        =3D> SEC_LEVEL_READ,
>   create      =3D> SEC_LEVEL_WRITE,
>   edit        =3D> SEC_LEVEL_WRITE,
>   remove      =3D> SEC_LEVEL_WRITE,
>  );
>
> Means that:
>
>  /Classified/search_form/ --> requires 'read' access to the handler
>  /Classified/search/      --> requires 'read' access to the handler
>  /Classified/show/        --> requires 'read' access to the handler
>  /Classified/create/      --> requires 'write' access to the handler
>  /Classified/edit/        --> requires 'write' access to the handler
>  /Classified/remove/      --> requires 'write' access to the handler
>
> Using:
>
>  %OpenInteract::Handler::Classified::security =3D (
>   DEFAULT_SECURITY_KEY() =3D> SEC_LEVEL_READ,
>  );
>
> Means that the minimum security for any task not specified is
> 'read'. And if a task isn't specified in the package security hash and
> there's no default set by you, then OpenInteract assumes 'write'
> access is required to run the task.
>
> Hope that makes sense,
>
> Chris
>
> --
> Chris Winters (ch...@cw...)
> Building enterprise-capable snack solutions since 1988.
>
> _______________________________________________
> openinteract-help mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openinteract-help
>

AW: [Openinteract-help] Security in CommonHandler

[<Tho...@be...>]

Yeah thats right, but the form security does not work.

If I set security level at edit to write, user who have read level can =
see
the form ! Only after clicking "Modify" the message "Task is forbidden"
appears.

I saw I have to set "show" to write but then all is secure, the user =
should
only see the Detailform not the editform, so that=20

/Classified/show/?edit must be writelevel and
/Classified/show/?classified_id=3Dxx must be level read.

is that possible ?

greets.
THomas


-----Urspr=FCngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]
Gesendet: Dienstag, 11. Dezember 2001 17:23
An: Tho...@be...
Cc: ope...@li...
Betreff: Re: [Openinteract-help] Security in CommonHandler


* Tho...@be... (Tho...@be...) [011211
10:57]:
> Is it possible to set the other forms secure like the search_form as
> done below ?

Sure thing -- each 'task' can be listed in the package 'security' hash
of your handler and assigned a minimum security level. So the
following security specification:

 %OpenInteract::Handler::Classified::security =3D (
  search_form =3D> SEC_LEVEL_READ,
  search      =3D> SEC_LEVEL_READ,
  show        =3D> SEC_LEVEL_READ,
  create      =3D> SEC_LEVEL_WRITE,
  edit        =3D> SEC_LEVEL_WRITE,
  remove      =3D> SEC_LEVEL_WRITE,
 );

Means that:

 /Classified/search_form/ --> requires 'read' access to the handler
 /Classified/search/      --> requires 'read' access to the handler
 /Classified/show/        --> requires 'read' access to the handler
 /Classified/create/      --> requires 'write' access to the handler
 /Classified/edit/        --> requires 'write' access to the handler
 /Classified/remove/      --> requires 'write' access to the handler

Using:

 %OpenInteract::Handler::Classified::security =3D (
  DEFAULT_SECURITY_KEY() =3D> SEC_LEVEL_READ,
 );

Means that the minimum security for any task not specified is
'read'. And if a task isn't specified in the package security hash and
there's no default set by you, then OpenInteract assumes 'write'
access is required to run the task.

Hope that makes sense,

Chris

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

Re: [Openinteract-help] static page serving and templates

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

* Chris Winters (ch...@cw...) [011210 20:42]:
> * John Sequeira (js...@me...) [011210 17:29]:
> > I'm having some trouble serving static pages.  I've got a package
> > with some web pages in the /html folder.  GIF's in a package
> > subfolder /html/images are served up correctly from my templates,
> > but I can't directly access these pages from a url. In other words,
> > http://myserver.com/mylogo.gif works but
> > http://myserver.com/newpagename.htm get a file not found error.  The
> > OpenInteract default page serves up correctly, so base_page is
> > working...  but not on html within my package.
> 
> Doh! I forgot to add this in to the apply/upgrade_package process. The
> problem is that there are no 'page' objects corresponding to the files
> in the filesystem. I'll try and fix this for the next verrsion. 

Well, I took a look at this and we have some problems. Basically,
there is no OpenInteract environment created when this process
(apply/upgrade_package, or OpenInteract::Package->install_to_website)
is running. The main reason is that we could be calling this when the
website is first being created, or before the user has configured the
site, or before the user has created the SQL tables necessary to hold
what we need.

So... the answer for now (and maybe forever) is to create a
data/mypages.dat file that includes the information OI needs to create
objects during the 'install_sql' action. This is pretty easy -- take a
look at:

 pkg/base_page-x.xx/data/page.dat
 pkg/system_doc-x.xx/data/page.dat

You'd then just specify it in your SQLInstall class, like:

 $BASE_INSTALL/pkg/base_page-x.xx/OpenInteract/SQLInstall/Page.pm
 $BASE_INSTALL/pkg/system_doc-x.xx/OpenInteract/SQLInstall/SystemDoc.pm

Also with the next version I'll probably have (somewhere) a script or
action you can call from oi_manage that will dump SQL data into the
above format for you. And an alteration of this could make for
portable/installable themes, which would be nifty.

Later,

Chris

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

Re: [Openinteract-help] new group?

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

* John Sequeira (js...@me...) [011212 12:00]:
> 'New group' doesn't seem to be working.
> 
> I get a "Group Detail" page containing a table with field labels,
> but no form fields when I go to http://127.0.0.1/Group/show/?edit=1
> 
> I looked at the code for the Group.pm and it doesn't look like
> there's any save routine or edit-specific template in the
> filesystem.  I understand this might be served up by SPOPS or the
> CommonHandler, but it didn't look like it was the intent.
> 
> I posted a bug report in SourceForge, but I'd like to mess around
> with security and creating a group is pretty key.  If there's a
> short term workaround I'd be grateful to hear about it.

I found the problem and fixed it. The new base_group package is (or
will be shortly) up on the Sourceforge file area [1] and the updates
are also in CVS.

Thanks for the report!

Chris

[1] http://sourceforge.net/project/showfiles.php?group_id=16810

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

Re: [Openinteract-help] calling handlers from code.

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

* Victor Piterbarg (ope...@ha...) [011212 15:35]:

> I wrote this handler that manages the purchasing process. It
> basically checks that all the needed objects exist -- like user
> profile, a credit card, etc., -- and calls appropriate action. For
> example, if there is no user profile it calls up the handler for
> user profiles with the 'create' task. Here's the gist of how I do
> it:
> ...
> sub buy_stuff
> {
> 	if(!$profile)
> 	{
> 		return OpenInteract::Handler::RegNasa->handler({task => 'create'});
> 	}
> }
> 
> This seems to work fine actually. I just was wondering if there
> perhaps was an interface to just run one of the actions I have
> defined in actions.perl from within a handler -- without having to
> explicitly refer to the handler I want to run. Seems it would be
> neater that way. Thanks.

Yes -- you can do:

 my ( $class, $method ) = $R->lookup_action( 'action_name' );
 $class->handler({ task => 'create' });

or if you'd prefer calling it directly:

 $class->$method();

You can see an example of this in OpenInteract::Handler::Logout in the
'base' package where we do:

 my ( $action_class, $action_method ) = $R->lookup_action( 'redirect' );
 return $action_class->$action_method({ url => $return });

This will be replaced in the relatively near future by an actual
action dispatcher, where you'd simply do something like:

 $R->dispatch( 'action_name', \%params );

And have security get checked properly, parameters from the action be
passed into the action, etc.

Chris

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

[Openinteract-help] calling handlers from code.

[Victor P. <ope...@ha...>]

Hi,

I wrote this handler that manages the purchasing process. It basically
checks that all the needed objects exist -- like user profile, a credit
card, etc., -- and calls appropriate action. For example, if there is no
user profile it calls up the handler for user profiles with the 'create'
task. Here's the gist of how I do it:

package OpenInteract::Handler::Purchase;

...
use OpenInteract::Handler::RegNasa;
@OpenInteract::Handler::Purchase::ISA     = qw(
        OpenInteract::GenericDispatcher
);

...

sub buy_stuff
{
	if(!$profile)
	{
		return OpenInteract::Handler::RegNasa->handler({task => 'create'});
	}
}

This seems to work fine actually. I just was wondering if there perhaps was
an interface to just run one of the actions I have defined in actions.perl
from within a handler -- without having to explicitly refer to the handler I
want to run. Seems it would be neater that way. Thanks.

-Victor

---
"Tatarsky, of course,  hated most of the manifestations of Soviet power, but
he still couldn't understand why  it was worth exchanging an evil empire for
an evil banana republic" --Viktor Pelevin, Generation P.

Re: [Openinteract-help] new group?

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

* John Sequeira (js...@me...) [011212 12:00]:
> 'New group' doesn't seem to be working.
> 
> I get a "Group Detail" page containing a table with field labels,  but no
> form fields when I go to http://127.0.0.1/Group/show/?edit=1
> 
> I looked at the code for the Group.pm and it doesn't look like there's any
> save routine or edit-specific template in the filesystem.  I understand this
> might be served up by SPOPS or the CommonHandler,  but it didn't  look like
> it was the intent.
> 
> I posted a bug report in SourceForge, but I'd like to mess around with
> security and creating a group is pretty key.  If there's a short term
> workaround I'd be grateful to hear about it.

Does the user you're logged in as have permissions to edit group
objects? Generally only members of the 'site admin' group or the
superuser can modify groups.

If that user should have permission to do so, I'll try and check on
this tonight -- I don't have a new OI install (yet) where I am during
the day.

> Also - the scan_for_new fix on static pages worked for me. thx.  I'm
> not sure why images were working... on my dev machine I haven't
> bothered with the proxy configuration.  it was probably some
> mime-type voodoo.

If you're using the httpd_modperl_solo.conf configuration then it has:

 <Location /images>
     SetHandler default-handler
 </Location>

Which tells Apache's normal routines to deal with everything under
/images.

Although I'm willing to chalk it up to voodoo, too :-)

Later,

Chris

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

Re: [Openinteract-help] base_page and mime types

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

* Andreas Nolte (And...@Be...) [011212 11:09]:
> .. well, while debugging my config errors, within some error
> conditions, you get transfered to search_form.. - just to let you
> know.

I fixed CommonHandler a few days ago to make this configurable so this
won't happen anymore. You can now setup what action will be taken
after a remove() as well as when a show(), edit() or remove() fails.
Before I release the next version I'll go through all the handlers and
make sure these are set properly.

> Dietmar and I talked about extending base_page a bit. Just to make
> sure, that you are not doing this already: we would like to be able
> to add local handlers as a content type. The reason is, that we
> would like build a system, where users can upload simple files
> through dull forms liks "ACME Call Center statistic of the day" and
> have the user etc. plotted into the table automatically. Based on
> this and the provided securety, we would build a dynamic view, where
> you only get links on those files, for which you have rights. If you
> could get handlers into this system, you could also manage these
> dynamically here.

Nice! I'm not planning on anything like that, so I'm interested to see
how it goes for you. And it would be nice to say that someone has used
OI to build a content management system :-)

Chris

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

[Openinteract-help] new group?

[John S. <js...@me...>]

'New group' doesn't seem to be working.

I get a "Group Detail" page containing a table with field labels,  but no
form fields when I go to http://127.0.0.1/Group/show/?edit=1

I looked at the code for the Group.pm and it doesn't look like there's any
save routine or edit-specific template in the filesystem.  I understand this
might be served up by SPOPS or the CommonHandler,  but it didn't  look like
it was the intent.

I posted a bug report in SourceForge, but I'd like to mess around with
security and creating a group is pretty key.  If there's a short term
workaround I'd be grateful to hear about it.

John Sequeira
http://www.pobox.com/~johnseq

Also - the scan_for_new fix on static pages worked for me. thx.  I'm not
sure why images were working... on my dev machine I haven't bothered with
the proxy configuration.  it was probably some mime-type voodoo.

AW: [Openinteract-help] base_page and mime types

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

.. well, while debugging my config errors, within some error =
conditions, you
get transfered to search_form.. - just to let you know.

Dietmar and I talked about extending base_page a bit. Just to make =
sure,
that you are not doing this already: we would like to be able to add =
local
handlers as a content type. The reason is, that we would like build a
system, where users can upload simple files through dull forms liks =
"ACME
Call Center statistic of the day" and have the user etc. plotted into =
the
table automatically. Based on this and the provided securety, we would =
build
a dynamic view, where you only get links on those files, for which you =
have
rights. If you could get handlers into this system, you could also =
manage
these dynamically here.=20


-----Urspr=FCngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]
Gesendet: Mittwoch, 12. Dezember 2001 17:12
An: Nolte, Andreas, D22K-MSN
Cc: ope...@li...
Betreff: Re: [Openinteract-help] base_page and mime types


* Andreas Nolte (And...@Be...) [011212 09:22]:
> .. and search_results is missing...
>=20
> Von: Nolte, Andreas, D22K-MSN=20
> Gesendet: Mittwoch, 12. Dezember 2001 14:59
> An: 'Chris Winters'
> Cc: ope...@li...
> Betreff: AW: [Openinteract-help] base_page and mime types
>=20
>=20
> .. OK, scrapping static_page did it. Though I found s.th. else: you =
forgot
> to override MY_SEARCH_FORM_TEMPLATE to return page_search_form =
instead of
> search_form.

Actually, I hadn't implemented either of these yet :-) If you call:

 /Page/directory_list/

You get a list of all directories, and you can drill down into them to
get a listing of pages in the directory. But I understand if you have
30,000 files this might not be the most desirable action.

The directory listing was to be an intermediate step until I needed to
create the searching functionality. Since that was determined by the
first person who asked, and you asked, it will likely be in the next
version :-)

Later,

Chris

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

Re: [Openinteract-help] base_page and mime types

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

* Andreas Nolte (And...@Be...) [011212 09:22]:
> .. and search_results is missing...
> 
> Von: Nolte, Andreas, D22K-MSN 
> Gesendet: Mittwoch, 12. Dezember 2001 14:59
> An: 'Chris Winters'
> Cc: ope...@li...
> Betreff: AW: [Openinteract-help] base_page and mime types
> 
> 
> .. OK, scrapping static_page did it. Though I found s.th. else: you forgot
> to override MY_SEARCH_FORM_TEMPLATE to return page_search_form instead of
> search_form.

Actually, I hadn't implemented either of these yet :-) If you call:

 /Page/directory_list/

You get a list of all directories, and you can drill down into them to
get a listing of pages in the directory. But I understand if you have
30,000 files this might not be the most desirable action.

The directory listing was to be an intermediate step until I needed to
create the searching functionality. Since that was determined by the
first person who asked, and you asked, it will likely be in the next
version :-)

Later,

Chris

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

AW: [Openinteract-help] base_page and mime types

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

.. and search_results is missing...

-----Urspr=FCngliche Nachricht-----
Von: Nolte, Andreas, D22K-MSN=20
Gesendet: Mittwoch, 12. Dezember 2001 14:59
An: 'Chris Winters'
Cc: ope...@li...
Betreff: AW: [Openinteract-help] base_page and mime types


.. OK, scrapping static_page did it. Though I found s.th. else: you =
forgot
to override MY_SEARCH_FORM_TEMPLATE to return page_search_form instead =
of
search_form.

later,

Andreas

-----Urspr=FCngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]
Gesendet: Mittwoch, 12. Dezember 2001 14:51
An: And...@Be...
Cc: ope...@li...
Betreff: Re: [Openinteract-help] base_page and mime types


* Andreas Nolte (And...@Be...) [011212 08:29]:
> .. I tried to overide the edit_document_box action in the
> action.perl of static_page because of this and this didn`t do it.=20

It's most likely still in the base installation action.perl file. (One
of the more annoying things I hope to fix...)

> Do I need the static_page package to be able to run the
> scan_for_new.pl script?

Nope -- once the static_page2base_page.pl has been run, you should be
able to get rid of the static_page package altogether.

Later,

Chris

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

AW: [Openinteract-help] base_page and mime types

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

.. OK, scrapping static_page did it. Though I found s.th. else: you =
forgot
to override MY_SEARCH_FORM_TEMPLATE to return page_search_form instead =
of
search_form.

later,

Andreas

-----Urspr=FCngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]
Gesendet: Mittwoch, 12. Dezember 2001 14:51
An: And...@Be...
Cc: ope...@li...
Betreff: Re: [Openinteract-help] base_page and mime types


* Andreas Nolte (And...@Be...) [011212 08:29]:
> .. I tried to overide the edit_document_box action in the
> action.perl of static_page because of this and this didn`t do it.=20

It's most likely still in the base installation action.perl file. (One
of the more annoying things I hope to fix...)

> Do I need the static_page package to be able to run the
> scan_for_new.pl script?

Nope -- once the static_page2base_page.pl has been run, you should be
able to get rid of the static_page package altogether.

Later,

Chris

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

Re: [Openinteract-help] base_page and mime types

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

* Andreas Nolte (And...@Be...) [011212 08:29]:
> .. I tried to overide the edit_document_box action in the
> action.perl of static_page because of this and this didn`t do it. 

It's most likely still in the base installation action.perl file. (One
of the more annoying things I hope to fix...)

> Do I need the static_page package to be able to run the
> scan_for_new.pl script?

Nope -- once the static_page2base_page.pl has been run, you should be
able to get rid of the static_page package altogether.

Later,

Chris

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

Re: [Openinteract-help] base_page and mime types

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

* Andreas Nolte (And...@Be...) [011212 03:43]:
> .. just got this one by RTFM: when updating to OI 1.36 on my test
> site, I used the sample server.ini, which defined the "none" handler
> to be page. On production I used the sample server.perl, which
> defined this still to be basicpage, which does not know about mime
> types..

Ah! I'll fix this, thanks.

> Well, now I tried scan_for_new and it also works for 30.000
> docs.... I think, base_page will get many of our users happy, which
> want to upload interesting things like excel statistics about
> whatever... Really great work, again Chris!

Excellent! Feedback is good :-)

A big motivation for doing this is to move toward enabling
OpenInteract to stand on its own using a pure-perl webserver. The
Apache/mod_perl solution would still work of course, but the
standalone server will hopefully be sufficient for most needs.

Chris

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

AW: [Openinteract-help] base_page and mime types

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

.. I tried to overide the edit_document_box action in the action.perl =
of
static_page because of this and this didn`t do it. Do I need the =
static_page
package to be able to run the scan_for_new.pl script?=20

-----Urspr=FCngliche Nachricht-----
Von: Chris Winters [mailto:ch...@cw...]
Gesendet: Mittwoch, 12. Dezember 2001 14:38
An: And...@Be...
Cc: ope...@li...
Betreff: Re: [Openinteract-help] base_page and mime types


* Andreas Nolte (And...@Be...) [011212 04:17]:
> ..aiihh! Just found another catch: if you have security set up for =
static
> page, remember to update sys_security from =
class=3D"MYSITE::BasicPage" to
> class=3D'MYSITE::Page' !

Forgot to add that -- thanks. (I'll add this to the 'UPGRADE' doc in
the base_page package.)

> Now only one bit is left: get the right edit_document_box
> called. Right now still the static_page variant gets loaded and I do
> not know why...

If you're not using the 'static_page' package anymore, just do:

 $ oi_manage remove_package --package static_page

Both packages define the edit_document_box, and since static_page gets
picked up last in the initialization process it overwrites the action
by the same name defined in base_page.

Chris

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