On 9/1/07, Martijn Dashorst [EMAIL PROTECTED] wrote:
On 9/1/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
i have just about zero swing experience :)
I think I have even less swing experience, I doubt my playground
experience from 25 years ago counts...
Martijn
I can testify that Wicket
Recently I had to go back to doing a couple of Swing screens and all
those inner classes and model objects were a breeze...
+1
I have done a lot of swing coding before and for the past 6 months in
wicket. I can definitely say this-
Although wicket has a lot of swing like programming style in
On 8/31/07, Scott Swank [EMAIL PROTECTED] wrote:
I will not argue against Lisp. The paucity of Lisp/Scheme/Haskell
within professional software development is criminal. That is why,
for example, we will be seeing continuations in Java 7.
Heh, even though the idea goes so far, that reminds me
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.
I'm going to go out on a limb - because I'm sure there are plenty of
anecdotal
Good luck with such solutions. If you want to build things like that, you've
got basically two approaches. Use GWT (or something alike) - code logic in
limited subset of java and have it magically translated to javascript. This
seems somewhat fragile and limiting to me, but I don't have enough
they are not fancier then generic data structures. they exist for a reason
and can do things other generic data structures cannot. i suggest you read
up on them, they are a pretty standard part of oop and are used throughout
java - unless of course you have been living in a struts-like land where
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
On 8/31/07, Kirk Israel [EMAIL PROTECTED] wrote:
Probably the most difficult grinding of gears, then, for someone who
gets the syntax and knows the basic concept in theory more than
practice, is the idea that it's reasonable to make small, single uses
class definitions (as opposed to setting
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
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
On 8/30/07, Kirk Israel [EMAIL PROTECTED] wrote:
Igor, sorry if I've irritated you. I know some of my frustration comes
from A. an ugly reluctance to embrace change and B. Wicket is doing
great things but it's somewhat early days, and the documentation
(tutorial books and recipe collections)
Igor, sorry if I've irritated you. I know some of my frustration
comes from ...
This certainly isn't the right attitude if you come here for help.
Well... if it means anything, from my perspective, the more I use Wicket,
the more I love it. I'm discovering new, and great things every
Igor, I'm sorry I've sounded unappreciative to the work the team is doing.
Yes, I'm a dumb curmudgeon who is having a lot of problems adjusting
to a new approach to things, and who, despite an honest effort to
embrace the wicket outlook, may have stumbled, and also dove right in
to the code base
On 8/30/07, Kirk Israel [EMAIL PROTECTED] wrote:
Igor, I'm sorry I've sounded unappreciative to the work the team is doing.
Yes, I'm a dumb curmudgeon who is having a lot of problems adjusting
to a new approach to things, and who, despite an honest effort to
embrace the wicket outlook, may
interface menuitem extends serializable { imodel getlabel(); abstract void
onclick(); }
class basepage extends webpage {
protected abstract listmenuitem getitems();
public basepage() {
add(new listview(menu, new propertymodel(this, items)) {
populateitems(item item) {
+1 here too. Although I am new to Wicket I realized very quickly why it is
a great framework. I have developed webapps in Java for 6 years, and this
is truly the first framework I've come across where there is no disconnect
or learning curve for a Designer to create my screens for me. JSP
On 8/30/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
interface menuitem extends serializable { imodel getlabel(); abstract void
onclick(); }
class basepage extends webpage {
protected abstract listmenuitem getitems();
public basepage() {
add(new listview(menu, new
right
interface menuitem extends serializable { imodel getlabel(); class? extends
page getpageclass(); }
class basepage extends webpage {
protected abstract listmenuitem getitems();
public basepage() {
add(new listview(menu, new propertymodel(this, items)) {
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
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
http://www.google.com/search?client=safarirls=enq=listview+wicket+site:cwiki.apache.org/wicketie=UTF-8oe=UTF-8
On 8/30/07, Kirk Israel [EMAIL PROTECTED] wrote:
Also, not ignoring the fact I needed to have dug in more to the
documentation that is there,
why doesn't
Hey there--
So I came up with a solution to this, but I suspect it's not very
Wicket-y, so I'd like some suggestions on best practices:
We want a header component that can go on different pages, with 1 2 or
3 links to other pages.
(Well, I guess ideally any #, but with my approach it was easier
You should use panels for this. You can have panels for 1 link, 2 links a 3
links. Or even put a repeater into panel to generate as many links as you
want. And you then need only one placeholder on the page (for the panel).
-Matej
On 8/29/07, Kirk Israel [EMAIL PROTECTED] wrote:
Hey there--
So let me try to rephrase your problem: you have a header component
that shows a variable number of components (links). Use a repeater
(e.g. list view or repeating view) for the variable number of
components, and you probably want to wrap the header component in a
panel so that it is easy to move
or just write something in perl and call it a day.
-igor
On 8/29/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
So let me try to rephrase your problem: you have a header component
that shows a variable number of components (links). Use a repeater
(e.g. list view or repeating view) for the
Igor, sorry if I've irritated you. I know some of my frustration comes
from A. an ugly reluctance to embrace change and B. Wicket is doing
great things but it's somewhat early days, and the documentation
(tutorial books and recipe collections) is still scanty.
Eelco, thanks, your summary was
So am I correct in thinking that, in general, most HTML pages in
WIcket will have all possible subcomponents listed, and the visibility
will control things that shouldn't be there...
That's one way to do it. But a better way typically is to build up
your pages dynamically, using panels for
I just dont understand how you expect us to continue helping you if you go
and talk trash about something we invest a lot of time in. Based on the
slashdot comments you left I dont really understand why you are using wicket
at all.
-igor
On 8/29/07, Kirk Israel [EMAIL PROTECTED] wrote:
Igor,
28 matches
Mail list logo