Test

Recall that I am a language nut.

GolfScript is a language built for the single purpose of code golf - solving a programming problem in the fewest number of characters, or strokes. ( Not lines, characters.) The two code golf venues where you'll see GolfScript are CodeGolf.SE (Which is not found at codegolf.se) and Anarchy Golf (which is extremely quiet, peaceful, well organized and automatically judged).

When I started hanging around CodeGolf.SE, I submitted all my golfs in J, an APL-like language with really mind-bending array-oriented, function-level features. But as short, dense and powerful as J is, my solutions ket getting beaten by even denser, more nonsensical-looking code in GolfScript, which I had never heard of. Here's an example of GolfScript:

@6?:yr) (f/s{][=p@s's}+>;4"#\vkec025:cu(

No, wait, that's a randomly generated¹ string of gibberish. This is actual GolfScript:

~\:@;0 1{.3$&{\@+\}{}if@@+:@;.+.3$>!}do;\;

( Thanks, Juan. )

So, for semi-obvious reasons, I kept at it with the J. See footnote 1 for an example of J, which can be quite lucid by comparison.

And I kept getting beaten, though mysteriously never on problems that involved floating point math. I looked at the GolfScript site... Looked at the builtins... Looked at the examples... And still didn't really get it.

Then, about a week ago, I finally caved and wrote some GolfScript.

GolfScript 101

Here's the official GolfScript tutorial. That glosses over how to run GolfScript, although it's almost trivial. You'll need Ruby installed, and you'll need GolfScript.rb saved somewhere handy. Also, you cannot provide input to GolfScript programs from the terminal, so you'll have to give it through pipes or redirection.

This article was published before it was finished, so I'm leaving it here to be continued at a later date...

1. The J code for generating random GolfScript looking-gibberish is "(u: (32+i.33), (91+i.36)) {~ ? (40) # 69". I'm really still a J guy.

Before jumping into the topic at hand, since this is my first "FLOG" post, let me introduce myself. My name is Matt Bieda and I specialize in web design conversion among my other development tasks.

In fact I really like design conversion; while I'm not the world's best web designer I do like to implement web designs in CSS and XHTML. Yes, I'm the nutty guy that will count pixels to get the slices just right.

So that's a little about me, hence a post on something fun with CSS... So let's get started.

Shiny Objects

A lot of modern web designs these days use what I call "shiny objects"; that is things that do nifty stuff to attract "ooh's and ahh's" from users. Many shiny objects are done using proprietary objects in Adobe Flash, or increasingly Microsoft Silverlight but the vast majority are still JavaScript or AJAX. Many of the latter are a combination of not just JavaScript procedures but CSS selectors and StyleSheets.

In the past (a subjective term depending on your browser) the developer had to rely on a lot of JS to play with shiny objects, even simple ones like buttons that would change when you hovered over them. And still today they often do so to create things like fly-out or drop-down menus. Not only that but one often had to modify routines in JS to handle multiple browser interpretations of the JS language. Although toolkits like jQuery, Melonic, Moo Tools and the like tend to make it easier on the developer, it can still be cumbersome to do some things in the browser, cross-browser, using the mash-up paradigm of JS and CSS.

Certainly when necessary, I like anyone else, use these tools to my advantage. But I also like to see what I can get away with using just CSS when appropriate. Usually (and specifically to this discussion) appropriate means not supporting moldy old browsers like the demon that is IE6. This is because modern browsers, even the normally-off-the-reservation MSIE these days (meaning IE8), are all getting really good at supporting CSS standards.

The :hover Selector

One of the tools that is becoming more useful in CSS 2 is the :hover selector. Most of you have probably seen this used on classes for the <A> tag, primarily in the form of "a:hover" along with "a:link, a:visited, and a:active" which are all specific to the <A> tag itself. Here :hover is often used to make the links do something nifty like change color or add/remove the underline etc... However :hover can be much more powerful, especially when used on any class or id selector, not just ones for the <A> tag.

Sticking with the good old <A> tag, there are some cool things you can do with :hover besides changing font properties. If you "display:block;" your <A> tag and position it relative with a set width and height, you can easily display a background image on the tag of the same dimensions. Then, using :hover you can replace the background image with something else when the user hovers the link. This is a super fast way to do button-like links using nothing but clean <A> tag markup using only one CSS class and two lines of CSS in your StyleSheet. No JS required.

The previous implementation is natively cross browser, even in crochety Mr. IE6, however the next one isn't.

Overflowing with Goodness

In CSS 2, you can use :hover on any class. So something like "div.mybox:hover" is perfectly legal. It works the same way it does on the <A> tag, when you hover you can swap or override many things on the base class. However something really special happens when you use :hover in combination with some simple mark-up, positioning statements and the "overflow" CSS selector.

Normally overflow is used as "overflow:hidden; or overflow:scroll;" to control content that would otherwise expand beyond the limits of the container. However you can use overflow to hide something using "overflow:hidden;" and then on :hover show it using "overflow:visible;" on the hover state. Under the right circumstances this can be very powerful and save a lot of JS programming using simple clean CSS. The reason is you can use it to create simple pop-up or fly-out menus or windows.

Consider the following classes and markup:

.mybox {
    display: block;
    position: relative;
    width: 100px;
    height: 50px;
    background-color: #00F;
    overflow: hidden;
}

.mybox:hover {
    height: 200px;
    overflow: visible;
}

.mybox h1 {
    display: block;
    position: relative;
    width: 100px;
    height: 50px;
}

.mybox .popbox {
    display: block;
    position: absolute;
    top: 50px;
    left: 0px;
    width: 150px;
    height: 150px;
    background-color: #000;
    color: #FFF;
}

~~~~

<div class="mybox">
    <h1>Hello World</h1>
    <div class="popbox">
         <ul>
            <li>What</li>
            <li>What What</li>
        </ul>
    </div>
</div>

In the above example the div "popbox" would not be visible normally because overflow is hidden and it is positioned 50px below "mybox" which is only 50px high. Now when you hover over the container "mybox" the overflow becomes visible and this would cause "popbox" to show along with the list it contains. As long as "mybox" has a z-index which is above its surroundings (or an object that contains multiple instances of "mybox" has a superior z-index) "popbox" will appear to pop-up on the page just like any JS version of same. Selectively using transparencies or alpha-blended PNG files you can do some nifty stuff with just CSS that those unaware would swear "had to be" done using JavaScript or even Flash.

Note that in the example I expanded the height of "mybox" to completely contain "popbox" this is not necessary. However it's good practice to do that because you can absolutely position the hidden item anywhere. Normally this might be a few pixels away from the container element to achieve a desired look, the only way for the user to be able to move their mouse from the hover area to the newly visible area is if there is an un-interrupted connection to it. If they're right next to eachother no expansion is needed. Also note that even if the hidden box is outside the specified bounds of the container element, thus far all modern browsers have interpreted this as being "over" the container element even if you aren't! This means your users can mouse over to the hover-visible item to read something, click something, scroll a panel, etc...

So some of you may have heard of the mythical CSS mega-menus or CSS flyout-navigation which use no JavaScript at all. The concept above is basically how those are done. It is important to note that they do not work in IE6 or older and do not work in mobile touch browsers like Safari in iPhone and iPad. However they are easy enough to disable using an override stylesheet that applies "display:none;" to the overflow:hidden; objects. In the cases where IE6 and mobile devices must be supported, creating alternate navigation which does not rely on the fly-out or drop-down menus can be extended to the mobile devices and versions of IE6 or older.

Real World Implementations

If you'd like to see actual implemented examples in "the wild" check out the following web sites:

http://www.asahq.org

http://www.orgsource.com

On both sites the mega-menus are pure CSS. On ASAHQ, internal pages have left-column navigation which has n-level nested flyout menus implemented in pure CSS. On .orgSource the home page has a visual feature with pop-ups that are implemented using pure CSS.

You can also look on our F648 site. The main navigation includes pure CSS drop menus for the Web Development, Managed Hosting, and Creative Services items.

So try it out for yourself and see what kind of cool pure CSS magic you can work out!

If you have used the Ektron API to pull a branch from the CMS Taxonomy tree, you may have noticed some unexpected results.  The taxonomy nodes are returned to you, ordered sequentially by the id assigned to the node upon creation.  Many times this order will not differ from the order of the items in the Workarea (if the default order has been preserved).  However, often the CMS admin will reorder the taxonomy into a specific order:

In the Workarea, under Modules -> Taxonomy -> {a specific tax category}
You can right-click 'Reorder' and choose 'Items' from the drop-down in the menu.  This will allow an admin to order the heirarchical display taxonomy items.

In this case, if you are pulling the taxanomy tree from the CMS via the API, you will produce a different display order than the Workarea.  To display the taxonomy items in their proper order, use the normal tax api but with SortOrder and SortDirection...

Dim i As Integer
Dim TaxAPI As New Ektron.Cms.API.Content.Taxonomy
Dim TaxRequest As New Ektron.Cms.TaxonomyRequest
Dim TaxData As Ektron.Cms.TaxonomyData

'where taxid is the id of the taxonomy branch
TaxRequest.TaxonomyId = taxid
TaxRequest.TaxonomyLanguage = 1033
TaxRequest.IncludeItems = True
TaxRequest.Depth = 1
TaxRequest.SortOrder = "taxonomy_item_display_order"
TaxRequest.SortDirection = "Ascending"

TaxData = TaxAPI.LoadTaxonomy(TaxRequest)

If TaxData.TaxonomyItemCount > 0 Then
For i = 0 To TaxData.TaxonomyItemCount - 1
'whatever processing is desired
Next
End If

From Ektron 7.5.2 onward, the taxonomy sort is available via the .SortOrder property.

Options are "date_created", "last_edit_date", "content_title", and "taxonomy_item_display_order"

This is my first entry for this programming-related blog, and there's really only one way I can open it.

My name is Jesse Millikan, and I am a language nut.

Have you ever been to a programming Meetup? I show up from time to time at the local Ruby and Python meetups, IndyAdobe, Indy Alt.Net and have been (once) to the local PHP meetup. Invariably, the first thing that happens at these meetups is the organizer says,"Okay, we're going to go around the room and I want each of you to justify your presence here." Joy.

Why am I here, anyway? Oh, that's right. "I'm here because I'm language nut."

And then... Some weak bit about what I do all day. "But... I do C# at work." "I'm a .NET monkey during the day." You can't really be a language nut at work. It doesn't take.

So you might think I would be a little bit bored doing .NET content management stuff all day. There's not a lot of language variety there, right? You've got C#, and then you've got VB.NET, which is C#. What else is there? Some XSLT, some Javascript, some HTML and CSS. The usual.

That's it, right?

Yeah. Basically. Pretty much. But... Well. Okay. It's just... Every time I do something in one of those languages, I end up using something that isn't just the language I thought I was working in. Like XML for config files. And all those complex bits of XPATH you need to keep your sanity while writing XSLT. Sitecore query and Fast query for finding sitecore items. Lucene query syntax for using custom indexes. Regular expressions for testing form values. CSS selectors for setting up stuff in jQuery. Fixing Emacs keyboard macros that didn't quite take.  .NET string formats. Specially formatted Sitecore fields. Markdown for using Stackoverflow. Powershell, globs, snippets.

I thought I was a C# monkey. Now I'm just confused. And probably overworked! I mean, I'm using twenty-odd languages now, and that's just my day job!

What's going on here?

Little Languages

Little Languages. That appears to be what.

The term is self-explanatory, mostly. A little language is a simple language for a narrow purpose. Sometimes you'd call one a domain-specific language, or a macro language, or a query language. Or something like that. But they're all small, and they're all there for a reason better than "We have to have a language to have a platform."

These things come in lots of flavors. You'll find these thigns where there's something that turns out to be just a little (or maybe a lot) too complicated to handle sanely in a so-called general language. A lot of the time, it has to do with searching and filtering. Sometimes it's templating, or macros, or math, or... Could be about anything, really. It it's complicated and doesn't fit nicely into an OO or procedural library, it's likely to end up as a little language.

And where there's a little language, the pain and tedium of using a not-terribly-good general language sort of fades away. The little language shoulders the load. Let me show you what I'm talking about.

The Zoo

XPATH

XPATH is used in XSLT to do searching and filtering operations, math, concatenation, and almost everything else useful with whatever data you have.

XPATH expressions tend to be really useful for building navigation elements in Umbraco and Sitecore (and anywhere else you have a hierarchical database that you can view as XML).

Want to build a breadcrumb?

The hard way is to start at your current node and recursively climb to the root of your site. Miserable. So, you write a template, call it recursively with the parent of the context and then write out the current link... And write out a separator before, no after, no, between the current... No, only if its... And then you have to call it with the maximum number of levels you want and there's xsl:param and xsl:with-param everywhere...

Miserable.

Here's the easy way (in Umbraco):

<xsl:for-each select="ancestor-or-self::* [@isDoc]">
<!-- link -->
<xsl:if test="position() != last()">
<!-- separator -->
</xsl:if>
</xsl:for-each>

There. Done. XPATH has this nice bit called axes and they do most of the heavy lifting when you're trying to write navigation.

Want to only show certain items in the breadcrumb according to the depth? Or halt at a certain level? Or exclude some non-displayed items from the breadcrumb based on a property? Easy. Just throw it in that XPATH expression.

XSLT

Okay, this one barely counts. Maybe it doesn't count. I included it in the list of "big" languages up top, didn't I?

But then, it doesn't have its own parser, except for the one parsing XPATH expressions; the rest is plain old XML. And it's for a very narrow purpose; it's only for transforming XML into other formats. 99% of the time, that means outputting simple HTML or XHTML.

And XSLT 1.0 is an awfully small language, not counting XPATH. Most of the power in XSLT is in XPATH, and the rest of the power of XSLT... Is also in XPATH. And then, there's some simplicity gained if you're outputting XML or HTML, because most of the time you just use the tags you want to spit out...

Sitecore Query & Fast Query

These two are loosely based on XPATH, but they're not XPATH. These are used exclusively for finding items in Sitecore. They are used mainly through the .NET API, but also in other little places - notably to set up filters for treelists, droptrees and so forth.

Sitecore query is the most complicated of the two, reflecting a great deal of the XPATH language but substituting sitecore item names for element names and tags. Axes, predicates and functions are still there.

Fast query is similar, but much slimmed down so that any fast query statement can be run as a SQL query against Sitecore's database structure. This makes fast query operations (usually) acceptably fast even in situations where you need to search the entire content tree for something.

Lucene Query Syntax

Lucene is an open source Java document indexing and searching technology. Lucene.net is the .NET equivalent used by sitecore for internal search indexing, and also made available by Sitecore for custom indexes.

Lucene recently proved to be very useful in building a cross-cutting taxonomy across a fairly large site.

The Lucene query syntax isn't essential; you can actually query an index at length through the .NET API using lots and lots and lots of classes.

But frankly, I'd rather just say

index.Search("keywords:'armadillo'");

than go through a bunch of instantiations.

Regular Expressions

People love to hate on RegEx. That's a discussion for a different day, certainly. I'm going to leave it that I like RegEx for what it's good at.

Anyway, you can use regular expressions for a lot of things, but what they're best at is digesting text in very simple formats, numbers, phone numbers, a useful subset of email adresses, simple ad-hoc protocols, that sort of thing.

You should never, ever use them to parse HTML or XML, or any language of any serious complexity.

Seriously. Don't do it.

CSS Selectors

It might seem unfair to call CSS selectors a little language. But, if you look closely at a lot of jQuery code, you'll very often see them being used to select elements outside of CSS. And there's certainly a lot of jQuery around these days.

From jQuery for designers:

$(function () {
    var tabContainers = $('div.tabs > div');
    
    $('div.tabs ul.tabNavigation a').click(function () {
        tabContainers.hide().filter(this.hash).show();
        
        $('div.tabs ul.tabNavigation a').removeClass('selected');
        $(this).addClass('selected');
        
        return false;
    }).filter(':first').click();
});

This code creates tabs (with an appropriate stylesheet). It's about 7 lines of code when you trim out the boilerplate. Look at what's doing all the work: CSS selectors. Wonderful.

Javascript is nice language, but it's not enough to make me write a bunch of loops and filters and finds instead of a single nice little CSS selector.

But then, what about CSS property lists? Those can be used separately from selectors too. In fast, considering that you use selectors separate from property lists, and property lists separate from selectors, most of CSS appears to just be the sum of two completely separate little languages, rather one single language!

Thusly

You begin to see how it doesn't effect my sanity so much that I supposedly spend all day working in the same one or two languages. My sanity is intact because, in fact, I don't. The little languages are here, keeping me company, walking by my side.

XPATH, I CHOOSE YOU!

I'm Jesse Millikan, and I'm a language nut. Even, apparently, at work.

Ektron released their Page Builder technology in CMS400.net version 7.6, and with it, a wealth of capabilities never before seen on the platform.  The immediate benefits were apparent, where developers could setup a simple template, program a couple of Ektron widgets, and then let content authors create their own pages! Voila, the ability to create landing pages and mini-sites was born...

However, at Foundation 648, we've been trying to make better use of this technology, making our web solutions even more dynamic.

Frequently, we are building websites that take advantage of Audience-Driven navigation and the use of multiple landing pages.  Each of these sites will have 5-10 templates, based on a common theme, but with their own navigation, their own content widgets, their own unique sub headers, etc.

Our old methodololgy would be to create a master page, then create master pages for each audience based on the main master page, then create content templates based on the audience's master page.  We would then assign the resulting .aspx page to a content folder in Ektron and all the content would be displayed in the appropriate audience template.  This would work well enough, but if the client wanted a different widget in a section, or wanted to change a sub header graphic, it would be time to open Visual Studio and make a change.

The "out-of-the-box" Page Builder system was great, in that you could create a Page where authors could control all the various elements on the page.  If you wanted to create a mini site, you could make copies of that page and customize the content for each page.

However, the problem became immediately apparent, what if you wanted to change a widget in the left column of the page and have it affect every page based on that layout?  Could you create a Page Builder Master Page?

Master Page Builder Template (Page Builder Page as a Content Template)

In comes Page Builder with a twist...  As we struggled with how to take advantage of this technology, a solution presented it self.  We would:

1. Create Ektron Page Builder Pages in a special folder within Ektron that would define the layout for each section of content
2. We would create a custom Ektron widget that essentially would act as a regular Ektron Content Block Control, recoginzing a dynamic parameter and loading that content
3. We would register that Page Builder Page as a template within Ektron
4. We would assign that template to that audience's content
5. The Quick Links for that content would then reference the Page Builder template and aliases would work correctly

Here are the details...

1.  Create Your Page Builder Page

Create your page builder page in Ektron, make sure you add a widget that will render an Ektron Content Block dynamically via the ID query string.

If you don't have one, go ahead and download this one.  Once you've added this, register it within Ektron and add it to your Page Builder Template.

Now, you have a Page Builder Page ready for dynamic content.

2.  Register Your Page Builder Page as an Ektron Template

Make note of the Page Builder Template and the Ektron Page ID from Step 1.  Then, in the Workarea, go to Settings -> Configuration -> Template Configuration.

Click 'Add' and in the 'Add New Template' dialog, enter the Page Builder Template + the Page Builder ID as follows:

PB-PressReleases.aspx?PageId=833

Do NOT check 'Page Builder Wireframe'.  Click 'Save'.

Now, you have a template that dynamically maps to your Page Builder Page!

3.  Assign the Dynamic Page Builder Template to your Content

Go to the content folder that contains the content blocks to be displayed in your dynamic template.  Click 'View' -> 'Properties'.  Click 'Edit Properties'.  Under the 'Templates' tab, add your dynamic Page Builder template to the list of templates and make it the default.  Click 'Save', then create your content.

If you go to the Library and view quick links, you'll see the links are formed appropriately.  The URL structure goes:

Page-Builder-Template.aspx?PageID=PBPageID&ID=ContentBlockID

If you create an alias for this content block, you'll see the URL is formed exactly the same!

With this technique in place, developers can take advantage of Ektron's Page Builder technology, while still giving content authors the more traditional, simple method of adding and managing content.  PLUS, these layouts can be managed completely with Ektron without needing to change code to add, subtract or edit layout components.

Enjoy...

At Foundation 648, we strive to empower our clients.  Either by the solutions we provide, or the information and knowledge we can impart.  In short, we want everyone whom we come into contact to benefit in some way, shape or form.

That's the idea behind "The FLOG".  We are constantly working within highly technical environments and applications to give our customers the solution they want. We often need tips and tricks on the various platforms we employ to get the job done.  We have benefited time and again from others who've freely published their problems and solutions, and we are "paying it forward" and doing the same.

"Freely you have received, freely give."

The Flog will be dedicated to publishing information that are bound to save someone hours of headaches.  These entries are the result of relentlessly beating a certain technology into submission (hence the term "Flog") and figuring something out that turned out to be beneficial.

We will concentrate on topics like:

• Ektron CMS400.net
• Sitecore CMS
• Google Search Appliance
• HTML / CSS
• Javascript
• XSLT
• Umbraco
• Telligent
• And more...

We will encourage all of our readers to submit comments and questions and if you're facing a technical hurdle, maybe you should contact us today and see if our team can help you out, like we do so many other clients.