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

Re: [Openinteract-dev] fetch_count patch for SPOPS::DBI.pm

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

On Tue, 2002-04-09 at 16:15, Ray Zimmerman wrote:
> Chris,
> 
> Here's a small patch which allows you to do joins safely in fetch_count().

Thanks. I've modified this to call 'id_field_select()' to get the
relevant SELECT clause so that multifield primary key classes can
override it with a generated method that does the right thing.

Chris

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

[Openinteract-dev] fetch_count patch for SPOPS::DBI.pm

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

Chris,

Here's a small patch which allows you to do joins safely in fetch_count().

--- DBI.pm.orig Tue Apr  9 16:06:16 2002
+++ DBI.pm      Tue Apr  9 16:10:21 2002
@@ -369,7 +369,7 @@

  sub fetch_count {
      my ( $class, $p ) = @_;
-    $p->{select} = [ $class->id_field ];
+    $p->{select} = [ $class->table_name . '.' . $class->id_field ];
      my $sth = $class->_execute_multiple_record_query( $p );
      my $row_count = 0;
      while ( my $row = $sth->fetch ) {

-- 
  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: [Openinteract-dev] XML server

[Perrin H. <pe...@el...>]

Ben Avery wrote:
> Could I just use blank templates, with my
> package creating the XML structures?

Template Toolkit is quite good for generating XML, but of course if you 
want to build the XML in another way you can make your templates just a 
single variable call to print the content passed into them.

- Perrin

Re: [Openinteract-dev] XML server

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

On Tue, 2002-04-02 at 05:30, Ben Avery wrote:
> hi again. happy easter!
> 
> The project I'm developing will serve data in two ways: for one group of
> users through a browser, and all this content I'm going to manage with OI,
> no problemo.
> But another group of users will be posting/receiving information to and from
> the central DB from (don't laugh - I didn't write the spec :-)  a PC
> application written in VB6. The data will be sent as XML, with the
> information and the transactions required, sent over HTTP. 
> So really I want OI to also work as an XML application server. Can anyone
> see any problems with this? Could I just use blank templates, with my
> package creating the XML structures?

Not a problem. You'll probably need to set in your handler the proper
content type, which you can do with something like:

  $R->{page}{content_type} = 'text/xml';

Icky, yes. It will be fixed :-)

Chris

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

[Openinteract-dev] XML server

[Ben A. <be...@th...>]

hi again. happy easter!

The project I'm developing will serve data in two ways: for one group of
users through a browser, and all this content I'm going to manage with OI,
no problemo.
But another group of users will be posting/receiving information to and from
the central DB from (don't laugh - I didn't write the spec :-)  a PC
application written in VB6. The data will be sent as XML, with the
information and the transactions required, sent over HTTP. 
So really I want OI to also work as an XML application server. Can anyone
see any problems with this? Could I just use blank templates, with my
package creating the XML structures?

Ben Avery
YouthNet UK
www.youthnet.org.uk

[Openinteract-dev] Re: [Openinteract-help] OI on Oracle

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

On Tue, 2002-03-26 at 13:05, Ben Avery wrote:
> I'm going ahead with using OI on this project, but need to use it with
> Oracle (8i Enterprise). 
> I understand SPOPS itself is okay with Oracle, but not OI yet. Is that
> right?
> I'm happy to do the work necessary to port OI to Oracle, but might need a
> little help, as I don't have too much surplus time on this project.

Excellent. These things always go much quicker when someone actually
needs to get something done :-)

> I've been looking through the files in the website I've created with
> oi_manage, to identify pieces of code which will need modification. The SQL
> in the .sql files in /struct dirs mostly won't work with Oracle, these will
> be easy to convert, however.

It would be great if you kept the converted files around -- we can
easily just make them part of the packages that get used for oracle
installs. In addition to the varchar -> varchar2 (etc.) issues, we'll
need to create files for the different sequences to create as well.
Easy.
 
> Could you help me identify any other places where DB-specific code is
> located, and any new modules that will need to be created to handle
> Oracle-specific code, and even any considerations you've come across in
> porting OI between DBs?

I'll need to noodle over this a little bit. I seriously doubt we need to
create any new modules, but that's just a first glance at the issue.

The only issues with porting OI across DBs have generally been small
things -- this database doesn't like 'NOT NULL' used with 'DEFAULT',
that database requires 'NOT NULL' to be used with 'DEFAULT' if a field
is used in a UNIQUE index. Annoying stuff :-)

