Re: WebObjects vs. Microsoft's .NET
Re: WebObjects vs. Microsoft's .NET
- Subject: Re: WebObjects vs. Microsoft's .NET
- From: Jonathan Rochkind <email@hidden>
- Date: Mon, 02 Jun 2003 11:22:40 -0500
At 12:15 AM 6/1/2003 -0400, Arturo Pirez wrote:
The key is this: don't worry about _how_ WO does what it does. Just take
it for granted that WO
can keep your state.
Well, I think it's a balancing act. The real problem is that your
_assumptions_ about how WO must work (or not work!), especially assumptions
based on inferior-ly designed products---can get in the way. Don't let
your lack of understanding of how WO works get in the way of letting WO
work for you---but on the other hand, is _is_ possible to understand how WO
works. In some areas less precisely than others, but you can get the
general idea, get a feeling for what WO is doing. It's not black magic. As
you use it more and more, if you are inquisitive and curious and keep
asking questions at the level you are at and answering them, you will
understand WO more and more, which will allow you to be a better and better
WO developer.
Additionally, Apple's current documentation really is quite good at
explaining what's really going on. Really. Nobody seems to believe this,
but the "Web Applications" document off the WO reference page really gets
into some complex stuff, explained in relatively simple ways. It's still
complex stuff sometimes, and maybe daunting, but when you are ready to
learn more, it's there for you.
I highly reccomend it at:
http://developer.apple.com/techpubs/webobjects/Web_Applications/
Although looking through it... it doesn't actually explain how WOContext
elementIDs work, which are behind how the WORepetition example Arturo
writes about works. In fact, WOContext elementIDs and the system built upon
them to do page generation and request processing---it's true that it's not
really explained very well anywhere. I still only have a basic
understanding of how it works, after developing for several years. That
would be a welcome addition to a document somewhere, but fortunately, as
Arturo says, you don't really need to understand it to use it. It's
actually quite simple in the end, which fortunately means it's not
complicated enough for weird bugs to exhibit in it which you need to
understand. Mostly, it just works.
--Jonathan
For example: One uses a WORepetition to iterate over an array generating a
submit button for each item in the array. Now, how does one keep track of
which one is activated?
Answer: One doesn't, WO does. One just uses the bound variable and
relies on WO to make sure it
is set correctly. It's kind of crazy because literally nothing else that
I've ever seen can do that.
It's black magic. But if one doesn't assume that WO can do it for you
then one ends up fighting
the framework. One writes lots of code trying to generate something
unique for each of the submit
buttons. One writes lots of code trying to figure out which button is
hit. Literally dozens or
hundreds of lines. When all one needed was
public WOComponent buttonAction() {
WOComponent woc =
pageWithName(selectedButtonObject.toString());
woc.takeValueForKey(selectedButtonObject, "usersChoice");
return woc;
}
I think most developers see the above and believe that it is a contrived
example. Surely it can
only be this simple for a toy application that does little of
interest? But, as it turns out,
the above 4 lines is easily 40-75% of the "real work" that most
applications do.
There's a lot that goes on behind the scenes. Why did one choose to
display those particular
submit buttons? Where does the data for the submit buttons reside? etc
etc. That's the
application logic. What unique value is there in trying to figure out
which button got pressed?
Any decent framework can figure that out for anyone and everyone who's
doing an application.
WO offloads all the minutiae of figuring out button presses and other
state changing
"events" so that one can concentrate on the unique aspects of one's
application.
And, in my experience, it offers at least a 3-8x productivity boost to a
developer by doing so.
Most people say that the true value of WO lies in EOF. I agree and
disagree. I think that the
true value of WO is the liberation of human time from all the bookkeeping
that Web development
requires. Cookies, hidden form fields, parameters encoded on URLs.
Blech! That's stuff that
should have gone out with 28.8kb modems. With WO they are. EOF is just
an extension of that
philosophy. (Or rather, since EOF predates WO, vice versa, but let's not
quibble).
Now, if only the job market for WebObjects developers was better.
Sorry if the above is too soapbox-ey.
-------
WebObjects in Philadelphia. You want a cheesesteak with that?
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.