On 11/8/05, Kieren Diment <[EMAIL PROTECTED]> wrote:
> I've had a look at Maypole::Manual::Terminology, and because working
> with other people's work is so much easier than working on your own,
> I've edited it.  Diff attached.
>
> I'll go through my refactoring pain tomorrow daytime  in my own time
> zone.  Expect lots of questions at your breakfast time!
>

Great stuff, mostly incorporated, here's the bits I haven't used:

> This is a part of the power of
> maypole.  A lesser application server might encode these in a HTTP GET
> request, rather than as a part of the URI.

A GET request is encoded as the URL. I think you mean a POST request?
Anyway, I'm not too keen on value judgements. We don't need to say
Maypole is great, we just need to Make It So.

> The distinction is probably unimportant when using Maypole in
> 'default' mode - i.e. using L<Maypole::Model::CDBI>, and allowing
> Maypole to autogenerate the 'model' classes straight out of the
> database. However, less-than-trivial applications,
> L<Maypole::Model::CDBI::Plain> will make your life much easier.

I think default mode consists of 2 things - using
Maypole::Model::CDBI, and not making the model classes inherit from
other model classes. The 2nd example in Manual::Inheritance shows how
to autogenerate a (presentation) model hierarchy, and then link that
to a custom domain model hierarchy. I'll be adding a 3rd example (no
autogeneration) soon.

Thanks, I've ommitted the changes.

d.


-------------------------------------------------------
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-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maypole-devel

Reply via email to