I just ran across a new Apache project called Olio.
Olio is a is a web2.0 toolkit to help evaluate the suitability, functionality and performance of web technologies. Olio defines an example web2.0 application ( an events site somewhat like yahoo.com/upcoming) and provides three initial implementations : PHP, Java EE and RubyOnRails (ROR). The toolkit also defines ways to drive load against the application in order to measure performance.
Olio provides a project description, raw data and relationships plus html and css mockups for each screen of the application.
The project is looking for alternate implementations which leads me to the actual point of this post:
This looks like a great opportunity for the various perl frameworks to showcase their unique advantages. As such it would also help some folks make the choice between the perl frameworks.
Will anyone besides the Mojo camp actually do this though?
The toolbox is full of crud. Granted, the CPAN, Catalyst and Mason are listed but WTF are people perpetuating Matt's Script Archive in 2007?
I have never heard of their 1st choice for online perl tutorials PageResource.com or half of the others, and I've doing (at least) weekly web searches on perl related topics for 10 years.
The Perl community can produce a much better list but could it boiled down to just 20 tools?
At $work we have a bunch of perl 4 style libraries that get required into apps when we need their functionality.
As they are not packages they automatically pull a whole pile of subroutine and variable definitions into the main:: namespace. I wasn't feeling very happy about that.
So in a effort to begin refactoring I wrote packages as wrappers around these libraries. The packages use Exporter and @EXPORT_OK so we could use the package and import only the subroutines our apps actually needed. This allows us to incrementally migrate the code base to the package style as we need to, by keeping the original libraries intact.
As these types of things usually do, there are interdependencies between the libraries, for example bar.pl calls a sub defined in foo.pl so the package for bar.pl (BarWrapper.pm) needs to require both bar.pl and foo.pl
When I "use" two wrapper packages and they both "require" the same lib, the second package gets shafted and doesn't get the subroutines defined and imported into its namespace.
How the heck can I work around or overcome this?
Or what's an alternate solution that meets my goals?