Chris

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

[Openinteract-dev] OI on Oracle

[Ben A. <be...@th...>]

I'm going ahead with using OI on this project, but need to use it with
Oracle (8i Enterprise). 
I understand SPOPS itself is okay with Oracle, but not OI yet. Is that
right?
I'm happy to do the work necessary to port OI to Oracle, but might need a
little help, as I don't have too much surplus time on this project.

I've been looking through the files in the website I've created with
oi_manage, to identify pieces of code which will need modification. The SQL
in the .sql files in /struct dirs mostly won't work with Oracle, these will
be easy to convert, however.

Could you help me identify any other places where DB-specific code is
located, and any new modules that will need to be created to handle
Oracle-specific code, and even any considerations you've come across in
porting OI between DBs?

----------------------------------------------------------------
Ben Avery			YouthNet UK	
Analyst/Programmer		2nd Floor
YouthNet UK			Broadmead House
Tel:+44 020 7925 2530		21 - 23 Panton Street
Fax:+44 020 7925 2830		London SW1Y 4DR              

e-mail:be...@th...
www.thesite.org.uk 
www.do-it.org.uk
www.youthnet.org.uk
----------------------------------------------------------------

Re: [Openinteract-dev] developer guide example

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

On Mon, 2002-03-18 at 10:52, Ben Avery wrote:
> I'm having difficulty working through the 'fruit' example package, from the
> OI Developer's Guide document.
> I'm pretty sure I've followed the instructions to the letter, OI and SPOPS
> seem to have installed correctly.
> The error comes when I get to the following oi_manage command:
> 
> oi_manage --base_dir /export/home/openinteract --website_dir
> /export/home/cares --package fruit apply_package
> 
> the response is:
> =========================
> Status of the packages you requested to be applied:
> fruit (0.01)
>   FAILED!: Cannot install package to website. Error: Website name not
>            set in package object.
> =========================

One question for you:

  1) Have you created a website already? From the statement above it
seems like you should have created a website in '/export/home/cares',
meaning it should have the directories 'conf/', 'pkg/', 'html/', among
others.

Also, note that I've just modified slightly the developer.html document
in CVS. You'll need to change the 'isa' key in conf/spops.perl to use
'OpenInteract::SPOPS::DBI' instead of 'OpenInteract::SPOPS' You might
also look at the 'doc/fruit-0.09.tar.gz' package as an example.

Good luck!

Chris

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

[Openinteract-dev] RE: developer guide example

[Ben A. <be...@th...>]

D'oh!

I've just realised my mistake, I hadn't first worked through the Admin guide
first to correctly create the website. 
sorry to waste anyone's time :-(

Ben
> ----------------------------------------------------------------
> Ben Avery			YouthNet UK	
> Analyst/Programmer		2nd Floor
> YouthNet UK			Broadmead House
> Tel:+44 020 7925 2530		21 - 23 Panton Street
> Fax:+44 020 7925 2830		London SW1Y 4DR              
> 
> e-mail:be...@th...
> www.thesite.org.uk 
> www.do-it.org.uk
> www.youthnet.org.uk
> ----------------------------------------------------------------
> 
> 

Re: [Openinteract-dev] Generic way to translate error messages

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

On Mon, 2002-03-18 at 09:08, Perrin Harkins wrote:
> The usual way to do it is to use constants, so you can say something 
> like $INVALID_EMAIL_ADDRESS instead of 15387.  You could even use a name 
> like that as the error's ID instead of a number.

I'm ambivalent about using a name as an error ID. It's generally easier
to remember than a code but you'd almost certainly have to look it up
anyway to find the exact phrasing. So why not make it succinct? Using
constants as you suggest allows you to do both, so that sounds good to
me. 

> Is it really necessary to use a database for this?  It seems like this 
> would be a read-only file in production.  I think this could be done 
> with a simple file structure, which would make it easy enough to edit by 
> hand (while still allowing tools to be built) and avoid the performance 
> issues.
> 
> Things like this straddle the line between templates and data.  In 
> general, I like to put things on the file system when possible so that 
> they're easy to get at.

In general, I agree with you. And for file structures we already have a
format defined in Apache::Language, although I've never used that so I
don't know how successful it is. To be more explicit about my
motivations for using a database (thinking out loud here):

