Archive for the ‘frameworks’ Category

The Context object in Symfony can cause hassles

Monday, August 24th, 2009

This summer I worked on a project where some other programmer had used the Context object in the model classes. This caused ridiculous problems. For instance, to run the command line tools (such as “symfony propel:build-model”) I had to hard-code the loading of a context object into the core classes – what an ugly hack!

So I was intrigued to read of the problems that the Context object can cause in your form classes, and how dependency injection gives us an easy way to avoid needing the Context object.

You might read that and think “woah, this is getting complicated!” but we’re not talking about dependency injection containers here, we’re simply saying that you can make your form object depend on something to run. The thing it depends on should not be the context singleton, it should be the minimum thing that the form needs to operate correctly – which in this case, is a user object that supports credentials.

…The test here is where we are making this form “dependent” on a user object. In this case we are insisting that the object is an instance of sfUser, which you may argue is tying us in to symfony again, but you could use any test here to ensure that the object will have the necessary functionality you need, maybe check for the existence of a “hasCredential()” method for example.

When writing a test for this form class, we now only need to instantiate a user object and load it with some credentials – much easier than doing the same thing and locking into a context singleton. There may be other times when this form could be useful in a lightweight environment, where you can get speedy access to a user object but don’t want the overhead of the symfony context – you might not think of one now, but it’s best to code this way and you’ll have less reasons to kick yourself further down the line.

The explosion of Java frameworks

Tuesday, July 28th, 2009

Having read a little about Apache Wicket, I wanted to learn more, so I went to the website. I was surprised by their list of Java frameworks:

Echo
Cocoon
Millstone
OXF
Struts
SOFIA
Tapestry
WebWork
RIFE
Spring MVC
Canyamo
Maverick
JPublish
JATO
Folium
Jucas
Verge
Niggle
Bishop
Barracuda
Action Framework
Shocks
TeaServlet
wingS
Expresso
Bento
jStatemachine
jZonic
OpenEmcee
Turbine
Scope
Warfare
JWAA
Jaffa
Jacquard
Macaw
Smile
MyFaces
Chiba
JBanana
Jeenius
JWarp
Genie
Melati
Dovetail
Cameleon
JFormular
Xoplon
Japple
Helma
Dinamica
WebOnSwing
Nacho
Cassandra
Baritus
Stripes
Click
GWT

Damn. How can anyone keep up? And that’s just plain Java frameworks. They are, apparently, not counting web frameworks like Grails, written in Groovy, which runs on the JVM.

There are so many languages, so many frameworks, so much new stuff. It has become impossible to make any pretense of choosing the “best” technology for a job. Rather, we are all subject to circumstance now, the accidents of our lives that bring us into contact with a particular technology at a particular time. This has always been true, but it beomces more obvious to me when I see a list like this.

This part of what Wicket says about itself has some appeal to me:

Most existing frameworks require special HTML code.

JSP is by far the worst offender, allowing the embedding of Java code directly in web pages, but to some degree almost all of the frameworks from the list (except Tapestry) above introduce some kind of special syntax to your HTML code.

Special syntax is highly undesirable because it changes the nature of HTML from the kind of pure-and-simple HTML markup that web designers are familiar with, to some kind of special HTML. This special HTML can be more difficult to preview, edit and understand.

Wicket does not introduce any special syntax to HTML. Instead, it extends HTML in a standards-compliant way via a Wicket namespace that is fully compliant with the XHTML standard. This means that you can use Macromedia Dreamweaver, Microsoft Front Page, Word, Adobe Go Live, or any other existing HTML editor to work on your web pages and Wicket components. To accomplish this, Wicket consistently uses a single id attribute in the Wicket namespace (”wicket:id”) to mark HTML tags that should receive special treatment by the toolkit. If you prefer not to render Wicket namespaced tags and attributes to your end-users, Wicket has a simple setting to strip them all out, resulting in ordinary, standards-compliant HTML.

No “special sauce” in your HTML means designers can mock up pages that you can use directly in development. Adding Java components to the HTML is as simple as setting the component name attribute. And you can then give the HTML back to your web designers knowing that they can change it with confidence.

Wicket, more than any other framework gives you a separation of concerns. Web designers can work on the HTML with very little knowledge of the application code (they cannot remove the component name tags and they cannot arbitrarily change the nesting of components, but anything else goes). Likewise, coders can work on the Java components that attach to the HTML without concerning themselves with what a given page looks like. By not stepping on each other’s toes, everyone can get more work done.
Existing frameworks are not easy.

Most of the existing toolkits have poorly defined or non-existent object models. In some cases, the model is defined using special XML syntaxes. The syntaxes may be so cumbersome that special tools are required to manipulate all the configuration information. Since these toolkits are not simple Java libraries you may or may not be able to use your favorite IDE tools such as editors, debuggers and compilers.

