richard head wrote:
> package BS::Actions::Provider;
> use Maypole::Application;
>
> BS::Actions::Provider->config->model("Maypole::Model::CDBI::Plain");
> BEGIN{BS::Actions::Provider->setup([qw/BS::DB::Provider/]);}
>
> BS::DB::Provider->untaint_columns(printable => [qw/name/]);
>
>
> sub view : Exported {
> my ($class,$r) = @_;
> #get provider etc...
> }
>
> where BS::DB::Provider is a Class::DBI subclass.
> Initialy, when I didnt have the BEGIN block, i get an attribute error for
> the :Exported sub ("Invalid Code attribute : Exported at
> ...."). Several sites suggested adding the BEGIN. This worked, but bought up
> the following Class::DBI::Loader error:
>
> Couldn't require loader class "Class::DBI::Loader::", "Can't locate
> Class/DBI/Loader/.pm in @INC (...)
>
> The problem is that the BEGIN block causes setup() to run before I set the
> underlying model() class, so the model class becomes Maypole::Model::CDBI by
> default. When this classes setup_database() is called, it expects a
> connection string to pass to Class::DBI::Loader. This string does not exist,
> and the call fails. As you can see in Loader's error message, the underlying
> loader is not given "Can't locate
> Class/DBI/Loader/.pm in @INC"
>
> Without the begin block, it would appear that config would be setup
> accordingly. But then I get an error regarding the :Exported sub. The
> question might then become: "Why does my Exported sub generate this error:
> Invalid Code attribute : Exported at ...."
My knowledge is getting out of date, so I've hesitated to reply so far,
but AFAIK ...
(1) Actions (i.e subs with the Exported attribute) are part of the
model, not the driver. You need to move it to a model class.
(2) You need to make your model class a subclass of a Maypole model
class, not CDBI, specifically so you can define Maypole actions. They
will inherit CDBI-ness via M::M-ness.
I'm pretty convinced that is how you make it work. I'm not sure how it
fits with M::M::CDBI::Plain and using existing CDBI classes. I think
Maypole nomenclature is confusing. The way I look at it, there are two
'models' in Maypole. There is a domain model ( >= object model >= data
model) that has nothing to do with Maypole and can be used in cronjobs
etc. That's what I call the 'model'. This might be your pre-existing
CDBI classes in simple cases, but usually also involves extra knowledge
and classes in real-world apps. Then there is the 'Maypole-model', which
I call the 'presentation', that knows about web applications. It knows
about the domain model (probably via inheritance but could be
composition) but it also knows about Maypole (by inheritance of
M::M::something). It contains web 'actions' and any other stuff that
sits between Maypole's 'driver' and its 'view'.
Cheers, Dave
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Maypole-users mailing list
Maypole-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/maypole-users