1. We already have mature tools to manipulate objects in a database.
(OTOH, if the messages are SPOPS objects, we don't really care where/how
they're stored.)

2. Keeping data in one place is a Good Thing for backup/restore
procedures, etc.

3. While error messages will rarely (if ever) be modified once they're
loaded, other localization messages almost certainly will be modified
more frequently and I hope to be able to use the same tools to do this.

4. Keeping a centralized store of messages makes it easier to ensure the
message are consistent across multiple servers 

Performance may be an issue, but I think (hope?) caching the messages on
demand will take care of that.

The ease of editing a file is something this system lacks. To
accommodate future use of files we'll probably have to either create an
import process to bring file contents into a database or create an open
interface so you can use either the database or the filesystem. I'd
rather do the former (it's easier) but can easily remain open for the
latter.

Chris

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

[Openinteract-dev] developer guide example

[Ben A. <be...@th...>]

I'm having difficulty working through the 'fruit' example package, from the
OI Developer's Guide document.
I'm pretty sure I've followed the instructions to the letter, OI and SPOPS
seem to have installed correctly.
The error comes when I get to the following oi_manage command:

oi_manage --base_dir /export/home/openinteract --website_dir
/export/home/cares --package fruit apply_package

the response is:
=========================
Status of the packages you requested to be applied:
fruit (0.01)
  FAILED!: Cannot install package to website. Error: Website name not
           set in package object.
=========================

can anyone help - where and how do I set this?

----------------------------------------------------------------
Ben Avery			YouthNet UK	
Analyst/Programmer		2nd Floor
YouthNet UK			Broadmead House
Tel:+44 020 7925 2530		21 - 23 Panton Street
Fax:+44 020 7925 2830		London SW1Y 4DR              

e-mail:be...@th...
www.thesite.org.uk 
www.do-it.org.uk
www.youthnet.org.uk
----------------------------------------------------------------

Re: [Openinteract-dev] Generic way to translate error messages

[Perrin H. <pe...@el...>]

Chris Winters wrote:
> The only problem with this is using an error code -- it doesn't
> immediately *feel* right to me. But I don't really see any way around
> this

The usual way to do it is to use constants, so you can say something 
like $INVALID_EMAIL_ADDRESS instead of 15387.  You could even use a name 
like that as the error's ID instead of a number.

> Using a database makes things easier for us -- no file locking issues,
> etc. -- so we'll almost certainly stick to it. I have some potential
> changes below.

Is it really necessary to use a database for this?  It seems like this 
would be a read-only file in production.  I think this could be done 
with a simple file structure, which would make it easy enough to edit by 
hand (while still allowing tools to be built) and avoid the performance 
issues.

Things like this straddle the line between templates and data.  In 
general, I like to put things on the file system when possible so that 
they're easy to get at.

- Perrin

Re: [Openinteract-dev] Generic way to translate error messages

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

On Mon, 2002-03-18 at 04:43, Magnus Espeland wrote:
> I'm developing for norwegian speaking users and need to make the sites in
> norwegian, but I see error messages and other small messages like this in
> the source code (from base_user::NewUser.pm):
> 
> my $error_msg = 'Could not create user in database. Error has ' .
> 		'been logged and administrator contacted.';
> 
> I was thinking, can we do something like this:
> 
> my $error_msg = OpenInteract::Translate->error('msg' => 'Could not create
> 						user ?1?, because ?2?',
> 						'1' => "$username",
> 						'2' => "$foo");
> 
> (you probably want to change class/method name and tokens, but that's
> another matter;-)

Error messages and handling has always been a sticky issue. What's in OI
right now is a little clunky and, as you found out, is impossible to
extend in any meaningful way.

I think what you've specified here is a start. But using the message in
the method call gives people the impression they can change it and the
translation will still work.

What many systems do is use error codes to specify the message to
display and allow variable substitution similar to what you've
specified. So we could create something like:

 my $msg = OpenInteract::Translate->error( 15789, $username, $foo );

Or even create a shortcut:

 use OpenInteract::Translate qw( error_message );
 ...
 my $msg = error_message 15789, $username, $foo;

The message would be pulled from a table based on the user's language,
or fall through to english if none is specified for the user's language.

The only problem with this is using an error code -- it doesn't
immediately *feel* right to me. But I don't really see any way around
this -- this is how standard libraries like GNU gettext work. So I
assume that after some usage it begins to feel more appropriate :-)

> The error method simply substitutes ?1? with $username and ?2? with $foo
> and falls thru if the user wants english. If not it replaces it with the
> translated version, like this:
>
> 1.First check if it's cached in the module
> I reckon we could save some db hits this way. Maybe we'll have to limit
> the cache size though, so we don't eat too much. Maybe we should do some
> cache ageing too?

We'd probably want to cache as much as possible. The web interface
should signal the cache to expire only the items being edited, otherwise
since these change fairly rarely we should have a very long-lived cache
for this.

> 2.If it's not in the module, check the database
> See my proposed db layout bellow. Maybe we should do it in a file instead?
> I feel like db, but don't know why;-) Add the translation to the cache in
> the module.

Using a database makes things easier for us -- no file locking issues,
etc. -- so we'll almost certainly stick to it. I have some potential
changes below.

> 3.If it's not in the database, add it
> If we can't find it, we add the english version to the db and tell an
> admin, (s)he will then see an untranslated line in the webinterface. This
> way all new erros in new versions of a package gets added, and we can
> translate as they come. The idea is to make it flexible...

Flexible is good.

> 4.Use english as backup language
> We already have the original message, so we can use that. Maybe some
> people would prefer a backup response in their language instead.

Yes, this should be modifiable from the server configuration.

> What I think we need/issues:
> 
> - Webinterface, to use for translating and uploading already translated
> errors (in a file)

Yes.

> - A way to share tranlations easy 

Yes, excellent idea.

> - It should be very little extra work for developers, maybe my proposed
> syntax is a bit too long?

Comments above.

> - Timestamp error messages, so that messages in old packages we don't use
> anymore can be discarded

Well, this probably isn't necessary if we use a database.

> - Larger language field in the sys_user table, we have 4 languages in
> Norway.. (Only two in popular use though)

I confess ignorance to these sorts of issues. I had thought the standard
language markers were two characters, but now I see there are also five
character versions (e.g., 'en-br'). Do you know if this is the largest
they get?

> Proposed db layout:
> 
> CREATE TABLE error_msg {
> 	error_msg_id	%%INCREMENT%%,
> 	error_msg	text,
> 	last_used	timestamp,
> 	primary key	(error_msg_id)
> };
> 
> CREATE TABLE error_msg_translated {
> 	error_msg_id	%%INCREMENT_TYPE%%,
> 	language	char(4),
> 	error_msg	text,
> 	primary key	(error_msg_id,language)
> };

With the ideas I mentioned above, we might use something like:

CREATE TABLE sys_error_message (
      error_msg_id     %%INCREMENT%%,
      error_code       varchar(8) not null
      language         varchar(5) not null,
      message          varchar(255),
      primary key( error_msg_id ),
      unique( error_code, language )
)

For tracking error_codes, we might also have:

CREATE TABLE sys_error_code (
      error_code      varchar(8) not null,
      error_type      varchar(150) not null,
      package         varchar(30) null,
      primary key( error_code )
)

This way you can easily create a report of all error codes in the system
for reference purposes. The 'package' field is so you can tell which
package created the original error message.

Both our schemes would also make it fairly simple to create 'message
balls', or distributable bundles of error messages. I've already done
something similar to this for distributing themes ('theme balls') in the
next version of OI.

> I haven't started coding this yet, I would like your feedback first...
> 
> Chris: How would you like me to make patches for you, if you want to
> add it in the offical code? (I've never made a patch before ;-)

We'd definitely add this to the base_error package. What do you think
about the error code idea?

Another thing to consider: back at the beginning of October on the -dev
list, Jochen Lillich and I had a more generic discussion about
localization in templates. But I have not been able to work on this yet
for the next version of OI. I don't know if these ideas should
necessarily be merged, but we might want to think about it. I actually
have some ideas on how they might be merged, but this email is getting
quite long.... :-)

Later,

Chris

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

[Openinteract-dev] Generic way to translate error messages

[Magnus E. <ma...@he...>]

Hi all!

I'm developing for norwegian speaking users and need to make the sites in
norwegian, but I see error messages and other small messages like this in
the source code (from base_user::NewUser.pm):

my $error_msg = 'Could not create user in database. Error has ' .
		'been logged and administrator contacted.';


I was thinking, can we do something like this:

my $error_msg = OpenInteract::Translate->error('msg' => 'Could not create
						user ?1?, because ?2?',
						'1' => "$username",
						'2' => "$foo");

(you probably want to change class/method name and tokens, but that's
another matter;-)

The error method simply substitutes ?1? with $username and ?2? with $foo
and falls thru if the user wants english. If not it replaces it with the
translated version, like this:

1.First check if it's cached in the module
I reckon we could save some db hits this way. Maybe we'll have to limit
the cache size though, so we don't eat too much. Maybe we should do some
cache ageing too?

2.If it's not in the module, check the database
See my proposed db layout bellow. Maybe we should do it in a file instead?
I feel like db, but don't know why;-) Add the translation to the cache in
the module.

3.If it's not in the database, add it
If we can't find it, we add the english version to the db and tell an
admin, (s)he will then see an untranslated line in the webinterface. This
way all new erros in new versions of a package gets added, and we can
translate as they come. The idea is to make it flexible...

4.Use english as backup language
We already have the original message, so we can use that. Maybe some
people would prefer a backup response in their language instead.


What I think we need/issues:

- Webinterface, to use for translating and uploading already translated
errors (in a file)
- A way to share tranlations easy 
- It should be very little extra work for developers, maybe my proposed
syntax is a bit too long?
- Timestamp error messages, so that messages in old packages we don't use
anymore can be discarded
- Larger language field in the sys_user table, we have 4 languages in
Norway.. (Only two in popular use though)


Proposed db layout:


CREATE TABLE error_msg {
	error_msg_id	%%INCREMENT%%,
	error_msg	text,
	last_used	timestamp,
	primary key	(error_msg_id)
};


CREATE TABLE error_msg_translated {
	error_msg_id	%%INCREMENT_TYPE%%,
	language	char(4),
	error_msg	text,
	primary key	(error_msg_id,language)
};



I haven't started coding this yet, I would like your feedback first...

Chris: How would you like me to make patches for you, if you want to
add it in the offical code? (I've never made a patch before ;-)

Bertelsmann.de guys: Did you do anything like this when translating to
german?


MVH/Best regards
-- 
Magnus Espeland
ma...@in...

RE: [Openinteract-dev] a wise choice?

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

Hi Ben,

maybe, this might smooth your worries:

I am working for a Bertelsmann Services company, and we are building custom
service solutions ( callcenters, logistics, etc ) for othe companies ( like
a major german airline, various banks, etc. )

We about a year ago we looked at all available perl web environments and did
not find anything, which met out goals ( and we looked at a lot, like Mason
etc. al ):
- OO desing
- MVS paradigm
- easy reuse
- installation framework
- able to do smaller apps in half a day
- integrate our LDAP directory for auth etc.

Right now we are running our intranet on OI ( with Linux and mysql/InnoDB
plus LDAP from a Netware cluster ) with currently about 500 users online
every day, who use real apps, like a trouble ticketing system, search
engines, file managing tools. The key point here was, to be able to build
interactive apps ( opposed to static pages ) within hours or days.
On the other end we are currently developing things like a customer ordering
system with credit card payment for a large mobile telephone company or a
desease management system for a public health care company.

Since I claim not to be mad, I know, what I do going this way ( well, at
least I am the responsible IT manager for this .. ).

Hope I could encourage you to use OI ! Otherwise, please ask me questions...

regards,

Andreas
-----Original Message-----
From: Ben Avery
To: 'ope...@li...'
Sent: 15.03.02 18:30
Subject: [Openinteract-dev] a wise choice?

hi,   I work for a UK web-based charity, and am starting a new project
with
the government to design and develop a web-based system for companies to
get
their employees involved in local and national community volunteering
work. 
I'm looking for some kind of web services framework to handle security,
user
sessions, templating and separation of HTML from code logic. I'd much
rather
go open source, and OpenInteract looks ideal, but I need a system which
can
guarantee reliability and good uptime.

I notice that the docs section of the OI site,
http://www.openinteract.org/docs/guides seems to work intermittently,
and
not at all at the moment, which is a little worrying.

Does anyone have commercial experience of using OI to deploy critical
systems, and any good/bad news stories?


Cheers!  (colloq. UK english - means thanks :-)

Ben Avery
----------------------------------------------------------------
Ben Avery			YouthNet UK	
Analyst/Programmer		2nd Floor
YouthNet UK			Broadmead House
Tel:+44 020 7925 2530		21 - 23 Panton Street
Fax:+44 020 7925 2830		London SW1Y 4DR              

e-mail:be...@th...
www.thesite.org.uk 
www.do-it.org.uk
www.youthnet.org.uk
----------------------------------------------------------------



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

[Openinteract-dev] a wise choice?

[Ben A. <be...@th...>]

hi,   I work for a UK web-based charity, and am starting a new project with
the government to design and develop a web-based system for companies to get
their employees involved in local and national community volunteering work. 
I'm looking for some kind of web services framework to handle security, user
sessions, templating and separation of HTML from code logic. I'd much rather
go open source, and OpenInteract looks ideal, but I need a system which can
guarantee reliability and good uptime.

I notice that the docs section of the OI site,
http://www.openinteract.org/docs/guides seems to work intermittently, and
not at all at the moment, which is a little worrying.

Does anyone have commercial experience of using OI to deploy critical
systems, and any good/bad news stories?


Cheers!  (colloq. UK english - means thanks :-)

Ben Avery
----------------------------------------------------------------
Ben Avery			YouthNet UK	
Analyst/Programmer		2nd Floor
YouthNet UK			Broadmead House
Tel:+44 020 7925 2530		21 - 23 Panton Street
Fax:+44 020 7925 2830		London SW1Y 4DR              

e-mail:be...@th...
www.thesite.org.uk 
www.do-it.org.uk
www.youthnet.org.uk
----------------------------------------------------------------

[Openinteract-dev] RE: fetch_group DEBUG flag?

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

On Mon, 2002-03-04 at 18:19, John Sequeira wrote:
> Drat.  I've got 0.56 and I don't see the trace output in the apache log.
> I'll scope the change logs to see if it's new.

IIRC this has been in there for a while, so I'm not sure what the
problem is. What happens when you create a self-contained (and more
easily debugged) script, like:

----------
#!/usr/bin/perl

use strict;
use OpenInteract::Startup;

{
    my $R = OpenInteract::Startup->setup_static_environment_options(
                 undef, {}, { temp_lib => 'lazy' } );
    $R->user->fetch_group({ where => 'last_name like ?',
                            value => 'smi%' });
}
----------

> > > Also, is there another way to get this info for debugging?
> >
> > Not right now. Did you have an idea about another way to get it?
> > Debugging has always kind of been a PITA, so ideas are welcome.
> 
> The other way I'd like to see the debug flag implemented is at the
> connection level.

This is an interesting idea. Actually, you can implement this now for
debugging purposes if you like. I probably won't put this in the final
code (performance), but maybe I'll make it conditional on the debug
being set in the datasource...

In any case, add the following to OpenInteract::SPOPS::DBI:

sub fetch_group {
    my ( $class, $p ) = @_;
    my $CONFIG = OpenInteract::Request->instance->CONFIG;
    my $datasource = $class->CONFIG->{datasource} ||
                     $CONFIG->{datasource}{default_connection_db};
    if ( $CONFIG->{datasource}{debug} ) {
        $p->{DEBUG} = $CONFIG->{datasource}{debug};
    }
    return $class->SUPER::fetch_group( $p );
}

This should enable you to use the configuration syntax you suggested:

> $data = {
>           'db_info' => {
>             'db_owner'    => '',
>             'username'    => 'test',
> 		...
>             'driver_name' => 'mysql',
> 		'debug'       => 1
>           },
>           ...
>  };
 
> Also,  it'd be cool if you delimited the SQL trace output in such a way that
> it could be easily grep'd out of the apache log file.

This is another interesting idea. We'd have to do something like split
the data into lines and then lead each debugging SQL line with a
particular string... I'll think about this one.

Later,

Chris

(cc'ing to oi-dev for posterity, etc.)

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

[Openinteract-dev] OpenInteract Mark II, a freeform jazz trio... [long]

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

(Playing at an amusement park near you...)

But seriously. As some of you might know, I've been working the last
five or six weeks on the next big version (OI2) of OpenInteract. It is
not yet at a usable state, but it's getting there and has reached the
point where some basic structures have already gelled into code and many
of the new features are on their way.

This is not a full rewrite. Some of the current things about
OpenInteract will be unchanged. But many of the fundamental structures
are being heavily refactored. Yes, this will require code changes. No, I
don't know the extent yet. Much of the changes will likely be automated
(if you wish), and most of the rest you should be able to use a
cookbook. I am trying to keep backward compatibility, but I'm also
trying to do things the right way :-)

So what are the changes?

 - OI will run under other environments: CGI, standalone HTTP server
(which I hope to include with the distribution ala OpenFrame), and
others. This has been a big motivation for many of the changes.

 - There will be no longer be a base installation directory, just a
website directory. This simplifies a number of plumbing tasks. This also
means the development process will be far more streamlined. Instead of: 

  develop->export->install->upgrade->restart server

you will just need to do the normal webdev:

  develop->restart server

You can then do an 'export' when you reach a good milestone.

 - Much of the functionality in the ubiquitious $R has been split out to
three separate objects:

    * Context: server-wide info, current request/response

    * Request: current request (session, URL, cookies, authentication,
etc.)

    * Response: current response (content type, content, cookies, etc.)

 - All of the management tasks are moved out of the monster script
'oi_manage' and into separate subclasses of 'OpenInteract::Manage',
which defines a simple interface for tasks that manage websites and
packages. This also means that we can create a web interface for this
stuff if we like.

 - (This part is still a little fuzzy) Handlers will all be subclasses
of an OpenInteract::Action, which does all the dispatching, security
checking, content caching, etc. If a handler wishes to use security, it
will just set it as part of its metadata (in conf/action.perl) rather
than in the class itself. 

Other components (boxes, complex template widgets, etc.) will be actions
as well, so it will be extremely easy to lookup a resource and generate
content from it and have all the other stuff (security checking,
caching) just happen for you.

There are more changes and many more details, but I don't want them to
get lost in a huge email. Hopefully as this stuff gels into code I'll be
able to create manual pages along the way (similar to SPOPS::Manual) and
have these available for everyone to read.

I haven't yet put the code into CVS on Sourceforge because I didn't know
if anyone other than me would find it useful yet -- only individual
pieces of it are currently working. LMK if you'd find it
useful/interesting.

For timeframe: I hope to get this (and more), plus SPOPS 1.0 (Ray Z's
modified relationship specs and the inheritable stuff, finally) all done
and ready to kick butt by the Perl Conference in July. I'm going to be
submitting proposals for one or two talks, so hopefully I'll be able to
go this year.

Later,

Chris

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

Re: [Openinteract-dev] base_page / common handler

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

On Tue, 2002-02-05 at 07:26, Die...@Be... wrote:
> Right now we're using base_page-0.77
> After uploading a file, the file will'be shown by default.
> (Common Handler method: sub MY_EDIT_DISPLAY_TASK       { return 'show' })
> But we want to show a refreshed file-list.
> So we inherited page and overwrote the method MY_EDIT_DISPLAY_TASK 
> -> MY_EDIT_DISPLAY_TASK       { return 'show_index' })
> 
> sub show_index {
> ...
> }
> 
> This is working ... but the URL in th browser is not updated. We don't  use
> redirect, because we want to process the error-message in $p if there is
> one.
> 
> Are there any possibilities to point to the correct URL?

I don't think it is possible to modify the URL the user sees without
doing a redirect. You might want to display one page if an error occurs,
and redirect to the directory index if there is no error.

Chris

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

[Openinteract-dev] base_page / common handler

[<Die...@Be...>]

Dear OI-Developers,

Right now we're using base_page-0.77
After uploading a file, the file will'be shown by default.
(Common Handler method: sub MY_EDIT_DISPLAY_TASK       { return 'show' })
But we want to show a refreshed file-list.
So we inherited page and overwrote the method MY_EDIT_DISPLAY_TASK 
-> MY_EDIT_DISPLAY_TASK       { return 'show_index' })

