|
From: Vsevolod (S. I. <si...@cs...> - 2003-12-18 23:58:15
|
Chris, Another nitpick: after using AUTOLOAD in subclasses of objects owning SPOPS objects (don't ask :) I found out that the can() method of SPOPS objects does not return true if you give it the autodiscovered column name. It would be neat if it did. Simon -- Simon (Vsevolod ILyushchenko) si...@cs... http://www.simonf.com America's business leaders simply don't want to think about complex technology issues - they want to think about golf. Microsoft promises them that. Andrew Grygus, www.aaxnet.com |
|
From: Chris W. <ch...@cw...> - 2003-12-19 00:49:01
|
On Dec 18, 2003, at 6:58 PM, Vsevolod (Simon) Ilyushchenko wrote: > Another nitpick: after using AUTOLOAD in subclasses of objects owning > SPOPS objects (don't ask :) I found out that the can() method of SPOPS > objects does not return true if you give it the autodiscovered column > name. It would be neat if it did. Does it work once you call the parameter? That is, if you do: SPOPS::Initialize->process( ... ); my $foo = Foo->new(); print "Can it before? ", $foo->can( 'bar' ) ? 'yes' : 'no', "\n"; $foo->bar( 'baz' ); print "Can it after? ", $foo->can( 'bar' ) ? 'yes' : 'no', "\n"; It should print out: Can it before? no Can it after? yes I agree that they should both say 'yes' and I'll see about making that happen. Later, Chris -- Chris Winters Creating enterprise-capable snack systems since 1988 |
|
From: Vsevolod (S. I. <si...@cs...> - 2003-12-19 22:26:16
|
Chris, Finally, an non-trivial question. :) I am implementing a hierarchy of objects, each of which owns an SPOPS object. (I tried to not separate them, inheriting my classes both from SPOPS and from my superclass, but the new() methods collided, and multiple inheritance is not a good idea anyway). So far this worked out well until I started using 'links_to'. Assume that MyPublisher and MyBook are my classes, SPOPS_Publisher and SPOPS_Book are SPOPS classes. Instances of MyPublisher refer to instances of SPOPS_Publisher, instances of MyBooks refer to instances of SPOPS_Books. The expected object behavior is this: $aMyPublisher->books produces an array of MyBooks. In actuality, $aMyPublisher->books produces an array of SPOPS_Books. Is it possible to generate the desired result without straining the framework too much? Looks like I can achieve this by mucking around in SPOPS::ClassFactory::DBI and providing some kind of callbacks within the get/add/remove functions, but I'd like to get an official word first. As for my previous question, > It should print out: > Can it before? no > Can it after? yes Precisely - I checked it. > I agree that they should both say 'yes' and I'll see about making that > happen. Thanks! Simon -- Simon (Vsevolod ILyushchenko) si...@cs... http://www.simonf.com America's business leaders simply don't want to think about complex technology issues - they want to think about golf. Microsoft promises them that. Andrew Grygus, www.aaxnet.com |
|
From: Chris W. <ch...@cw...> - 2003-12-20 16:46:52
|
On Dec 19, 2003, at 5:25 PM, Vsevolod (Simon) Ilyushchenko wrote:
> ...
> So far this worked out well until I started using 'links_to'. Assume
> that MyPublisher and MyBook are my classes, SPOPS_Publisher and
> SPOPS_Book are SPOPS classes. Instances of MyPublisher refer to
> instances of SPOPS_Publisher, instances of MyBooks refer to instances
> of SPOPS_Books.
Right -- I think it's easier (now) to make MyBooks a subclass of
SPOPS_Books (more below)
> The expected object behavior is this:
>
> $aMyPublisher->books produces an array of MyBooks.
>
> In actuality,
>
> $aMyPublisher->books produces an array of SPOPS_Books.
>
> Is it possible to generate the desired result without straining the
> framework too much? Looks like I can achieve this by mucking around in
> SPOPS::ClassFactory::DBI and providing some kind of callbacks within
> the get/add/remove functions, but I'd like to get an official word
> first
Coincidentally, I made a change in 0.80 that allows you to do:
SPOPS class: SPOPS_Books
Your class: MyBooks isa SPOPS_Books
SPOPS class: SPOPS_Publisher
Your class: MyPublisher isa SPOPS_Publisher
Then declare in your publisher configuration:
links_to => { MyBooks => 'link_table' }
So you can use your subclass ('MyBooks') rather than the
SPOPS-generated class as the class to link to. I know this goes against
the GoF declaration to 'Prefer composition over inheritance', but it is
a much cleaner solution that using the 'code_class' configuration item
(crazy idea that). I've modified all the code in OpenInteract2 to use
this pattern, naming the SPOPS-generated classes 'FooPersist' for
clarity.
The only caveat is that you cannot 'use base' to declare the parent
relationship; you need to use @ISA explicitly:
package MyBooks;
@MyBooks::ISA = qw( SPOPS_Books );
sub my_custom_sub {
...
}
The change in SPOPS 0.80 to enable this was just to do a 'require' on
the class specified in has_a and links_to before using it in the code
generation process.
Hope that makes sense.
Chris
--
Chris Winters
Creating enterprise-capable snack systems since 1988
|
|
From: Vsevolod (S. I. <si...@cs...> - 2003-12-22 19:51:52
|
Chris, > Coincidentally, I made a change in 0.80 that allows you to do: > > SPOPS class: SPOPS_Books > Your class: MyBooks isa SPOPS_Books > SPOPS class: SPOPS_Publisher > Your class: MyPublisher isa SPOPS_Publisher Thanks! This almost works out for me. But here is the problem: my classes have a superclass. Let's call it MyObject. So I inherit MyBooks from SPOPS_Books and MyObject. I have to double-dispatch the new() method, but I can live with it. However, I use strict field checking and field autodiscovery. When I begin to store attributes in MyObject via the regular Perl getter/setter methods which use $self as a hashref, I start to get SPOPS errors about accessing fields that are not present. Obviously, I can turn strict fields off, but I'd like to retain that. The alternative is to somehow keep autodiscovery, but add in the config hash of SPOPS_Books additional fields which correspond to "instance variables" of MyObject. I am not sure how to do it, but even if I could, it's messy because I'll have to repeat it in every SPOPS_* class. This can be made a little less messy if I do not inherit from MyObject, but store a reference to it, but this one reference still has to be mentioned in SPOPS config. Simon -- Simon (Vsevolod ILyushchenko) si...@cs... http://www.simonf.com America's business leaders simply don't want to think about complex technology issues - they want to think about golf. Microsoft promises them that. Andrew Grygus, www.aaxnet.com |
|
From: Vsevolod (S. I. <si...@cs...> - 2003-12-23 17:12:34
|
> Coincidentally, I made a change in 0.80 that allows you to do:
>
> SPOPS class: SPOPS_Books
> Your class: MyBooks isa SPOPS_Books
> SPOPS class: SPOPS_Publisher
> Your class: MyPublisher isa SPOPS_Publisher
>
> Then declare in your publisher configuration:
>
> links_to => { MyBooks => 'link_table' }
Chris,
I may be doing something wrong, but I hit another snag. I am trying to
use objects that refer to each other, and I use links_to in both
configuration. (I call them Job and Task, but they are similar in their
relationship to Publisher and Book).
I attach the four class files and the script that tries to use them.
I inherit Job from SPOPS_Job and Task from SPOPS_Task. The SPOPS
configuration refers to Common.pm, which would be different in your case.
There are four possible configurations:
SPOPS_Job links to SPOPS_Task, SPOPS_Task links to SPOPS_Job
SPOPS_Job links to Task, SPOPS_Task links to SPOPS_Job
SPOPS_Job links to SPOPS_Task, SPOPS_Task links to Job
SPOPS_Job links to Task, SPOPS_Task links to Job
The first three work, but the last one, which is of greater interest,
does not. Could you please look at this and tell me if I am doing
anything wrong?
The error message is:
Cannot run behavior in [links_to] [SPOPS_Job]: Failed to retrieve
configuration from Compilation failed in require at Job.pm line 5.
The tables that the config files refer to are created thusly:
CREATE TABLE `Job` (`job_id` int(11));
CREATE TABLE `Task` (`task_id` int(11));
CREATE TABLE `JobToTask` (`id` int(11), `job_id` int(11), `task_id`
int(11));
Merry Christmas!
Thanks,
Simon
--
Simon (Vsevolod ILyushchenko) si...@cs...
http://www.simonf.com
America's business leaders simply don't want to think
about complex technology issues - they want to think
about golf. Microsoft promises them that.
Andrew Grygus, www.aaxnet.com
|
|
From: Teemu A. <te...@io...> - 2003-12-29 14:22:27
|
Hi, I'm using OpenInteract 1.60. I noticed a problem with Stash class. I might be wrong but my understanding is that the Stash class makes sure you can run several different OpenInteract websites on one Apache mod_perl server without any problems. I have a mod_perl server with two different OpenInteract websites running on different virtual hosts, both configured with their own httpd_modperl_solo.conf with virtualhost configurations and with different databases. Both have different OIStashClass and startup.pl. Lets say that on website #1 (configuration Included first in my apache.conf) I have the following additional SPOPS objects installed: course student Which both I can access through $R->[object] without problems. On website #2 however (configuration included second in apache.conf) I have the following SPOPS objects installed: course teacher I can access course without problems through $R. But $R->teacher->fetch_group() however results in the following error: Can't locate object method "teacher" via package "OpenInteract::Request". Strangely, I'm able to access $R->student from website #2, which is not installed on website #2! (but it doesn't work as it should, because I don't have such a table in the database of website #2). If I disable website #1 on my webserver, website #2 works as it should. $R->teacher works as it should. I also noticed that on website #2, defining new object classes for $R in system_alias configuration in server.ini doesn't work. Seems like website #2 accesses the object class aliases from website #1, which is loaded first into our Apache. It seems like everything in this Stash works (actions, own database connections, other configuration options...) expect object class aliases for $R. Just to let you know, oi_manage list_objects for website #2 returns the correct list of installed objects and there is no sign of student there, but the site still works the other way around. I know the Stash implementation is a little bit of a hack, but this hack obviously does something wrong at the moment. Currently I have to work-around this problem by running separate apaches on one server, which is maybe more clever anyway. - Teemu Arina |
|
From: Chris W. <ch...@cw...> - 2004-01-05 11:40:05
|
On Dec 29, 2003, at 9:21 AM, Teemu Arina wrote: > I'm using OpenInteract 1.60. > > I noticed a problem with Stash class. I might be wrong but my > understanding is > that the Stash class makes sure you can run several different > OpenInteract > websites on one Apache mod_perl server without any problems. That was its original intent. Unfortunately a number of other problems get in the way and this doesn't work properly. That's why I removed this non-feature entirely for OI2. Sorry for the bad news... Chris -- Chris Winters Creating enterprise-capable snack systems since 1988 |