Topic: MVC

Griffon and a PureMVC Plugin: Some Initial Thoughts

puremvc-icongroffon

I finally have some small amount of spare time to start working on my Griffon PureMVC plugin. One of the first things to think about is where to we make the marriage between the two frameworks?

Griffon has Models, Views and Controllers, as does PureMVC (actually, it has Commands, Mediators and Proxies, which essentially perform the tasks under MVC). My initial thought is that Griffon's MVC triads really perform the tasks of a complex view, and PureMVC wires these complex views together via it's message bus. So, my thinking is to wrap each MVC triad into a Mediator, with the Mediator mostly talking to the Griffon controller and perhaps the Griffon model.

I'll make some more posts here as my thinking and experimenting evolves.

Topics: , ,

Learning PureMVC the Hard Way (is there any other way?)

This ends week one of my investigations into PureMVC. So far I'm impressed with the framework itself in it's many versions and incarnations, but the documentation and tutorials for platforms other than Flex leave something to be desired. To all those folks that claim that Cairngorm is easier to learn than PureMVC, I can agree, but only because of this lack of good documentation.

So what should we Java/GWT developers do? Taking a cue from my colleague Noel Rappin, we should Read the Source, Luke. This code reading is a triangulation excercise worthy of Bill Clinton, involving API docs, source in other languages and source in other versions and platforms.

Continue reading »

Topics: , , , , ,

PureMVC, Spanning the Platform Spectrum?

PureMVCAt Pathfinder we do a fair amount of desktop style development -- iPhone/Cocoa, WebForms, Swing -- and web application development -- Grails, Rails, JSP, ASP.NET, etc., etc.. In the last two years we, like a lot of other software development shops, have experienced a convergence in our efforts. The web is coming to the desktop in the form of Air and the Desktop is coming to the web in the form of RIA's. Now web MVC, which used to be a pretty benign pattern mostly concerned with app flow and validation, is starting to resemble desktop MVC, which has to deal with document-centric models and long lived views and all of the plumbing that requires.

So we recently had a powwow between all the different parties to talk about MVC and this convergence. With the exception of the insufferable Mac and iPhone developers and their disgustingly mature Cocoa framework, we all agreed it would be nice to have an application level MVC framework for each platform. We also agreed that Swing is a great example of what happens when the vendor doesn't provide such a thing -- spaghetti code that relies on component level MVC and hard wiring at the application level. There are a few MVC frameworks for Swing, such as TikeSwing and Spring Rich Client (soon to be superseded by Spring Desktop), but for every Swing app that has this sort of design, there are hundreds that are just a mess.
Continue reading »

GWT and the Discipline of MVC

When you're developing a desktop or GWT application you're going to go through a bunch of iterations, tweaking the UI, adding components, etc. Sometimes in all of that work it is very tempting to take a shortcut and update a view directly from a controller (label.setText(model.messsageString)). That way lies madness. Before long you've got your view code strewn across the length and breadth of your application. Change the view or some aspect of the model and you're on a refactoring of biblical proportions.

In fact there's never a good time to break out of MVC, but sometimes you just don't know what sort of Observable your model should be. Will you be using a table, a tree, some custom component? In those situations I try to preserve MVC while punting the hard decision until later. To this end, I've written a little set of utility classes called SimpleModel. How do you use SimpleModel?
Continue reading »

Topics: , ,

From JSP to Ruby on Rails: First thoughts on front-end coding conventions

Now that I've got a few Ruby on Rails projects under my belt, I finally feel qualified to comment on Rails front-end coding conventions. As a UI specialist coming to Rails from the JSP world, I find a lot of room for improvement in the RoR approach to view-layer code. I love working on the non-view aspects of RoR projects, but I find I've got to do tons of cleanup at the ERB layer. Expect to see some open-source components from Pathfinder to help ease this pain. In the meantime, let me articulate my pain points:

Code organization

If I'm filling a front-end role on a Rails project, most of the files I need are in /app/views and /public. I dig that. Likewise, I appreciate the underscore naming conventions for partials. However, I wish /layouts weren't just another subdirectory of /app/views. Layouts are inherently different from standard view templates. A better hierarchy within /app/views would help drive this home. Likewise, I wish partials and full templates each had their own directory within a specific controller's view folder. That would help keep directories manageable on big projects. The /public directory, on the other hand, offers just the right amount of organization.

Continue reading »

Topics: , , , , , ,

Pretty Blocks in Rails Views

One of the easiest ways to improve the readability and reusability of a Rails application is to refactor the view layer. I find that most Rails code I look at in models and controllers tends to be very good, but views are a huge mess of single-use partials, repeated behavior, and lots and lots of missed opportunities to implement some really graceful and reusable helpers. I wanted to whomp up a quick blog post discussing some of my favorite techniques for making views prettier.

Continue reading »

Topics: ,

GWT, Remote Models and the Need for Better Replication Algorithms

PESSIMISM, n.
A philosophy forced upon the convictions of theĀ  observer by the disheartening prevalence of the optimist with hisĀ  scarecrow hope and his unsightly smile.

-- Ambrose Bierce, The Devil's Dictionary

I frequently crawl through the various GWT project hosted on Google Code, as well as the few that aren't (like the almost venerable GWT Widget Library). One type of solution that is emerging is what I would call model synchronization libraries. These build on top of the GWT-RPC mechanism and allow a synchronization of an object model on the client-side with a corresponding one on the server-side.

Right now there are two major choices available:

  • hibernate4gwt - Number one with a bullet. Elegant and powerful library that allows you to ship domain objects back and forth between the GWT client and the Java server, persisting changes, all at the cost of extending one class: LazyGwtPojo. There are two basic flavors -- stateless and stateful -- with a couple of different subflavors to support a variety of development use cases.
  • Gwittir - Developed by the two dudes who wrote GWT in Practice, this library provides domain object bindings without forcing a dependency on Hibernate (should we add "Hibernate infected" to our lexicon along side "Maven infected?").

It's clear why these libraries are gaining in popularity. The whole idea of writing applications in GWT is to have a commonality of language and domain model. You want to be consistent and not have to navigate the OO/RPC boundary every time you modify or retrieve your client-side model. (An additional alternative worth mentioning is IT Mill Toolkit 5, which as a server-side ajax framework with it's widgets realized in GWT, already has the client-server synchronization baked in.)

Continue reading »

Launch: Pathfinder Newsletter

    Get a monthly update on best practices for delivering successful software.

    Subscribe via email


    Subscribe via RSS      RSS icon

Topics

Search

WordPress

Comments about this site: info@pathf.com