sub show_index {
    my ( $class, $p ) = @_;
    my $R = OpenInteract::Request->instance;

    $p->{directory} = $p->{location} = $R->apache->param('directory');

    my ( $dir_class, $dir_method ) =
$R->lookup_action($class->_get_location( $p ));
    
    delete $p->{page};
    delete $p->{object};

    return $dir_class->$dir_method( $p );
}

This is working ... but the URL in th browser is not updated. We don't  use
redirect, because we want to process the error-message in $p if there is
one.

Are there any possibilities to point to the correct URL?

Thanx in advance!

Greetings

                                                                    
Dietmar Hanisch
Applied Software Technology GmbH
A BERTELSMANN COMPANY
E-Mail:	Die...@ap...
Tel.:	04421/9789-75
Fax:	04421/9789-64

Re: [Openinteract-dev] Common-Handler

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

On Mon, 2002-02-04 at 07:10, Ewa...@ap... wrote:
> I want to use the Common-Handler and have a little problem with
> the method search.
>  
> I wrote a new Handler and tried to use the property skip_security.
> So I overwrote the method _search_build_and_run. At
> fetch_object I set value 1 to the skip_security property. In 
> the iterator hash was the value of the _skip_iterator key 1.
> It works.
>  
> In step 2 I overwrote the method MY_SEARCH_RESULTS_PAGED
> (return 1). This retrieve no entries. In the iterator hash the 
> value of the _skip_iterator key was undef. I think that is the 
> reason I don't retrieve an result.

