Blog items tagged with "preview"

Integrating Bootstrap 4 into Exponent

TBootstraphe primary theme framework for Exponent CMS is Twitter Bootstrap, currently at version 3 (actually 3.3.7). The next Bootstrap release, version 4 should be available in the near future and is currently in the beta 2 stage. It would be good to integrate support for the Bootstrap 4 framework, but there are several obstacles:

  • Bootstrap 4 requires SASS/SCSS stylesheet compilation, where previous versions were based on LESS...and there is only one PHP based SCSS compiler available which chokes on some of our needed stylesheets. However, we've developed a 'hack' to compile them on the fly.
  • Bootstrap 4 also leans toward needing 'autoprefixer' support to add additional 'browser-specific' styles into the compiled stylesheets. There is currently no PHP based autoprefixer (except for some which require node.js be running on the server). This may not be an issue since most modern browsers are supposed to be moving away from vendor specific style properties.
  • Bootstrap 4 is a much greater departure (change) from the previous version (3) than in the past (e.g., v2 to v3). While not insurmountable, it will require updating a lot of Exponent code to produce compatible output for auto-generated form controls and menus, etc...

Now having said that, preliminary support for Bootstrap 4 (beta 2) is already being integrated into Exponent, which in turn also requires a new theme. Though the initial integration at this point is limited to functional navbars/menus and chrome, it is usable (if you can get past some of the odd styling on the page). It is expected this initial integration will be included in the next release of Exponent.

Once Bootstrap 4 is released as final AND we have fully integrated it with a functional theme, it will be released...most likely as Exponent v3. The roadmap to Exponent v3 will also throw off the shackles created by a need to support obsolete browsers and ancient PHP versions, both of which should not be used if security is of any importance. You can expect to see the next release of Exponent (either v2.4.1patch7, v2.4.2, or v3.0.0) around the end of the year.

About the author

Dave Leffler
Exponent CMS Developer

Offline Blog Post Editing

Writing Blog ArticlesExponent provides an excellent environment for writing and sharing articles or 'blogs'.  A site where the 'back-end' is on the front-end and a variety of what-you-see-is-what-you-get WYSIWYG editors take away some of the creative hassles with writing.  Another nice convenience for writing articles which is found on other blog applications (like WP), is editing the articles offline by using an application to manage and edit multiple blog articles.  Though there was preliminary support for this feature in the v0.99beta1 release (before v2.x), it has not been available to the v2.x code line...until now.  

Why would you want to use a desktop application to edit articles instead of simply using the browser?

  • Submitting the same or similar articles to multiple blogs or sites
  • Simultaneously working on many draft articles (beginning a new article while have several unfinished articles)
  • Not having immediate, unrestricted access to a reliable high-speed internet connection, but you have your PC

The new offline blog editing feature will be available in the next release (currently at v2.3.4patch1).  It will be turned OFF by default, but can be turned on using 'Site Configuration' under the 'Security' tab.  It has been tested with several offline blog applications (mostly Windows based) such as Windows Live Writer, Zoundry Raven, Blog2Post, Windows 2007+, and ScrybeFire running in the Chrome browser.  Most of these interface with the blog site by adding an account.  This account creation process attempts to determine the type of blog, but all require the following information.

  • user logon name (with create/edit permission to a blog module)
  • user password
  • url to the blog web page - www.mysite.org/my-blog
  • url to the blog xmlrpc interface (blog post url) - www.mysite.org/xmlrpc.php
  • type of blog - Metaweblog API (NOT WordPress, nor Blogger, etc...)
  • image/picture uploading handled by - the blog provider

During the process, the offline application attempt to determine the type of blog, but will likely need some assistance in completing the process.  You should be shown the list of all the blog modules on the site.  Most applications will require a separate account be created for each blog module on the site, where others may only display the first blog module listed from the site.

Many of these applications provide support for publishing the article or posting it as a draft, tags (adding new tags or selecting from existing tags), categories (adding new categories or selecting from existing ones), setting the article publish date, inserting graphics, boilerplate templates, downloading the site 'theme' for better offline previews, and turning off user comments.  Some of these features require they be turned on within that blog module.  You may even be able to pull down recent or all blog posts from that blog to edit or archive.

