"framework" entries
Abstraction in web apps: an idea, not an ideology
Create the Web instead of colonizing it.
Some weeks ago, when it was still wintry in one half of U.S.A. and anything but in the other half, I encountered the following Tweet:
The old man seemed lost and friendless. “I miss static HTML,” he said.
— Jeffrey Zeldman (@zeldman) March 12, 2015
I’m grateful to call Jeffrey Zeldman a friend, seeing as he’s a terrific guy in addition to being one of the foremost doyens of web design. In that sentiment and with the wish to call attention to his lament, I replied:
@zeldman Story of my last five years, that. When did simplification & removal of dependencies become subversive?
— Ben Henick (@bhenick) March 12, 2015
…And now I get to unpack all of that, as briefly as possible.
Make magic with Ruby DSLs
Demystifying your favorite libraries' domain-specific languages
For better or worse, I believe you can develop basic, yet useful, applications in Ruby on Rails with just a minimum amount of Ruby knowledge. Rails tucks away details behind object-to-table mapping, routing, database preparation, and other necessities for web applications to function. So, is Rails magic? It may seem like something shady’s going on behind the scenes at first, but all of these examples are really just instances of well-designed domain-specific languages within the Rails framework.
A domain-specific language, or DSL, focuses on a particular problem set, or domain, instead of trying to be all things to all people. By contrast, typical programming languages like Ruby are general-purpose languages–they offer a large, varied set of tools to accomplish any number of tasks. Ruby itself is a great example of a general purpose language: You can use it to perform system maintenance tasks, retrieve data from external services, calculate statistics–not to mention, develop complex web applications. But what if you need to focus on a specific task, like running system backups, test-driving software development, or defining database migrations in a Rails application? This is where DSLs come into play.
There are two types of domain-specific language, as defined by Martin Fowler. An external DSL requires its own parser to process commands passed to it. The result is a language that will likely not look at all like the language it was implemented in. SQL, for example, is an external DSL. You interact with a database via a language developed specifically for creating queries–not in the language your database itself was written in.
A Birds-eye View with Lift
Organize and control content with the Lift web framework
Lift is a web framework built for the Scala programming language, running on the Java Virtual Machine. Version 2.5 recently shipped, and I’m highlighting features of the framework that I find appealing.
Last time it was transforms and REST services, and this time it’s two features around organizing and controlling access to content.
SiteMap
How do you manage the HTML pages on site? Maybe some pages are available to everyone, others require login or some condition for access, and often pages are grouped in some way. Lift has an optional mechanism for expressing all this in one place, and it’s called SiteMap. This is how it looks in code:
lazy val home = Menu.i("home") / "index"
lazy val poets = Menu.i("poets") / "list" submenus (
Menu("Larkin") / "a-z" / "larkin",
Menu("Tennyson") / "a-z" / "tennyson"
)
LiftRules.setSiteMap(SiteMap(home, poets))
We’ve defined a site made up of a home page, and pages for poets we like. Why is this a good thing?
First, it’s a pretty readable representation of the site in (compiler checked) Scala code. You can probably figure out that we have a page called “home” found at /index.html (or / as it’s usually known).
What might not be obvious is that Menu.i is using “home” as a key into your translation resources, meaning the link text will be the localized version—if you’re building an internationalized site. The link to the page can be generated by a Menu.builder, a snippet you can use on pages to give your users navigation of the SiteMap.
The second menu item is called “poets,” served up from a template called list.html. On the home page, the navigation snippet would give you a link to the “poets” page, but by default is smart enough to hide the submenus until you visit the list of poets.
SiteMap also performs access control: if you use SiteMap, HTML pages have to be listed in it to be accessed. It’s a simple line of defense, but you can improve on this by adding location parameters. These are rules for controlling access to a page.
Let’s say we wanted to only offer some content to customers paying for our premium plan:
val PremiumCustomersOnly = If(
() => false,
() => S.redirectTo("https://shop.example.org/") )
This is an if-then-else construct, made up of two functions. The first function is a test for what qualifies as a premium customer. It’s an arbitrary computation, and in this example it’s false, meaning nobody is a premium customer (in reality, we’d perhaps check a property of the logged user). If you nevertheless try to get to the page, the second function kicks in, and you’d be sent to our store front.
We can apply the “premium customer” rule to any part of the site, but we’re going to just restrict Tennyson poems:
Menu("Tennyson") / "a-z" / "tennyson" >> PremiumCustomersOnly
If you don’t like the >> method name, use rule instead. If you just don’t like this domain specific language (DSL), you can construct a SiteMap in longer-form method calls.
What’s great about SiteMap is the flexibility it gives you: if you can’t get the behavior you want out of the box, you can write custom functions and classes, and drop them into the SiteMap. If you want menus displayed in a completely different way, not handled by Menu.builder customization, you can write a different navigation snippet. Location parameter rules allow you to isolate logic, and combine them as needed to parts of your site.
eZ Publish: A CMS Framework with Open Source in Its DNA
Leading eZ Publish advocates look at what lies ahead for CMS programmers and users
There are a variety of options when it comes to content management. We’ve explored Drupal a bit, and in this email interview I talked to some folks who work with eZ Publish. It is an open source (with commercial options) CMS written in PHP. Brandon Chambers and Greg McAvoy-Jensen talk about how the platform acts as a content management framework, how being open source has affected the project, and what we should expect to see coming up for CMS in general.
Brandon Chambers is a Senior Developer at Granite Horizon, an eZ Publish integrator. He has 14 years of web development experience focused on open source technologies such as PHP, MySQL, Python, Java, Android, HTML, JavaScript, AJAX, CSS and XML.
Greg McAvoy-Jensen is a member of the eZ Publish Community Project Board. He also founded and is the CEO of Granite Horizon, and has been developing with eZ Publish since 2002.
Q: What problems does eZ Publish solve for users?
A: eZ Publish grew up not just as a CMS, but as a content management framework. It sports a flexible and object-oriented content model (an important early decision), and provides developers an MVC framework as a platform for building complex web applications and extending the CMS. Like any CMS it makes content publishing accessible for the non-programmer, and provides an easy editorial interface. eZ Publish does a fine job of separating content from presentation and providing reusability and multi-channel delivery. It targets the enterprise more than smaller organizations, so the software quality remains pegged at high standards, and high degrees of flexibility and extensibility continue to be required.
Q: How you feel being open source has affected the project?
A: Fourteen years on, eZ Systems is still firm that open source is in its DNA. This foundational commitment created a culture of sharing, and it attracts developers who prefer to share their code and to collaborate with others outside their organization for the benefit of their customers. Contributions flow in as both extensions and core code pull requests. The commercial open source model, similar to Red Hat’s, means the vendor takes primary responsibility for code maintenance and development, and derives its profit from support subscriptions, while leaving customizations to its network of certified partners. Because the source is open, organizations evaluating the software can have their developers compare the code of, for example, eZ Publish and Drupal, and make their own determinations. This, in turn, keeps the vendor accountable for the code: eZ engineers program knowing full well that the world can see their work.
Q: What distinguishes eZ Publish from other CMS options?
A: While there may be a thousand or so CMS’s around, analysts typically look at something more like 30 that are important today. eZ Publish fits into that group, most recently by inclusion on Gartner’s Magic Quadrant beginning in 2011. Not all open source CMS’s have a vendor behind them who both provides support and has full control over the code, a level of accountability required in enterprise applications. eZ is a great fit for particularly complex implementations, or situations where there is no assurance that future needs will be simple. And despite the complex customizations developers do with eZ Publish, they rarely interfere with upgrades.
eZ’s engineers recently became dissatisfied with the merely vast degree of flexibility they had built into the MVC framework, so they’ve now moved the whole system on top of the Symfony PHP framework. eZ Publish is now a native Symfony application, the only CMS to utilize Symfony’s full stack. This leverages the great speed and excellent libraries Symfony provides, and makes eZ easier to learn by those who are familiar with Symfony. Some CMS’s require many plug-ins just to get a basic feature set going on a site, but eZ Publish has long included granular security, content versioning, multi-language support, multi-channel/multi-site capability, workflows, and the like as part of the kernel.
Read more…
The Fluent Online Conference Preview
JavaScript power on display
As JavaScript and the Web connect more and more technologies, conversations grow broader and broader. While the Fluent conference is large enough to cover a broad range, we created a sampler of topics for the two-hour online conference I hosted with Peter Cooper last Thursday. They’re all very different talks, showing many paths you can explore.
Martha Girdler opened the show with a pure JavaScript talk, “this” in JavaScript: How It Really Works (at 6:38). She isolated the headaches I’d given myself the last time I used “this” with her discussion of sorting out the scope chain (at 14:34).
Next up was Wes Bos, demonstrating Hardware Access and Device APIs with JavaScript and HTML5 (at 23:30). As new APIs let JavaScript connect more deeply with the capabilities of the mobile devices we carry, he’s finding opportunities that go well beyond what we thought of as “the Web” even a couple of years ago. He demonstrated how access to the camera and microphone can let you treat the device as a motion detector, an unusual task for a web browser (at 44:07).
Pam Selle visited the server side, demonstrating Prototyping a la Node with Express (at 1:02:41). She showed how to quickly build a simple application for user testing, explaining how the testing worked as well as the code (at 1:14:17, though I really liked the discussion of anger in testing at 1:17:20).
Given the intense activity in JavaScript frameworks, we had to explore at least one. Brad Green and Shyam Seshadri, who just finished our AngularJS book, explored the Principles of AngularJS (at 1:23:35). The shift toward a model in which a framework “allows you to teach the browser how to understand these new components that you create” (at 1:27:08) reminded me that JavaScript isn’t just working with the browser lately. In many ways, it’s becoming a tool for adding capabilities to the browser instead. As they put it later (at 1:42:03), AngularJS is in many ways a meta-framework.
The video doesn’t quite capture the interactivity of the event, though you’ll get to see the questions speakers took from the audience over chat. For a much more intense encounter with JavaScript and the Web, please consider coming to the live version of Fluent, May 28th to 30th in San Francisco. We’ll have coverage of all of these topics and many many more.
[adrotate banner=”3″]