On 11/8/05, Kieren Diment <[EMAIL PROTECTED]> wrote: > So this one went a bit over my head, and might benefit from being > split into two separate man pages. > > Anyway, here's my diff, attached. >
Hi Kieren, thanks for this, I've modified some bits, and your comments emphasize that I need to add a description of building the model completely by hand. On some specific points: - I can't predict the size of the user's screen, all I can do is keep the diagram to < 80 columns wide. I think it's reasonably important that the user can see the whole thing in 1 diagram. Once it's up on CPAN, it'll be easier to see. > Finally, the relationships among these tables are set up. Either do > this manually, perhaps with the help of L<Class::DBI::Relationship> > (for simple, almost-trivial applications), or use > L<Maypole::Plugin::Relationship>. In the latter case, you need to set > up the relationships configuration before calling C<setup()>. I've re-written this to clarify the pros and cons a bit. > Essentially making a usable MVC architecture is about compromise. An > MVC that can do everything conceivably possible is not going to > satisfy anyone. An MVC that doesn't let you re-define your > application at anything except the lowest possible level is called a > procedural program. I don't like this bit. I don't see MVC as compromise - at least, no more than any other approach to engineering a software solution. Also, Catalyst is an MVC that can do just about anything, and it satisfies lots of people. And the last sentence is true, but I don't think it adds anything useful. > To start we want our model to be under the application programmer's > control, not the MVC programmers' control. To this end we will use > L<Class::DBI::Plain> rather than L<Class::DBI::Loader>. The example I give still uses Class::DBI::Loader, but I do need to add one that doesn't. > [Is this mutually exclusive from the previous section, or is it a > progression. I think you need to make your intention clear] Not sure what you're referring to here, perhaps a diff isn't the best way to communicate. I'm aware that the document is reasonably high level, but I think that's how it needs to be. My intention is that users would read this later rather than earlier. They might read it before getting their first app up and running, and might not grok too much of it then, but it should provide quick answers whenever you have an architectural question - when you're trying to get your head around what inherits from what, and where that gets set up. It's not intended as a detailed guide for developing complete apps, but as a map of what goes where. I've committed some edits, see what you think. Thanks, 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
