On 8/31/07, Scott Swank <[EMAIL PROTECTED]> wrote:
> That is why flat, page/request granularity web UI frameworks have
> succeeded. They are simple and procedural. The reason that languages
> such as Smalltalk, Java & C# are much better than languages such as
> Fortan, Pascal and C is that the former have a range of syntax,
> objects, that their procedural predecessors lack.
I want to hear you argue with the people who feel Lisp (Paul Graham
among them) is horribly under-represented in software development
outside of Academia. (The trouble with Lisp (at least as it was taught
in Princeton-program based Universities in the early 90s) is that,
like a lot of languages, you tend to judge it on its common APIs and
libraries, and for many students that's just a primitive little
command loop with primitive file I/O at best.)
And I swear, I'm trying to learn here, and not pick fights. I'm also
trying to not let me sometimes working out of my "comfort zone" make
me highly defensive or judgemental. So let me play devil's advocate
here: You said
"flat, page/request granularity web UI frameworks have succeeded.
They are simple and procedural."
Simplicity is often regarded as a good thing. Probably, it is, in of
itself, a good thing: the problem then occurs where you try to use the
simple methods on problems they go beyond their scope.
CGI-centric approaches offer some beautifully simple concepts, a
pretty hammer that (I'd say) may well be right for many programming
situations: a simple key/value map for input, another key/value map
for storing things on a session, output as text that the browser will
interpret and turn into screen elements. This may even map well to how
"civilians" see the web. (as opposed to a desktop app). They click a
link, they get a page. Click, page. Form, Click, page.
But not every problem is a nail for this simple hammer.
In practice, I'd say there are a few gotchas to be aware of w/
page-centric approaches. One is the general issue of conceptual
weight. This is probably worse for shlubs like me, but even then,
there tend to be more things to be kept track of, more potential
interactions , and more things to know about -- especially because I
feel, in practice, Wicket doesn't let you know THAT much less about
the HTML, Javascript, and CSS,(There are exceptions, for the prebuilt
component, but those aren't core Wicket.) but requires you to
understand how to apply that knowledge in the Wicket context.
The second gotcha for people, especially who are a bit procedural
minded, is the stacktrace problem. The more OO- you are, the more what
you are seeing on screen (whether a complete webpage or a stacktrace)
is the result of properly established object and relations earlier in
the app workflow, the tougher it can be to know where the mistake
occurred. Sometimes it's not a problem, and the 2 lines you see of
your code are around where the error was, and other times Wicket is
pretty helpful in telling you the kind of thing that went wrong.
So in short... I "get" objects and have for a while. But I'm learning
that there are further levels of "get"ness I can aspire to.
> In an OO language one can wrap data and behavior up into objects and
> then assemble those objects and pass them to other objects.
>
> From my perspective that is the value that Wicket brings to web
> development. Now a developer has the power of OO instead of being
> stuck writing the same sort of procedural code that would be at home
> in Cobol.
>
> The bright side to all of this is that a Java developer that "gets" OO
> is worth 3 or 4 that don't. I review most of the interviews that come
> in to Vegas.com and I conduct most of the phone screen interviews. I
> don't consider anyone who doesn't get objects. That is our base line
> for entry. So put in the work. It's worth it.
>
> Oh, and does anyone want to move to sunny Las Vegas and work with a
> team of a dozen other developers who "get it"? We're still hiring --
> especially folk with experience with Wicket.
>
> Cheers,
> Scott
>
> On 8/31/07, Kirk Israel <[EMAIL PROTECTED]> wrote:
> > Well, that's a good point--
> > They aren't complex, per se, but they (and especially anonymous inner
> > classes) seem to show up a lot more in the class of programming of
> > which Applets and Wicket are both subsets than they do in most of the
> > rest of Java land. So they're a little less familiar to me, and I'm
> > not sure if they represent more complexity (given they're obviously
> > "fancier" than using more generic data structures in that they may be
> > doing arbitrarily complex things in their functions) or less (since
> > they live in the same .java file as the page, and can be nicely tuned
> > to handle the problem at hand).
> >
> > On 8/30/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > > heh, if you think inner classes are complex you are def using the wrong
> > > framework
> > >
> > > -igor
> > >
> > >
> > > On 8/30/07, Kirk Israel <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Ok, thanks...
> > > > I refactored what i had with this in mind. It was a little more
> > > > complicated because I want to delegate responsibility for generating
> > > > the link and caption to the page (some of our links our kind of
> > > > complex to promote lazy initialization), so the page is still calling
> > > > into static functions to know what id to give the caption and label.
> > > > Plus I had to create an additional class to hold that link plus the
> > > > seperator( to do the comma and "or" in something like "A, B or C")
> > > >
> > > > The list is then
> > > >
> > > > add(new ListView("linklist", listSepLinks)
> > > > {
> > > > private static final long serialVersionUID = 0L;
> > > > public void populateItem(final ListItem listItem)
> > > > {
> > > > CaptionedLinkAndSeperator linkAndSep =
> > > > (CaptionedLinkAndSeperator)listItem.getModelObject();
> > > > listItem.add(linkAndSep.getPageLink());
> > > > listItem.add(new Label("sep",
> > > > linkAndSep.getSeperator()));
> > > > }
> > > > });
> > > >
> > > > and the HTML is then
> > > >
> > > > <span wicket:id="linklist">
> > > > <a href="#" wicket:id="link" class="link"><span
> > > > wicket:id="caption">[LINK CAPTION]</span></a><span wicket:id =
> > > > "sep">[,]</span>
> > > > </span>
> > > >
> > > > So, the complexity isn't too bad despite the inner class and it's less
> > > > kludgey than what i had earlier.
> > > >
> > > > Thanks.
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Scott Swank
> reformed mathematician
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
