On 8/31/07, Kirk Israel <[EMAIL PROTECTED]> wrote:
>
> 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 if you have application this simple, then using Wicket is like killing a
fly with a racket launcher.
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.
Huh? You can write AJAX applications without writing a single line of
javascript. And I know people who have next to nothing knowledge of
Javascript and are developing AJAX application with Wicket.
HTML? CSS? The point of Wicket is that it doesn't shield you from HTML or
CSS. It doesn't even attempt to. If you don't want to know anything about
HTML/CSS then Wicket definitely is wrong choices.
But what Wicket shields you from is HTTP. You don't have to think in
requests/responses. You don't have to construct URLs and to parse them. You
don't have to maintain session attributes (how often do you cleanup session
attributes in regular model 2 applications, if at all?). You don't have to
process form submittions automatically (which button submitted the form?
what should be selected checkbox value?).
You probably haven't been burned enough by a "manual" state management (such
as I can't add a tabbed panel into this page, because i'd have to change
every single link to preserve the selected tab). Image a model 2 application
with two sortable pageable lists, tree, tabbed panel and two forms. With
Wicket it's dead simple. Try that with struts.
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.
Wicket is not for newbie OOP developers. We don't pretend that it is. That
was never the goal. You need rather solid OO skills to get Wicket. But if
you want to learn, I think Wicket is a pretty good "material".
-Matej
> 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]
>
>