Wicket is all about simplicity. There are no configuration files to learn in Wicket. Wicket is a simple class library with a consistent approach to component structure. In Wicket, your web applications will more closely resemble a Swing application than a JSP application. If you know Java (and especially if you know Swing), you already know a lot about Wicket.

Left JOINs with Propel in Symfony

Sunday, July 26th, 2009

Here is the stupid, clumsy way that I tried to do a LEFT JOIN in Symfony:

$query = ”
SELECT bailiwick_question.*, count(bailiwick_answer.id) AS howManyAnswers
FROM bailiwick_question LEFT JOIN bailiwick_answer
ON bailiwick_question.id = bailiwick_answer.question_id
WHERE bailiwick_question.end_at > ‘” . date(’Y-m-d h-i-s’) . “‘
GROUP BY bailiwick_question.id
ORDER BY howManyAnswers desc
“;

$connection = Propel::getConnection();
$this->questionStatement = $connection->prepare($query);

$this->pager = new statementPager(null, 10);
$this->pager->setStatement($this->questionStatement);
$this->pager->setPage($request->getParameter(’page’, 1));
$this->pager->init();

Here is the way someone much smarter than I re-wrote the code:

$c = new Criteria();
$c->addJoin(BailiwickQuestionPeer::ID,BailiwickAnswerPeer::QUESTION_ID, Criteria::LEFT_JOIN);
$c->add(BailiwickQuestionPeer::END_AT, date(”Y-m-d h-i-s”), CRITERIA::GREATER_THAN);
$c->addSelectColumn(’bailiwick_question.*’);
$c->addGroupByColumn(BailiwickQuestionPeer::ID);
$c->addDescendingOrderByColumn(’COUNT(bailiwick_answer.id)’);
$questions = BailiwickQuestionPeer::doSelectStmt($c);

How to do pagination in Symfony

Tuesday, July 22nd, 2008

Our new client is Bluepie. We are working on a project that is being built using the Symfony project. Today I had to figure out how to do pagination in Symfony. This short article was superb.

The Second Road gets mentioned in the press

Monday, June 9th, 2008

Our biggest project of the last 8 months has been The Second Road. This site is built on top of the framework that I started developing back at Category4.com (which they released as open source). We had a big roll-out on May 29th, which we completed and clarified much of the functionality. The site just got a nice write up in the local paper:

Often it is late at night, when there is neither a 12-step meeting to attend nor anyone awake to phone, that the craving for a drink is strongest.

And it is times like these when Ginger Bauler goes online to reach out to others recovering from addiction, finding solace in their tales of success and providing encouragement for those trying to break the shackles of dependency.

Bauler, who used to manage a research laboratory in Charlottesville, writes a blog about her struggles with alcoholism and her quest for sobriety on The Second Road — a new online support community for drug and alcohol addicts started by Charlottesville residents.

Writing about her battles enables Bauler to become “accountable” for her recovery, she says. And meeting and keeping in touch with those dealing with similar experiences gives her strength.

“I develop these relationships with total strangers, but with whom I’m completely connected because of this disease,” said Bauler, who has become a managing editor of the site.

The Second Road is the brainchild of local documentary filmmaker Melissa Shore, who partnered with Chip Ransler, owner of a digital publishing firm, to launch the site in November. By late May the social networking site had 225 members and more than 1,400 different people had visited it in a recent 10-day stretch.

Each member of The Second Road has his or her own profile page, similar to sites such as Facebook and MySpace, where they can post information and display customized features. The site also includes a series of blogs, chat groups, a “sharing wall” for inspirational quotes and testimonial videos from recovering addicts.

Shore, who grew up watching family members battle addictions, noticed that there was a gap in services for people in recovery and a need for round-the-clock services.

People in recovery do not always have access to meetings or counseling services, and some may have no one to turn to in times of crisis, Shore realized. That is especially true in rural communities, where social services either might not be readily available or are far away.

“There are hours of the day when you can’t or don’t feel comfortable reaching out for help,” Shore said. “The beauty of the Internet, of course, is that it’s 24-7.”

The site has won praise from many in the local mental health community as a vital tool to help round out recovery services.

“The concept is absolutely brilliant,” said Jeff Gould, administrator of the Charlottesville/Albemarle Drug Court. “This type of online recovery network is just perfect for people who can’t get to meetings.”

Beth Elliott, a retired social worker who advises the site’s creators, says that members are using The Second Road to implement the treatment plans they develop with counselors, through making lists and blogging about their successes and missteps.

When your code generates HTML, you rob designers of their ability to innovate

Friday, June 29th, 2007

