I am the author of this module. I was surprised to discover that CPAN did not have a module like this when I first encountered a need for it back in 1994. I went through several iterations before arriving at the solution that I finally posted to CPAN in 2004. I find this module distribution indespensible. Working with HTML forms is simply tedious without it.
1 out of 5 found this review helpful. Was this review helpful to you? Yes No
I am the author of this module. I created it because I wasn't totally happy with any of the existing object/relational database modules on CPAN. Rose::DB::Object is the culmination of many years of experience. During that time, I developed several prototypes, none of which I deemed worthy of CPAN. This is the first one I felt comfortable with sharing. It's still in active development, but I already like it a lot more than any of the alternatives.
1 out of 4 found this review helpful. Was this review helpful to you? Yes No
(I am the author of this module.)
I discussed this on the module-authors list. I initially wanted to upload everything as a single distribution, like Maypole, Bricolage, or any other "branded" framework on CPAN. But some of the Rose::* modules are useful in isolation (e.g., the HTML objects) so I was persuaded to break things up. Breaking things up also lets me start to release things as they are done, rather than having to wait until the whole suite is ready for release.
So I'm faced with the problem of how to version the suite as a whole, yes, but more importantly, where to even *talk* about the suite as a whole. Bundle::Rose isn't a useful place for suite-wide documentation because it doesn't actually get installed anywhere.
I settled on Rose.pm, where I currently describe the development policy and will later outline the philosophy of the entire suite. I think a "documentation + version" module isn't all that awful, and actually solves a problem in this case. As a result, "perldoc Rose" shows what the user expects it to show: an explanation of the entire Rose suite.
Regarding the comment by Mark Thomas: "If you've got modules that could be useful outside of Rose, they shouldn't be in the Rose namespace." The problem is that the modules that are useful outside of Rose still rely on other Rose modules (i.e. have them as prerequisites), which makes them realistically "Rose-related" even if they theoretically might not seem to be.
4 out of 5 found this review helpful. Was this review helpful to you? Yes No