Thanks David.
Hopefully I'm getting to the end of this particular part of the
maze. If I"m not, then I'm in trouble...
On 10 Nov 2005, at 20:18, David Baird wrote:
The use BeerDB::Beer etc statements are necessary, it just seems like
they're not. The call to setup(), among other things, adds the model
class to the @ISA of each class you pass in the setup() call. That act
automagically creates the BeerDB::Beer etc namespaces if they don't
already exist. So you can now call methods of BeerDB::Beer, and as
long as somewhere in the inheritance chain, the method is defined,
then BeerDB::Beer seems to work as expected. But you haven't actually
loaded/compiled and custom code in BeerDB/Beer.pm
Right. I've wound the HardBeerDB back to something that apparently
works again, and now I'm trying to break it.
So, no authentication, no plugins. One, apparently working exported
method that doesn't do anything.
I experimented until I had the minimum crap in the use base qw//
statement in BeerDB::DBI which was:
use base qw/Maypole::Application Maypole::Model::CDBI::Plain /;
Now the frontpage displays fine, but anything that needs the database
fails because the CDBI classes haven't been compiled. Before I got
the :Exported method working database access and entry was fine.
Adding the use BeerDB::Beer ... BeerDB::* statements to BeerDB.pm ,
the app dies with the following error:
Can't use string ("BeerDB::Beer") as a HASH ref while "strict refs"
in use at /Library/Perl/5.8.6/Class/Accessor/Fast.pm line 39.
Compilation failed in require at /usr/local/src/beer/lib//BeerDB.pm
line 5.
BEGIN failed--compilation aborted at /usr/local/src/beer/lib//
BeerDB.pm line 5.
Compilation failed in require at (eval 19) line 3.
I've tried a few obvious-but-stab-in-the-twilight things: wrapping
all the calls to the config and setup stuff in a BEGIN or INIT
block. changing "use" to "require"
A little more thought to this. It looks like compilation is failing
in the call to BeerDB::Beer->table('beer'); in BeerDB::Beer, but it
doesn't outside of Maypole.
Any further ideas? According to Simon's tutorial (p 23), this
process of using plain Class::DBI classes should be straightforward:
"Use plain Class::DBI. By using ordinary Class::DBI instead of
Class::DBI::Loader,
you can put each class, its relationships and its actions into a
separate module file; again, it just
makes the code easier to organise. "
It's pretty clear to me that how to do this properly _needs_ to be
documented.
It's also useful from a pedagogical perspective, as It's a good
starting point in adding programmed complexity into the application,
as it's kind of the simplest possible heavily-customisable use-case.
At least, that's my latest theory. Under the plain model, somewhere,
it's up to you to ensure the code in the subclasses is compiled,
So the upshot is that it isn't obvious to me how to do this. And
there are a stack of symptoms that I'm not competent to diagnose.
For the user subclass, have you defined this class in a separate file?
It can't live in the same file as another package, because of a bug in
USC (again, that'll be fixed for 2.11).
User subclass is all on it's own in BeerDB/User.pm
What happens if you don't include Maypole::Application in the use
base? Just say 'use Maypole::Application' instead.
This doesn't work: moving the Maypole::Application bit it's own use
statement complained about a lack of Maypole::Config, and an
undefined sub &BeerDB::handler.
Cheers.
kd
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Maypole-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maypole-users