You're probably correct. If you set SPOPS->DEBUG to 1 and watch your
error log, the fetch_object() method of SPOPS::Iterator::DBI should let
you know when it catches a security exception.

You can check your theory by removing SPOPS::Secure from the 'isa'
property in the spops.perl file, restarting the server and re-running
the search. However, removing security is probably not a permanent
option for you.

> Where do I have to set the skip_security property using the
> Common-Handler?

Ah, good question. Currently, you can't without hacking it yourself.
However, I just committed to CVS a change to OpenInteract::CommonHandler
which allows you to define something like:

 sub MY_SEARCH_ADDITIONAL_PARAMETERS {
     return { skip_security => 1 }
 }

This will be in the next version of OI.

Chris

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

[Openinteract-dev] Common-Handler

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

Hi out there,
 
I want to use the Common-Handler and have a little problem with
the method search.
 
I wrote a new Handler and tried to use the property skip_security.
So I overwrote the method _search_build_and_run. At
fetch_object I set value 1 to the skip_security property. In 
the iterator hash was the value of the _skip_iterator key 1.
It works.
 
In step 2 I overwrote the method MY_SEARCH_RESULTS_PAGED
(return 1). This retrieve no entries. In the iterator hash the 
value of the _skip_iterator key was undef. I think that is the 
reason I don't retrieve an result.
 