Some fellow posted a commerical notice to the comp.lang.php newsgroup. For a mere $79 per developer, you can get a PHP framework that does all the same stuff as the free, open-source PHP frameworks. And it has all the same problems, too. In an old post on the Category4 weblog I was ranting about the problems that stem from generating HTML from inside of PHP code. When a PHP framework generates HTML and CSS from inside the PHP code, then programmers end up working on problems that designers could solve much faster. Consider this problem, which the PHP Developers Kit offers as an example of all the wonderful things you can do if you use their $79 framework:

The workhorse of PHP Kit is the container class . It is a box containing other objects, like text, links, paragraphs and even other containers. It is under CSS control so you may create a container using several dozen options, like background color, border style, border color, font size and font color.

Note: the containers above displayed correctly in Microsoft IE when displayed inline (left to right). However, Mozilla Firefox version 1.5.0.4 displayed them left to right but with no width or height except for the width of their borders. When displayed as block (one above the other), Mozilla displayed their size correctly. The display property (inline or block) is not suppose to effect an element’s assigned width and height.

So, um, you really should be able to control these containers from your code, but when you run into a problem, such as different browsers interpreting your CSS differently, you (the programmer) are stuck solving it. The designer, who specializes in CSS, can not solve your CSS problem for you, because they don’t know how to edit the PHP code that generates the CSS. Ideally, all CSS issues should be the domain of your designers, not your programmers, but when all the CSS is controlled by PHP code, then solving this problem is shifted from the designers to the programmers. This leads to workflow problems – in too many web design shops the programmers have too much work to do and the designers too little, and frameworks such as this are to blame. This is bad economics – to the extent that your programmers are paid more than your designers you should be trying to shift work from programmers to designers.

Concentrating all of the important design work into the hands of the programmers is also bad for morale – I’ve worked in shops where the designers had no work to do because they were waiting for the programmers to finish a bit of PHP/CSS template code. It is demeaning and embarrassing for the designers to have no work. I’ve seen them try to make busy work for themselves and they always look a little embarrassed and ashamed. A well-run web design shop will strive to avoid this.

Designers are focused on communicating with other humans, programmers are focused on communicating with machines. One’s users and clients suffer when the actual power to design is taken away from designers and given (even accidentally) to programmers. It is a rare programmer whose insight into user behavior matches that of a highly skilled designer. An intuitive sense of the user experience is the most important skill that a good designer brings to their work. If all the real design power is in the hands of the programmers, one’s websites and web software are likely to be less intuitive than what might have otherwise been achieved. By contrast, a framework that maximizes the power of the designers is a framework that maximizes the chances of a great user experience being achieved.

Again, let me repeat (as I said in that previous post), frameworks like this (I mean the one I’m criticizing) are fine for the individual freelancer who does all their own programming and design work. But these frameworks are harmful to web design firms that work on large sites and who, therefore, need programmers and designers to work together. As soon as you have a division of labor, you need a framework that facilitates workflow, rather than blocks it.

The last time I wrote on this issue (back when I still worked at Category4) a fellow named Matt responded:

While I generally agree on your view of no html in your php, I think there are exceptions. It’s really about choosing what for when and where. For example, form elements being generated by code is acceptable to me. Even as a designer, I would think that looking at a page with a few php/template tags would be better than a page with lots of html; it’s still code. Less control, but as long as the code is doing what you want then there is no worry. And you could always either override/extend the classes generating the code or hack it…. I think that my point is that one could continue to mull over what to use and prematurely optimize resources to the point of getting nothing done.

I’ll say again, if an individual is doing both the programming and the designing, then putting HTML into the PHP might speed things up for them, but as soon as the jobs of programmer and designer are split, then anything that robs designers of their power is likely to lead to work-flow problems. And those cost money, time, morale and sometimes management focus. They also limit the ability of the designers to achieve a great user experience. Matt suggests that form code can be generated by PHP code, but if you do that, you will very likely get cookie-cutter forms. Forms are the single most important area for designers to innovate a great user experience, but the ability of designers to innovate is wiped out if the HTML is generated by PHP code.

As to “you could always either override/extend the classes generating the code or hack it”, only a programmer can do this. Designers can’t do this on their own. If the designers need this done, then they need to wait on the programmer to do it. And then, once again, you end up with a work-flow problem that damages the productivity of the firm. Either the firm’s profits will be reduced or the costs must be past along to the client, driving up what they must pay for the project.

As to “one could continue to mull over what to use and prematurely optimize resources to the point of getting nothing done”, I’m sorry I haven’t stressed this, but the opinions I’m expressing have grown up on me slowly over the last 5 years. In 2002 I started work on a PHP/MySql content management system and I made every mistake that I’m now critical of. Back then, I wrote functions to simplify my forms, such as:

textInput(”author”);

All the HTML was in the function. It’s exactly what I’m now critical of. So what I’m expressing in this post isn’t premature optimization. It’s way-overdue optimization. I’m looking back at the mistakes I’ve made over the last 5 years and I’m trying to express what I’ve learned so others might now avoid making the same mistakes I’ve made.