Menu
▾
▴
openinteract-dev — For OI developers, includes project coordination and technical discussion.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(19) |
Nov
(22) |
Dec
(19) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(35) |
Feb
(5) |
Mar
(13) |
Apr
(9) |
May
(3) |
Jun
(16) |
Jul
|
Aug
(6) |
Sep
(15) |
Oct
(5) |
Nov
(3) |
Dec
(7) |
| 2003 |
Jan
(16) |
Feb
(10) |
Mar
(19) |
Apr
(13) |
May
(5) |
Jun
(20) |
Jul
(33) |
Aug
(9) |
Sep
(1) |
Oct
(12) |
Nov
(17) |
Dec
(2) |
| 2004 |
Jan
(3) |
Feb
(9) |
Mar
(7) |
Apr
(16) |
May
(6) |
Jun
(6) |
Jul
(18) |
Aug
(8) |
Sep
(27) |
Oct
(8) |
Nov
(14) |
Dec
(29) |
| 2005 |
Jan
(1) |
Feb
(11) |
Mar
(33) |
Apr
(2) |
May
(4) |
Jun
(21) |
Jul
(41) |
Aug
(6) |
Sep
|
Oct
(1) |
Nov
|
Dec
(1) |
| 2006 |
Jan
(8) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Chris W. <ch...@cw...> - 2002-01-08 15:14:55
|
On Tue, 2002-01-08 at 10:02, Die...@Be... wrote:
> Hi Chris,
>
> We're editing documents like this:
> /Page/show/?location=/my/location;edit=1
> and we have the entry
> 'page' => {
> 'class' => 'OpenInteract::Handler::Page',
> 'security' => '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=/mysite list_actions says:
> (I guess something is not working ...)
>
> Running list_actions...
> =========================
>
> 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
--
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.
|
|
From: <Die...@Be...> - 2002-01-08 15:04:35
|
Hi Chris,
We're editing documents like this:
/Page/show/?location=/my/location;edit=1
and we have the entry
'page' => {
'class' => 'OpenInteract::Handler::Page',
'security' => 'yes',
} in our action.perl
so here is what oi_manage --website_dir=/mysite list_actions says:
(I guess something is not working ...)
Running list_actions...
=========================
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.
OpenInteract::Startup::require_module (346) >> --require error:
oit::Handler::SystemDoc (from system_doc): Can't locate
oit/Handler/SystemDoc.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 111) line 3.
OpenInteract::Startup::require_module (346) >> --require error:
oit::Handler::ObjectActivity (from object_activity): Can't
locate oit/Handler/ObjectActivity.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 112) line 3.
OpenInteract::Startup::require_module (346) >> --require error:
oit::Handler::Marcuspkg (from marcuspkg): Can't locate
oit/Handler/Marcuspkg.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 113) line 3.
OpenInteract::Startup::require_module (346) >> --require error:
oit::Handler::Ticket (from nats): Can't locate
oit/Handler/Ticket.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 114) line 3.
OpenInteract::Startup::require_module (346) >> --require error:
oit::Handler::Error (from base_error): Can't locate
oit/Handler/Error.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
115) line 3.
OpenInteract::Startup::require_module (346) >> --require error:
oit::Handler::Blz (from blz): Can't locate
oit/Handler/Blz.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
117) line 3.
OpenInteract::Startup::require_module (346) >> --require error:
oit::Handler::Related (from object_link): Can't locate
oit/Handler/Related.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 118) line 3.
OpenInteract::Startup::require_module (346) >> --require error:
oit::Handler::Package (from base): Can't locate
oit/Handler/Package.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 119) line 3.
OpenInteract::Startup::require_module (346) >> --require error:
oit::Handler::Theme (from base_theme): Can't locate
oit/Handler/Theme.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
120) line 3.
OpenInteract::Startup::require_module (346) >> --require error:
oit::Handler::Bank24 (from bank24): Can't locate
oit/Handler/Bank24.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
Dietmar
|
|
From: Chris W. <ch...@cw...> - 2002-01-08 14:49:38
|
On Tue, 2002-01-08 at 09:09, Die...@Be... wrote:
> Dear OI-Users,
>
> we got some troubles using the new package base_page-0.58!
> After the successful installation of this package, we tried to select
> the URL 'Create a new document' (http://mywebsite/Page/create/?) in the
> Document Info Box.
> After that, we've got the following message:
> Index not found Directory index not found for /page/create
> Editing a document is working!
When you edit a document, do you use the URL?
/Page/show/?location=/my/location;edit=1
or:
/my/location?edit=1
If you use the latter, you probably don't have an action setup in the
action table to catch the 'page' requests. Your action table for the
base_page package in:
$WEBSITE_DIR/pkg/base_page-0.58/conf/action.perl
Should have an entry like this:
'page' => {
'class' => 'OpenInteract::Handler::Page',
'security' => 'yes',
},
If you *do* have an entry like that, then please post the results of:
$ oi_manage --website_dir=$WEBSITE_DIR list_actions
to the list.
Chris
--
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.
|
|
From: <Die...@Be...> - 2002-01-08 14:11:46
|
Dear OI-Users,
we got some troubles using the new package base_page-0.58!
After the successful installation of this package, we tried to select
the URL 'Create a new document' (http://mywebsite/Page/create/?) in the
Document Info Box.
After that, we've got the following message:
Index not found Directory index not found for /page/create
Editing a document is working!
What's wrong?
Thanx al lot!
Dietmar Hanisch
Applied Software Technology GmbH
A BERTELSMANN COMPANY
E-Mail: Die...@ap...
Tel.: 04421/9789-75
Fax: 04421/9789-64
|
|
From: Chris W. <ch...@cw...> - 2002-01-08 05:28:39
|
First, there's an article on Perlmonks [1] about using SPOPS (along with other modules) to find MP3 files and insert the metadata into a DBI database. He (and others) also prompted me to create an SPOPS tutorial which I'll hopefully be able to get out relatively soon. Second, the author of that article pinged me beforehand and asked why he couldn't specify the DBI connection params in the object configuration. I didn't have a particularly good answer, so I implemented this (as a ClassFactory behavior) for both DBI and LDAP, and both are in CVS (in the 'SPOPS/eg' directory). Third, I've modified all SPOPS code to throw exceptions rather than die with an error message and set package variables. For now, there's a backward compatibility layer so you can still access the SPOPS::Error package variables, but that will be removed before we get to 1.0 (a little while yet). All this will be in 0.56, out fairly soon. After that the next release (barring bugfix releases) should have the modified object relationships as specified (more or less) by Ray Z's two excellent emails. Before 1.0, I'd also like to make a stab at centralizing the core SPOPS calls so the implementing modules have to do less. We'll see.... Chris [1] http://www.perlmonks.org/index.pl?node_id=136913 -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
|
From: Habib HAIBI<ha...@fr...> - 2002-01-05 19:12:26
|
Meilleurs Voeux pour 2002 : année de mémoire, de mobilisation, d'action, de justice et de sérénité - Appel au soutien moral et financier ======================== M. Habib HAIBI, 7, Aguesseau St. 69007 LYON - France Tél. 00 33 4 72 73 19 08 - Fax 00 33 4 78 61 39 27 Email : ha...@fr... http://haibi.free.fr Je suis qualifié pour exprimer mes voeux pour le Nouvel An à tous les survivants et les familles des victimes des attaques terroristes, au peuple américain, ses dirigeants, ses institutions, son président et tous les combattants de la liberté, loin de leurs foyers, tout autour du monde! Je suis fier de vous dire avec gratitude combien Les USA sont puissants, démocratiques et qualifiés pour défendre la liberté et la démocratie avec humanisme et sérénité. L'ennemi du progrès du genre humain peut encore frapper. La liberté et la démocratie peuvent être encore sous attaques! Personne ne s'imaginait que cela pouvait arriver et c'est arrivé en ce jour pacifique du 11 septembre 2001 Personne ne s'imaginait que cela pouvait arriver en France et c'est arrivé le 26 février 2001 quand les magistrats du parquet de Lyon, par impulsion suicidaire et préméditée, ont eu recours à l'arbitraire pour entraver l'action Publique mise en Mouvement : ils ont requis l'expertise psychiatrique de la Partie Civile par l'action avant de l'entendre dans ses accusations ! Cette dérive obscurantiste a dépassé tout entendement C'est arrivé un jour pacifique pour moi et pour les institutions de la République en France. Le réquisitoire aux fins de l'expertise psychiatrique de la partie civile par l'action, avant de l'entendre dans ses accusations, constitue une atteinte obscurantiste à l'intégrité de la personne de la partie civile et surtout un attentat aux valeurs fondamentales de la société civilisée et une infamie assénée à la République et ses Institutions: - à tous les martyrs de la liberté qui ont payé de leur vie la défense des personnes et des biens et des valeurs fondamentales et universelles de la République. - à tous ceux qui dans l'exercice de leurs fonctions, au nom du devoir de servir, exposeraient leurs vies, sans hésitation, pour la défense de ces mêmes valeurs - à tous les hommes ou femmes de bonne volonté, citoyens anonymes, élevés sur la foi en une société pacifiée par l'avènement de la République, la crainte des lois et l'indéfectibilité de l'Etat, de la Justice et des Institutions en Démocratie. J'étais, longtemps avant le WTC l'autre "point zéro" de la planète qui a subit les premières vagues d'attaque contre les institutions de la République, la liberté et les droits de l'homme en France ! Il y a eu trois autres attaques avec la même détermination, diabolique et suicidaire, de stopper l'action publique régulièrement mise en mouvement ! J'ai fait face à l'adversité en mettant en accusation 15 magistrats, saisis par la foudre de l'action publique en colère, nominativement impliqués, des deux juridictions de Lyon tout rôle et rang confondus pour abus d'autorité aggravé et trafic d'influence aggravé. Une fois que vous avez pris la mesure de l'attaque contre les valeurs universelles de la liberté et la justice en démocratie en France et assimilé la grandeur de la querelle qui m'anime Votre réaction sera vivement souhaitée et sollicitée ! Je recevrai vos contributions morales et financières comme une juste consolation pour le grand préjudice moral que je subis dans l'attente de la réparation de la faute lourde par la justice et l'Etat. Souvenez-vous que la paix civile fut conquise au prix de feu, de sang et de sacrifices avec pour objectif le règne absolu et égalitaire de la loi. Imaginez les victimes du 11 septembre 2001 dans un monde sans liberté, sans justice et sans démocratie Imaginez tous les sacrifices de tous les combattants de la liberté, depuis deux siècles et plus, laissés pour compte et discrédités en une seule journée d'attaques perpétrées par les forces diaboliques de l'arbitraire et de l'obscurantisme dans le pays qui a donné naissance au reigne de la loi, l'avènement de la République et les droits de l'homme. Une nouvelle ère a commencé où le grand pays que sont les Etats Unis vont guider et pour longtemps l'impulsion de l'alerte et de la réaction pour perpétuer la liberté et la justice en démocraties. C'est aussi votre combat et le combat de tous les hommes libres. Merci au président des Etats Unis pour son leadership, l'immense puissance de son pays et sa sérénité. Merci à tous d'avoir lu et compris ce message. Merci pour vos réactions et vos contributions. ========================== Ces contributions sont souhaitées à la hauteur de 500 $ ou euros et plus pour tous les représentants élus des peuples, sénateurs et députés, quelque soit leur pays et quelque soit le moyen utilisé pour les alerter des attaques contre la démocratie et de la colère de l'action Publique en mouvement : "ma tristesse s'est muée en colère et la colère en résolution "! (ma conviction est que si de tels actes ont pu se produire c'est à cause d'un climat de permissivité qui a pu s'installer par l'absence du contrôle de l'exécutif par le pouvoir législatif ). ======= vous pouvez verser directement vos contributions financières sur le compte : RIP RELEVE D'IDENTITE BANCAIRE 20041 01007 1112632 F038 69 IBAN IDENTIFIANT INTERNATIONAL FR 53 20041 01007 1112632 F 038 69 Ou envoyer un mandat cash à mon nom et à mon adresse. ================================ Les contributions seront libres et bienvenues de la part de tout autre citoyen sensible à l'idée de vivre dans une société pacifiée par la crainte des lois et la crédibilité des institutions démocratiques. ============ Mon objectif est de réunir 10 000 réactions à 100 $ ou euros chacune : vous pouvez m'aider à atteindre ce but. Je serai, à coup sûr, un homme riche! Mais je ne recouvrerai la paix intérieure avant que justice soit faite! 'J'ai un rêve"! La justice sera faite ! ============ Le site où est publié l'ensemble du dossier est en français, vous pouvez vous aider pour la traduction par un moteur de traduction sur internet. http://haibi.free.fr ============ Cette mailing liste, non exhaustive, est composée de 30 000 emails : des représentants élus, les représentants de l'Etat, hauts fonctionnaires, magistrats, avocats, journalistes, chefs d'entreprise, président ou membre d'association, profession libérale ou tout autre simple citoyen intéressé par la vie sociale, administrative et judiciaire. ======================= Vous pourrez discuter en circuit interne non publié sur le net en vous abonnant au groupe créé pour cet objet "Il n'y a pas d'alternative à la justice en république en france" Coordonnées du groupe : Email du groupe : lec...@sm... Email du gestionnaire : lec...@sm... Pour devenir membre : lec...@sm... Pour ne plus être membre : lec...@sm... Accueil du groupe : http://smartgroups.wanadoo.fr/groups/lecitoyen.laloi.larepubliqu e ====================== Si vous ne vous sentez pas concerné, vous pouvez demander à ce que votre email soit effacer en exprimant votre volonté à l'adresse email : ha...@fr... Merci encore de participer à l'alerte et au suivi de l'action publique en mouvement, et au soutien moral et financier de la partie civile par l'action. ================================ =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =============================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== =================================================== ================================================== Vous pourrez recevoir une autre version en anglais. Ceci n'est pas un spam Merci! NEVER SEND SPAM. IT IS BAD. |
|
From: Ray Z. <rz...@co...> - 2002-01-04 21:59:52
|
Chris,
I realized the other day that the enhanced has-a semantics I proposed
in an e-mail to the list back on 7/3/01 is not quite general enough
for all of our needs. (I've included the entire original proposal at
the end of this e-mail for reference).
The issue is that I assumed that any secondary objects auto-fetched
(or lazy-fetched) with the primary object should always be auto-saved
with that object as well. Based on this assumption, I did not include
any explicit 'save' configuration in the new has-a syntax. The 3
rules for saving were ...
----------
(I'm pulling this text directly out of the original write-up, where
$x belongs to class X which has-a field named 'myA' which is an
object of type A, and a field named 'myB' which is an object of type
B) ...
1. In all forward direction fetch configurations (manual, auto and
lazy), if $x->{myA} contains a reference to an A object when $x is
saved, it will save the A object during the pre_save stage before
saving $x with the updated id of the A object. If $x->{myA} contains
an id only, nothing special is done when $x is saved.
2. In all reverse direction fetch configurations (manual_by, auto_by
and lazy_by), if $a->{'list_of_Xs'} contains an arrayref of X objects
when $a is saved, it will save each X during the post_save stage
after updating the myA field in each X with the new id of $a.
3. For all links (manual, auto and lazy), whether or not
$a->{'linked_Bs'} contains anything when $a is saved, it will NOT
automatically save any X's or B's.
----------
I've run across some cases where that isn't the desired behavior. In
particular, sometimes one may not want to auto-save the secondary
objects even though they are being auto/lazy-fetched. This could be
the case for either forward or backward direction fetch
configurations. On the other hand, one may want to allow auto-saving
of linked secondary objects (not allowed by 3 above).
My new proposal is to let the old proposal define the default
behavior, but add an optional parameter to the 'fetch' and 'link'
parts of the configuration. In the 'fetch' configuration allow an
optional 'no_save' parameter with values 0 or 1, where 0 corresponds
to the default behavior (saving all secondary objects) and 1
specifies that it should not do any saving of secondary objects.
In the 'link' configuration, allow an optional 'save' parameter with
values 0 or 1, where 0 specifies the default (don't auto-save
anything) and 1 means to save any linked objects, if necessary
creating the corresponding linking objects.
There are more details to be worked out with this, but I thought I'd
better send you what I have at the moment, before I get pulled off to
other things.
Ray
[ Original proposal from 7/3/01 (LONG) ]
------------------------------------------------------------------------
=================================
=== New Has-A Semantics ===
=================================
Assuming ...
X has-a A, and
X has-a B (that is, X links A to B)
We want to allow the 'has_a' configuration for 'X has-a A' to define
the following options for ...
... fetch behavior:
(1) all manual fetches & saves (default)
(2) fetch X auto-fetches A & save X auto-saves A
(3) fetch X lazy-fetches A & save X auto-saves A
(4) fetch A auto-fetches X's into $a->{'list_of_Xs'} & save A
auto-saves X's
(5) fetch A lazy-fetches X's into $a->{'list_of_Xs'} & save A
auto-saves X's
(6) fetch A auto-fetches B's into $a->{'linked_Bs'} (no auto-saving)
(7) fetch A lazy-fetches B's into $a->{'linked_Bs'} (no auto-saving)
... remove behavior:
(1) all manual removes (default)
(2) remove X auto-removes A
(3) remove A auto-sets to NULL has_a field in X's
(4) remove A auto-removes X's
(if 'X has_a B' is configured to auto-remove B, then
removing A will auto-remove corresponding X's and B's)
======================
Configuration Syntax
======================
$CONF = {
X_alias => {
class => 'X',
field => [ qw/ x_id x_data myA myB / ],
has_a => {
myA => {
class => 'A',
fetch => {
type => 'manual|auto|lazy|manual_by|auto_by|lazy_by',
name => 'someA',
list_field => 'list_of_Xs',
},
link => {
type => 'manual|auto|lazy',
field => 'myB'
name => 'someB',
list_field => 'linked_Bs',
},
remove => {
type =>
'manual|auto|manual_by|auto_by|manual_null|auto_null'
name => 'removeSomeA',
list_field => 'list_of_Xs',
}
},
myB => {
class => 'B',
fetch => {
type => 'manual|auto|lazy|auto_by|lazy_by',
name => 'someB',
list_field => 'linked_Bs',
},
link => {
type => 'manual|auto|lazy',
field => 'myA'
name => 'someA',
list_field => 'list_of_As',
},
remove => {
type =>
'manual|auto|manual_by|auto_by|manual_null|auto_null'
name => 'removeSomeB',
list_field => 'list_of_Xs',
}
},
}
},
A_alias => {
class => 'A',
field => [ qw/ a_id a_data / ],
list_field => { X => ['list_of_Xs'],
B => ['linked_Bs'] }
},
B_alias => {
class => 'B',
field => [ qw/ b_id b_data / ],
},
}
==========
Overview
==========
For the sake of clarity in the discussion, assume that X has-a A and
X has-a B, namely fields myA and myB, respectively, and we're
examining the meaning of the has_a data corresponding to the myA
field.
The new 'has_a' config data is a hashref where the keys are the names
of fields in the table containing IDs of other objects (foreign
keys). These can be names of fields in inherited classes with certain
restrictions. Each value in the hash is another hashref with the
following possible keys ...
class
fetch
link
remove
The value for 'class' is the name of the class of objects being
linked by this field. If this field is defined in a parent class (as
opposed to the current class) then the class specified here must be a
sub-class of the one specified in the has_a config of the parent
class. (E.g. if a Team has-a Coach, it's fine to override the has_a
specification for the coach field in Team to say that SoccerTeam
has-a SoccerCoach, but not that SoccerTeam has-a TeamCaptain.)
The values for 'fetch', 'remove' and 'link' are each hashrefs, with
possible keys as follows:
fetch remove link
----- ------ ----
name name name
type type type
list_field list_field list_field
field
The 'fetch' parameters specify what methods will be automatically
created for fetching one object from the other (methods in X to fetch
the A or in A to fetch the X's) and when they are called.
The 'remove' parameters specify what methods will be automatically
created for removing one object from the other (methods in X to
remove the A or in A to remove the X's) and when they are called.
If the 'link' key is present it means that this class (X) serves to
link two other objects together via this field (myA) and another
has-a field (myB). The 'link' parameters specify what methods will be
automatically created in the foreign object (A) for adding and
removing links (instances of X) to the other object (B) and for
accessing the linked objects, and when these methods are called.
=======
Fetch
=======
The fetch specification allows for 3 types of fetch operations for
the has-a relationship in question, manual, automatic and lazy,
either in the forward direction (given an X, fetch its A) or in the
reverse direction (given an A, fetch its list of X's). The types
'manual', 'auto' and 'lazy' indicate a forward direction and
'manual_by', 'auto_by' and 'lazy_by' indicate a reverse direction
(that the corresponding X's will be fetched BY an A). In the case of
the forward direction, we'll call X the primary object and A the
secondary object. For the reverse direction, A will be primary and X
secondary. Using that terminology, manual means that secondary object
are only fetched in response to an explicit request to fetch them.
Auto means they are fetched automatically when the primary object is
fetched (and they are stashed in the primary object), and lazy means
they are fetched (and stashed) by the primary object only at the
moment an access to the secondary object is attempted.
The methods that are created are always created in the primary object
for fetching the secondary object(s).
The forward direction specifies that a method be created in X for
fetching the corresponding A. If the 'name' parameter is present, it
gives the name of the method to create. If it is not present, it will
use the default name 'fetch_<field_name>' (in this example
'fetch_myA'). This method accepts only a hashref of parameters (db
handle, etc) as input args and returns the secondary object.
The reverse direction specifies that a method be created in A for
fetching the list of corresponding X's. If the 'name' parameter is
present, it gives the name of the method to create, otherwise it will
use the default name 'fetch_<list_field>' (in this example
'fetch_list_of_Xs'). This method accepts only a hashref of parameters
(db handle, etc) as input args and returns an arrayref of the
secondary objects.
The 'list_field' parameter, which is mandatory for reverse direction,
must match a list_field defined for this class in the primary
object's configuration (i.e. the list_field specification in class
A's config).
If the fetch type is set to 'auto', assuming default naming of
methods, then doing ...
$x = X->fetch($x_id);
... automatically does ...
$x->{myA} = $x->fetch_myA;
... during the post_fetch stage. If the fetch type is set to 'lazy',
the second operation happens whenever $x->{myA} is accessed the first
time. In all forward direction fetch configurations (manual, auto and
lazy), if $x->{myA} contains a reference to an A object when $x is
saved, it will save the A object during the pre_save stage before
saving $x with the updated id of the A object. If $x->{myA} contains
an id only, nothing special is done when $x is saved.
If the fetch type is set to 'auto_by', assuming default method
naming, then doing ...
$a = A->fetch($a_id);
... automatically does ...
$a->{'list_of_Xs'} = $a->fetch_list_of_Xs;
... during the post_fetch stage. If the fetch type is set to
'lazy_by', the second operation happens whenever $a->{'list_of_Xs'}
is accessed the first time. In all reverse direction fetch
configurations (manual_by, auto_by and lazy_by), if
$a->{'list_of_Xs'} contains an arrayref of X objects when $a is
saved, it will save each X during the post_save stage after updating
the myA field in each X with the new id of $a.
For auto_by and lazy_by, two additional methods are created in A, one
for adding objects to its list of X's and one for removing objects
from it. These can only be used after the A object has been saved.
Their primary purpose is to keep the list in memory in sync with
what's in the database, so when using auto_by or lazy_by it's a good
idea to use only these methods to add or remove corresponding X's. If
the 'name' parameter is present, the methods are named add_<name> and
remove_<name>. If the 'name' parameter is not present they are named
add_to_<list_field> and remove_from_<list_field>. The method to add
X's takes an X object or an arrayref of X objects as inputs and
returns the same object or arrayref to the objects after saving them.
The method to remove X's takes an id or arrayref of ids and returns
the number of X's successfuly removed.
========
Remove
========
The remove specification allows for 6 types of remove operations for
the has-a relationship in question, 'manual', 'auto', 'manual_by',
'auto_by', 'manual_null' and 'auto_null'. The types 'manual' and
'auto' specify a forward direction (given an X, remove its A) and
'manual_by' and 'auto_by' specify a reverse direction (given an A,
remove it's list of X's). The types 'manual_null' and 'auto_null'
also specify a reverse direction, but instead of removing the list of
X's corresponding to a given A, they set the linking field (myA, in
the example) to NULL in each of the X's.
For the forward direction ('manual' and 'auto'), a method is created
in X to remove the corresponding A. If the 'name' parameter is
present, it gives the name of the method to create. If it is not
present, it will use the default name remove_<field_name> (in this
example 'remove_myA'). This method accepts only a hashref of
parameters (db handle, etc) as input args and returns a true value if
the remove was successful. If the type is 'auto', this method will be
called automatically in the pre-remove phase whenever X is removed.
That is ...
$x->remove;
... automatically does ...
$x->remove_myA;
... during the pre_remove stage.
The reverse direction ('manual_by' and 'auto_by') specifies that a
method be created in A for removing the corresponding X's. If the
'name' parameter is present, it gives the name of the method to
create, otherwise it will use the default name 'remove_<list_field>'
(in this example 'remove_list_of_Xs'). This method accepts only a
hashref of parameters (db handle, etc) as input args and returns the
number of objects removed.
The 'list_field' parameter, which is mandatory for reverse direction,
must match a list_field defined for this class in the primary
object's configuration (i.e. the list_field specification in class
A's config).
If the remove type is set to 'auto_by', assuming default method
naming, then doing ...
$a->remove;
... automatically does ...
$a->remove_list_of_Xs;
... during the pre_remove stage.
If the remove type is set to 'manual_null' or 'auto_null' a method is
created in A for setting the field in each of the X's corresponding
to that A to NULL. If the 'name' parameter is present, it gives the
name of the method to create, otherwise it will use the default name
'null_<list_field>' (in this example 'null_list_of_Xs').
If the remove type is 'auto_null', assuming default method naming,
then doing ...
$a->remove;
... automatically does ...
$a->null_list_of_Xs;
... during the pre_remove stage.
======
Link
======
The link specification, is used to indicate that the class (X) is
used to link two objects together via this field (myA) and another
has-a field. The 'field' parameter specifies the name of the other
has-a field (myB in this example). A method will be created in A to
allow an object of type A to fetch all of the objects of type B which
are linked to that A via the corresponding X's. If the 'name'
parameter is present, it gives the name of the method to create,
otherwise it will use the default name 'fetch_<list_field>' (in this
example 'fetch_linked_Bs'). This method accepts only a hashref of
parameters (db handle, etc) as input args and returns an arrayref of
the linked objects.
There are two other methods which are defined which allow an A to
easily create and remove links (objects of class X) to B's. If the
'name' parameter is present, they will be called 'add_link_<name>'
and 'remove_link_<name>', otherwise the default names,
'add_link_<list_field>' and 'remove_link_<list_field>', are used.
Both methods take an id or an arrayref of ids of B objects as inputs
and return the number of links added or removed respectively.
If the link type is set to 'auto', assuming default method naming,
then doing ...
$a = A->fetch($a_id);
... automatically does ...
$a->{'linked_Bs'} = $a->fetch_linked_Bs;
... during the post_fetch stage. If the link type is set to 'lazy',
the second operation happens whenever $a->{'linked_Bs'} is accessed
the first time.
For all links (manual, auto and lazy), whether or not
$a->{'linked_Bs'} contains anything when $a is saved, it will NOT
automatically save any X's or B's.
============
Misc Notes
============
- If X links A and B, then when adding a link via
$a->add_link_linked_Bs(), how would other fields in X (besides myA
and myB) be specified?
- Maybe the add_link_<link_field> and remove_link_<link_field>
methods are unecessarily asking for trouble and we should only allow
links (X objects) to be created and removed directly via methods in X
(not via A). These methods were an attempt to duplicate the current
SPOPS links_to functionality by making the linking table correspond
to just another SPOPS object. This also allows for a bit more
generality in that the linking table can also add other attributes to
the linking table (e.g. an effective date on a club membership).
- We must avoid has_a cycles (e.g. Boat has_a anchor and Anchor has_a
Boat, both set up to auto-remove/fetch the other).
==========
Examples
==========
All Manual
----------
$CONF = {
X_alias => {
class => 'X',
field => [ qw/ x_id myA / ],
has_a => {
myA => {
class => 'A',
fetch => { type => 'manual' },
remove => { type => 'manual' }
}
}
},
A_alias => {
class => 'A',
field => [ qw/ a_id a_data / ]
},
};
$x = X->new # create a new X
$a = A->new # create its A
$a_id = $a->save; # save the A
$x->{myA} = $a_id; # put the A's id in the X
$x_id = $x->save; # save the X
$x = X->fetch($x_id); # fetch an X
$a_id = $x->myA; # get the id of its A
$a = $x->fetch_myA; # fetch the A object
$a->remove; # remove the A
$x->remove; # remove the X
Auto | Lazy (think X=Boat has-a A=Anchor)
-----------
$CONF = {
X_alias => {
class => 'X',
field => [ qw/ x_id myA / ],
has_a => {
myA => {
class => 'A',
fetch => { type => 'auto' }, # or 'lazy'
remove => { type => 'auto' }
}
}
},
A_alias => {
class => 'A',
field => [ qw/ a_id a_data / ]
},
};
$x = X->new({myA => A->new}); # create a new X and its new A
$x_id = $x->save; # save the X and its A
$x = X->fetch($x_id); # fetch an X and its A
$a = $x->myA; # get the A out of the X
$x->remove; # remove the X and its A
Auto | Lazy By (think X=Slip has-a A=Boatyard)
--------------
$CONF = {
X_alias => {
class => 'X',
field => [ qw/ x_id myA / ],
has_a => {
myA => {
class => 'A',
fetch => { type => 'auto_by', # or 'lazy_by'
list_field => 'list_of_Xs'
},
remove => { type => 'auto_by' }
}
}
},
A_alias => {
class => 'A',
field => [ qw/ a_id a_data / ]
list_field => { X => ['list_of_Xs'] }
},
};
$a = A->new; # create new A
$a->add_to_list_of_Xs( [X->new, X->new] ); # add some new X's
$a_id = $a->save; # save the A and all of its X's
$a = A->fetch($a_id); # fetch the A and all of its X's
$x1 = $a->{list_of_Xs}->[1];# access a particular X
$a->remove; # remove the A and all of its X's
Auto | Lazy Link (think X=BoatyardSlipLink has-a A=Boatyard, B=Slip)
----------------
$CONF = {
X_alias => {
class => 'X',
field => [ qw/ x_id myA myB / ],
has_a => {
myA => {
class => 'A',
link => { type => 'auto',
field => 'myB',
list_field => 'linked_Bs',
},
remove => { type => 'auto_by' }
},
myB => {
class => 'B',
fetch => { type => 'lazy' },
remove => { type => 'auto' }
}
}
},
A_alias => {
class => 'A',
field => [ qw/ a_id a_data / ]
list_field => { X => ['linked_Bs'] }
},
B_alias => {
class => 'B',
field => [ qw/ b_id b_data / ]
},
};
$a = A->new; # create new A
$a_id = $a->save # save the A
$b1_id = B->new->save; # create and save some B's
$b2_id = B->new->save;
$b3_id = B->new->save;
$a->add_link_linked_Bs($b1_id); # create & save X which links $a to $b1
$a->add_link_linked_Bs([$b2_id,$b3_id]); # and $b2 and $b3
$a->remove_link_linked_Bs($b2_id); # remove X which links $a to $b2
# (the X also auto-removes $b2)
$a = A->fetch($a_id); # fetch the A and all of its linked B's
$a->remove; # remove the A and all of its X's (&
linked B's)
Manual Link (think X=ClubMembership has-a A=Club, B=Person)
-----------
$CONF = {
X_alias => {
class => 'X',
field => [ qw/ x_id myA myB / ],
fetch_by=> [ qw/ myA myB /]
has_a => {
myA => {
class => 'A',
link => { type => 'manual',
field => 'myB',
list_field => 'linked_Bs',
},
remove => { type => 'auto_by' }
},
myB => {
class => 'B',
link => { type => 'manual',
field => 'myA',
list_field => 'linked_As',
},
remove => { type => 'auto_null' }
}
}
},
A_alias => {
class => 'A',
field => [ qw/ a_id a_data / ]
list_field => 'linked_Bs',
},
B_alias => {
class => 'B',
field => [ qw/ b_id b_data / ]
list_field => 'linked_As',
},
};
$a1 = A->new; # create some new A's ...
$a2 = A->new;
$b1 = B->new; # ... and some new B's ...
$b2 = B->new;
$b3 = B->new;
$a1_id = $a1->save; # ... and save them
$a2_id = $a2->save;
$b1_id = $b1->save;
$b2_id = $b2->save;
$b3_id = $b3->save;
$a1->add_link_linked_Bs([$b1_id, $b2_id]); # create some linking X's via A
$b3->add_link_linked_As([$a1_id, $a2_id]); # create some linking X's via B
$x4 = X->new({myA=>$a2_id,myB=>$b1_id})->save; # create linking X directly
[$b1, $b2, $b3] = $a1->fetch_linked_Bs; # fetch B's linked to a given A
[$x1, $x2, $x3] = X->fetch_by_myA($a1_id); # fetch X's for a given A
$a2->remove; # remove an A and it's corresponding X's (but not the B's)
$a1->remove_link_linked_Bs([$b1_id]); # remove linking X
$b2->remove; # remove a B and set field in linking X's to NULL
--
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
|
|
From: Chris W. <ch...@cw...> - 2001-12-29 22:18:26
|
On Fri, 2001-12-28 at 17:10, And...@Be... wrote: > - Devel::DProf works OK with OI in "script mode". Just use it like the docs > say: perl -dDProf thescript.pl and then: dprofpp I used this with some > userlisting scripts etc. Cool -- I'll have to play around with this in the next n months, when I get some free time :-) > - actions and base_page: > If you abstract this, then all we to is map some partial url to some code. > The action table does this directly by mapping say /news to > mysite::Handler::News. base_page does little different things now, map e.g. > /stats/mistot.xls to a db query ( storage type database ) or /index.html to > a file handler (storage filesystem ) and since the last version > /family_pics/ to again code to display a directory. Why not have /news be a > base_page with type handler and point to the right code? How could this be > done? Maybe oi_manage could create the necessary base_page objects. If we > had this, the conductor only needed to look at one place to find the handler > to call. I am definetly not sure, if this is a good idea - just thinking > loud. This is something to think about. But the main difference I see is that a normal action (e.g., '/news') says to OpenInteract that it defines tasks within that entire URL-space -- every URL beginning with '/news' should just be passed to that handler which will deal with generating the content. Directory handlers instead only hook into a single URL rather than entire URL-space, and they can be inherited and used across other URLs as well. So '/mynews/' might be handled by a directory handler but '/mynews/latest.html' is a normal page which the directory handler never has to deal with. As my wife is fond of saying, this may be a distinction without a difference. And I may be too close to tell right now -- we might need to let this ferment a little to see what it smells like :-) Later, Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
|
From: Chris W. <ch...@cw...> - 2001-12-29 22:13:18
|
On Fri, 2001-12-28 at 15:47, And...@Be... wrote: > Also I think, the generation of templib should be done here. Just a follow-up: I didn't see anything about the templib generation in your separate email. I'm curious as to what you found about this. Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
|
From: <And...@Be...> - 2001-12-28 22:21:33
|
- Devel::DProf works OK with OI in "script mode". Just use it like the = docs say: perl -dDProf thescript.pl and then: dprofpp I used this with some userlisting scripts etc. - actions and base_page: If you abstract this, then all we to is map some partial url to some = code. The action table does this directly by mapping say /news to mysite::Handler::News. base_page does little different things now, map = e.g. /stats/mistot.xls to a db query ( storage type database ) or = /index.html to a file handler (storage filesystem ) and since the last version /family_pics/ to again code to display a directory. Why not have /news = be a base_page with type handler and point to the right code? How could this = be done? Maybe oi_manage could create the necessary base_page objects. If = we had this, the conductor only needed to look at one place to find the = handler to call. I am definetly not sure, if this is a good idea - just = thinking loud. later, Andreas -----Urspr=FCngliche Nachricht----- Von: Chris Winters [mailto:ch...@cw...] Gesendet am: Freitag, 28. Dezember 2001 22:55 An: And...@Be... Cc: ope...@li... Betreff: Re: Random thoughts or: my time with Time::HiRes On Fri, 2001-12-28 at 16:09, And...@Be... wrote: > Hi Chris, >=20 > still one of my favorite tasks with OI is finding out, how to tune = it. Since > I had no luck with Devel::DProf, I used Time::HiRes now and dug down = into > the code. Here some observations: I'm curious -- can you run Devel::DProf if you start up the OI environment outside of Apache? (LMK if you need an example of this.) = I'm more curious about performance aspects of SPOPS (tied hashes and all) than about some other things.=20 =20 > - OpenInteract::Request::lookup_action gets called twice: once in > OpenInteract::find_action_handler and once from > OpenInteract::run_content_handler - how about caching this in $R ? Good idea. > - how about caching the results of lookup_action ? Do you mean keep a table of URL -> action results? I don't think this = is necessary - lookup_action should be a fairly minor task since it's just consulting an in-memory hash. And I'm planning to rewrite this action dispatch stuff anyway. > - when a user comes in with an existing session, I found, that all = calls are > done like when he first comes in. Why not cache things like groups, = theme, > etc inside the session ? This isn't a bad idea at all. I'm a little concerned about stale = session info -- an administrator assigns a user to a group but the user doesn't see the change take effect until a logout/login or a session refresh. But we can deal with that. > - I question the file based template caching stuff: I tried a simple process > global hash based lookup inside = OpenInteract::Template::Provider::fetch and > it speeded this part up about factor 100 !=20 There are actually two pieces to template caching. First is the file-based, which is really only good for persisting the templates across server restarts. I wouldn't have done this if it took any = effort, but we get it for free with TT so why not. TT should also be doing in-process template caching unless something is fubared. So I'm curious why you got such a speedup... Can you send me (offlist) your copy of OI::Template::Provider so I can compare? > - if I got the startup code right, at least > OpenInteract::Startup->read_base_config is called twice: once at = server > startup, once at child init. This has nothing process specific in it, right? Right. This is also a fairly minor task but we should get rid of the duplication anyway. > I think the static/global and dynamic/process parts need to be = separated > more obvious. The latest with apache 2.0 we will have threads to deal = with > in adition.. For now, the more work can be done at server startup, = the > better, I think, since this will just be copied over on fork(). This = also > holds for modules. Why don`t we pull in many more modules here? First of all, you're right that the server/childinit stuff needs to be separated better. Also, it would definitely be a good idea to pull in more modules at server startup -- we actually used to do this a version or two back.=20 However, since I introduced SPOPS initialization code that uses datasource handles (the 'field_discover' stuff, among other things) the issue gets fairly complicated. I ran into a number of problems using these features so I moved all the initialization to a child init handler. I think I can fix it if I modify how database handles are opened up and stored, but I'm going to put that off for a bit. > - totally different topic maybe: looking at the new base_page stuff - = why > not make actions just entries here? Wouldn`t it be nice to have this = in one > place? As I told you earlier, we think about tweaking some sort of = dynamic > handler into this already, but: actually I think this is totally unnecessary Not sure I understand what you mean. A directory handler is just = another action that is aware it's a directory handler. That said, this feature is very new so please continue playing :-) > so far so good for now - hope this makes any sense ;-) Lots -- thanks for the work! C --=20 Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
|
From: Chris W. <ch...@cw...> - 2001-12-28 21:55:00
|
On Fri, 2001-12-28 at 16:09, And...@Be... wrote: > Hi Chris, > > still one of my favorite tasks with OI is finding out, how to tune it. Since > I had no luck with Devel::DProf, I used Time::HiRes now and dug down into > the code. Here some observations: I'm curious -- can you run Devel::DProf if you start up the OI environment outside of Apache? (LMK if you need an example of this.) I'm more curious about performance aspects of SPOPS (tied hashes and all) than about some other things. > - OpenInteract::Request::lookup_action gets called twice: once in > OpenInteract::find_action_handler and once from > OpenInteract::run_content_handler - how about caching this in $R ? Good idea. > - how about caching the results of lookup_action ? Do you mean keep a table of URL -> action results? I don't think this is necessary - lookup_action should be a fairly minor task since it's just consulting an in-memory hash. And I'm planning to rewrite this action dispatch stuff anyway. > - when a user comes in with an existing session, I found, that all calls are > done like when he first comes in. Why not cache things like groups, theme, > etc inside the session ? This isn't a bad idea at all. I'm a little concerned about stale session info -- an administrator assigns a user to a group but the user doesn't see the change take effect until a logout/login or a session refresh. But we can deal with that. > - I question the file based template caching stuff: I tried a simple process > global hash based lookup inside OpenInteract::Template::Provider::fetch and > it speeded this part up about factor 100 ! There are actually two pieces to template caching. First is the file-based, which is really only good for persisting the templates across server restarts. I wouldn't have done this if it took any effort, but we get it for free with TT so why not. TT should also be doing in-process template caching unless something is fubared. So I'm curious why you got such a speedup... Can you send me (offlist) your copy of OI::Template::Provider so I can compare? > - if I got the startup code right, at least > OpenInteract::Startup->read_base_config is called twice: once at server > startup, once at child init. This has nothing process specific in it, right? Right. This is also a fairly minor task but we should get rid of the duplication anyway. > I think the static/global and dynamic/process parts need to be separated > more obvious. The latest with apache 2.0 we will have threads to deal with > in adition.. For now, the more work can be done at server startup, the > better, I think, since this will just be copied over on fork(). This also > holds for modules. Why don`t we pull in many more modules here? First of all, you're right that the server/childinit stuff needs to be separated better. Also, it would definitely be a good idea to pull in more modules at server startup -- we actually used to do this a version or two back. However, since I introduced SPOPS initialization code that uses datasource handles (the 'field_discover' stuff, among other things) the issue gets fairly complicated. I ran into a number of problems using these features so I moved all the initialization to a child init handler. I think I can fix it if I modify how database handles are opened up and stored, but I'm going to put that off for a bit. > - totally different topic maybe: looking at the new base_page stuff - why > not make actions just entries here? Wouldn`t it be nice to have this in one > place? As I told you earlier, we think about tweaking some sort of dynamic > handler into this already, but: actually I think this is totally unnecessary Not sure I understand what you mean. A directory handler is just another action that is aware it's a directory handler. That said, this feature is very new so please continue playing :-) > so far so good for now - hope this makes any sense ;-) Lots -- thanks for the work! C -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
|
From: Chris W. <ch...@cw...> - 2001-12-28 21:37:04
|
On Fri, 2001-12-28 at 15:47, And...@Be... wrote: > first I`d like to support your views. A second thought on this: you could > still sort of support many virtual hosts on one box by sharing the frontend > / static httpd and just have backend daemons for each site. Very true, and a point worth highlighting. > Also I think, the generation of templib should be done here. When wading > through the code with Time::HiRes ( see post that follows ) I also > questioned, if other parts of the config process might be changed... Ah, this should be interesting. I can tell things are maturing if we're dealing with performance :-) C -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
|
From: <And...@Be...> - 2001-12-28 21:20:31
|
Hi Chris, still one of my favorite tasks with OI is finding out, how to tune it. Since I had no luck with Devel::DProf, I used Time::HiRes now and dug down into the code. Here some observations: - OpenInteract::Request::lookup_action gets called twice: once in OpenInteract::find_action_handler and once from OpenInteract::run_content_handler - how about caching this in $R ? - how about caching the results of lookup_action ? - when a user comes in with an existing session, I found, that all calls are done like when he first comes in. Why not cache things like groups, theme, etc inside the session ? - I question the file based template caching stuff: I tried a simple process global hash based lookup inside OpenInteract::Template::Provider::fetch and it speeded this part up about factor 100 ! - if I got the startup code right, at least OpenInteract::Startup->read_base_config is called twice: once at server startup, once at child init. This has nothing process specific in it, right? I think the static/global and dynamic/process parts need to be separated more obvious. The latest with apache 2.0 we will have threads to deal with in adition.. For now, the more work can be done at server startup, the better, I think, since this will just be copied over on fork(). This also holds for modules. Why don`t we pull in many more modules here? - totally different topic maybe: looking at the new base_page stuff - why not make actions just entries here? Wouldn`t it be nice to have this in one place? As I told you earlier, we think about tweaking some sort of dynamic handler into this already, but: actually I think this is totally unnecessary so far so good for now - hope this makes any sense ;-) later, Andreas |
|
From: <And...@Be...> - 2001-12-28 20:58:29
|
Hi Chris, first I`d like to support your views. A second thought on this: you = could still sort of support many virtual hosts on one box by sharing the = frontend / static httpd and just have backend daemons for each site. Also I think, the generation of templib should be done here. When = wading through the code with Time::HiRes ( see post that follows ) I also questioned, if other parts of the config process might be changed... later, Andreas -----Urspr=FCngliche Nachricht----- Von: Chris Winters [mailto:ch...@cw...] Gesendet am: Freitag, 28. Dezember 2001 07:25 An: ope...@li... Betreff: [Openinteract-dev] an OpenInteract direction: management interface and single website I've been working lately on importing/exporting data using SPOPS (out soon) and wanted to replace OpenInteract::SQLInstall with the results, making it just a wrapper around the necessary SPOPS::Import classes. Unfortunately, this got me thinking about oi_manage. I try not to think about it too much because I have this irrational (?) need to clean it up, factor things out, etc. But it basically works now so I'm loathe to mess with it. But then I thought about it a little too much, and had some initial ideas about how to rewrite it. This is a good thing. Unfortunately, this got me thinking about the issue we touched on briefly a couple weeks ago [1] about the base installation directory. The original point of the thing was so that multiple websites could run in a single mod_perl process and share code. But that's a questionable point as I'm strongly leaning toward a one-website/one-process model for a number of reasons. First, it will simplify a number of issues -- off the top of my head: deployment, site management, conceptualization, packaging, configuration and resource management. Second, it will make the task of running OpenInteract as a standalone process much easier. (Getting it running standalone will be one of my New Year's resolutions, BTW :-) So instead of doing the OI install and then applying/upgrading packages from there, you'd just create a new website and upgrade those packages directly, eliminating the middle step entirely. The only version of the packages that the website knows about would be in the website itself. (Unsure about whether a website should still be a namespace, but that's minor.) I floated this idea back in July [2] and the response was minimal, so I'm inclined to just go ahead and plow forward. But this is a 'speak = now or forever hold your peace' sort of thing... Thanks, Chris [1] http://www.geocrawler.com/lists/3/SourceForge/8429/0/7359734/ [2] http://www.geocrawler.com/archives/3/8393/2001/7/0/ --=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 |
|
From: Chris W. <ch...@cw...> - 2001-12-28 06:02:06
|
I've been working lately on importing/exporting data using SPOPS (out soon) and wanted to replace OpenInteract::SQLInstall with the results, making it just a wrapper around the necessary SPOPS::Import classes. Unfortunately, this got me thinking about oi_manage. I try not to think about it too much because I have this irrational (?) need to clean it up, factor things out, etc. But it basically works now so I'm loathe to mess with it. But then I thought about it a little too much, and had some initial ideas about how to rewrite it. This is a good thing. Unfortunately, this got me thinking about the issue we touched on briefly a couple weeks ago [1] about the base installation directory. The original point of the thing was so that multiple websites could run in a single mod_perl process and share code. But that's a questionable point as I'm strongly leaning toward a one-website/one-process model for a number of reasons. First, it will simplify a number of issues -- off the top of my head: deployment, site management, conceptualization, packaging, configuration and resource management. Second, it will make the task of running OpenInteract as a standalone process much easier. (Getting it running standalone will be one of my New Year's resolutions, BTW :-) So instead of doing the OI install and then applying/upgrading packages from there, you'd just create a new website and upgrade those packages directly, eliminating the middle step entirely. The only version of the packages that the website knows about would be in the website itself. (Unsure about whether a website should still be a namespace, but that's minor.) I floated this idea back in July [2] and the response was minimal, so I'm inclined to just go ahead and plow forward. But this is a 'speak now or forever hold your peace' sort of thing... Thanks, Chris [1] http://www.geocrawler.com/lists/3/SourceForge/8429/0/7359734/ [2] http://www.geocrawler.com/archives/3/8393/2001/7/0/ -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
|
From: Chris W. <ch...@cw...> - 2001-12-28 04:33:53
|
Earlier today I uploaded to sourceforge a new version of the base_page
package. This version includes directory handlers and includes two so
you can see how they work.
The first directory handler replaces the DirectoryIndex-like behavior
built into the normal page handler before -- so http://blah/dir/ looks
for http://blah/dir/index.html.
The second handler provides a simple directory index so you can browse
around files like an FTP site.
So if you'd like to play with it, have fun. Note that I haven't put the
option for editing the directory handler mappings ('/PageDirectory/')
into the Admin Toolbox yet. Also, be sure to look at the table
definitions -- the 'content_type' table got a field added as well as new
data, and there's a new 'page_directory' table along with data.
Chris
--
Chris Winters (ch...@cw...)
Building enterprise-capable snack solutions since 1988.
|
|
From: Ray Z. <rz...@co...> - 2001-12-20 13:59:52
|
I think there are really two pieces to the idea we have ...
(1) caching
(2) prevention of duplicate in memory objects
... where (1) has to do with avoiding going to the database for a
fetch, and (2) has to do with making sure that if you fetch twice you
get two variables pointing to the same object in memory.
I'm not sure if the Cache::Cache stuff addresses both or only (1).
Guess it's time for me to go do some reading.
At 2:26 PM -0500 12/19/01, Chris Winters wrote:
>On Wed, 2001-12-19 at 13:22, Ray Zimmerman wrote:
> > The issue we were concerned with first came up when we were deciding
>> whether to auto-fetch an Account object with a TransactionItem which
>> "has-a" Account. We realized that if you fetch a bunch of
>> TransactionItems which reference the same Account id, you'll get a
>> bunch of identical copies of the Account object in memory. It would
>> be nice to just fetch one copy and then have future fetches just
>> return a reference to that object.
>
>I hadn't really thought about in-process copies before. My original idea
>had been to just provide an interface to the Cache::Cache hierarchy
>since you'd get for free all sorts of good stuff -- and smarter people
>than me are worrying about how it all works.
>
>I assume the benefit of an in-process cache would be to have a change
>made to one object reflected in all of them. I'm a little wary of this,
>mostly because I tend to think in multi-process (mod_perl) terms.
>However... the Cache::MemoryBackend might be worth checking out.
Yes, I definitely view this as a benefit. The way I think about it is
that there is only one "real" object - the one in the database. It's
just that each process that fetches the object gets copies in memory
that it can use to manipulate the "real" object. Using a cache like
we're proposing makes sure each process only has a single copy.
IIRC, Tangram does not allow you to fetch more than one copy of an
object in a single process.
> > I believe this could easily be handled by modifying fetch() to stick
>> objects in a cache when they're fetched and to always look to the
>> cache first when doing a fetch.
>
>Yeah, that's one of the places where the hook is. Basically it goes like
>this:
>
> fetch
> - check cache and return if exist
> - fetch object; exit on failure or non-retrieval
> - add object to cache
>
> save
> - save object; exit on failure
> - refresh (add/update) object in cache
I'm not sure this last step would be necessary if the object in cache
is the only copy of the object in memory.
> remove
> - remove object; exit on failure
> - remove object from cache
>
>Fairly straightforward. The main wrinkle with this is
>fetch_group/fetch_iterator. I modified fetch_group a while back to grab
>the objects in one pass rather than grabbing the ID of the objects and
>just calling fetch() for each of them.
>
>The latter is cleaner because we can have the caching and other logic in
>one place (fetch()), but it's a very inefficient use of a database --
>and I normally don't even think about speed :-)
>
>We could make this optional if you're using a cache.... But while I
>haven't thought about this much, my gut feeling is that the current
>design does not support this readily.
Another thing about fetch_group (and I assume fetch_iterator, which I
haven't yet used) is that things get uglier when you start dealing
with inheritance like we do in ESPOPS. You almost have to go back to
getting IDs and then calling fetch (ESPOPS fetch_group still does
this) since the objects returned may not all be of the same class.
E.g. If I want to fetch all Vehicles owned by Bob, and he owns a Car
and a Boat, I want the objects returned to be of type Car and Boat,
not just of type Vehicle (the base class used to do the fetch_group).
I suppose you could make it smarter and fetch all of the Vehicles in
one pass and then only re-fetch the objects which belong to a
sub-class.
But yeah, fetch_group is likely to complicate the caching picture a
bit, though hopefully not too much.
>It's not inconceivable that much of the security/caching stuff will get
>moved up a level, with the actual persistence getting called through
>callbacks.
Hmmm ... now that sounds interesting.
> > The only complicated thing is keeping a reference count so that the
>> object get's destroyed when the reference in the cache is the only
>> one left.
>
>This is something I'd rather not deal with :-) If the Cache::* framework
>doesn't support this then I think we'd be better off working on that and
>making SPOPS work well with it.
I think I agree.
>Caching is one of those things that I really want to implement but I
>never get around to it because I don't have a pressing need. I also have
>a feeling it will necessitate some redesign (as mentioned above) which,
>while not a bad thing, can be time consuming :-) (OTOH, there'd be the
>benefit of having more users and developers around...)
>
>Isn't the ambivalence oozing off this email? :-)
Yeah, you were supposed to have thought through all of this stuff and
have definitive answers by now :-)
>So if you guys have ideas, I'm all ears. Particularly if they're as
>well-written and thought-out as the object relationship stuff.
Thanks ... I'm not likely to have the time to do anything quite that
complete for caching in the near future, but if I do have more
concrete ideas, don't worry ... I'll pass them along :-)
--
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
|
|
From: Chris W. <ch...@cw...> - 2001-12-19 19:25:27
|
On Wed, 2001-12-19 at 13:22, Ray Zimmerman wrote: > Chris, > > How's the SPOPS development is coming? Not bad -- I keep getting sidetracked from the new object relationship stuff, but it's coming along. The next version will have some useful (I hope) import (data and structure) and export (data only) methods along with a couple other little items. > Raj Chandran and I have been talking about something that we think > should be included in SPOPS. I know you have some sort of plans for > caching, but I'm not sure what it includes and how much is currently > implemented. Right now there are hooks in DBI.pm (at least) to use caching if it's available. When the caching gets on the radar these will probably change... > The issue we were concerned with first came up when we were deciding > whether to auto-fetch an Account object with a TransactionItem which > "has-a" Account. We realized that if you fetch a bunch of > TransactionItems which reference the same Account id, you'll get a > bunch of identical copies of the Account object in memory. It would > be nice to just fetch one copy and then have future fetches just > return a reference to that object. I hadn't really thought about in-process copies before. My original idea had been to just provide an interface to the Cache::Cache hierarchy since you'd get for free all sorts of good stuff -- and smarter people than me are worrying about how it all works. I assume the benefit of an in-process cache would be to have a change made to one object reflected in all of them. I'm a little wary of this, mostly because I tend to think in multi-process (mod_perl) terms. However... the Cache::MemoryBackend might be worth checking out. > I believe this could easily be handled by modifying fetch() to stick > objects in a cache when they're fetched and to always look to the > cache first when doing a fetch. Yeah, that's one of the places where the hook is. Basically it goes like this: fetch - check cache and return if exist - fetch object; exit on failure or non-retrieval - add object to cache save - save object; exit on failure - refresh (add/update) object in cache remove - remove object; exit on failure - remove object from cache Fairly straightforward. The main wrinkle with this is fetch_group/fetch_iterator. I modified fetch_group a while back to grab the objects in one pass rather than grabbing the ID of the objects and just calling fetch() for each of them. The latter is cleaner because we can have the caching and other logic in one place (fetch()), but it's a very inefficient use of a database -- and I normally don't even think about speed :-) We could make this optional if you're using a cache.... But while I haven't thought about this much, my gut feeling is that the current design does not support this readily. It's not inconceivable that much of the security/caching stuff will get moved up a level, with the actual persistence getting called through callbacks. > The only complicated thing is keeping a reference count so that the > object get's destroyed when the reference in the cache is the only > one left. This is something I'd rather not deal with :-) If the Cache::* framework doesn't support this then I think we'd be better off working on that and making SPOPS work well with it. > You'd also need a way to force a fetch to skip the cache ... I think passing in 'skip_cache' is currently there already. If it's not it will be. > I'm sure you've probably already thought about all of these > issues already. What do you think? Caching is one of those things that I really want to implement but I never get around to it because I don't have a pressing need. I also have a feeling it will necessitate some redesign (as mentioned above) which, while not a bad thing, can be time consuming :-) (OTOH, there'd be the benefit of having more users and developers around...) Isn't the ambivalence oozing off this email? :-) So if you guys have ideas, I'm all ears. Particularly if they're as well-written and thought-out as the object relationship stuff. Later, Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
|
From: Ray Z. <rz...@co...> - 2001-12-19 18:25:06
|
Chris,
How's the SPOPS development is coming?
Raj Chandran and I have been talking about something that we think
should be included in SPOPS. I know you have some sort of plans for
caching, but I'm not sure what it includes and how much is currently
implemented.
The issue we were concerned with first came up when we were deciding
whether to auto-fetch an Account object with a TransactionItem which
"has-a" Account. We realized that if you fetch a bunch of
TransactionItems which reference the same Account id, you'll get a
bunch of identical copies of the Account object in memory. It would
be nice to just fetch one copy and then have future fetches just
return a reference to that object.
I believe this could easily be handled by modifying fetch() to stick
objects in a cache when they're fetched and to always look to the
cache first when doing a fetch.
The only complicated thing is keeping a reference count so that the
object get's destroyed when the reference in the cache is the only
one left.
You'd also need a way to force a fetch to skip the cache ...
I'm sure you've probably already thought about all of these issues
already. What do you think?
--
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
|
|
From: <And...@Be...> - 2001-12-19 09:38:58
|
Hey, just tried to do some profiling of some of our requests, but I cannot get Apache::DProf running with OI. Did anyone get this going? later, Andreas |
|
From: Chris W. <ch...@cw...> - 2001-12-19 06:25:43
|
On Tue, 2001-12-18 at 14:42, Jochen Lillich wrote: > Hi! > > I just had an idea: How about OI apps with XML-RPC or SOAP interfaces? > How far are we from this as a reality? Is this only a matter of a > SOAP-compliant OI handler? This is actually on the SF feature request list[1]. I haven't attempted this yet, but if I understand everything correctly here's how it would be implemented: (1) Create a SOAP conductor -- this would replace OI::UI::Main with OI::UI::SOAP (or something, bad naming scheme) (2) Name the conductor in your server configuration (3) In an action you wanted to respond to SOAP requests, you'd specify the SOAP conductor's name (4) Instead of returning HTML content, I guess you'd pass off whatever objects result from the request to the conductor, which would create the response with the payload. AFAICT, this is actually fairly simple and if I'd actually used SOAP before (or had a paying customer needing it now) it would probably already be in there :-) Other ideas: - Creating a service that advertises available SOAP methods would be a snap since that information is already in the action table.(I can't remember if this is UDDI, WDSL or some other acronym. I saw this at Ziggy's presentation at YAPC::NA and it immediately made sense, so it can't be too hard :-) - Create a simple SOAP gateway for SPOPS objects. This would be pretty cool because you can not only retrofit an object mapping to one or more relational tables very quickly, you can expose that mapping to many languages at once. (Potentially impressive demo tool :-) The other benefit is that 'SOAP-SPOPS' uses only three letters... Chris [1]http://sourceforge.net/tracker/index.php?func=detail&aid=468934&group_id=16810&atid=366810 -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
|
From: Jochen L. <ge...@li...> - 2001-12-18 19:43:16
|
Hi!
I just had an idea: How about OI apps with XML-RPC or SOAP interfaces?
How far are we from this as a reality? Is this only a matter of a
SOAP-compliant OI handler?
Best regards,
Jochen
--
Jochen Lillich http://geewiz.teamlinux.de
Weird enough for government work.
|
|
From: Chris W. <ch...@cw...> - 2001-12-14 13:31:24
|
On Thu, 2001-12-13 at 11:37, And...@Be... wrote: > .. this really sounds like a good idea. It probably would ease my plan to > port Apache::MP3 to OI. Oh, this is an interesting idea! > In a recent post I told you about our plan to add features to base_page to > build differnt views, which probably come close to these directory handlers. Kind of -- it sounded more like the homepage you get on sourceforge.net/my/, which collects relevant information (all bugs/feature requests/tasks you've created or that are assigned to you, projects you've bookmarked, projects you're a member of, etc.) -- a summary page. > I think, that you need two sorts of directory handlers: > - one like you described before, where you build the index by reading > through files of some sort and extracting whatever metainfo or displaying > them This will be the standard one, I think. > - one which looks at who the user is and which rights he has and from this > build some kind of "portal" with links to the information he shall see Sure -- this is basically just another OI handler, so you can do whatever you want. (Now that I think of it, it would probably be cool to create a 'userpages' package which acts like the mod_userdir apache module so I could have http://blah/~cwinters/, etc.) But I want to create as little structure as possible for these -- your handler will get some extra information in the parameter hashref (the infamous $p) but that's about it. What you do with it is up to you. > Also, the type of the "pages" in the Page hierarchy should be irrelevant. It > does not matter, if the information is in files, some db, an external > website or dynamically generated. What do you think? Exactly! If the existing photo stuff isn't adequate then I was planning to start out using files for captions etc (like Randal's column discusses) and once that gels and looks good, put items in the database and make them user-commentable. Ok, now to find some time to do this... :-) Later, Chris -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
|
From: <And...@Be...> - 2001-12-13 16:48:18
|
.. this really sounds like a good idea. It probably would ease my plan = to port Apache::MP3 to OI.=20 In a recent post I told you about our plan to add features to base_page = to build differnt views, which probably come close to these directory = handlers. I think, that you need two sorts of directory handlers: - one like you described before, where you build the index by reading through files of some sort and extracting whatever metainfo or = displaying them - one which looks at who the user is and which rights he has and from = this build some kind of "portal" with links to the information he shall see Also, the type of the "pages" in the Page hierarchy should be = irrelevant. It does not matter, if the information is in files, some db, an external website or dynamically generated. What do you think? later, Andreas -----Urspr=FCngliche Nachricht----- Von: Chris Winters [mailto:ch...@cw...] Gesendet: Donnerstag, 13. Dezember 2001 14:43 An: ope...@li... Betreff: [Openinteract-dev] extending base_page: custom directory handlers I've been meaning for some time to get my own website back up and on the latest version of OpenInteract. But before I do that I'd like to have a good photo album program in place -- the one I wrote a while ago was just a bad and temporary hack, and one that sucked up mounds of CPU cycles at that. So I was thinking about a WebTechniques column [1] of Randal's where he implemented the photo album that's running on his site now [2], plus a recent discussion of such systems on either the mod_perl or TT mailing lists. And then it hit me -- all we need to do is tell OpenInteract is to treat requests for directory indexes differently. Then I thought: why can't we just associate a particular action with a directory request? And then: actions that are meant to be directory indexes can be flagged in the action table, just like actions that are lookups. I can hear you asking: These are different from normal actions how? Generally an action takes over an entire URL space -- all requests for /Photos/ would have to be handled by a particular action. This type of action is focused only on the directory request and leaves OpenInteract to deal with the files or subdirectories by its normal means. So, say you have a directory /Photos/. You could edit this as an individual object (page_directory), give it a description and pick 'photo_album' from the available directory handlers installed on your site. Thereafter, requests for /Photos/ will check to see if there's a directory handler registered and if so, execute that action. You can also tell subdirectories of /Photos/ that they should inherit the settings from parent directories, so you won't have to create an object for every subdirectory you want using the same directory handler. One of the good things is that we'd hopefully be able to create a simple wrapper around existing modules -- Apache::OpenIndex, Apache::PhotoIndex, etc. And creating a custom index should be a snap -- one of the sites I work on has a directory with files following a regular pattern (20011213.html) -- it would be nice to be able to list these out as: November 18, 2001 December 13, 2001 ... And have it automatically be updated when a new file is created in the directory. And so on. I wanted to put it out here to see if anyone had any ideas, problems, etc.=20 Chris [1] http://web.stonehenge.com/merlyn/WebTechniques/col41.html [2] http://web.stonehenge.com/merlyn/Pictures/ --=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 |
|
From: Chris W. <ch...@cw...> - 2001-12-13 13:21:26
|
I've been meaning for some time to get my own website back up and on the latest version of OpenInteract. But before I do that I'd like to have a good photo album program in place -- the one I wrote a while ago was just a bad and temporary hack, and one that sucked up mounds of CPU cycles at that. So I was thinking about a WebTechniques column [1] of Randal's where he implemented the photo album that's running on his site now [2], plus a recent discussion of such systems on either the mod_perl or TT mailing lists. And then it hit me -- all we need to do is tell OpenInteract is to treat requests for directory indexes differently. Then I thought: why can't we just associate a particular action with a directory request? And then: actions that are meant to be directory indexes can be flagged in the action table, just like actions that are lookups. I can hear you asking: These are different from normal actions how? Generally an action takes over an entire URL space -- all requests for /Photos/ would have to be handled by a particular action. This type of action is focused only on the directory request and leaves OpenInteract to deal with the files or subdirectories by its normal means. So, say you have a directory /Photos/. You could edit this as an individual object (page_directory), give it a description and pick 'photo_album' from the available directory handlers installed on your site. Thereafter, requests for /Photos/ will check to see if there's a directory handler registered and if so, execute that action. You can also tell subdirectories of /Photos/ that they should inherit the settings from parent directories, so you won't have to create an object for every subdirectory you want using the same directory handler. One of the good things is that we'd hopefully be able to create a simple wrapper around existing modules -- Apache::OpenIndex, Apache::PhotoIndex, etc. And creating a custom index should be a snap -- one of the sites I work on has a directory with files following a regular pattern (20011213.html) -- it would be nice to be able to list these out as: November 18, 2001 December 13, 2001 ... And have it automatically be updated when a new file is created in the directory. And so on. I wanted to put it out here to see if anyone had any ideas, problems, etc. Chris [1] http://web.stonehenge.com/merlyn/WebTechniques/col41.html [2] http://web.stonehenge.com/merlyn/Pictures/ -- Chris Winters (ch...@cw...) Building enterprise-capable snack solutions since 1988. |
1 message has been excluded from this view by a project administrator.