Where do I have to set the skip_security property using the
Common-Handler?
 
Can I set the skip_security in the spops.perl?
 
eh



                                                                  
Ewald Hinrichs 
Applied Software Technology GmbH 
A BERTELSMANN COMPANY 
E-Mail: Ewa...@ap... 
Tel.:   04421/9789-69 
Fax:    04421/9789-64 

 

[Openinteract-dev] Re: patch for bug in SPOPS::clone()

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

On Tue, 2002-01-29 at 15:11, Ray Zimmerman wrote:
> Hi Chris,
> 
> Here's a patch for SPOPS which fixes a problem with initialization 
> data passed in to clone(). The problem is that a field which has a 
> "true" value in the original object cannot be set to a false value by 
> a hash passed to clone().
> 
> --- SPOPS-0.56/SPOPS.pm Sun Jan 13 22:12:15 2002
> +++ SPOPS-0.56-patched/SPOPS.pm Tue Jan 29 14:37:51 2002
> @@ -183,7 +183,7 @@
>       while ( my ( $k, $v ) = each %{ $self } ) {
>           next unless ( $k );
>           next if ( $id_field and $k eq $id_field );
> -        $initial_data{ $k } = $p->{ $k } || $v;
> +        $initial_data{ $k } = exists $p->{ $k } ? $p->{ $k } : $v;
>       }
> 
>       return $class->new({ %initial_data, skip_default_values => 1 });

