Simon Cozens:
> Sebastian Riedel:
> > What are the reasons you wanted to avoid this?
>
> If you have both configuration (of actions) and code for actions, you're
> duplicating information. Not duplicating information is the first rule of good
> programming. I would like Maypole to continue being good programming. :)
>
Right, i absolutely hate duplication too!
Let me convince you that this is good programming.
When we say...
actions:
cart:
add:
- cart: add
- cart: content
- cdbi_item: resolve
- cdbi_product: resolve
...it means that our engine "tries" to run...
PetStore::Controller::Cart::add()
PetStore::Model::Cart::add()
PetStore::Model::Cart::content()
PetStore::Model::CDBI::Item::resolve()
PetStore::Model::CDBI::Product::resolve()
...but it doesn't matter if PetStore::Controller::Cart::add() exists, it
can be completely virtual. (controller actions are automatically
exported when they appear in config)
In fact, this approach is much more about code reuse, since you group
code snippets from different models to actions.
actions:
cart:
add:
- cart: add
- cart: content
- cdbi_item: resolve
- cdbi_product: resolve
update:
- cart: update
- cart: content
- cdbi_item: resolve
- cdbi_product: resolve
view:
- cart: content
- cdbi_item: resolve
- cdbi_product: resolve
This is just an example but you see...
PetStore::Model::Cart::content()
PetStore::Model::CDBI::Item::resolve()
PetStore::Model::CDBI::Product::resolve()
...are reused.
Some would say this is a bit AOP like. ;)
I would really like to push blueprint driven development and design
patterns.
For example we could make the CRUD stuff a blueprint with a set of
baseclasses, people could begin to design their applications around.
name: My Maypole CRUD
root: '/home/sri/CRUD/templates'
base: http://localhost/crud
models:
- name: Stuff
base: CRUD
dsn: dbi:Pg:dbname=petstore
user: postgres
pass: 0
opts:
AutoCommit: 1
views:
- name: MyTT
base: TT
controllers:
- name: MyFoo
base: CRUD
This class definition would generate something like this. (pseudocode to
visualize)
We assume the CRUD model to default to a CDBI loader, loading the two
tables foo and bar.
# Controller
package MyApp::Controller::MyFoo;
use base 'Maypole::Controller::CRUD';
# Model
package MyApp::Model::Stuff;
use base 'Maypole::Model::CRUD';
package MyApp::Model::Stuff::Foo;
use base 'Maypole::Model::Stuff';
package MyApp::Model::Stuff::Bar;
use base 'Maypole::Model::Stuff';
# View
package MyApp::View::MyTT;
use base 'Maypole::View::TT';
Maypole::Controller::CRUD would define the basic action sets while
Maypole::Model::CRUD provides the snippets to modify the data.
Extending this blueprint would be as easy as, "create this file",...
package MyApp::Model::Stuff::Foo;
sub my_list {
my ($self, $r) = @_;
$r->objects([__PACKAGE__->retrieve_all]);
}
...(it will be automatically required), "then a new virtual action"...
actions:
crud:
my_list:
- stuff_foo: do_some_built_in_things
- stuff_foo: my_list
..."and finally a my_list template for the tt view"...
[% FOR thing = objects %]
Thing: [% thing %]
[% END %]
The biggest problem is that you have to rethink, you no more do stuff on
tables, you do it on controllers.
So http://localhost/crud/table/list would become
http://localhost/crud/list/table
Dynamic dispatching based on arguments like the table name would happen
in "real actions" in the controller.
sebastian
_______________________________________________
maypole mailing list
maypole at lists.netthink.co.uk
http://lists.netthink.co.uk/listinfo/maypole
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:57 GMT