[ajug-members] Can anyone recommend a book for learningRubyonRails?

[Les Hazlewood]

On Wed, Jul 30, 2008 at 6:11 PM, Rick <rickcr at gmail.com> wrote:

> On Wed, Jul 30, 2008 at 3:50 PM, Les Hazlewood <les at hazlewood.com> wrote:
> >  t I think these frameworks and those like them totally miss the mark.
> >
> > Component oriented design is much more in line with Object-Orientation.
> > Frameworks that cater to component-oriented design, re-use, OO, etc, etc.
> > *That's* what people should be looking at.  Frameworks like Wicket, GWT,
> > Tapestry 5, and my current favorite, Click.
>
> To emphatically state (with asterisks) *that's* what people should be
> looking it is completely wrong.


Wow, such harsh feedback - you should calm down a bit ;)

And it's not wrong - it is my opinion, and I *emphatically* stand by it. :)


> I'd maybe concede that's what people
> *should consider* looking at. I'm so tired of this haughty "My
> framework is the killer OO framework and it allows for reuse, yada
> yada."


I made no such statement.  I classified the *type* of frameworks that people
should be looking at, especially if they want to utilize all the benefits of
Object Orientation (giving more than a few examples of what is very
popular), which I believe to be of value to most people on a OO language
list.  And from the previous email and by the end of this one, I present
quite a few concrete benefits of these OO frameworks, yet you've given no
such support for what I call the 'psuedo OO' ones - not particularly
beneficial if you wish to support your counter argument, IMO.


> I 'used' to think the way you did, then reality hit in after
> coding a bazillion web applications.


This sounds as if my way of thinking is not as valid or that I also haven't
coded a 'bazillion' web applications.  I've coded more of them that I care
to even remember, so that implication is unfounded.  And I feel that my
breadth of exposure to frameworks and their use in the real world would be
valuable to people evaluating either sets of approaches.  I have developed
or assisted with numerous production applications written in Struts, RoR,
Grails, Tapestry, GWT, Adobe Flex, Echo2, ThinWire, Spring MVC, and my most
recent one, Click.  That gives me a somewhat valuable perspective on the
modern java web framework landscape that people on this list might find
worthwhile in the context of the current discussion, so I feel I have
something of benefit to add for those interested.

However, I have no idea of your background or your experience so I however
wouldn't imply that my 'bazillion' applications means your opinions are not
grounded in reality.



> How often do you really reuse web
> application components? Sure you might reuse a display widget but all
> the latest "fast and easy" frameworks handle that already with out the
> bloat of having to code a web app like a Swing app.  Sure enjoy it if
> you want, but I want productivity these days.


I and the teams that I work with are extremely productive with the OO
frameworks I menitoned.  In some cases my 'gut feeling' estimate of
productivity improvements were an order of magnitude better than compared to
say, Struts of Spring MVC.  That goes back to the the 'efficient' criteria
in my original post.


> And yes I've used Wicket
> -  been involved in the community even. It's a very nice framework if
> you think component based frameworks are the pinnacle of coolness. I
> still think it's typically 100% overkill solution for 95% of the web
> applications developers will need to code.


If you view 95% of web applications as those being developed by one or two
people that take two or three weeks to churn out, then I might agree with
you.  But the huge majority of web apps that at least I've come across and
been involved with rarely ever match that criteria.  But maybe that's my
experience - nothing wrong with that, it just means we have different
viewpoints and people on this list can evaluate what would be worth looking
into depending on their own environments.


> I haven't used Click but took a quick look at some of the example
> code. Whenever I see this in a Java web app, I'm turned off. If I'm
> going to build my app with true event handlers and components I'd
> rather spend the time with Flex, otherwise I'm happy with ajax events.
>

>
>   public void onInit() {
>        form = new Form("form");
>        form.add(new HiddenField("id", Integer.class));
>        form.add(new TextField("firstName"));
>        form.add(new TextField("lastName"));
>        Select stateSelect = new Select("state");
>        populateStates(stateSelect);
>        form.add(stateSelect);
>        form.add(new DateTextField("birthDate"));
>        form.add(new Submit("submit", this, "onSubmit"));
>        addControl(form);
>    }


In my opinion, you've directly contradicted yourself - what do you think you
do with Flex?  It is component oriented, solid GUI development.  So are
these web frameworks - which have mostly the exact same benefits and
detriments.  Many people can't choose flex, nor would they want to in many
situations:  one of the biggest appeals of component-oriented HTTP
frameworks like Wicket and Click is that the resulting output is often
search-engine friendly - they can retain the page paradigm, instead of a
desktop paradigm (like GWT leans towards).

If you want a browser-only solution (client mandate, whatever) sometimes you
can't use Flex.  But the point is now these newer frameworks give you that
same power.  My strong belief is to choose page-oriented or desktop-oriented
paradigms to suit what the business wants, but choose solid OO in either
case.  I can't believe I'm rationalizing this on a Java list :)

The only place I see the true benefit of a component based web
> framework is if you anticipate that your large company is going to
> truly need some java based web components that you will need to use in
> DIFFERENT web applications.  The amount of times this comes up in
> reality I'm sure is extremely slim and I'd like some true real
> examples of the "reuse" part that you mention above.


Sure, that's easy enough.  But perhaps you're ignoring the large number of
user contributions for most of these frameworks, such as "wicket stuff" or
"click click" or the Tapestry 5 user community contributions, or the tons of
GWT add ons.  That's the real power of component-oriented design - code
reuse for the masses, not necessarily code reuse across two or three pages
in one's current webapp.  That and it tends to make a lot more sense and is
easier to grasp to most OO people ;)

If you download these additional components from the respective locations,
you have an insane amount of functionality ready-to-use without doing much
work at all.  Here's a good example: look at Tapestry 5's 'beaneditform'
tag:  http://tapestry.apache.org/tapestry5/tutorial1/forms.html.  How many
times do people repeat the JavaScript validation-as-you-type features, CSS
formatting, data binding, etc, from project to project?

The value of a feature-rich component library, appended by user
contributions, which can be customized using OO principles (subclassing,
template method design pattern, etc) cannot be understated in a world where
time-to-market and efficiency are ultra important.  That's one of the
biggest reasons I hinge my framework choice on OO component frameworks.  The
others are code readability, simpler unit testing, abstracting the 'guts' of
HTTP away and focusing on real GUI design, code maintainability, etc, etc,
etc. -or any of the other common reasons why OO languages are touted.

These are the reasons I emphatically stand by my opinion, especially when
representing to people on an OO language list.  My main point of that last
email is that people are often stuck on what I call procedural 'old school'
web frameworks and need to get away from that paradigm and try out this
whole new facet of web-based development.  It has been an extremely
beneficial experience for me and pretty much all of my engineers, and I
wouldn't go back to the older ways for anything (unless a client payed me a
rediculous amount of money to do so ;) ).

Peace and love,

Les
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ajug.org/pipermail/ajug-members/attachments/20080731/ede4eeb2/attachment-0001.html