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.
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]
