Dave Howorth:
> Sebastian Riedel wrote:
> > So i began to reimplement Maypole from scratch. (really)
>
> WOW!
>
> > --- #YAML:1.0
> > name: Maypole PetStore
> > root: '/home/sri/PetStore/templates'
> > base: http://localhost/petstore
> > models:
> > - name: CDBI
> > base: CDBI
> > dsn: dbi:Pg:dbname=petstore
> > user: postgres
> > pass: 0
> > opts:
> > AutoCommit: 1
> > views:
> > - name: TT
> > base: TT
> > controllers:
> > - name: Categories
> > - name: Cart
> > - name: Items
> > - name: Products
> > logic:
> > - controller: categories
> > action: list
> > rules:
> > - model: cdbi_category
> > auth:
> > user_class: MyApp::Customer
> > user_field: email
> > session_class: Apache::Session::Postgres
> > session_args:
> > DataSource: dbi:Pg:dbname=petstore
> > TableName: session
> > UserName: postgres
> > Password: 0
> > Commit: 1
>
> This looks great; very exciting.
>
> > Well, name, root, base and auth are self explaining.
>
> I think template_root is self explanatory, but not root.
> (a fortiori, is 'extension' self explanatory?). Come to that, uri_base
> and application_name tell me more about what they mean as well.
Well, template_root doesn't sound right anymore, since we removed all
TT2 slang.
Could be called additional_files_root or something like that. :)
We'll decide later...
>
> > The name will be internally translated to the class "MyApp::Model::CDBI"
> > and will get "Maypole::Model::CDBI" as it's base class.
>
> Where does "MyApp" come from?
You still need a MyApp.pm
package PetStore;
use strict;
use Maypole::Application
qw(-Debug Config::YAML Authentication::Abstract Component -Setup);
use Maypole::Constants;
sub authenticate {
my $r = shift;
return OK if $r->parent;
$r->public;
return OK;
}
1;
>
> > The other options will be passed to the setup() method of
> > "MyApp::Model::CDBI".
> >
> > Internally we never use class names (we are lazy), so we have aliases.
> > "CDBI" becomes "cdbi", "MyApp::Model::CDBI::Stuff" becomes "cdbi_stuff".
>
> I don't like this, even though it may mean less typing. It means that
> everybody has to keep the extra transformation in mind in their head.
> It's sowing confusion and doubt - what does SuperModel become? Anglic
> peoples aren't so used to concatenating words and extracting the meaning
> intuitively. I'd prefer to have just one name for something and use
> it everywhere, so I can see at first glance what it means.
>
> I guess a compromise might be to declare the aliases explicitly in the
> config file?
>
Shouldn't be a big problem since you normally don't access other
namespaces directly.
You just pass around your data in $r->objects and $r->trunk from
model-action to model-action and modify it.
> > Maypole::Model::CDBI's setup() automatically creates and loads
> > subclasses for your tables and registers them with aliases.
>
> What happened to my choice of loader? I need this back please.
Should be easy to port other loaders...
>
> > Exactly the same thing happens for views and controllers. (Yes, even
> > setup() gets called for them)
>
> Great.
>
> > === Logic ===
> >
> > The core of all this is logic, it's an intelligent and dynamic internal
> > mapping between controllers and models.
>
> Now this I really like.
Replaced by actions, see my other posts. =)
>
> > logic:
> > - controller: categories
> > action: list
> > rules:
> > - model: cdbi_category
> >
> > This small example means that when someone requests
> > http://localhost/categories/list not only
> > MyApp::Controller::Categories::list() will be called but also
> > MyApp::Model::CDBI::Category::list() (and possibly more models and
> > actions if you define them).
> >
> > In fact MyApp::Controller::Categories::list() doesn't even have to exist
> > as method, as soon as its defined in logic it's automatically exported.
> >
> > The current set of available logic options is not yet finished...so
> > there is much room for cool features.
> >
> > logic:
> > - controller: categories
> > action: list
> > rules:
> > - model: cdbi_category
> > pre:
> > - first_post
> > post:
> > - i_am_late
> > - i_am_the_last
> >
> > Right now i'm thinking about pre and post actions, so the model actions
> > could be called before and after the controller ones.
> >
> > Controllers, Models and Views don't communicate directly, they use
> > $r->objects and $r->trunk to exchange informations.
>
> What's $r->trunk?
$r->trunk eq $r->template_args
Getting rid of TT2 slang...but it's also used to pass data from model
action to model action, everything that doesn't fit in objects should go
to the trunk.
>
> What can a model see? What must it see?
>
It should only see:
$r->objects
$r->trunk
$r->params
$r->args
But it can see and interact with everything.
> > Views can be dynamically switched by setting
> > $r->view('some_view_alias').
>
> Excellent.
>
> > So it's very very simple to switch between TT2, Mason or a YAML
> > Serializer. ;)
> >
> > === END ===
> >
> > Now the best thing, this is not pseudo code, i already implemented all
> > this!
> > You can grab a (not yet very clean) snapshot at
> > http://files.oook.de/PetStore.tar.gz
> >
> > That should be enough to make your heads explode, but there are many
> > more changes to be exposed! =)
> >
> > Feedback is very welcome, even when it's "WOW!" or "You Moron!".
>
> WOW!
>
> > sebastian
>
> Dave
>
>
> _______________________________________________
> maypole mailing list
> maypole at lists.netthink.co.uk
> http://lists.netthink.co.uk/listinfo/maypole
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