All-in-all, another tool in the Exponent CMS arsenal to assist you in maintaining and managing your web site.

Windows Live Writer

About the author

Dave Leffler
Exponent CMS Developer

More About Less

less cssCSS3Back in version 2.0.8 we added the LESS ​stylesheet compiler to Exponent.  LESS is a dynamic stylesheet language which extends CSS with dynamic behavior such as variables, ​mixins, operations and functions.  This functionality makes it much easier to create flexible stylesheets since redundant styles and style variations can be handled by the compiler/server instead of the designer.  Though this addition to Exponent was primarily to support Twitter-Bootstrap, its use is increasing especially beginning with v2.2.3.

In this article our focus is on creating or updating .less stylesheets.  For information on how to incorporate .less style sheets into your custom theme, module, or view, please see this help doc.  The use of .less stylesheets in place of .css stylesheets is transparent within Exponent.  

In version 2.2.3 we convert all our core css stylesheets to .less, since we now also have custom 'mixins' to do some of the heavy lifting.  Mixins allow you to tie a bunch of properties and customizable values all into one nice little package.  Here’s an example:

/* Mixin */
.box-shadow (@x: 0px, @y: 3px, @blur: 5px, @color: #333) {
  -webkit-box-shadow: @x @y @blur rgba(0, 0, 0, @color);
  -moz-box-shadow: @x @y @blur rgba(0, 0, 0, @color);
  box-shadow: @x @y @blur rgba(0, 0, 0, @color);
}

This takes all of the box-shadow code needed for display on multiple browsers and wraps it up nicely into a single mixin that can be implemented with custom values (or the defaults that we used above). Now, instead of writing a huge chunk of code every time you want a box-shadow, this is all you need:

/* Implementation */
.somediv {
  .box-shadow(5px, 5px, 6px, #eee);
}

Pretty awesome right? When this code is compiled automatically by Exponent, it’ll create a the appropriate CSS stylesheet. You get a much more readable code without sacrificing browser compatibility.

In v2.2.3 we include a custom 'mixins' file which is located in /framework/core/assets/less/exponent.less.  This mixn may be included in your .less file by adding the following line to the top.

 @import '/framework/core/assets/less/exponent.less'

Here are some of the mixins found in exponent.less:

  • .border-radius and .border-radius-custom
  • .box-shadow and .drop-shadow
  • .gradient and .quick-gradient
  • .reflect
  • .opacity

Take a look at exponent.less to see all the included mixins, plus some implementation samples.

I think you'll appreciate how LESS can make your work 'more' productive and will consider using it in your next project.

About the author

Dave Leffler
Exponent CMS Developer

Permit me to tell you a little about the next version

While v2.2.3 (when released) will focus on addressing issues in v2.2.2 and removing all the deprecated features and 0.9x compatibility, there will be a few minor new features and changes to the permissions system (final implementation will be based on your feedback to this article!).

New features include adding a 'copy' item command to the portfolio module, adding an optional 'force image resize' during a quick upload, and better theme support for mobile devices by use of optional 'touch' icons and the 'meta viewport' tag.  We may also be able to squeeze in a 'multi-day' feature to the event module along with external calendar (ical & google xml) feed caching.

However, the bigger changes will be to user/group permissions.  This will be accomplished by the addition of group global permissions (restrictions) and changing the way we deal with the 'create' permission.

Group Global Permissions - This new feature provides greater control over what basic users are allowed to do (or more accurately 'are prevented from doing').  These restrictions will be implemented within a 'User Group', therefore the 'user' must be assigned to a 'group' in order to enforce these 'global permissions'.  However, this method will ensure that upgrading from a previous version will continue to operate transparently the same as before.  But if you want to apply them to all basic users, you can set the group as a 'default group' to be assigned to all new users.  Based on user requests, Global Permissions/Restrictions already include:

  • Prevent File Uploading - will prevent the user from being able to upload a new file.  They will still be able to select existing files from the file manager.
  • Prevent User Profile Changes - will prevent the user from being able to change their user profile (email address, profile extensions, etc...)  This does NOT affect the user being able to change their password since we already have a global setting to 'disable user password change requests' in the Site Configuration settings.
  • Disable Slingbar (Exponent Menu Bar) or Slingbar menus - will  'hide' the 'Exponent', 'Files', and/or 'Pages' menus from the user (leaving only the 'User' menu).  Or you can select to hide the entire 'Exponent Menu Bar'.  Under normal circumstances, a user with any permission on the site would see the 'slingbar.'  This feature allows greater control on preventing it's display.

Enhanced 'Create' Permission - Unlike the group global permission feature, the enhanced 'create' permission feature may affect some users ability to perform actions after a version upgrade!  Currently (v2.2.2), the 'create' permission also always implies/provides the 'edit' permission.  This means that if you can create new module items, you will also be able to edit all module items (but still requires a 'delete' permission to remove the item).  However under the new (v2.2.3) system, the 'create' permission would be separate from the 'edit' permission.  What's NEW is that the 'create' permission (without an 'edit' permission) would also allow you to edit any module item you had created (no change here), but NOT the other users' module items.  To edit other users' module items, you'd also need to have an 'edit' permission.  The same applies to deleting a module item.  If you have a 'create' permission, you may delete a module item you created, but would need a 'delete' permission to delete other users' module items.  In practice, this new feature will allow a module to have many users who are able to create and manage their own items, but not have any influence on the other module users (unless you also gave them an 'edit', 'delete', or 'manage' permission).

As a permissions primer...permissions cascade down through any child objects such as pages, containers, and the module.  The 'manage' permission implies/provides ALL permissions.  The 'configure' permission is needed to access module configuration settings (change the module's action, view, and other module settings).  The 'create' permission is needed to create new items or modules (and up to v2.2.2 also provides an 'edit' permission).  The 'edit' permission is needed to edit an existing module item.  And the 'delete' permission is needed to delete/remove an item or a module.  Admin users are always granted permission!

While this new approach to the 'create' permission should greatly enhance a multi-user site, it is not a complete solution.  There are some scenarios where a user would be allowed to 'create' a new module item, but NOT edit it (invoices, etc...).  It is recommended the developer create a new module controller method/add_permission for that instance.  Creating a stricter permission system would be very complex and time-consuming to implement.  However, there are plans to implement some 'workflow' features such as 'revisions' (allow rolling back to a previous item version) and 'approvals' (optionally require a user with approval permission to approve new or updated content).  These workflow features would not be as complex as those partially implemented in the 0.9x code, but should become very useful.  The workflow features are targeted for the v2.2.4 release.

If you have any suggestions to the above features especially the Group Global Permissions and Enhance Create Permission, please respond with a comment.

About the author

Dave Leffler
Exponent CMS Developer

Facebook and Tweet Integration in v2.2.1

FacebookTwitterThe next release will introduce a new 'Facebook' module and optional Facebook 'Like' and Twitter 'Tweet' buttons to blog posts.  

The new Facebook module will allow you to insert a 'Like' button onto a page which points to the site, the page, or a custom url.  It will also allow you to insert a 'Like Box' (or timeline) onto a page.  These views interact with Facebook to display results from Facebook, and also update 'Likes' on Facebook.  There are several display options which reflect the same options offered by the widget on Facebook.com.

Blog posts may now optionally display Facebook 'Like' and/or Twitter 'Tweet' buttons at the bottom of each post.  These features should allow greater proliferation of your ideas and works.

Additionally, we've added a new optional 'Follow' button to the Twitter module view, and there will be a new (optional) user profile extension which allows creating a 'signature' which is automatically attached to the end of blog posts you create.

About the author

Dave Leffler
Exponent CMS Developer

The 'Wizard' Returns to Exponent

The WizardOne feature which didn't make the move from Exponent 1.x to 2.x was the 'Wizard'...essentially a sequential set of forms.  Well 'ta-daaa', we're planning to have a wizard or paged-form feature in the next release (already in the 'develop' code branch)!  This will be a much simpler implementation than available in 1.x, as a 2.x paged form can easily be designed all in one place, instead of having to create separate form pages, etc...  This feature will be available in both the forms module/site forms (event registration now uses site forms) and in templates/views.

You may be asking, 'how does a paged form or wizard work?'  Well in many of the system forms, we use 'tabs' to segregate collections of input, and recently also introduced 'groups' to further segregate sets of controls on a page/tab.  These will still be used in most cases, but in some scenarios a sequential or progressive set of controls is more intuitive.  This is more evident in a complex form requiring a great deal of customer input such as a 'camp registration and release' form.  On the other hand, the 'site configuration' form is NOT intended to be sequential and would be practically unusable if it did not remain as a tabbed form.

How will a paged form work in Exponent?  In the form designer, it will be as simple as adding a 'form page break' control as the first/top control, and placing one where ever you want to begin a new 'form page'.  Exponent will do all the heaving lifting from that point.  If you want to revert to a standard form, you'd simply remove/delete the page break controls from that form using the form designer.  In practice a paged form would have at least two page breaks (including the top one) with one or more being the break(s) between the different pages.

The result will then look something like this.  Exponent performs input validation on all visible controls prior to moving to the next 'page.'  And as the development code matures prior to the next release, we will likely add form module configuration settings to enable/disable certain features like the 'page' description (Basic Information, etc...) appearing below the 'page' caption (Step 1, Step 2, etc...) AND also at the top of the current 'page', etc...

How will a paged form work within a template/view?  In the simplest sense a 'paged' form is simply one with controls grouped inside 'fieldsets' and then a jQuery plugin is used.  The {form} block function has been updated to accept a new 'paged' parameter which now also requires you pass an 'id' or 'name'.  Then within the form you group pages of control with the 'page' block with a required 'label' and an optional 'description' param.  Let's take a module view (mass-mailer) that is currently coded like this:

    {form action=mass_mail_out}
        {group label="Send this Message To"|gettext}
            {control type="checkbox" class="emailall" postfalse=1 name="allusers" label="All Site Users?"|gettext value=1 description='Uncheck to allow user/group/freeform selection'|gettext}
            {control type="checkbox" postfalse=1 name="batchsend" label="Batch Send?"|gettext value=1 checked=1 description='Hide email addresses from other users'|gettext}
            {userlistcontrol class="email" name="user_list" label="Users"}
            {grouplistcontrol class="email" name="group_list" label="Groups"}
            {control type="listbuilder" class="email" name="address_list" label="Other Addresses" size=5}
        {/group}
        {group label="Message"|gettext}
            {control type="text" name="subject" label="Subject"|gettext}
            {control type="html" name="body" label="Message"|gettext}
            {control type="uploader" name="attach" label="Attachment"|gettext description='Optionally send a file attachment'|gettext}
        {/group}
        {control type="buttongroup" submit="Send"|gettext cancel="Cancel"|gettext}
    {/form}

a 'paged' version (if we wanted one) is easily created and would be coded like this:

    {form action=mass_mail_out name='mass-mail' paged=1}
        {page label="Send this Message To"|gettext description="Select Recipients"}
            {control type="checkbox" class="emailall" postfalse=1 name="allusers" label="All Site Users?"|gettext value=1 description='Uncheck to allow user/group/freeform selection'|gettext}
            {control type="checkbox" postfalse=1 name="batchsend" label="Batch Send?"|gettext value=1 checked=1 description='Hide email addresses from other users'|gettext}
            {userlistcontrol class="email" name="user_list" label="Users"}
            {grouplistcontrol class="email" name="group_list" label="Groups"}
            {control type="listbuilder" class="email" name="address_list" label="Other Addresses" size=5}
        {/page}
        {page label="Message"|gettext description="Email Content"}
            {control type="text" name="subject" label="Subject"|gettext}
            {control type="html" name="body" label="Message"|gettext}
            {control type="uploader" name="attach" label="Attachment"|gettext description='Optionally send a file attachment'|gettext}
        {/page}
        {control type="buttongroup" submit="Send"|gettext cancel="Cancel"|gettext class='finish'}
    {/form}

As with all pre-release code, the specifics listed above are subject to change prior to the actual release.

We've also already added another 1.x feature missing in 2.x...'Configuration Profiles' which allows backing up and restoring the current site configuration (on the server).  This becomes really handy in a test or development environment as you can very quickly switch between databases and themes to test a new feature or customization.

About the author

Dave Leffler
Exponent CMS Developer

v2.2.0...Is it worth the upgrade?

Since v2.2.0 is classified a 'major update' to Exponent, you may be hesitant to consider upgrading your sites.  Although in reality it is simply the next incremental version update, it does mark a milestone in the maturity of the Exponent 2.0 code.  Here are some immediate and long term benefits to updating to version 2.2.0 once the stable version is released in the near future:

  1. As always, a new version means many issues (bugs) have been fixed, and many new features will have been added.
    • For example, as web browser versions are updated more often than ever, an Exponent web site will now offer features to take advantage of new browsers and devices (e.g., html5 forms)
    • There is also a new html5 media player which will work on non-Flash enabled devices, unlike the Flowplayer module.
    • We've also put a lot of work into getting the e-Commerce module(s) working out-of-the-box, including a new sample store database which can be included during installation.  We've especially polished the event registration and donations modules.
    • There are also some new views for the blog module which now offers optional category support.  Additionally, there is a new sample blog database available during installation which automatically creates a new wp-like site.
  2. Once you've gotten your custom theme over the 'v2.2.0 hump,' there shouldn't be any custom theme changes required for future updates since we'll have finally eliminated all of the old 1.0 code.
    • Since the initial release of v2.0.0, a couple version updates have required custom themes be updated to continue working.  This was primarily due to the deprecation and replacement of old 1.0 code or modules needed for that original release.  Therefore, since all the old 1.0 code has been removed in the v2.2.0 release, we don't anticipate any major format changes which would require a custom theme update to work with future releases.

We anticipate releasing a stable v2.2.0 by the end of May 2013.

About the author

Dave Leffler
Exponent CMS Developer

Upcoming Major Version Release Strategy

The remnants of 'old school' Exponent are numbered...meaning very soon we'll no longer be strapped to the modules, subsystems, etc... of Exponent 0.9x that were necessary to get Exponent 2.0 up and flying.  For the most part, we've been able to disguise the great differences between the 0.9x coding architecture and the 2.x MVC coding architecture.  This was done by updating some of the  old school (0.9x) module admin interfaces to look (and act?) similar to the 2.x modules.  However this was done at some (resource) cost, and the complexity of having to deal with two different animals.  Therefore we'll modify our release and development strategies to best accommodate existing installations, yet not restrict such a bold move into the future!  What follows are some notes to Administrators/Designers and another set to Developers about how this will occur.

For Administrators/Designers - Putting out less-than-stable code for the upgrade of a production server is NOT what any administrator or user would expect, nor want to hear.  However, moving to a fully updated 2.0 system (no old school code) would likely temporarily disable some sites, and may diminish the stability of a running site.  That is, until some custom features (like a theme?) are upgraded on that site.  So how can we maintain stability (a stable code release line), yet vastly change the way things work (implement a major change without stagnating the release flow)?  By moving to a parallel release/development strategy!

What this means, is that while there will be many bug fixes and feature additions found in the next release (v2.1.1), it really won't be different from many of the releases over this past year (though looking back, some of the releases since 2.0.0 stable could be considered to have required major changes).  And you can likely expect at least one more (late spring?) release in like manner (v2.1.2), but it may likely be the last of the 2.0/2.1 line.  However, even that will NOT be a dead end, because it will be an easy move into the 'next' version (v2.2).  Version 2.2 will leave 0.9x (old school) compatibility behind, but will continue to be backwards compatible with any v2.x themes, modules, etc...  So things like any lingering old school modules (the ones found in the /framework/modules-1/ folder) or calls the old school theme compatibility layer (exponent_theme_xxx) will simply NOT exist (meaning the page will probably crash/break)!  However, things like YUI2/YUI3 (javascript/styling library) will still be fully available, but begin moving into a background role.  What will take front, center stage will be a reliance on 'Twitter Bootstrap' (styling library) and 'jQuery' (javascript library)!  We may also leave PHP v5.2.x compatibility behind since v5.5.x is about to be released and the use of v5.3 itself is no longer recommended.  The biggest change found in v2.2 will be a moderate change to the database which will prevent regressing to an earlier version (except by using an EQL backup)!  In fact, installing the v2.2 code on an existing site will give you the impression the site was wiped out...until you run and complete the 'upgrade/install' process!  So the big question is how can we move from a fully stable v2.1.2 to a fully stable v2.2?

Well the answer is to have both a stable release line (v2.1.x) and an unstable pre-release line (v2.2.x) running simultaneously.  In some respects, we already do this with the stable release ('master' branch of the git code repo) and the working development code ('develop' branch of the git code repo).  The BIG departure will be that unlike the 'develop' branch which is updated moment by moment and may be broken at times, the 'unstable' release will only be created as needed and should be a working set of code.  Therefore, when you see v2.1.1 hit the street in the near future, you can expect the release of v2.2.0-alpha1 almost simultaneously.  Any changes made to the v2.1.x line will also appear in the v2.2.x code, so if there are any future updates to the v2.0/2.1 line, it'll already be in the v2.2 code.  Then once v2.2 becomes stable, the v2.0/2.1 line would only receive critical patch updates, with the intent being a move to the v2.2 line.

This strategy should allow for the stability needed by most production sites, and yet allow (early) access to new features in a somewhat less than 'bleeding edge' manner.  For all intents and purposes, v2.2.0-alpha1 should be fully functional, but will NOT have been tested under many scenarios.

For Developers - Most of the changes will affect how we develop and release software updates, but primarily how we manage code branches.  Though these won't be much different from how we've been managing code using the Git-Flow paradigm.  For the most part, 'master' will (always) still be the most recent stable release.  'Develop' will still be the primary place for code updates to the stable release...in this case prep for a possible v2.1.2, but NOT the move to Twitter-Bootstrap, nor the Container 2.0 changes.

The big change however, will be the creation of several new branches of code in the git repo.  There is already a new branch called 'feature/container2' which will become v2.2.0-alpha1.  It already holds container 2.0, Twitter-Bootstrap, and a new bootstraptheme.  These are the major changes slated for v2.2.0.  The 'feature/container2' branch will be updated (merged) from the 'develop' branch on a regular (daily?) basis.  Conversely, the 'develop' branch will NOT be updated from 'feature/container2' until just prior to the release of v2.2.0 (stable).  We may also create a new 'hotfix' branch based on master AFTER the release of v2.1.1.  It will be where any fixes for v2.1.1 would be coded and will be merged/updated into 'develop' (which in turn is merged/updated into 'feature/container2').  We will also create an 'unstable' branch as a substitute for pulling from the the repo using a tag like v2.2.0-alpha1.  And as always there will be temporary (release testing) branches created between a code freeze and code release, which also includes any alpha and beta releases.  Therefore, there will be several branches of code in the Exponent git repo:

  • master = most recent stable release (currently v2.1.0)
  • develop = changes/updates slated for the next stable release (currently v2.1.1 pre-release).  It will hold any changes planned/needed for the v2.1 (2.0) line.
  • feature/container2 = work on the next major release v2.2.0, updated from 'develop' regularly.  Will exist until AFTER v2.2.0 stable is released.  At that point, 'master' would then hold v2.2.0 stable (the most recent stable release at that time), and all code work would move to the 'develop' branch.  This branch can be thought of as the develop branch for v2.2.0 until it is stable.
  • hotfix = fixes need for the most recent stable release.  Any work here wil1 eventually becomes a patch release to the current stable release.  'develop' is updated from this temporary branch.  We will automatically create a 'hotfix' branch once v2.1.1 is released to hold any fixes that need to be applied to v2.1.1.
  • unstable = snapshot of 'feature/container2' at time of most recent unstable release, which is a substitute for pulling from the repo using a tag like 'v2.2.0-alpha1' or 'v2.2.0-beta1'  This makes it easier to update/test on a site using git pull instead of the unstable package release.

So, if you want the most recent stable release, you'd pull from the master branch.  If you want the most recent unstable release (alpha, beta, release candidate, etc...), you'd pull from the 'unstable' branch.  If you want the pre-release of the next stable version, you'd pull from the 'develop' branch.  And if you want the bleeding edge code, you'd pull from the 'feature/container2' branch.

For the most part this is a tried and true approach. It only seems new, because we didn't have a stable branch to deal with when we were working toward the first stable release of v2.0.0 .  Most likely things will work there way back to how we operate now once v.2.2.0 is released as stable.

About the author

Dave Leffler
Exponent CMS Developer

(updated) Two Column Forms (or something like that...)

(Updated Aug 2nd) We've had several requests lately to 'make forms look like they did in versions prior to v0.97.'  Meaning, place the label and input control on the same line instead of the label above the input control.  Since we're trying to move away from using tables to format the layout (the html5 way of doing things), it's not an easy fix, HOWEVER we can simulate the look using css styles.  (NOTE: we have implemented a Single column/Two Column form settings option in the next version 2.0.9 which will easily implement this feature)

Forms in 2.0

Forms in 0.96

Restyled Forms in 2.0

Though you won't necessarily end up with an exact reproduction, it will look similar.  One drawback is the width of the label is a hard width and will truncate long labels.  This more robust styling below prevents the label truncation.  Enter/Change this into your theme stylesheet: (updated Aug 2nd)

.control  {
    overflow: auto;
}

.control .label {
    display: block;
    float: left;
    width: 150px;  /* non-flexible part truncates label */
    text-align: right;
}

.control.radio .label {
    width: auto;  /* make radio buttons look normal */
}

.control.checkbox .label {
    width: auto;  /* make checkboxes look normal? may not be needed */
}

.datetime.date, .control table, .control.radiogroup table, .control.radio table, .control.checkbox table {
    display: inline;
}

.control-desc {
    margin-left: 160px;  /* make description fall directly under input */
}

.formmoduleedit .item-actions {
    display: inline;
    float:  right;
}

 

About the author

Dave Leffler
Exponent CMS Developer

The Shape of Things to Come?

In recent conversations in the #exponent-cms irc chat on irc.freenode.net we’ve been discussing how best to maintain Exponent using the most current software technology.  Though Exponent has been based on YUI (Yahoo User Interface) for years, there are more commonly supported libraries which might be worth considering.  Some of these have familiar names in the developer community such as ‘jQuery’, ‘Twitter-Bootstrap’, and the ‘LESS’ css stylesheet compiler.  What’s more, several aspects of YUI are currently broken and unusable in Exponent (e.g., we ship v3.4.0 because newer versions such as v3.4.1, v3.5.x and the soon to be released v3.6.x break our displays).  (Rest assured, we'll maintain backwards compatibility) So here’s where Exponent MIGHT go within the next several releases.

The LESS css stylesheet compiler will likely be implemented and ship with v2.0.8, though not necessarily in its final configuration.  LESS allows a designer to create stylesheet templates with variables and other programming commands to allow the ‘machine’ to do most of the work rather than the designer needing to continually re-write redundant styles.  More information can be found at http://leafo.net/lessphp.  You will be able to fully use .less files in v2.0.8, however their location MAY have to be moved and their inclusion statements MAY need to be edited in future versions once we finalize support.

jQuery is a javascript library similar to YUI, but is designed for smaller projects.  However, it is more widely used and supported across the developer community.  If you were to browse the internet for examples of coding solutions, you’d most likely see several based on jQuery and very few solutions based on YUI.  There are tons of interface add-ons and other solutions available for jQuery.  More information can be found at http://jquery.com/.

Twitter-Bootstrap is a new user interface library of components and styles similar to YUI .  It uses both jQuery & LESS.  In many ways it is much simpler to implement than YUI and is more responsive to various display sizes without the need for multiple stylesheets or themes.  More information can be found at http://twitter.github.com/bootstrap/.
We already have locally running copies of Exponent using these technologies in the form of a custom theme which could easily be dropped into an existing v2.0.8 installation if desired.  So a future version of Exponent with a Bootstrap theme could look like this:

About the author

Dave Leffler
Exponent CMS Developer