When I first started talking to the developers in #scoop, I asked them about the usual stuff that the scoop developers are tired of being asked about (i18n, CSS over table-based layout, etc.). Janra informed me that before any work on those projects could begin, the HTML and displayed text needed to be moved out of the Perl code and into the database (so that it can be associated with a theme and a locale). So, being fairly proficient in Perl, I fired up vim, checked out the latest CVS of scoop, and dove in. My strategy was this (again, as per discussions w/ the developers): I would remove the HTML in the code and replace it with references to vars and blocks. I got every last bit of HTML and displayed text out of Scoop.pm (top level module), which went pretty smoothly. I hadn't created that many new blocks, and Scoop.pm was now fully agnostic of its theme and locale (I created a default-css theme that got rid of the <font> tags and used CSS instead just to test it out, it worked beautifully).
I then turned to the Admin subdirectory of the scoop source and started to do the same work in Ads.pm (the module that controls the Ad Admin page). I was making new blocks left and right with ridiculously long names (not to mention the fact that they contained little blurbs of text that no one would probably ever want to change except for l10n purposes). Then I got to an error message that informed the user that the admin type they requested did not exist. Like all error messages should, it contained logic to inform the user what admin type had been requested to generate the error. This could not be converted to a block because it was dynamic, it needed that Perl code to be able to grab the requested admin type for the error message. I realized that between this problem and the explosion of vars and blocks I was creating, we needed to rethink this strategy.
I went back to #scoop to discuss the situation. Hillct suggested that we create a status/error object that we always passed around (accessible through $S I imagine) that would consolidate status/error message handling and make it more consistent. Modules could then pass error/status states from call to call. This would also eliminate a subset of the text fragments I was running into (and making an obscene number of blocks to handle).
However, this still left us with the remaining text fragments and the dynamic messages that didn't fall under the categories of status or error. I suggested that we create subcategories to handle all these vars and blocks, putting the less significant ones into lower categories. Hillct suggested that we also needed to recode many of the modules so that they used a primary template block which referenced the appropriate vars/blocks inside it (instead of haphazardly constructing the "block" in the Perl source). He gave Admin/EditBoxes.pm as an example of this. This module computes a hash of the values for the special vars in the template block and then runs that block (admin_boxes_form) through the interpolate function at the end. In looking over this file I noticed that it still contained a decent amount of HTML and/or displayed text (mostly where it was setting the values of the special vars/blocks). However, this was not a design flaw, it needed to have these things in the code because they are dynamic. It wouldn't do to put their value into a static var or block (static in the sense that it can only change if a user or admin changes it, scoop itself can only read the value).
So, even with subcategories and cleaned-up modules, we still had the problem of dynamic content. Then I realized, handling dynamic content is what boxes are for. So then I thought about what a box actually is. It's really just code that happens to be in the database. That's when I had an epiphany that I was going about this backwards. I didn't need to pull the HTML and the text out of the code (well, in some places it really should have been moved to a var/block), instead I should be putting the code, HTML, and displayed text all into the DB. When I suggested this to hillct, he said it had been discussed before. The idea was to turn scoop into a box-running framework. The problem with doing it right now is that it would make updates a nightmare. However, if we had an XML-RPC based Box Exchange system up and running, we could check MD5 checksums of boxes in the DB against the version in the exchange, and if they match, we could auto-upgrade the box. If not, we inform the site admin that there is a new version of the box available and let her/him merge it with her/his changes. Hillct said that was something he'd like to do with scoop 2.0, which is a little ways off yet. I went back to thinking about simpler mechanisms that could be used with 1.0-era scoop. I suggested that we keep filesystem information in the DB, so when we needed to update, we simply export all the code into its filesystem hierarchy (this would also be handy for hacking on it), update it w/ CVS (so we get all the nice merge-handling), then re-import it into the DB.
To summarize, for scoop to gain features such as CSS-based layout or i18n, it needs to have every bit of HTML and displayed text moved into the database. However, there are many text fragments throughout the code that would create a var/block explosion if they were all moved out as individual pieces. Var/block subcategories could ease this confusion somewhat as most admins would only need to deal with the upper-most categories (leaving theme/l10n developers to mess with the rest), but it would need to be combined with module code reorganization similar to what hillct did with Admin/EditBoxes.pm to keep it somewhat sane. It was also suggested that perhaps we get a little more strict about the naming conventions for vars and blocks (w/ various ideas suggested about how we effectively do that). But, like in EditBoxes.pm, we still have lots of dynamic content that needs to be handled by some Perl before we know what its value should be. Creating a common status/error object would help here, but there is still dynamic content that would fall outside that component's task. So, the ultimate solution is to move as much of the code into the DB as possible thereby allowing it to be themed and localized. However, the one big gotcha with that plan is how to handle updates. My suggestion of filesystem export seems as though it could work as an interim solution until the Scoop Box Exchange is ready for prime time (it's still in "That's a Neat Idea" phase), but I could be missing something important that would make it more trouble than it's worth.
So now it's time for comments. What approach should we take here? And if we come up with one, can we decide on a roadmap and version targets? There are many layers to this problem no matter how we choose to tackle it, and each one is not very glamourous to work on. We really need to implement each of these ideas to varying degrees because they each have a hand in keeping things sane. The state of the scoop development community right now would be hard pressed, I think, to accomplish all these tasks in an orderly fashion (w/ that caveat that I'm new here, so what do I know?). However, if we get an overall goal in mind and then divide that into the mundane tasks that need to be done in order to accomplish it and put that all into a roadmap w/ assigned teams (some/many of which may consist of only one person at first, but we need a mechanism for not letting things get left undone because the person they were assigned lost interest/time/whatever), we can get scoop development moving again, and moving in the right direction.
