Esentially, block types are differentiated based on the suffix of their name. This is of sourse, a poor long term strategy. In order to facilitate the (as yet undocumented) themeing strategy, we will need more clearly defined block types. My proposal is for the aspects of block management that I need and would be inclined to write myself if I had time. I believe they can easily be integrated with the themeing strategy as it has been described on several ocasions (none in writing unless someone has the IRC logs from #scoop).
I propose two interface elements be added to the block admin tool and one field be added to the blocks table.
First, add a pulldown menu to select block type, when creating or editing blocks, as well as a textbox to allow users to create new block types. The content of the textbox should be taken in preference to the content of the pulldown menu wren writing block records to the DB (where if the textbox is empty, then the selection from the the pulldown menu is used). The pulldown menu should be populated from the new field of the boxes table, for eample: SELECT boxtype FROM boxes GROUP BY boxtype ORDER BY boxtype.
Block Type should not be optional. There should be a default box type defined in the DB field 'General' or something similar. The initial box types that come to mind are: template, boxtemplate, General, System. the 'System' boxtype is intended for boxes containing data called from within the admin tools (and as such sohuldn't be modified generally) in order to facilitate migration of HTML out from within the codebase into blocks. Then, block types could be used as the determining factor in generating menus of templates, for ecample in the admin/templates interface, and so fourth.
I further propose a file upload interface be included in the block admin interface to alloww for more convenient creation/modification of blocks. Also, a block download/save function would allow for easy saving of blocks for editing outside of scoop. This download function would simply output the content of the block, setting a content type of 'application/octet-stream' and a reasonable filename, cauing the user to be prompted to save the block as a file. Alternatively, if might be useful to extend 'boxtool' to allow editing of blocks.
The comment that special pages were simply blocks that are just putput using a different template threw me for a moment until I thought about it but it makes sense upon reflection. Realistically, there is no need for a seperate 'Special Pages' interface. It would be a simple matter to move the content of the special pages table into the blocks table with a block ID of 'special' and to migrate the 'Special Pages' OP code out of the codebase into a (tremendously trivial) box that just checks the block type of the argument to the OP and just displays it. This both simplifies the interface, brings to the database closer to first normal form, as well as serves to clean up the codebase somewhat.
This all integrates nicely with the plans for themes which as i recall, involves addding another field in the blocks table 'theme' and modification of the primary key making it a dual key made up of both 'blockid' and 'theme' where theme would have a default value for all exissting blocks, and users would be able to select from the available themes and if there is not a specific block for a particular theme a user has selected, then the block belonging to the default theme will be selected.
--CTH
--
ScoopHost.com - Premier Scoop Hosting and custom development from the lead developers.
|
