Random hate-box: MVC Web Frameworks debate (blurb)

First of all, I like to say all this below is just my uninformed opinions. The whole point of this blog is so I can mimic GTA4’s www.blogsnobs.com (what?).

Anyway, awhile ago I did a series of blurbs (retarded blurbs you may say) on my seat-of-the-pants experience with Django. To be honest, it was merely a dipping of the toe into the shark-infested water of Django; imho one should take what I had to say with a heavy dose of salt, for it was just my two week impression, that’s it, don’t read too deep into it. So I did say something along the line of template implies view, model implies model and other blahs. Well, it wasn’t precisely correct. I tend to do a lot of hand waving and blurbs. It was just me sitting here and putting my stream of thoughts out on this page, without reallying getting into too much of a detailed thought.

To me MVC is merely a pattern, useful for implementation of “separation of concern.” One can argue this and that, but to me, Django does have this sort of separation of concern. Sure, it may not be exactly like a desktop GUI application’s MVC, but the point is that it has this sort of MVC equivalent separation of concern generalization (Does it use encapsulation and abstraction to separate out different functions pertaining to view, controller, and data computation? Yes? Well, you know the saying: talks like a duck, smells like a duck, then it must a singularity!) When I say template == view, I really mean template + a servelet like thing on the server side. The “servelet thing” can handle request and response (and by operating with respect to the ‘model’ in Django). So Django is not neccessary MVC per-se, but it fits this MVC like separation of concern generalization.

The reason I said what I said is because I’ve just finished working with SEAM, which has this MVC-like seperation concern of thing going. With the “View” consisting of both the crap on the JSF side and EJB3 side. But please DO NOT QUOTE me on this. This is just a personal blog. I don’t have much experience with Web Development.

Also this entire web app. thing can also be argued to fit into this MVC pattern. With the web client the “view” and with the business logic / data (Model) residing on the server. Can one argue that the entire Client-Server architecture fits in with this MVC pattern also? IMHO one can make an argument for it.

Django final blurb: Equivalence to SEAM and other J2EE stuff.

Well, first impressions are often wrong. I would not say at this point something like J2EE frameworks are more enterprisy, even though as an OPINION it is valid.

You can do the pretty much the same stuff (no shit).

Bye bye. I will write up a more detail comparision later… Or maybe not, kinda busy.

Safe to say though, I like Django. Learning curve is easy. Provides a lot of helper things. Ease of use is optimal.

Still the only thing that it lacks is the so called SEAM conversation (google it, I think you will find some nice examples.) Of course this can be implemented using Django, I believe.

Later.

Django blurb: SEAM bijection

Ahh… Another reason for why I’m having the impression I’m having… SEAM supports the so called bijection… I’m so used to doing stuff using bijection…

I need to collect my thoughts on this and will post more in the future.

Django blurbs: Genshi

Maybe my impression is due to being more used to an XML based template engine. Perhaps after my mind starts to grasp at the more familiar (XML based templating), my impression will change. I’m really used to JSF, together with Facelets… Combined they kick much ass on the presentation side.

So I’m going to take Genshi out for a ride and see if it changes my opinions.

Still, SEAM has that stateful framework which I have been telling you (yes, I’m going to blog it soon), that I’m really, really into… Hehe. Let’s hope there is something equivalent in Django.

Django blurb: Day 2 (impressions)

So I’ve been doing the Django tutorial… Just finished part 3, have not started the form processing one yet. Here are some impressions, comparing it with SEAM:

*Java 2, JSF, EJB3, Hibernate, and SEAM seem more powerful:

Perhaps I’m just looking at it from the wrong angle. My impression so far, is that with all the different things that Java 2 and friends offer seems MUCH more powerful and much more expressive (i.e. it is full featured). At least it seems that way to me. What is my definition of powerful? Well, with SEAM tying together JSF and EJB3 and the so called Stateful framework (e.g. long running conversations), not to mention Richfaces or Icefaces; my impression is that one can develop much more advanced apps, using provided offerings of the SEAM framework. (Gavin King and friends have mucho resprect from me. I bow down to you greatness) Of course, this is simply an initial observation, without any concrete backing of real experience and data, given that I’ve only been messing around with the tutorials. Also I’m sure one can accomplish the exact same thing using the two frameworks, but it is a matter of how much hoop one is willing to jump through.

Perhaps that is not what Django is about. But definitely Java 2 and SEAM just seem much more enterprisy…To be fair, I need to read all the Django docs like I did the SEAM docs before I make that final call.

Django offers the whole Ruby on Rails thing (note, never messed with ROR) with manage.py. Seam offers the same functionalties with SEAM-GEN. But to me manage.py is more user friendly and seems like it has more to offer. However, I think one can accomplish the same with both.

*Django learning curve is low:

So far, Django has been a breeze to understand and learn. Compared that against the whole J2EE EAR, WAR, XML shebang, it’s much easier to grasp for a beginner, conceptually. But SEAM offers SEAM-GEN which helps with managing the J2EE ‘web-app structure.’ Still, my first impression is Django is easier to learn.

*Python beats Java

Yes… Python rocks. Nuff said.

—

Please excuse my lame … excuse for this massive exercise in hand-waving. I’m having fun so

I will probably get into the nitty gritty of the SEAM stateful framework in a future post and how it compares with what Django has to offer.

Maybe Django has everything that SEAM has… If so, with Django having Python on it’s side, I think Django gets the Gold… If that is the case. But at this point SEAM just seems that much more professional.

What would really kick ass is SEAM in Python!!! Or something equivalent.

And I guess I do have a SEAM fetish afterall.

Oh BTW… Django fantatics don’t kill me please… I am a coward… You win…

Django blurb:

Task: Need to make a little web-app for a relative of mine who runs a small business.

So I’ve decied to go with Django. Why? Of course I wanted to use SEAM, not because of some Java SEAM (and to a certain extent, JBoss) fetish, but mainly because this is what I have been using, thus I don’t want to abandon it. But, I’m using a shared host that is mainly Apache (no mod_python) based, that is, it’s not a J2EE application server. So can’t use SEAM there. However, it does have python support (I’m going to use FastCGI)… So I’m saved! Yeah.

I’ve been doing the DJango tutorial, so far it kicks ass. Everything is just so succinct, it’s beautiful man. Python is a work of art, imho! Doing web work with Python will be a blast!

One of the biggest thing that SEAM touts is the so called stateful-web-application (which I’m not going to get into right now), the SEAM stateful framework is one of the major features that supposely makes it stand out. I do not have much experience with various web-app frameworks, so I can’t tell you whether that is true or not. However, I will blog about experiences with Django and will try to make a comparison against SEAM. In the sense of ease of use, features, etc. (Definitely not going to go near the scalability question).  Of course I’m probably comparing apples with oranges… And I only have intermediate knowledge of SEAM, and web development in general. Since this is my blog, I will just blog it, I don’t care whether it makes sense, is right, or whatever. *Shrugs*