Thanks, applied.

(I always wanted to say that!)

Chris

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

[Openinteract-dev] patch for bug in SPOPS::clone()

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

Hi Chris,

Here's a patch for SPOPS which fixes a problem with initialization 
data passed in to clone(). The problem is that a field which has a 
"true" value in the original object cannot be set to a false value by 
a hash passed to clone().


--- SPOPS-0.56/SPOPS.pm Sun Jan 13 22:12:15 2002
+++ SPOPS-0.56-patched/SPOPS.pm Tue Jan 29 14:37:51 2002
@@ -183,7 +183,7 @@
      while ( my ( $k, $v ) = each %{ $self } ) {
          next unless ( $k );
          next if ( $id_field and $k eq $id_field );
-        $initial_data{ $k } = $p->{ $k } || $v;
+        $initial_data{ $k } = exists $p->{ $k } ? $p->{ $k } : $v;
      }

      return $class->new({ %initial_data, skip_default_values => 1 });


-- 
  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: [Openinteract-dev] base_user

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

On Mon, 2002-01-28 at 05:03, Ewa...@ap... wrote:
> 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 );

Thanks. I've modified this comparison to first check the group ID type
in the server configuration ('id'->'group_type'). The fix is in CVS, but
I'm not going to upload the package to Sourceforge because the base_user
package has a change that depends on the next version of SPOPS.

Chris

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