For projects I was considering, Maypole commits too much to a particular strategy. I've found frameworks like that to be very great to get something started, but almost everyone wants to tweak something (especially customers, and at random times, and always urgent), and Maypole didn't look like it could "slide laterally" very well.
That's actually why I wrote CGI::Prototype - to try to get the framework out of the way, yet have a nice framework where I'd have a place to write each thing once.
| [reply] |
Maypole is designed to have some CRUD (CReate, Update, Delete) database web app very quick. And it is good at that. If your app fits that model well than you have saved lot's of time if not you will have to spend a lot of time to add the missing functionality. I thought that CRUD could quite flexible if you were allowed to use database views but first views were not supported by the Maypole libraries (I eventually got it working with some patches with Postgresql), second it still is not that flexible as I thought.
And the last point the paging is not done right - at last in search, I remember, all the data is fetched first from the database and only then the items for the current page are filtered. So if you have in your database hundreds of thousends of records you'll have all of them in the memory in one huge array only to filter then a few of them. | [reply] |
I remember, all the data is fetched first from the database and only then the items for the current page are filtered. So if you have in your database hundreds of thousends of records you'll have all of them in the memory in one huge array only to filter then a few of them.
This is a problem with Class::DBI, not Maypole. Class::DBI::Iterator fetches all the data and stores it as an array, as opposed to wrapping the underlying DBI statement handle.
| [reply] |