 |
|
Tuesday, October 26. 2004
Detail pages display a particular record on a site. If you have datatype specific modules, you might be tempted to have a detail.php capability within it - usually by just copying the detail.php file from the general module. Unless you'll be implementing a lot of custom code on the detail page, say to hook in to a third party shopping cart app, you're probably safer just re-using the general detail script.
Let's assume you have Press Releases to display and have put the related code in modules/press_release. Your user.conf.php file would have at least the following lines to register the module:
// The Abstract Documents Module
Modules::addModule('press_release', 'Press Releases');
Modules::setAttribute('press_release', 'content_label', 'Press Release');
Modules::setAttribute('press_release', 'datatype', array( DATATYPE_DOCUMENT ));
Modules::setAttribute('press_release', 'public_exposure', true);
Moduels::setCapability('press_release', 'list' );
By NOT specifying a detail capability above, Syntax will route requests to /content/press_releases/detail/444 through modules/general/detail.php. This gains you a few things:
- Fetching the record is done using collections, so that record privileges will be checked and enforced. If a record is restricted to a specific group or user, then it will only be displayed to them.
- Will check if the datatype is in the exposed content datatypes list.
- Breadcrumb to the detail page will be automatically built depending on if user's came to the page from a section or another module.
- Less time coding or copying this code and one less file to manage.
Detail.php is smart enough to look for a custom detail.tpl file to use to display the matching record. It will look in the first module that works with the specified datatype. So, in this case it would look for modules/press_release/templates/detail.tpl and use that file if it exists. In your custom template, you have to use the $Record variable to get information out for display.
Sunday, October 24. 2004
I thought I'd comment on what we are trying to do with Syntax CMS and help potential users decide if it's right for them.
What Syntax CMS Is
Syntax CMS is a result of our custom development for Non Profit clients. Syntax CMS is the platform most of the sites that Forum One Communications has developed were built upon, either in its current form or one of the intermediate predecessors. Accordingly, you'll find it suited to people who have to build out a lot of custom features but don't want to reinvent the wheel each time. Syntax CMS and its ancestors have been used for everything from five or six-page sites without a lot of dynamic content to gargantuan information repositories to a environmental data collection and display Web application.
Syntax CMS is a starting point. Syntax CMS is built with the assumption that what you get out-of-the-box is not what you'll end up with as your finished site. We assume you'll not only want to change the templates around, but create new content types and program a couple of custom displays or even Web applications.
Syntax CMS is optimized for content administrators and programmers. Syntax CMS, as befits its primary role as our in-house development platform, is optimized for content administrators who only work with installed and configured instances as well as programmers who develop the applications the content administrators will later use. This is not to say it is the be-all and end-all of usability for either case, but this is where much of the effort we have put into the system has been. Accordingly, you'll see better documentation than in most in-house projects for programmers, and easier-to-use content interfaces than some more developer-centric Web applications. Improving both continues to be a priority for us, especially usability for content administrators.
Syntax CMS is content-based. Syntax CMS was developed with Forum One's clients in mind: policy organizations with a great amount of existing content either locked away in a static HTML Web site or offline in individual documents. Accordingly, the site assumes you'll have different content types, want to use the existing content anywhere it's appropriate, and maximize the ability of users to find the content no matter the strategy they use to find it: clicking on pages, filtering by category, or searching.
This is the main reason Syntax CMS exists--to support faceted classification and content discovery. My favorite metaphor, which I freely stole from one of our senior strategists, is finding salsa in the grocery store. You can look at the store directory and find "condiments," go to that aisle, and find salsa. But you can also find the same product under "ethnic food." And if there's a display of party supplies that includes tortilla chips, salsa will be there. It will also likely be near where tortilla chips themselves are sold. So the store wants to make it as easy as possible to find salsa, no matter how you might think of finding it. Syntax CMS wants to make it as easy as possible to find content items, no matter how you think of finding them.
What Syntax CMS Is Not
Syntax CMS is not a "product" Forum One sells. We sell and support solutions. There's no Syntax CMS box. We don't ship it. It's free. We don't provide support for the open source version the way we do the solutions we create for our customers, though of course you are welcome to make a special arrangement with Forum One to get support on a time and materials basis. It's open source because we thought it might be useful to the community, and really we have no reason to keep it closed. An active user community would be nice, as would contributions and improvements from that community, especially in areas that aren't our in-house priority (just because they're not a priority doesn't mean we wouldn't think they're useful or of value). However, our goal is not Syntax CMS on every server. We expect it will be useful for people with problems like ours. We expect to keep using it to provide smart solutions for policy organizations who come to us for strategy and development. We don't expect to make a lot of money from people who want a given feature and will pay us to implement it--though we of course would be happy to work something out. But bottom line, Syntax CMS is not a "product" and will not be for the foreseeable future.
Syntax CMS is not a CMS-in-a-box. In accordance with our "not a product" strategy, the open source download of Syntax CMS is not designed to be a finished application after installation. You should be able to do some things with it, but it's expected you'll want to tweak it and program it. This means we haven't put in a lot of time to things like a nice-looking default design, or swappable and extendable themes, or even making sure the thing generates zero errors when you first install it on a different server environment than ours (though it should be mostly useable, and getting to error-free is a goal of ours--just not a high priority).
Syntax CMS is not optimized for lone webmasters looking for a quick CMS. While we would love an installation wizard like Serendipity's, it's just not a priority of ours. After all, it's not a product we're trying to sell. So you'll find that while we try to reduce the dependencies, there are a number. It is not yet as easily configurable for different servers as we'd like. We haven't spent a lot of time making it work for other databases, though it is built to allow that possibility. These are areas we would actually encourage any outside users to contribute code or design advice. However it's not a priority inside our organization. But Syntax CMS is not designed for easy installation and configuration to put up a quick CMS for users to start in on. If you're the lone webmaster of an organization that wants a dynamic Web site without a lot of effort, you probably want one of the other Open Source CMSes out there. Even if we get it more easily installed, our not-a-product strategy means it is unlikely you'll see attractive default themes or every module your heart could desire ready and waiting for you. Unless, of course, you hire us to develop a really great Web site for you.
Syntax CMS is not (primarily) page-based. Some CMSes assume that all content will appear on pages, and pages will have authors, and everything on a page is configurable. Syntax CMS is not one of those CMSes. We assume users will come to our content from different directions: searching, browsing by some classification, exploring links of related content, or by following a heirarchical tree of pages. But for Syntax CMS, the content is the thing. We do provide the tools that let you use Syntax CMS to generate a site that mainly gives you dynamic control of a 5-page brochure site (and we have used it in this way). However, that's just not our focus.
In fact, it is this non-page-centric approach that has caused us to build and maintain our own solution, as I noted above. So if you're looking for a solution that is what Syntax CMS is and isn't what Syntax CMS isn't, give it a whirl and tell us what you think. But remember that it's not designed to be a one-size-fits-all product--it's just designed to be a flexible enough platform for you to turn it into the solution you need--just like we do on a daily basis.
Update: I have edited the entry to clarify our stance on the open source CMS we have made available versus the solutions we regularly provide to our clients.
Tuesday, October 5. 2004
I just checked in a new type of pick table that will be available in our next release. Just in case you are wondering, in Syntax a pick table is a simple database table of id, name pairs that are used mostly for categorizing other records. For example, you could have a picktable for topics, regions, and countries and use those across all your content types - people, documents, events, etc. Until now, these have been flat lists, and in truth they still are, but by adding a field called parent to a picktable, they can be displayed as a tree of options to users.
In the site administration application, child picks are drawn indented underneath their parent and sorted alphabetically. Also, you can not delete picks that have no parent ( parent=0 ) or that have children.
In an input form, if you use the pick_tree widget with a pick table with a parent column, they will be drawn as a hierarchical set of options for the user to select.
Wednesday, September 29. 2004
Not at all Syntax related but I was looking at PHP Presents today and am quite impressed by the range of presentations available. Does anyone know if there are similar presentaion repositories available for HTML, MySql, or other LAMP components?
Monday, September 27. 2004
Version 1.1.1 of Syntax CMS is available Syntax CMS 1.1.1. This release bundles a number of bugfixes and minor feature improvements:
- Various fixes to make syntax less dependent on register_globals being on
- Added :hover styling for rows in navigation widget to make it easier to pick out where to publish/feature content.
- Added htmlarea textarea WYSIWG editor as an available widget.
- Display fixes in Site Administration application.
- Added _link() method to simplify outputing href tags.
- Standardized use of NAV_ROOT_EL to build out section paths, breadcrumbs, etc.
- Improved CSS style of Site Administration app.
Thursday, September 16. 2004
The ListWidget class goes a long way towards making it easy to work with input widgets for lists of options. One of the most common uses of it is for building filtering interfaces based on a picktable in your syntax database. Usually, to do so you have to jump through a small number of hoops.
pxdb_import( 'content.output.pxdb_picktable' );
$picks = new pxdb_picktable( 'topics' );
$topics = $picks->get_listwidget_array();
// add default 'All' option at top
$topics = array_unshift( $topics, array( 'value' => '', 'label'=>'All' ) );
$topicsList= new ListWidget( $topics, 'topic' );
Now in cvs, is a single function that replicates the above lines. Its signature is list_from_picktable( $form_element_name, $pick_table_name, $additional_elements). The $additional_elements parameter is primarily there for adding a default or 'All' element at the beginning of your list.
$topicsList = list_from_picktable( 'topic', 'topics', array( 'value' => '', 'label'=>'All' ) );
Tuesday, September 14. 2004
One of the task's we're often asked to do is save input from a form to the database and also send a notification message to a recipient. Recently I had to do that and include the record's data as part of the email message. While it's easy enough to build a custom message each time, the following solution builds the message body based on a defined view for your datatype. You'll need a newer copy of the metadata.pxdb_view class as I had to add a method to it allowing you to create a pxdb_view object based on the datatype id and view name. The main benefit to this approach, beyond it's flexibility is that we can add new fields to our view and the email sent out will automatically include those too without further intervention on your part.
if( $rec_id = $adm->save() )
{
pxdb_import( 'content.output.pxdb_record' );
pxdb_import( 'metadata.pxdb_view' );
// success! -- $rec_id is saved (or added) record id
$view = "success"; // for redirection later
// now get the just saved record back out of the database
$record = new pxdb_record( $rec_id );
// start building our email message
$msg = "A new feedback message has been sent:\n";
//get the 'public' view for the FEEDBACK datatype. We used
// this view to present a form to users.
$view = pxdb_view::fetch_object_view( DATATYPE_FEEDBACK, 'public' );
// build the rest of the message based on the fields used
$viewfields = $view->arr_typesfields();
while ( list(,$viewfield) = each( $viewfields ) )
{
$msg .= "\n ".$viewfield['displayname'].': '.$record->get_field( $viewfield['identifier'] );
}
// send it off to the intended recipient
mail( FEEDBACK_RECIPIENT, FEEDBACK_SUBJECT, $msg, "auto@".$_SERVER['SERVER_NAME']."\r\n" );
} // end if
Friday, September 10. 2004
Version 1.1.0 of Syntax CMS is now availabler for download as a gzipped tar file: Syntax CMS 1.1.0
The PHP source is also available to anyone via anonymous cvs:
export CVSROOT=:pserver:anoncvs@cvs.tigris.org:/cvs
cvs checkout -d syntaxSandbox syntax-cms/src
Thursday, September 9. 2004
The listwidget class depends on register globals being on to determine what value(s) in a list is selected or checked.
if($currSelected === false) {
global ${$elementName};
$this->selected = ${$elementName};
} else {
$this->selected = $currSelected;
}
Friday, September 3. 2004
Filtering by a parent object, such as a seciton, was previously a needlessly complicated process that involved setting up a parent filter and adding it to your main filter via add_parent, as show below:
$sectionFilter =& pxdb_search::filter(DATATYPE_SECTION);
$sectionFilter->add_value('id', $Request->getVar('in_section'));
$content_filter->add_parent($sectionFilter);
The latest CVS snapshot simplified add_parent by allowing it accept either a pxdb_search filter, a pxdb_record or descendant object, a numeric record id, or a record's idnum value. This makes it easier to filter by parent objects since any of the following are now valid calls. The add_parent() method will handle all the filtering internally.
$content_filter->add_parent( $Section ); // seciton is a pxdb_record descendant
or
$content_filter->add_parent( $Section->get_id() );
or
$content_filter->add_parent( $pxdb_record->get_field( 'idnum' ) );
Tuesday, August 17. 2004
When thinking about the architecture of a Syntax site, remember that just because someone may want a list of documents or events, it doesn't mean that ginning up a module and plunking it on the main navigation is the right answer. It has a lot of drawbacks:
- Your site navigation is not dynamic. This starts to resemble the Bad Old Days of static HTML. Once you pick a term, you're stuck with it. Never underestimate the psychological comfort that is had by having the option to change something, even if it's a bad idea to do it.
- Your page title is similarly static. This further resembles the Bad Old Days. It helps to get a project out the door when you can say "if you don't like it, you can change it." Again, this is true even if you've done killer information architecture and selected culturally appropriate and tested terms.
- You have limited options for dynamic text on the main listing page. You can embed a section call within the template through
F1CMS::module() (more on the power of that later), but that requires modifying not only the list template but also creating a custom template for each hidden section so it doesn't start listing other content items. Plus it turns your Section Navigation admin area into a nest of hidden sections that aren't really sections but content items. You could introduce a datatype that will function in that capacity, but that creates its own complications. How do you decide where each item will be published? Will you build its own module just for display?
Fortunately a much better option exists. You'll still have to create a custom section template, but it will be a logical, functional, and non-hidden section.
Continue reading "Sectional Thinking About Modules"
Monday, August 16. 2004
One of the cool features of Syntax, left over from its F1DB days, is the variable type field for each object.
The upshot is that, by default, when you use the type dbfield in an object, Syntax automagically looks for a picklist with the name of the datatype in it, in this format:
{name of object}types
So if you have a datatype called "article," the corresponding type picklist would be articletypes.
This is really useful, because it allows each datatype to have its own picklist of types--eventtypes, articletypes, puddingtypes--but only use one field in the master records table.
Otherwise, you'd have to make a new dbfield entry for each type you had, and they'd be available to other datatypes--which is silly when your datatype is blancmange and your list is puddingtypes (Blood, Yorkshire, Figgy).
However, with great power comes great responsibility. If you set up a new datatype and you choose to repurpose the type dbfield, you'll be up a creek.
But what if you'd like another such field?
Then you need to investigate the "Variable Table" feature of DBasis when creating that dbfield entry. So far, to my knowledge, it only accepts one variable:
$(objecttype)
The setup for the type dbfield is:
pickid variable table $(objecttype)types
Any text before or after $(objecttype) will be used when constructing the name of the pick table to look for. So my($objecttype)ingredients would result in myarticleingredients, myeventingredients, and of course, myblancmangeingredients.
Generally, of course, you'll find just the one default type dbfield more than sufficient.
Wednesday, August 11. 2004
I've updated the source code documentation to reflect the changes and additions we've made to get it ready for release.
Monday, August 9. 2004
For Sections, breadcrumb trail is automatically set based on the hierachy of sections and the page title is set to the last section in the trail. When you're working with modules, to add elements to the breadcrumb trail and set the page title you only need to do one thing: add a trail point to the Request object. Its probably best to only do this if the request is not an internal module request:
if (!$Request->isIncluded())
{
$Request->addTrailPoint( array( 'url'=>$_SERVER['REQUEST_URI'], 'crumb'=>$Record->get_field( 'name' ) ) );
include_once(SITE_TPL_PATH . '/header.tpl');
}
Wednesday, August 4. 2004
This post is mostly to test is the Images feature of serendipity is working. Below is a fuzzy screencap of the latest version of Context, the admin tool used in syntax cms. It has come a long way from ugly html table hacked layout to more CSS friendly layout. I particularly like the fact that content types with content waiting to be approved are bolded ala email programs. Of course, that may be because I added that feature.
|
|
