Re: Help with Wicket Adoption Numbers

[Leo . Erlandsson]

>As my English is not my mother's tongue, even though I do speak it pretty
>good, what is the meaning of "pointy haired bosses"?
>I think I can understand it, but hey, I want to know if these are the 
kinds
>of bosses I encountered too often..

It's from the Dilbert Comic Strip :)

Wikipedia:
http://en.wikipedia.org/wiki/Pointy-Haired_Boss

"The Pointy-Haired Boss (often abbreviated to just PHB) is Dilbert's boss 
in the Dilbert comic strip. He is notable for his micromanagement, gross 
incompetence and unawareness of his surroundings, yet somehow retains 
power in the workplace."

Re: Help with Wicket Adoption Numbers

[Bert]

It a figure from the famous dilbert comics.

here is an image of him:

http://files.myopera.com/ThePast/albums/170779/pointy%20haired%20boss.jpg

Enjoy

On Mon, Jan 11, 2010 at 08:58, Eyal Golan  wrote:
> As my English is not my mother's tongue, even though I do speak it pretty
> good, what is the meaning of "pointy haired bosses"?
> I think I can understand it, but hey, I want to know if these are the kinds
> of bosses I encountered too often..
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Help with Wicket Adoption Numbers

[Ernesto Reinaldo Barreiro]

Hi Lester,

Right now I'm in a similar situation: I'm working for a company that wants
to (possibly) change from struts 1.X to something else and it is my job
"present" the choices to the developers and managers, so that they can
decide which will be the next framework the company will adopt for WEB
development. I'm also trying to get Wicket adopted over the other candidates
but that won't be easy...

I fully agree with Jonathan: the only thing PHBs care about is theirs own
personal interests... So, they pay special attention to keep themselves "on
the safe side of the fence".

Cheers,

Ernesto

On Mon, Jan 11, 2010 at 8:17 AM, Lester Chua  wrote:

> Jonathan,
>
> Bingo, I think you may have hit it on the spot.
>
> Igor,
>
> I have not managed to get a reply on how they determined Struts2 to be
> better supported compared to Wicket. But I suspect the list of a approved
> technologies is not very updated. I.e. the evaluation was probably done 2
> years ago.
>
> Thanks for all the responses. The anecdotes and points made were very
> helpful and have helped out get out of my depression over the weekend. And I
> have written a long and hopefully thoughtful reply to the technical
> committee and will keep you guys posted.
>
> Lester
>
>
>
> Jonathan Locke wrote:
>
>> honestly, your response is too thoughtful. these pointy haired bosses are
>> self-serving. they don't care about training costs or developer pain and
>> they don't really care if their org runs efficiently.  what they care
>> about
>> is that if there is a failure, their choice didn't cause it.  which is why
>> the old saying goes "nobody ever got fired for buying IBM."  same seems to
>> go for struts.  an idiotic technology choice, but you won't get fired for
>> making the same idiotic choice everyone else is making.
>>
>>
>> Loritsch, Berin C. wrote:
>>
>>
>>> "But why choose an inferior technology just because of its adoption
>>> numbers?"
>>>
>>> The pointy haired bosses that do this believe in their heart of hearts
>>> that if you choose the same technology everyone else is using that they
>>> can turn thinking developers for mindless drones.  It has more to do
>>> with avoiding training costs and rational thought, and more to do with
>>> trying to turn software development into an assembly line process.
>>> Reality never fits this mold, but it doesn't stop the pointy haired boss
>>> from trying.  In this respect they are eternal optimists.
>>>
>>> -Original Message-
>>> From: leo.erlands...@tyringe.com [mailto:leo.erlands...@tyringe.com]
>>> Sent: Friday, January 08, 2010 4:09 AM
>>> To: users@wicket.apache.org
>>> Subject: Re: Help with Wicket Adoption Numbers
>>>
>>> Hi,
>>>
>>> We also had the same consideration when we chose Wicket. But why choose
>>> an inferior technology just because of it's Adoption Numbers? Also,
>>> Wicket
>>> is becoming more and more popular as people see the light :)
>>>
>>> Check out Jobs Trends (Relative Growth) here (JSF vs Struts vs Wicket):
>>> http://www.indeed.com/jobtrends?q=Struts%2C+JSF%2C+Wicket&l=&relative=1
>>>
>>> We have a couple of hundred customers and so far the feedback is great
>>> both from our Developers and our Software Architects. Customers like
>>> that the GUIs are faster due to the simplicity of Ajax Adoption in
>>> Wicket.
>>>
>>> I also know that several large privately held companies in Sweden are
>>> using Wicket, as well as large Government Agencies (e.g. the Swedish
>>> Immigration Office).
>>>
>>>
>>> Sincerely yours
>>> Leo Erlandsson
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: [OT] ASP.NET equivalent of WicketTester?

[Martijn Dashorst]

He wasn't impressed by the capabilities of Wicket, and made the other
team switch to Wicket instead? Might be easier :)

Martijn

On Sun, Jan 10, 2010 at 7:03 PM, Steve Hiller  wrote:
> My manager was so impressed by the unit testing capabilities of the 
> WicketTester class
> that he asked me to research for an ASP.NET equivalent, to be used by another 
> development
> team. I didn't find anything obvious by googling? Anybody know of a useful 
> tool?
>
> Thanks!
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Help with Wicket Adoption Numbers

[Lester Chua]

Hi Ernesto,

Cant offer much advise here myself. The others have already great tips 
as well as morale support.
If you are up to it, you should do a fair-sized prototype (with 
multi-forms/multi girds+ajax in typical pages) and just kick their arses.
In my situation, we did a mini project with it and were just blow away 
with the results.
I find it frustrating when technical evaluators do not sit down and get 
their hands dirty while making decisions that will affect whole 
companies' competitiveness and productivity.
When making recommendations, we should do a detailed hands on the 
technology and should not just cut and paste whatever we find off the 
web and present it as having done our research. Doing tutorials only are 
also dangerous as they typically cover only a small subset of use cases 
and normally do not illustrate the complex UI's that can arises from 
users requests.


Regards,

Lester

Ernesto Reinaldo Barreiro wrote:

Hi Lester,

Right now I'm in a similar situation: I'm working for a company that wants
to (possibly) change from struts 1.X to something else and it is my job
"present" the choices to the developers and managers, so that they can
decide which will be the next framework the company will adopt for WEB
development. I'm also trying to get Wicket adopted over the other candidates
but that won't be easy...

I fully agree with Jonathan: the only thing PHBs care about is theirs own
personal interests... So, they pay special attention to keep themselves "on
the safe side of the fence".

Cheers,

Ernesto

On Mon, Jan 11, 2010 at 8:17 AM, Lester Chua  wrote:

  

Jonathan,

Bingo, I think you may have hit it on the spot.

Igor,

I have not managed to get a reply on how they determined Struts2 to be
better supported compared to Wicket. But I suspect the list of a approved
technologies is not very updated. I.e. the evaluation was probably done 2
years ago.

Thanks for all the responses. The anecdotes and points made were very
helpful and have helped out get out of my depression over the weekend. And I
have written a long and hopefully thoughtful reply to the technical
committee and will keep you guys posted.

Lester



Jonathan Locke wrote:



honestly, your response is too thoughtful. these pointy haired bosses are
self-serving. they don't care about training costs or developer pain and
they don't really care if their org runs efficiently.  what they care
about
is that if there is a failure, their choice didn't cause it.  which is why
the old saying goes "nobody ever got fired for buying IBM."  same seems to
go for struts.  an idiotic technology choice, but you won't get fired for
making the same idiotic choice everyone else is making.


Loritsch, Berin C. wrote:


  

"But why choose an inferior technology just because of its adoption
numbers?"

The pointy haired bosses that do this believe in their heart of hearts
that if you choose the same technology everyone else is using that they
can turn thinking developers for mindless drones.  It has more to do
with avoiding training costs and rational thought, and more to do with
trying to turn software development into an assembly line process.
Reality never fits this mold, but it doesn't stop the pointy haired boss
from trying.  In this respect they are eternal optimists.

-Original Message-
From: leo.erlands...@tyringe.com [mailto:leo.erlands...@tyringe.com]
Sent: Friday, January 08, 2010 4:09 AM
To: users@wicket.apache.org
Subject: Re: Help with Wicket Adoption Numbers

Hi,

We also had the same consideration when we chose Wicket. But why choose
an inferior technology just because of it's Adoption Numbers? Also,
Wicket
is becoming more and more popular as people see the light :)

Check out Jobs Trends (Relative Growth) here (JSF vs Struts vs Wicket):
http://www.indeed.com/jobtrends?q=Struts%2C+JSF%2C+Wicket&l=&relative=1

We have a couple of hundred customers and so far the feedback is great
both from our Developers and our Software Architects. Customers like
that the GUIs are faster due to the simplicity of Ajax Adoption in
Wicket.

I also know that several large privately held companies in Sweden are
using Wicket, as well as large Government Agencies (e.g. the Swedish
Immigration Office).


Sincerely yours
Leo Erlandsson


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org








  

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org





  



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: [whishlist] JS libraries

[Cemal Bayramoglu]

Ernesto,
Sounds good - just drop us a line, ideally with a Skype id, a timezone
and any thoughts/experience you have on WiQuery, via our "Contact Us"
page and one of us should be in touch towards the end of the week or
early next week.

Regards - Cemal
jWeekend
OO & Java Technologies, Wicket
Consulting, Development, Training
http://jWeekend.com


2010/1/10 Ernesto Reinaldo Barreiro :
> Hi Cemal,
> Nice to know there is already some implementation in place. Yes I would like
> to help even if it is only by testing what you have and providing some
> feed-back, although I expect to contribute a bit more than that;-). I'll
> contact you in private.
> Best,
> Ernesto
>
> On Sat, Jan 9, 2010 at 1:52 AM, Cemal Bayramoglu
>  wrote:
>>
>> Ernesto,
>>
>> jqGrid is indeed a handy component to be able to pull out of the
>> toolbox and seems to be evolving nicely.
>>
>> In fact we have been integrating/using it with Wicket as part of our
>> work on WiQuery [1], mainly for use on our own products/R&D but
>> possibly for client projects later, once we're sure jqGrid is
>> production ready and well maintained, which so far seems to be the
>> case.
>> We're not yet ready to make this public, due to our other priorities,
>> but if you'd like to get involved, drop me a line and we can have a
>> chat. I expect we're not too far now from having something quite
>> robust, and we could potentially make our existing demo pages public
>> at some point, without too much effort, for people to get a feel for
>> what can be done with jqGrid-as-a-Wicket/WiQuery component.
>> Richard has been heavily involved in this integration, but he's also
>> on other projects at the moment. However, I know he wants to expose
>> some of the more compelling 3.6 features to Wicket (again, via
>> WiQuery), like the new column selection and reordering etc, and
>> there's a good chance that API may already be working and pretty well
>> tested by Monday, especially if the weather brings London to a
>> standstill this weekend.
>> Knowing that projects like WiQuery exist and the access from Wicket it
>> facilitates to such useful jQuery components (without writing any or
>> much JavaScript), that can be relatively easily integrated, in a
>> properly thought-out, well-defined and consistent way is also good
>> ammunition for those of you on the thread re "Wicket Adoption Rates"
>> aiming to convince your managers that Wicket is the right choice.
>> We've found Wicket to be a very good choice on projects we and our
>> clients have been lucky enough to use it on.
>>
>> Regards - Cemal
>> jWeekend
>> OO & Java Technologies, Wicket
>> Consulting, Development, Training
>> http://jWeekend.com
>>
>> [1] http://code.google.com/p/wiquery/
>>
>> 2010/1/8 Ernesto Reinaldo Barreiro :
>> > If there is interest I can try to find some time and contribute an
>> > integration with
>> >
>> > http://www.trirand.com/blog/jqgrid/jqgrid.html
>> >
>> > Ernesto
>> >
>> > On Fri, Jan 8, 2010 at 7:30 PM, nino martinez wael <
>> > nino.martinez.w...@gmail.com> wrote:
>> >
>> >> Hi
>> >>
>> >> This is a whishlist for js that should be integrated with wicket but
>> >> arent.. So please go ahead and whish, I just might do an integration
>> >> if it's something I need aswell :)
>> >>
>> >> regards Nino
>> >>
>> >> -
>> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> >> For additional commands, e-mail: users-h...@wicket.apache.org
>> >>
>> >>
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: component xxx:yyy:zzz not found on page

[nino martinez wael]

I think the conclusion from the wicket reaction game was (which
consisted of a grid with a lot clickable fields and had this issue a
lot), either to veil. Or wait and see if there's anything in Wicket
1.5 that prevents this.

Im not sure if theres some thing you can override that would let
Wicket fail in silence (which essentially are what you are looking
for) when encountering missing components during ajax.

regards Nino

2010/1/9 Douglas Ferguson :
> Anybody have any thoughts on how to systematically deal with this problem 
> rather than updating every link to disable after onclick..
>
> D/
>
> On Jan 8, 2010, at 12:46 PM, nino martinez wael wrote:
>
>> I your site is "slow" and the user manages to click the delete twice i
>> could happen (I can see you write that too)..
>>
>> Put a veil over the button when it's clicked so the user cant click it 
>> twice..
>>
>> 2010/1/8 Douglas Ferguson :
>>> Our application periodically gets these errors, where wicket say the 
>>> component could not be found.
>>>
>>> Take this example.
>>>
>>> 1) There is a delete link on the page.
>>> 2) The user clicks the delete button
>>> 3) They get the "delete button" component not found error.
>>>
>>> The intriguing part is that the item is actually deleted.
>>>
>>> This makes me think it could be a double click error.
>>> i.e. the item is delete and the js has another click call queued up but the 
>>> page changes before it comes through.
>>>
>>> Is this possible? If so how do I prevent it?
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Help with Wicket Adoption Numbers

[Ernesto Reinaldo Barreiro]

Hi Lester,

What I have done is implement the same "mini" application in several
technologies:

-Struts + Spring + Hibernate
-Seam + JSF + Hibernate
-Wicket + Spring/Guice + Hibernate

With detailed explanations of how things work...

Additionally I have created  a more complex prototype of another
application, done in Wicket +Spring/Guice, which shows advanced
functionality like:

-Auto-CRUDs panels, generated out of annotated POJOs, with grids supporting
column reordering via drag-drop, export to Excel, PDF, etc.
-Workspace like functionality: a page where users can work with different
floating panels as in a desktop. One of these windows contains an AJAX
driven wizard and the others are search screens the user can use to check
information while using the wizard...
-Trees, Palettes, Grids, etc.

In a couple of weeks we have some training sessions... and after that a
decision will be taken...

Regards,

Ernesto

On Mon, Jan 11, 2010 at 10:28 AM, Lester Chua  wrote:

> Hi Ernesto,
>
> Cant offer much advise here myself. The others have already great tips as
> well as morale support.
> If you are up to it, you should do a fair-sized prototype (with
> multi-forms/multi girds+ajax in typical pages) and just kick their arses.
> In my situation, we did a mini project with it and were just blow away with
> the results.
> I find it frustrating when technical evaluators do not sit down and get
> their hands dirty while making decisions that will affect whole companies'
> competitiveness and productivity.
> When making recommendations, we should do a detailed hands on the
> technology and should not just cut and paste whatever we find off the web
> and present it as having done our research. Doing tutorials only are also
> dangerous as they typically cover only a small subset of use cases and
> normally do not illustrate the complex UI's that can arises from users
> requests.
>
> Regards,
>
> Lester
>
>
> Ernesto Reinaldo Barreiro wrote:
>
>> Hi Lester,
>>
>> Right now I'm in a similar situation: I'm working for a company that wants
>> to (possibly) change from struts 1.X to something else and it is my job
>> "present" the choices to the developers and managers, so that they can
>> decide which will be the next framework the company will adopt for WEB
>> development. I'm also trying to get Wicket adopted over the other
>> candidates
>> but that won't be easy...
>>
>> I fully agree with Jonathan: the only thing PHBs care about is theirs own
>> personal interests... So, they pay special attention to keep themselves
>> "on
>> the safe side of the fence".
>>
>> Cheers,
>>
>> Ernesto
>>
>> On Mon, Jan 11, 2010 at 8:17 AM, Lester Chua 
>> wrote:
>>
>>
>>
>>> Jonathan,
>>>
>>> Bingo, I think you may have hit it on the spot.
>>>
>>> Igor,
>>>
>>> I have not managed to get a reply on how they determined Struts2 to be
>>> better supported compared to Wicket. But I suspect the list of a approved
>>> technologies is not very updated. I.e. the evaluation was probably done 2
>>> years ago.
>>>
>>> Thanks for all the responses. The anecdotes and points made were very
>>> helpful and have helped out get out of my depression over the weekend.
>>> And I
>>> have written a long and hopefully thoughtful reply to the technical
>>> committee and will keep you guys posted.
>>>
>>> Lester
>>>
>>>
>>>
>>> Jonathan Locke wrote:
>>>
>>>
>>>
 honestly, your response is too thoughtful. these pointy haired bosses
 are
 self-serving. they don't care about training costs or developer pain and
 they don't really care if their org runs efficiently.  what they care
 about
 is that if there is a failure, their choice didn't cause it.  which is
 why
 the old saying goes "nobody ever got fired for buying IBM."  same seems
 to
 go for struts.  an idiotic technology choice, but you won't get fired
 for
 making the same idiotic choice everyone else is making.


 Loritsch, Berin C. wrote:




> "But why choose an inferior technology just because of its adoption
> numbers?"
>
> The pointy haired bosses that do this believe in their heart of hearts
> that if you choose the same technology everyone else is using that they
> can turn thinking developers for mindless drones.  It has more to do
> with avoiding training costs and rational thought, and more to do with
> trying to turn software development into an assembly line process.
> Reality never fits this mold, but it doesn't stop the pointy haired
> boss
> from trying.  In this respect they are eternal optimists.
>
> -Original Message-
> From: leo.erlands...@tyringe.com [mailto:leo.erlands...@tyringe.com]
> Sent: Friday, January 08, 2010 4:09 AM
> To: users@wicket.apache.org
> Subject: Re: Help with Wicket Adoption Numbers
>
> Hi,
>
> We also had the same consideration when we chose Wicket. But why choose
> an inferior technology just bec

Wicket does not(?) prevent multiple submits

[Muro Copenhagen]

Hi,

I have this urgent an vital problem i must solve, so i hope someone could
assist.

I am seeing this odd case of double/triple submit of forms, that should't

I hope someone can explain what goes wrong.

I have a page that i am adding a Form to. The page and form is
straightforward and contains:

public FirstPage(PageParameters parameters) {
...
MyForm form = new MyForm("myForm", kmt);
..
form.add(new SubmitLink("continue"));
add(form);
}

class MyForm extends Form {
...
protected void onSubmit() {
   MyEvent event = (MyEvent ) getSession().getApprovalEvent();
   getModelManager().handleEvent(event);
FinishEvent finishEvent = new FinishEvent ();

getModelManager().handleEvent(finishEvent );

setResponsePage(ReceiptPage.class, new
PageParameters("secure=ok"));
}
}

As i understand wicket, it should not be possible to submit the form several
times.
However i can see in the log, that a second and even a third post is
submitted, just
before the line setResponsePage(ReceiptPage.class ... is reached/executed.

The second submit will fail, because the first MyEvent must only be executed
once.

Can anyone explain how this could occur...

Thanks in advance ...
Muro

Re: Wicket does not(?) prevent multiple submits

[Uwe Schäfer]

Muro Copenhagen schrieb:


I have this urgent an vital problem i must solve, so i hope someone could
assist.


captured from the list:

http://www.codesmell.org/blog/2008/12/wicket-resubmitsafeform/

cu uwe

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Any servlet filter- like WebRequest interceptor or filter ?

[smallufo]

Hi :

I wonder if wicket has any servletFilter-like WebRequest interceptor or
filter ?
That the interceptor can intercept WebRequest or HttpSession and
pre-processing , and maybe redirect to some specified WebPage ...

Thanks a lot.

Re: Any servlet filter- like WebRequest interceptor or filter ?

[smallufo]

For example :
A Wicket application may have many WebPages or Wizards which are
inter-connected ...
The interceptor(or filter , whatever called) can monitor the user's cookie ,
when some situation matches , he will be redirected to a specified page,
after filling some forms , he will be redirect back to the original target
page or wizard step...

Is it possible in wicket ?

2010/1/11 smallufo 

> Hi :
>
> I wonder if wicket has any servletFilter-like WebRequest interceptor or
> filter ?
> That the interceptor can intercept WebRequest or HttpSession and
> pre-processing , and maybe redirect to some specified WebPage ...
>
> Thanks a lot.
>

Wicket Wizard previous

[Christoph Hochreiner]

Hi
is there any possibility to disable the "previous" button in the Wicket 
wizard, so that there is no possibility to step back.


regards
Christoph

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

I feel silly asking this

[Wayne Pope]

Ok , I think I must have a brain block or something.

Basically how do you localize the submit  on a form with having
to add a Button?
Currently we have a fairly large number of forms in the applicaiton
that just the default form onSubmit and we just add something like:


to the html.

Do we need to add Buttons to all our pages or is there a way to
specify in our application properties files what the default value
should be for submits?

many thanks

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: I feel silly asking this

[Martin Makundi]

**
Martin

2010/1/11 Wayne Pope :
> Ok , I think I must have a brain block or something.
>
> Basically how do you localize the submit  on a form with having
> to add a Button?
> Currently we have a fairly large number of forms in the applicaiton
> that just the default form onSubmit and we just add something like:
> 
>
> to the html.
>
> Do we need to add Buttons to all our pages or is there a way to
> specify in our application properties files what the default value
> should be for submits?
>
> many thanks
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: I feel silly asking this

[Jonas]

have a look at http://cwiki.apache.org/WICKET/wickets-xhtml-tags.html

section 'Attribute wicket:message'

On Mon, Jan 11, 2010 at 12:56 PM, Wayne Pope
 wrote:
> Ok , I think I must have a brain block or something.
>
> Basically how do you localize the submit  on a form with having
> to add a Button?
> Currently we have a fairly large number of forms in the applicaiton
> that just the default form onSubmit and we just add something like:
> 
>
> to the html.
>
> Do we need to add Buttons to all our pages or is there a way to
> specify in our application properties files what the default value
> should be for submits?
>
> many thanks
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket Wizard previous

[nino martinez wael]

Just empty the page map?

2010/1/11 Christoph Hochreiner :
> Hi
> is there any possibility to disable the "previous" button in the Wicket
> wizard, so that there is no possibility to step back.
>
> regards
> Christoph
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: [whishlist] JS libraries

[Ernesto Reinaldo Barreiro]

Done.

Regards,

Ernesto

On Mon, Jan 11, 2010 at 10:48 AM, Cemal Bayramoglu <
jweekend_for...@cabouge.com> wrote:

> Ernesto,
> Sounds good - just drop us a line, ideally with a Skype id, a timezone
> and any thoughts/experience you have on WiQuery, via our "Contact Us"
> page and one of us should be in touch towards the end of the week or
> early next week.
>
> Regards - Cemal
> jWeekend
> OO & Java Technologies, Wicket
> Consulting, Development, Training
> http://jWeekend.com
>
>
> 2010/1/10 Ernesto Reinaldo Barreiro :
> > Hi Cemal,
> > Nice to know there is already some implementation in place. Yes I would
> like
> > to help even if it is only by testing what you have and providing some
> > feed-back, although I expect to contribute a bit more than that;-). I'll
> > contact you in private.
> > Best,
> > Ernesto
> >
> > On Sat, Jan 9, 2010 at 1:52 AM, Cemal Bayramoglu
> >  wrote:
> >>
> >> Ernesto,
> >>
> >> jqGrid is indeed a handy component to be able to pull out of the
> >> toolbox and seems to be evolving nicely.
> >>
> >> In fact we have been integrating/using it with Wicket as part of our
> >> work on WiQuery [1], mainly for use on our own products/R&D but
> >> possibly for client projects later, once we're sure jqGrid is
> >> production ready and well maintained, which so far seems to be the
> >> case.
> >> We're not yet ready to make this public, due to our other priorities,
> >> but if you'd like to get involved, drop me a line and we can have a
> >> chat. I expect we're not too far now from having something quite
> >> robust, and we could potentially make our existing demo pages public
> >> at some point, without too much effort, for people to get a feel for
> >> what can be done with jqGrid-as-a-Wicket/WiQuery component.
> >> Richard has been heavily involved in this integration, but he's also
> >> on other projects at the moment. However, I know he wants to expose
> >> some of the more compelling 3.6 features to Wicket (again, via
> >> WiQuery), like the new column selection and reordering etc, and
> >> there's a good chance that API may already be working and pretty well
> >> tested by Monday, especially if the weather brings London to a
> >> standstill this weekend.
> >> Knowing that projects like WiQuery exist and the access from Wicket it
> >> facilitates to such useful jQuery components (without writing any or
> >> much JavaScript), that can be relatively easily integrated, in a
> >> properly thought-out, well-defined and consistent way is also good
> >> ammunition for those of you on the thread re "Wicket Adoption Rates"
> >> aiming to convince your managers that Wicket is the right choice.
> >> We've found Wicket to be a very good choice on projects we and our
> >> clients have been lucky enough to use it on.
> >>
> >> Regards - Cemal
> >> jWeekend
> >> OO & Java Technologies, Wicket
> >> Consulting, Development, Training
> >> http://jWeekend.com
> >>
> >> [1] http://code.google.com/p/wiquery/
> >>
> >> 2010/1/8 Ernesto Reinaldo Barreiro :
> >> > If there is interest I can try to find some time and contribute an
> >> > integration with
> >> >
> >> > http://www.trirand.com/blog/jqgrid/jqgrid.html
> >> >
> >> > Ernesto
> >> >
> >> > On Fri, Jan 8, 2010 at 7:30 PM, nino martinez wael <
> >> > nino.martinez.w...@gmail.com> wrote:
> >> >
> >> >> Hi
> >> >>
> >> >> This is a whishlist for js that should be integrated with wicket but
> >> >> arent.. So please go ahead and whish, I just might do an integration
> >> >> if it's something I need aswell :)
> >> >>
> >> >> regards Nino
> >> >>
> >> >> -
> >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >> >>
> >> >>
> >> >
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Help with Wicket Adoption Numbers

[Per Lundholm]

Since the PHB like to stay on the safe side of the fence, make them feel
safe with Wicket.

Tell successtories about Wicket. Tell failstories about other systems. :-)

/Per

On Mon, Jan 11, 2010 at 10:06 AM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> Hi Lester,
>
> Right now I'm in a similar situation: I'm working for a company that wants
> to (possibly) change from struts 1.X to something else and it is my job
> "present" the choices to the developers and managers, so that they can
> decide which will be the next framework the company will adopt for WEB
> development. I'm also trying to get Wicket adopted over the other
> candidates
> but that won't be easy...
>
> I fully agree with Jonathan: the only thing PHBs care about is theirs own
> personal interests... So, they pay special attention to keep themselves "on
> the safe side of the fence".
>
> Cheers,
>
> Ernesto
>
> On Mon, Jan 11, 2010 at 8:17 AM, Lester Chua  wrote:
>
> > Jonathan,
> >
> > Bingo, I think you may have hit it on the spot.
> >
> > Igor,
> >
> > I have not managed to get a reply on how they determined Struts2 to be
> > better supported compared to Wicket. But I suspect the list of a approved
> > technologies is not very updated. I.e. the evaluation was probably done 2
> > years ago.
> >
> > Thanks for all the responses. The anecdotes and points made were very
> > helpful and have helped out get out of my depression over the weekend.
> And I
> > have written a long and hopefully thoughtful reply to the technical
> > committee and will keep you guys posted.
> >
> > Lester
> >
> >
> >
> > Jonathan Locke wrote:
> >
> >> honestly, your response is too thoughtful. these pointy haired bosses
> are
> >> self-serving. they don't care about training costs or developer pain and
> >> they don't really care if their org runs efficiently.  what they care
> >> about
> >> is that if there is a failure, their choice didn't cause it.  which is
> why
> >> the old saying goes "nobody ever got fired for buying IBM."  same seems
> to
> >> go for struts.  an idiotic technology choice, but you won't get fired
> for
> >> making the same idiotic choice everyone else is making.
> >>
> >>
> >> Loritsch, Berin C. wrote:
> >>
> >>
> >>> "But why choose an inferior technology just because of its adoption
> >>> numbers?"
> >>>
> >>> The pointy haired bosses that do this believe in their heart of hearts
> >>> that if you choose the same technology everyone else is using that they
> >>> can turn thinking developers for mindless drones.  It has more to do
> >>> with avoiding training costs and rational thought, and more to do with
> >>> trying to turn software development into an assembly line process.
> >>> Reality never fits this mold, but it doesn't stop the pointy haired
> boss
> >>> from trying.  In this respect they are eternal optimists.
> >>>
> >>> -Original Message-
> >>> From: leo.erlands...@tyringe.com [mailto:leo.erlands...@tyringe.com]
> >>> Sent: Friday, January 08, 2010 4:09 AM
> >>> To: users@wicket.apache.org
> >>> Subject: Re: Help with Wicket Adoption Numbers
> >>>
> >>> Hi,
> >>>
> >>> We also had the same consideration when we chose Wicket. But why choose
> >>> an inferior technology just because of it's Adoption Numbers? Also,
> >>> Wicket
> >>> is becoming more and more popular as people see the light :)
> >>>
> >>> Check out Jobs Trends (Relative Growth) here (JSF vs Struts vs Wicket):
> >>>
> http://www.indeed.com/jobtrends?q=Struts%2C+JSF%2C+Wicket&l=&relative=1
> >>>
> >>> We have a couple of hundred customers and so far the feedback is great
> >>> both from our Developers and our Software Architects. Customers like
> >>> that the GUIs are faster due to the simplicity of Ajax Adoption in
> >>> Wicket.
> >>>
> >>> I also know that several large privately held companies in Sweden are
> >>> using Wicket, as well as large Government Agencies (e.g. the Swedish
> >>> Immigration Office).
> >>>
> >>>
> >>> Sincerely yours
> >>> Leo Erlandsson
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
>

Re: [OT] ASP.NET equivalent of WicketTester?

[shetc]

It's a legacy system written by another non-IT department -- we are now
supporting it
but not permitted to rewrite it. So my manager would like to stabilize it by
adding some 
unit/integration testing. Such is the way of the corporate world...
-- 
View this message in context: 
http://old.nabble.com/-OT---ASP.NET-equivalent-of-WicketTester--tp27100736p27109691.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: [OT] ASP.NET equivalent of WicketTester?

[Martijn Dashorst]

I might suggest webdriver (which is not embedded as WicketTester, but
provides a similar api)

Martijn

On Mon, Jan 11, 2010 at 1:28 PM, shetc  wrote:
>
> It's a legacy system written by another non-IT department -- we are now
> supporting it
> but not permitted to rewrite it. So my manager would like to stabilize it by
> adding some
> unit/integration testing. Such is the way of the corporate world...
> --
> View this message in context: 
> http://old.nabble.com/-OT---ASP.NET-equivalent-of-WicketTester--tp27100736p27109691.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.4

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

JVM crash, Wicket class mentioned

[Steve Swinsburg]

Hi,

This came up on another list I am part of, and being a member of this list, 
thought I'd ask here to see if this is a known fixed issue. This is with an app 
written using Wicket 1.3.0. Essentially, the JVM crashed with this error under 
Java 1.6, the same app runs fine under Java 1.5:

#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x2b5fa7fb, pid=21669, tid=1218128192
#
# JRE version: 6.0_17-b04
# Java VM: Java HotSpot(TM) 64-Bit Server VM (14.3-b01 mixed mode
linux-amd64 )
# Problematic frame:
# J
org.apache.wicket.util.io.WicketObjectOutputStream.writeObjectOverride(Ljava/lang/Object;)V

Some relevant parts from the log:

Stack: [0x488b2000,0x489b3000],  sp=0x489af470,  free 
space=1013k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
J  
org.apache.wicket.util.io.WicketObjectOutputStream.writeObjectOverride(Ljava/lang/Object;)V

2aac13c5d000-2aac13c81000 r-xs 0017e000 fd:01 1204727
/usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-1.3.0.jar
2aac13c81000-2aac13c83000 r-xs 0002d000 fd:01 1204728
/usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-datetime-1.3.0.jar
2aac13c83000-2aac13c8e000 r-xs 0004e000 fd:01 1204719
/usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-extensions-1.3.0.jar
2aac13c8e000-2aac13c9 r-xs 4000 fd:01 1204722
/usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-ioc-1.3.0.jar
2aac13c9-2aac13c92000 r-xs 3000 fd:01 1204729
/usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-spring-1.3.0.jar
2aac13c92000-2aac13c93000 r-xs 3000 fd:01 1204724
/usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-spring-annot-1.3.0.jar


I can send the log to interest parties, but there is only this reference to the 
Wicket class, as well as a few Wicket jars on the classpath, unless there is 
more you need to see.

So, any known issues? An upgrade is required of course, but we'd like to 
resolve what the problem was to start with.

thanks,
Steve




smime.p7s
Description: S/MIME cryptographic signature

Re: JVM crash, Wicket class mentioned

[Martin Makundi]

Hi!

Did you try newer jvm build?

**
Martin

2010/1/11 Steve Swinsburg :
> Hi,
>
> This came up on another list I am part of, and being a member of this list, 
> thought I'd ask here to see if this is a known fixed issue. This is with an 
> app written using Wicket 1.3.0. Essentially, the JVM crashed with this error 
> under Java 1.6, the same app runs fine under Java 1.5:
>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x2b5fa7fb, pid=21669, tid=1218128192
> #
> # JRE version: 6.0_17-b04
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (14.3-b01 mixed mode
> linux-amd64 )
> # Problematic frame:
> # J
> org.apache.wicket.util.io.WicketObjectOutputStream.writeObjectOverride(Ljava/lang/Object;)V
>
> Some relevant parts from the log:
>
> Stack: [0x488b2000,0x489b3000],  sp=0x489af470,  free 
> space=1013k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> J  
> org.apache.wicket.util.io.WicketObjectOutputStream.writeObjectOverride(Ljava/lang/Object;)V
>
> 2aac13c5d000-2aac13c81000 r-xs 0017e000 fd:01 1204727                    
> /usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-1.3.0.jar
> 2aac13c81000-2aac13c83000 r-xs 0002d000 fd:01 1204728                    
> /usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-datetime-1.3.0.jar
> 2aac13c83000-2aac13c8e000 r-xs 0004e000 fd:01 1204719                    
> /usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-extensions-1.3.0.jar
> 2aac13c8e000-2aac13c9 r-xs 4000 fd:01 1204722                    
> /usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-ioc-1.3.0.jar
> 2aac13c9-2aac13c92000 r-xs 3000 fd:01 1204729                    
> /usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-spring-1.3.0.jar
> 2aac13c92000-2aac13c93000 r-xs 3000 fd:01 1204724                    
> /usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-spring-annot-1.3.0.jar
>
>
> I can send the log to interest parties, but there is only this reference to 
> the Wicket class, as well as a few Wicket jars on the classpath, unless there 
> is more you need to see.
>
> So, any known issues? An upgrade is required of course, but we'd like to 
> resolve what the problem was to start with.
>
> thanks,
> Steve
>
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: [OT] ASP.NET equivalent of WicketTester?

[shetc]

Thanks Martijn -- I'll have a look. I guess the main thing I was looking for
is the ability to test using
a plain JUnit class without the need for a browser or app server.
-- 
View this message in context: 
http://old.nabble.com/-OT---ASP.NET-equivalent-of-WicketTester--tp27100736p27110052.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: JVM crash, Wicket class mentioned

[Steve Swinsburg]

Hi Martin,

I'll pass that on, but the JRE version is 1.6.0_17-b04 unless you mean the 
14.3-b01 VM version?

Heres the system info from the log:


OS:SUSE Linux Enterprise Server 10 (x86_64)
VERSION = 10
PATCHLEVEL = 2

uname:Linux 2.6.16.60-0.42.5-smp #1 SMP Mon Aug 24 09:41:41 UTC 2009 x86_64
libc:glibc 2.4 NPTL 2.4 
rlimit: STACK 8192k, CORE 0k, NPROC 69119, NOFILE 10, AS infinity
load average:0.32 1.14 0.74

CPU:total 4 (1 cores per cpu, 2 threads per core) family 15 model 4 stepping 1, 
cmov, cx8, fxsr, mmx, sse, sse2, sse3, ht

Memory: 4k page, physical 8118936k(50388k free), swap 5242872k(5179744k free)

vm_info: Java HotSpot(TM) 64-Bit Server VM (14.3-b01) for linux-amd64 JRE 
(1.6.0_17-b04), built on Oct 11 2009 01:08:48 by "java_re" with gcc 3.2.2 (SuSE 
Linux)

time: Sat Jan  9 18:54:46 2010
elapsed time: 536 seconds


cheers,
Steve

On 11/01/2010, at 11:54 PM, Martin Makundi wrote:

> Hi!
> 
> Did you try newer jvm build?
> 
> **
> Martin
> 
> 2010/1/11 Steve Swinsburg :
>> Hi,
>> 
>> This came up on another list I am part of, and being a member of this list, 
>> thought I'd ask here to see if this is a known fixed issue. This is with an 
>> app written using Wicket 1.3.0. Essentially, the JVM crashed with this error 
>> under Java 1.6, the same app runs fine under Java 1.5:
>> 
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # SIGSEGV (0xb) at pc=0x2b5fa7fb, pid=21669, tid=1218128192
>> #
>> # JRE version: 6.0_17-b04
>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (14.3-b01 mixed mode
>> linux-amd64 )
>> # Problematic frame:
>> # J
>> org.apache.wicket.util.io.WicketObjectOutputStream.writeObjectOverride(Ljava/lang/Object;)V
>> 
>> Some relevant parts from the log:
>> 
>> Stack: [0x488b2000,0x489b3000],  sp=0x489af470,  
>> free space=1013k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
>> code)
>> J  
>> org.apache.wicket.util.io.WicketObjectOutputStream.writeObjectOverride(Ljava/lang/Object;)V
>> 
>> 2aac13c5d000-2aac13c81000 r-xs 0017e000 fd:01 1204727
>> /usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-1.3.0.jar
>> 2aac13c81000-2aac13c83000 r-xs 0002d000 fd:01 1204728
>> /usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-datetime-1.3.0.jar
>> 2aac13c83000-2aac13c8e000 r-xs 0004e000 fd:01 1204719
>> /usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-extensions-1.3.0.jar
>> 2aac13c8e000-2aac13c9 r-xs 4000 fd:01 1204722
>> /usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-ioc-1.3.0.jar
>> 2aac13c9-2aac13c92000 r-xs 3000 fd:01 1204729
>> /usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-spring-1.3.0.jar
>> 2aac13c92000-2aac13c93000 r-xs 3000 fd:01 1204724
>> /usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-spring-annot-1.3.0.jar
>> 
>> 
>> I can send the log to interest parties, but there is only this reference to 
>> the Wicket class, as well as a few Wicket jars on the classpath, unless 
>> there is more you need to see.
>> 
>> So, any known issues? An upgrade is required of course, but we'd like to 
>> resolve what the problem was to start with.
>> 
>> thanks,
>> Steve
>> 
>> 
>> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: I feel silly asking this

[Wayne Pope]

of course the attribute !

ah monday mornings.

thanks everyone!


On Mon, Jan 11, 2010 at 1:00 PM, Jonas  wrote:
> have a look at http://cwiki.apache.org/WICKET/wickets-xhtml-tags.html
>
> section 'Attribute wicket:message'
>
> On Mon, Jan 11, 2010 at 12:56 PM, Wayne Pope
>  wrote:
>> Ok , I think I must have a brain block or something.
>>
>> Basically how do you localize the submit  on a form with having
>> to add a Button?
>> Currently we have a fairly large number of forms in the applicaiton
>> that just the default form onSubmit and we just add something like:
>> 
>>
>> to the html.
>>
>> Do we need to add Buttons to all our pages or is there a way to
>> specify in our application properties files what the default value
>> should be for submits?
>>
>> many thanks
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: JVM crash, Wicket class mentioned

[Martin Makundi]

Hi!

No, I remember having similar problems before and they were fixed by
upgarding jvm (1.6.0_17 -> 1.6.0_18 for example).

**
Martin

2010/1/11 Steve Swinsburg :
> Hi Martin,
>
> I'll pass that on, but the JRE version is 1.6.0_17-b04 unless you mean the 
> 14.3-b01 VM version?
>
> Heres the system info from the log:
>
> 
> OS:SUSE Linux Enterprise Server 10 (x86_64)
> VERSION = 10
> PATCHLEVEL = 2
>
> uname:Linux 2.6.16.60-0.42.5-smp #1 SMP Mon Aug 24 09:41:41 UTC 2009 x86_64
> libc:glibc 2.4 NPTL 2.4
> rlimit: STACK 8192k, CORE 0k, NPROC 69119, NOFILE 10, AS infinity
> load average:0.32 1.14 0.74
>
> CPU:total 4 (1 cores per cpu, 2 threads per core) family 15 model 4 stepping 
> 1, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ht
>
> Memory: 4k page, physical 8118936k(50388k free), swap 5242872k(5179744k free)
>
> vm_info: Java HotSpot(TM) 64-Bit Server VM (14.3-b01) for linux-amd64 JRE 
> (1.6.0_17-b04), built on Oct 11 2009 01:08:48 by "java_re" with gcc 3.2.2 
> (SuSE Linux)
>
> time: Sat Jan  9 18:54:46 2010
> elapsed time: 536 seconds
> 
>
> cheers,
> Steve
>
> On 11/01/2010, at 11:54 PM, Martin Makundi wrote:
>
>> Hi!
>>
>> Did you try newer jvm build?
>>
>> **
>> Martin
>>
>> 2010/1/11 Steve Swinsburg :
>>> Hi,
>>>
>>> This came up on another list I am part of, and being a member of this list, 
>>> thought I'd ask here to see if this is a known fixed issue. This is with an 
>>> app written using Wicket 1.3.0. Essentially, the JVM crashed with this 
>>> error under Java 1.6, the same app runs fine under Java 1.5:
>>>
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #
>>> # SIGSEGV (0xb) at pc=0x2b5fa7fb, pid=21669, tid=1218128192
>>> #
>>> # JRE version: 6.0_17-b04
>>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (14.3-b01 mixed mode
>>> linux-amd64 )
>>> # Problematic frame:
>>> # J
>>> org.apache.wicket.util.io.WicketObjectOutputStream.writeObjectOverride(Ljava/lang/Object;)V
>>>
>>> Some relevant parts from the log:
>>>
>>> Stack: [0x488b2000,0x489b3000],  sp=0x489af470,  
>>> free space=1013k
>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
>>> code)
>>> J  
>>> org.apache.wicket.util.io.WicketObjectOutputStream.writeObjectOverride(Ljava/lang/Object;)V
>>>
>>> 2aac13c5d000-2aac13c81000 r-xs 0017e000 fd:01 1204727                    
>>> /usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-1.3.0.jar
>>> 2aac13c81000-2aac13c83000 r-xs 0002d000 fd:01 1204728                    
>>> /usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-datetime-1.3.0.jar
>>> 2aac13c83000-2aac13c8e000 r-xs 0004e000 fd:01 1204719                    
>>> /usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-extensions-1.3.0.jar
>>> 2aac13c8e000-2aac13c9 r-xs 4000 fd:01 1204722                    
>>> /usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-ioc-1.3.0.jar
>>> 2aac13c9-2aac13c92000 r-xs 3000 fd:01 1204729                    
>>> /usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-spring-1.3.0.jar
>>> 2aac13c92000-2aac13c93000 r-xs 3000 fd:01 1204724                    
>>> /usr/local/xxx/webapps/the-app/WEB-INF/lib/wicket-spring-annot-1.3.0.jar
>>>
>>>
>>> I can send the log to interest parties, but there is only this reference to 
>>> the Wicket class, as well as a few Wicket jars on the classpath, unless 
>>> there is more you need to see.
>>>
>>> So, any known issues? An upgrade is required of course, but we'd like to 
>>> resolve what the problem was to start with.
>>>
>>> thanks,
>>> Steve
>>>
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: JVM crash, Wicket class mentioned

[Reinout van Schouwen]

Op maandag 11-01-2010 om 15:07 uur [tijdzone +0200], schreef Martin
Makundi:
> Hi!
> 
> No, I remember having similar problems before and they were fixed by
> upgarding jvm (1.6.0_17 -> 1.6.0_18 for example).

For what it's worth, I've had better luck with the OpenJDK on 64-bit
Linux than with the Sun 64-bit JDK. It might have been fixed in the mean
time but when I tried it I suffered from random JVM crashes.

regards,

-- 
Reinout van Schouwen


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Lazy loading

[Giovanni]

In my current project, we have many situations in which we have to load a page, 
which is very slow. The slowness is not because of Wicket, but because there 
are heavy queries on the DB.

In some of these situations, we used the AjaxLazyLoadPanel, when we have to 
load a "slow" panel.

In some other situations, when we are not loading a panel, but a page, how can 
we do to prevent the user from "crazy clicking" on the application, because he 
is impatient with the slow loading?

More generally, is there a standard way to disable all the links and click-able 
components of the application, while a new component is loading?

best regards,
giovanni


  

Re: Help with Wicket Adoption Numbers

[manuelbarzi]

may you take into account the new "wicket-like" framework, Apache Click,
too, just passing the incubator now... as another alternative to compare
with, but also to show the tendency - and then the present and future - of
web presentation frameworks... ;)

On Mon, Jan 11, 2010 at 1:12 PM, Per Lundholm wrote:

> Since the PHB like to stay on the safe side of the fence, make them feel
> safe with Wicket.
>
> Tell successtories about Wicket. Tell failstories about other systems. :-)
>
> /Per
>
> On Mon, Jan 11, 2010 at 10:06 AM, Ernesto Reinaldo Barreiro <
> reier...@gmail.com> wrote:
>
> > Hi Lester,
> >
> > Right now I'm in a similar situation: I'm working for a company that
> wants
> > to (possibly) change from struts 1.X to something else and it is my job
> > "present" the choices to the developers and managers, so that they can
> > decide which will be the next framework the company will adopt for WEB
> > development. I'm also trying to get Wicket adopted over the other
> > candidates
> > but that won't be easy...
> >
> > I fully agree with Jonathan: the only thing PHBs care about is theirs own
> > personal interests... So, they pay special attention to keep themselves
> "on
> > the safe side of the fence".
> >
> > Cheers,
> >
> > Ernesto
> >
> > On Mon, Jan 11, 2010 at 8:17 AM, Lester Chua 
> wrote:
> >
> > > Jonathan,
> > >
> > > Bingo, I think you may have hit it on the spot.
> > >
> > > Igor,
> > >
> > > I have not managed to get a reply on how they determined Struts2 to be
> > > better supported compared to Wicket. But I suspect the list of a
> approved
> > > technologies is not very updated. I.e. the evaluation was probably done
> 2
> > > years ago.
> > >
> > > Thanks for all the responses. The anecdotes and points made were very
> > > helpful and have helped out get out of my depression over the weekend.
> > And I
> > > have written a long and hopefully thoughtful reply to the technical
> > > committee and will keep you guys posted.
> > >
> > > Lester
> > >
> > >
> > >
> > > Jonathan Locke wrote:
> > >
> > >> honestly, your response is too thoughtful. these pointy haired bosses
> > are
> > >> self-serving. they don't care about training costs or developer pain
> and
> > >> they don't really care if their org runs efficiently.  what they care
> > >> about
> > >> is that if there is a failure, their choice didn't cause it.  which is
> > why
> > >> the old saying goes "nobody ever got fired for buying IBM."  same
> seems
> > to
> > >> go for struts.  an idiotic technology choice, but you won't get fired
> > for
> > >> making the same idiotic choice everyone else is making.
> > >>
> > >>
> > >> Loritsch, Berin C. wrote:
> > >>
> > >>
> > >>> "But why choose an inferior technology just because of its adoption
> > >>> numbers?"
> > >>>
> > >>> The pointy haired bosses that do this believe in their heart of
> hearts
> > >>> that if you choose the same technology everyone else is using that
> they
> > >>> can turn thinking developers for mindless drones.  It has more to do
> > >>> with avoiding training costs and rational thought, and more to do
> with
> > >>> trying to turn software development into an assembly line process.
> > >>> Reality never fits this mold, but it doesn't stop the pointy haired
> > boss
> > >>> from trying.  In this respect they are eternal optimists.
> > >>>
> > >>> -Original Message-
> > >>> From: leo.erlands...@tyringe.com [mailto:leo.erlands...@tyringe.com]
> > >>> Sent: Friday, January 08, 2010 4:09 AM
> > >>> To: users@wicket.apache.org
> > >>> Subject: Re: Help with Wicket Adoption Numbers
> > >>>
> > >>> Hi,
> > >>>
> > >>> We also had the same consideration when we chose Wicket. But why
> choose
> > >>> an inferior technology just because of it's Adoption Numbers? Also,
> > >>> Wicket
> > >>> is becoming more and more popular as people see the light :)
> > >>>
> > >>> Check out Jobs Trends (Relative Growth) here (JSF vs Struts vs
> Wicket):
> > >>>
> > http://www.indeed.com/jobtrends?q=Struts%2C+JSF%2C+Wicket&l=&relative=1
> > >>>
> > >>> We have a couple of hundred customers and so far the feedback is
> great
> > >>> both from our Developers and our Software Architects. Customers like
> > >>> that the GUIs are faster due to the simplicity of Ajax Adoption in
> > >>> Wicket.
> > >>>
> > >>> I also know that several large privately held companies in Sweden are
> > >>> using Wicket, as well as large Government Agencies (e.g. the Swedish
> > >>> Immigration Office).
> > >>>
> > >>>
> > >>> Sincerely yours
> > >>> Leo Erlandsson
> > >>>
> > >>>
> > >>> -
> > >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > >>> For additional commands, e-mail: users-h...@wicket.apache.org
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >

Re: Lazy loading

[James Carman]

Using a "veil" perhaps?

On Mon, Jan 11, 2010 at 8:43 AM, Giovanni  wrote:
> In my current project, we have many situations in which we have to load a 
> page, which is very slow. The slowness is not because of Wicket, but because 
> there are heavy queries on the DB.
>
> In some of these situations, we used the AjaxLazyLoadPanel, when we have to 
> load a "slow" panel.
>
> In some other situations, when we are not loading a panel, but a page, how 
> can we do to prevent the user from "crazy clicking" on the application, 
> because he is impatient with the slow loading?
>
> More generally, is there a standard way to disable all the links and 
> click-able components of the application, while a new component is loading?
>
> best regards,
> giovanni
>
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Lazy loading

[Martin Makundi]

Hi!

What we do is we draw a full-screen transparent DIV (like modal
window) onto the screen with a "Loading" sign whenever the user clicks
any link,button anything... and we reset it when a page loads.

http://cwiki.apache.org/WICKET/generic-busy-indicator-for-both-ajax-and-non-ajax-submits.html

**
Martin

2010/1/11 Giovanni :
> In my current project, we have many situations in which we have to load a 
> page, which is very slow. The slowness is not because of Wicket, but because 
> there are heavy queries on the DB.
>
> In some of these situations, we used the AjaxLazyLoadPanel, when we have to 
> load a "slow" panel.
>
> In some other situations, when we are not loading a panel, but a page, how 
> can we do to prevent the user from "crazy clicking" on the application, 
> because he is impatient with the slow loading?
>
> More generally, is there a standard way to disable all the links and 
> click-able components of the application, while a new component is loading?
>
> best regards,
> giovanni
>
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Lazy loading

[Ilja Pavkovic]

Hi,

use a veil. You could use this one:

http://wicketinaction.com/2008/12/preventing-double-ajax-requests-in-3-lines-
of-code/

or (as I personally think it bloats the ajax links)

get familiar with some javascript, add

 to your page with a style like

#veil {
position: absolute;
z-index:1;
top: 0px;
left: 0px;
height:100%;
width:100%;
background: grey;
display: none;
}

and add some javascript to your page like 

window.wicketGlobalPreCallHandler = function() {
window.getElementById("veil").style.display="block";
};

window.wicketGlobalPostCallHandler = function() {
window.getElementById("veil").style.display="none";
};

javascript may not work as I personally use jquery here to get some more fance 
fadeIn fadeOut and I just wrote it down here :)


Best Regards,
Ilja Pavkovic


Am Montag, 11. Januar 2010 14:43:42 schrieb Giovanni:
> In my current project, we have many situations in which we have to load a
>  page, which is very slow. The slowness is not because of Wicket, but
>  because there are heavy queries on the DB.
> 
> In some of these situations, we used the AjaxLazyLoadPanel, when we have to
>  load a "slow" panel.
> 
> In some other situations, when we are not loading a panel, but a page, how
>  can we do to prevent the user from "crazy clicking" on the application,
>  because he is impatient with the slow loading?
> 
> More generally, is there a standard way to disable all the links and
>  click-able components of the application, while a new component is
>  loading?
> 
> best regards,
> giovanni
> 

-- 
binaere bauten gmbh · tempelhofer ufer 1a · 10961 berlin

   +49 · 171 · 9342 465

Handelsregister: HRB 115854 - Amtsgericht Charlottenburg
Geschäftsführer: Dipl.-Inform. Ilja Pavkovic, Dipl.-Inform. Jost Becker

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Lazy loading

[Giovanni]

Thanks a lot.

I will try your suggestion.

best regards,
giovanni





From: Martin Makundi 
To: users@wicket.apache.org
Sent: Mon, January 11, 2010 2:47:18 PM
Subject: Re: Lazy loading

Hi!

What we do is we draw a full-screen transparent DIV (like modal
window) onto the screen with a "Loading" sign whenever the user clicks
any link,button anything... and we reset it when a page loads.

http://cwiki.apache.org/WICKET/generic-busy-indicator-for-both-ajax-and-non-ajax-submits.html

**
Martin

2010/1/11 Giovanni :
> In my current project, we have many situations in which we have to load a 
> page, which is very slow. The slowness is not because of Wicket, but because 
> there are heavy queries on the DB.
>
> In some of these situations, we used the AjaxLazyLoadPanel, when we have to 
> load a "slow" panel.
>
> In some other situations, when we are not loading a panel, but a page, how 
> can we do to prevent the user from "crazy clicking" on the application, 
> because he is impatient with the slow loading?
>
> More generally, is there a standard way to disable all the links and 
> click-able components of the application, while a new component is loading?
>
> best regards,
> giovanni
>
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


  

Re: Lazy loading

[Giovanni]

Thanks a lot.

I will try your suggestion too.

best regards,
giovanni




From: Ilja Pavkovic 
To: users@wicket.apache.org
Cc: Giovanni 
Sent: Mon, January 11, 2010 3:00:28 PM
Subject: Re: Lazy loading

Hi,

use a veil. You could use this one:

http://wicketinaction.com/2008/12/preventing-double-ajax-requests-in-3-lines-
of-code/

or (as I personally think it bloats the ajax links)

get familiar with some javascript, add

 to your page with a style like

#veil {
position: absolute;
z-index:1;
top: 0px;
left: 0px;
height:100%;
width:100%;
background: grey;
display: none;
}

and add some javascript to your page like 

window.wicketGlobalPreCallHandler = function() {
window.getElementById("veil").style.display="block";
};

window.wicketGlobalPostCallHandler = function() {
window.getElementById("veil").style.display="none";
};

javascript may not work as I personally use jquery here to get some more fance 
fadeIn fadeOut and I just wrote it down here :)


Best Regards,
Ilja Pavkovic


Am Montag, 11. Januar 2010 14:43:42 schrieb Giovanni:
> In my current project, we have many situations in which we have to load a
>  page, which is very slow. The slowness is not because of Wicket, but
>  because there are heavy queries on the DB.
> 
> In some of these situations, we used the AjaxLazyLoadPanel, when we have to
>  load a "slow" panel.
> 
> In some other situations, when we are not loading a panel, but a page, how
>  can we do to prevent the user from "crazy clicking" on the application,
>  because he is impatient with the slow loading?
> 
> More generally, is there a standard way to disable all the links and
>  click-able components of the application, while a new component is
>  loading?
> 
> best regards,
> giovanni
> 

-- 
binaere bauten gmbh · tempelhofer ufer 1a · 10961 berlin

   +49 · 171 · 9342 465

Handelsregister: HRB 115854 - Amtsgericht Charlottenburg
Geschäftsführer: Dipl.-Inform. Ilja Pavkovic, Dipl.-Inform. Jost Becker

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


  

Re: Lazy loading

[Giovanni]

Thanks.

I will try it.

best regards
giovanni





From: James Carman 
To: users@wicket.apache.org
Sent: Mon, January 11, 2010 2:45:11 PM
Subject: Re: Lazy loading

Using a "veil" perhaps?

On Mon, Jan 11, 2010 at 8:43 AM, Giovanni  wrote:
> In my current project, we have many situations in which we have to load a 
> page, which is very slow. The slowness is not because of Wicket, but because 
> there are heavy queries on the DB.
>
> In some of these situations, we used the AjaxLazyLoadPanel, when we have to 
> load a "slow" panel.
>
> In some other situations, when we are not loading a panel, but a page, how 
> can we do to prevent the user from "crazy clicking" on the application, 
> because he is impatient with the slow loading?
>
> More generally, is there a standard way to disable all the links and 
> click-able components of the application, while a new component is loading?
>
> best regards,
> giovanni
>
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


  

Re: DropDownChoiceWithStylingOptions

[aditsu]

There's a small bug - endOptGroup(tmp) for "OptGroup changed" actually closes
the optgroup after the current option, not before.
I replaced it with buffer.append(""), but I wonder if there can
be some other markup after the previous  and whether that matters.

-- 
View this message in context: 
http://old.nabble.com/DropDownChoiceWithStylingOptions%3CT%3E-tp26642690p27111776.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: DropDownChoiceWithStylingOptions

[Martin Makundi]

> There's a small bug - endOptGroup(tmp) for "OptGroup changed" actually closes
> the optgroup after the current option, not before.

Note: It is supposed to close the previous optgroup. Not the current
optgroup. If there is a bug, can you give me your testcase?

**
Martin

> I replaced it with buffer.append(""), but I wonder if there can
> be some other markup after the previous  and whether that matters.
>
> --
> View this message in context: 
> http://old.nabble.com/DropDownChoiceWithStylingOptions%3CT%3E-tp26642690p27111776.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: DropDownChoiceWithStylingOptions

[aditsu]

Hi, thanks for the quick reply.


MartinM wrote:
> 
>> There's a small bug - endOptGroup(tmp) for "OptGroup changed" actually
>> closes
>> the optgroup after the current option, not before.
> 
> Note: It is supposed to close the previous optgroup. Not the current
> optgroup.
> 

Yep, that's why it's a bug. It actually starts a new optgroup and closes it
after one option.



> If there is a bug, can you give me your testcase?
> 

Sure, here's the code:


package test;

import java.io.Serializable;
import java.util.ArrayList;
import java.util.List;

import org.apache.wicket.markup.html.WebPage;

public class TestPage extends WebPage {
private static class Val implements Serializable {
private static final long serialVersionUID = 1L;

private final String text;
private final String group;

public Val(final String text, final String group) {
this.text = text;
this.group = group;
}

public String getText() {
return text;
}

public String getGroup() {
return group;
}
}

private static final IStyledChoiceRenderer R = new
IStyledChoiceRenderer() {
private static final long serialVersionUID = 1L;

@Override
public String getIdValue(final Val object, final int index) {
return String.valueOf(index);
}

@Override
public Object getDisplayValue(final Val object) {
return object.getText();
}

@Override
public String getOptionCssClassName(final Val t) {
return null;
}

@Override
public String getOptGroupLabel(final Val t) {
return t.getGroup();
}
}; 

public TestPage() {
final List list = new ArrayList();
for (int i = 0; i < 3; ++i) {
for (int j = 0; j < 3; ++j) {
list.add(new Val("text" + j, "group" + i));
}
}
add(new DropDownChoiceWithStylingOptions("test", list, R));
}
}


and the markup:










This is what it generates (I haven't stripped the wicket tags):





Choose One
text0
text1
text2
text0
text1
text2

text0
text1
text2





Adrian
-- 
View this message in context: 
http://old.nabble.com/DropDownChoiceWithStylingOptions%3CT%3E-tp26642690p27112292.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: DropDownChoiceWithStylingOptions

[Martin Makundi]

Hi!

Hmm.. mine seems to work fine with some other test cases, is this the
same code you have or is it different:

/**
   * @see 
org.apache.wicket.markup.html.form.AbstractChoice#appendOptionHtml(org.apache.wicket.util.string.AppendingStringBuffer,
java.lang.Object, int, java.lang.String)
   */
  @Override
  protected void appendOptionHtml(AppendingStringBuffer buffer, T choice,
  int index, String selected) {
AppendingStringBuffer tmp = new AppendingStringBuffer(50);
super.appendOptionHtml(tmp, choice, index, selected);

if (getChoiceRenderer() instanceof IStyledChoiceRenderer) {
  IStyledChoiceRenderer styledChoiceRenderer =
(IStyledChoiceRenderer) getChoiceRenderer();

  String currentOptGroupLabel =
styledChoiceRenderer.getOptGroupLabel(choice);

  if (!Utils.equalsOrNull(currentOptGroupLabel,
previouslyAppendedOptGroupLabel)) {
// OptGroup changed
if (previouslyAppendedOptGroupLabel != null) {
  endOptGroup(tmp);
}
if (currentOptGroupLabel != null) {
  // OptGroup started
  int start = tmp.indexOf("");
  tmp.insert(start, label);
}
  }

  if ((currentOptGroupLabel != null) && (index == (choices-1))) {
// Last option group must end too
endOptGroup(tmp);
  }

  {
String cssClass = styledChoiceRenderer.getOptionCssClassName(choice);
if (cssClass != null) {
  int start = tmp.indexOf(":
>
> Hi, thanks for the quick reply.
>
>
> MartinM wrote:
>>
>>> There's a small bug - endOptGroup(tmp) for "OptGroup changed" actually
>>> closes
>>> the optgroup after the current option, not before.
>>
>> Note: It is supposed to close the previous optgroup. Not the current
>> optgroup.
>>
>
> Yep, that's why it's a bug. It actually starts a new optgroup and closes it
> after one option.
>
>
>
>> If there is a bug, can you give me your testcase?
>>
>
> Sure, here's the code:
>
>
> package test;
>
> import java.io.Serializable;
> import java.util.ArrayList;
> import java.util.List;
>
> import org.apache.wicket.markup.html.WebPage;
>
> public class TestPage extends WebPage {
>        private static class Val implements Serializable {
>                private static final long serialVersionUID = 1L;
>
>                private final String text;
>                private final String group;
>
>                public Val(final String text, final String group) {
>                        this.text = text;
>                        this.group = group;
>                }
>
>                public String getText() {
>                        return text;
>                }
>
>                public String getGroup() {
>                        return group;
>                }
>        }
>
>        private static final IStyledChoiceRenderer R = new
> IStyledChoiceRenderer() {
>                private static final long serialVersionUID = 1L;
>
>               �...@override
>                public String getIdValue(final Val object, final int index) {
>                        return String.valueOf(index);
>                }
>
>               �...@override
>                public Object getDisplayValue(final Val object) {
>                        return object.getText();
>                }
>
>               �...@override
>                public String getOptionCssClassName(final Val t) {
>                        return null;
>                }
>
>               �...@override
>                public String getOptGroupLabel(final Val t) {
>                        return t.getGroup();
>                }
>        };
>
>        public TestPage() {
>                final List list = new ArrayList();
>                for (int i = 0; i < 3; ++i) {
>                        for (int j = 0; j < 3; ++j) {
>                                list.add(new Val("text" + j, "group" + i));
>                        }
>                }
>                add(new DropDownChoiceWithStylingOptions("test", list, 
> R));
>        }
> }
>
>
> and the markup:
>
>
> 
> 
> 
> 
> 
>
>
>
> This is what it generates (I haven't stripped the wicket tags):
>
>
> 
> 
> 
> Choose One
> text0
> text1
> text2
> text0
> text1
> text2
>
> text0
> text1
> text2
> 
> 
> 
>
>
> Adrian
> --
> View this message in context: 
> http://old.nabble.com/DropDownChoiceWithStylingOptions%3CT%3E-tp26642690p27112292.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: DropDownChoiceWithStylingOptions

[aditsu]

MartinM wrote:
> 
> Hmm.. mine seems to work fine with some other test cases, is this the
> same code you have or is it different:
> 

It's the same, except for "Utils.equalsOrNull" which must be from your
unpublished code, and I replaced it with one of my own utility methods. Just
try my test case.

Adrian
-- 
View this message in context: 
http://old.nabble.com/DropDownChoiceWithStylingOptions%3CT%3E-tp26642690p27112556.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Help with Wicket Adoption Numbers

[Thies Edeling]

The e-ticket application of the Dutch railways (NS) uses Wicket as well, 
https://www.ns.nl/eticket/ticket


On 1/8/2010 10:32 AM, Martijn Dashorst wrote:

The dutch railways use wicket in at least one of their online apps
(http://eropuit.nl), I know some dutch government agencies are using
Wicket, dutch royal airlines (KLM) had/have a project using Wicket.

Martijn

On Fri, Jan 8, 2010 at 10:09 AM,  wrote:
   

Hi,

We also had the same consideration when we chose Wicket. But why choose an
inferior technology just because of it's Adoption Numbers? Also, Wicket is
becoming more and more popular as people see the light :)

Check out Jobs Trends (Relative Growth) here (JSF vs Struts vs Wicket):
http://www.indeed.com/jobtrends?q=Struts%2C+JSF%2C+Wicket&l=&relative=1

We have a couple of hundred customers and so far the feedback is great
both from our Developers and our Software Architects. Customers like that
the GUIs are faster due to the simplicity of Ajax Adoption in Wicket.

I also know that several large privately held companies in Sweden are
using Wicket, as well as large Government Agencies (e.g. the Swedish
Immigration Office).


Sincerely yours
Leo Erlandsson






Lester Chua
2010-01-08 01:43
Sänd svar till
users@wicket.apache.org


Till
users@wicket.apache.org
Kopia

Ärende
Help with Wicket Adoption Numbers






Hi,

I am facing a hurdle that need crossing in my final attempt to push
Wicket for use in an organization.
I have:

1) Prototyped a small size module
2) Did 2-3 presentations on the key features and advantages of wicket

No one is disputing my claims about productivity and good OO code that
was the result.

BUT, the technology evaluation committee is NOT recommending Wicket
because of. of all things.
- Wicket's Low Adoption Rate
Can I find any numbers to blow this away?

My alternative is to accept the finding and work with Struts 2. Which
will mean the stack will need to expand to DWR
  (for security). I REALLY don't want to go there, and am even
considering not taking part in this project due to the high risk
involved, only 9 months to introduce huge changes to a system that has
lots of legacy problems (took about 3 years to build). I think a lot of
those years were spent wrestling with the monster that is EJB 1.1. The
only way I thought the project can even be on time is to scrap the
entire presentation layer (aka Struts) and redo it in Wicket with 1
dedicated developer while the rest of the team work on killing the beast
that is EJB 1.1 by refactoring the biz code.

Sigh, my choices are stark. It's either to keep the job and plough ahead
and probably fail spectacularly 9 months later or go hungry and explain
to my wife why we need to spend less on the kid..

It's easy to blame the tech committee but they did help me find wicket
by rejecting my initial proposal to build the new system on a
(JQuery+JSON+REST) framework, which can be very productive as well, if
not as "clean" as Wicket.

Sorry for rambling so much. Is there any way I can demolish the silly
low adoption rate argument (omg I still don't believe it can be so lame)?

Lester



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




 



   



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: DropDownChoiceWithStylingOptions

[Martin Makundi]

Hi!

Thanks for pointing that out.. must have been drunk when I coded that >8-)

Here is an improved version:

/**
   * @see 
org.apache.wicket.markup.html.form.AbstractChoice#appendOptionHtml(org.apache.wicket.util.string.AppendingStringBuffer,
java.lang.Object, int, java.lang.String)
   */
  @Override
  protected void appendOptionHtml(AppendingStringBuffer buffer, T choice,
  int index, String selected) {
AppendingStringBuffer tmp = new AppendingStringBuffer(50);
super.appendOptionHtml(tmp, choice, index, selected);

if (getChoiceRenderer() instanceof IStyledChoiceRenderer) {
  IStyledChoiceRenderer styledChoiceRenderer =
(IStyledChoiceRenderer) getChoiceRenderer();

  String currentOptGroupLabel =
styledChoiceRenderer.getOptGroupLabel(choice);

  if (!Utils.equalsOrNull(currentOptGroupLabel,
previouslyAppendedOptGroupLabel)) {
// OptGroup changed
if (previouslyAppendedOptGroupLabel != null) {
  endOptGroup(buffer);
}

if (currentOptGroupLabel != null) {
  // OptGroup started
  int start = tmp.indexOf("");
  tmp.insert(start, label);
}
  }

  if ((currentOptGroupLabel != null) && (index == (choices-1))) {
// Last option group must end too
endOptGroup(tmp);
  }

  {
String cssClass = styledChoiceRenderer.getOptionCssClassName(choice);
if (cssClass != null) {
  int start = tmp.indexOf("");
tmp.insert(start + 9, "");
  }


It produces:



Valitse yksi


  text0

  text1

  text2



  text0

  text1

  text2



  text0

  text1

  text2



2010/1/11 aditsu :
>
>
> MartinM wrote:
>>
>> Hmm.. mine seems to work fine with some other test cases, is this the
>> same code you have or is it different:
>>
>
> It's the same, except for "Utils.equalsOrNull" which must be from your
> unpublished code, and I replaced it with one of my own utility methods. Just
> try my test case.
>
> Adrian
> --
> View this message in context: 
> http://old.nabble.com/DropDownChoiceWithStylingOptions%3CT%3E-tp26642690p27112556.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Lazy loading

[Douglas Ferguson]

Do you mind sharing your JQuery?

On Jan 11, 2010, at 8:00 AM, Ilja Pavkovic wrote:

> Hi,
> 
> use a veil. You could use this one:
> 
> http://wicketinaction.com/2008/12/preventing-double-ajax-requests-in-3-lines-
> of-code/
> 
> or (as I personally think it bloats the ajax links)
> 
> get familiar with some javascript, add
> 
>  to your page with a style like
> 
> #veil {
>position: absolute;
>z-index:1;
>top: 0px;
>left: 0px;
>height:100%;
>width:100%;
>background: grey;
>display: none;
> }
> 
> and add some javascript to your page like 
> 
> window.wicketGlobalPreCallHandler = function() {
> window.getElementById("veil").style.display="block";
> };
> 
> window.wicketGlobalPostCallHandler = function() {
> window.getElementById("veil").style.display="none";
> };
> 
> javascript may not work as I personally use jquery here to get some more 
> fance 
> fadeIn fadeOut and I just wrote it down here :)
> 
> 
> Best Regards,
>   Ilja Pavkovic
> 
> 
> Am Montag, 11. Januar 2010 14:43:42 schrieb Giovanni:
>> In my current project, we have many situations in which we have to load a
>> page, which is very slow. The slowness is not because of Wicket, but
>> because there are heavy queries on the DB.
>> 
>> In some of these situations, we used the AjaxLazyLoadPanel, when we have to
>> load a "slow" panel.
>> 
>> In some other situations, when we are not loading a panel, but a page, how
>> can we do to prevent the user from "crazy clicking" on the application,
>> because he is impatient with the slow loading?
>> 
>> More generally, is there a standard way to disable all the links and
>> click-able components of the application, while a new component is
>> loading?
>> 
>> best regards,
>> giovanni
>> 
> 
> -- 
> binaere bauten gmbh · tempelhofer ufer 1a · 10961 berlin
> 
>   +49 · 171 · 9342 465
> 
> Handelsregister: HRB 115854 - Amtsgericht Charlottenburg
> Geschäftsführer: Dipl.-Inform. Ilja Pavkovic, Dipl.-Inform. Jost Becker
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: testing autocomplete with WicketTester

[Douglas Ferguson]

I am assuming that since it is actually a text field that I could just "get" 
the component and cast it to a TextField then set the model object.

However, I'm not sure that we fire the appropriate events to make the 
autocomplete work properly as there are onchange events, etc on it..

D/

On Jan 10, 2010, at 7:56 PM, Douglas Ferguson wrote:

> What is the recommended way to test autocomplete using wicket tester?
> 
> D/
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Lazy loading

[Ilja Pavkovic]

Dear Douglas,

> Do you mind sharing your JQuery?
no fancy stuff but as we already use jquery ...

You can play around with the fadeIn-fadeOut times, from a visual point of view 
it should not be too short or you will have flickering.

function showModalOverlay() {
//Set the css and fade in our overlay
$("#veil").css("opacity", 0.8).fadeIn(100);

}

function hideModalOverlay() {
// stop running animations and fadeOut
 $("#veil").stop().fadeOut(100);
}

window.wicketGlobalPreCallHandler = function() {
showModalOverlay();
};

window.wicketGlobalPostCallHandler = function() {
hideModalOverlay();
};

To show an  message just put something into the veil div:


wait for ajax call... 

or put some images inside, you can create some nice ajax load indicators at

http://www.ajaxload.info/

Best Regards,
Ilja Pavkovic



Am Montag, 11. Januar 2010 17:21:27 schrieb Douglas Ferguson:
> 
> On Jan 11, 2010, at 8:00 AM, Ilja Pavkovic wrote:
> > Hi,
> >
> > use a veil. You could use this one:
> >
> > http://wicketinaction.com/2008/12/preventing-double-ajax-requests-in-3-li
> >nes- of-code/
> >
> > or (as I personally think it bloats the ajax links)
> >
> > get familiar with some javascript, add
> >
> >  to your page with a style like
> >
> > #veil {
> >position: absolute;
> >z-index:1;
> >top: 0px;
> >left: 0px;
> >height:100%;
> >width:100%;
> >background: grey;
> >display: none;
> > }
> >
> > and add some javascript to your page like
> >
> > window.wicketGlobalPreCallHandler = function() {
> > window.getElementById("veil").style.display="block";
> > };
> >
> > window.wicketGlobalPostCallHandler = function() {
> > window.getElementById("veil").style.display="none";
> > };
> >
> > javascript may not work as I personally use jquery here to get some more
> > fance fadeIn fadeOut and I just wrote it down here :)
> >
> >
> > Best Regards,
> > Ilja Pavkovic
> >
> > Am Montag, 11. Januar 2010 14:43:42 schrieb Giovanni:
> >> In my current project, we have many situations in which we have to load
> >> a page, which is very slow. The slowness is not because of Wicket, but
> >> because there are heavy queries on the DB.
> >>
> >> In some of these situations, we used the AjaxLazyLoadPanel, when we have
> >> to load a "slow" panel.
> >>
> >> In some other situations, when we are not loading a panel, but a page,
> >> how can we do to prevent the user from "crazy clicking" on the
> >> application, because he is impatient with the slow loading?
> >>
> >> More generally, is there a standard way to disable all the links and
> >> click-able components of the application, while a new component is
> >> loading?
> >>
> >> best regards,
> >> giovanni
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 

-- 
binaere bauten gmbh · tempelhofer ufer 1a · 10961 berlin

   +49 · 171 · 9342 465

Handelsregister: HRB 115854 - Amtsgericht Charlottenburg
Geschäftsführer: Dipl.-Inform. Ilja Pavkovic, Dipl.-Inform. Jost Becker

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Wicket Wizard and HTML Validator for XHTML Transitional

[VGoel]

We are a State agency  and using wicket. For us accessibility is a must. 
We are using following DTD
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>

HTML validator is generating 2 errors while using Wizard. This may change 
our decision for not using wicket in future projects. We will appreciate 
if we can get a solution for following.

Wizard component is adding "". 
Throws error in HTML validator. Is it possible this markup is not 
generated.
Second wizard is adding a span tag  as the top element . This throws 
another error of span can not contain div or form. If span can be replaced 
by div, this will solve our problem.


Error in HTML Validator
Line 27, Column 350: Attribute "autocomplete" is not a valid attribute 
…en">" or "") inside an inline element 
(such as "", "", or ""). 




Notice: This communication, including any attachments, is intended solely 
for the use of the individual or entity to which it is addressed. This 
communication may contain information that is protected from disclosure 
under State and/or Federal law. Please notify the sender immediately if 
you have received this communication in error and delete this email from 
your system. If you are not the intended recipient, you are requested not 
to disclose, copy, distribute or take any action in reliance on the 
contents of this information.

Re: about org.apache.wicket.extensions.markup.html.form.palette.Palette

[Igor Vaynberg]

you can build a palette that works without javascript but the user
experience will probably be poor

-igor

On Sun, Jan 10, 2010 at 11:41 PM, Chuck Brinkman  wrote:
> As you can guess I'm new to wicket.  Seems very good so far.  I found this
> Palette component and thought it might work well for me but I need to make
> some modifications.  So I started to dig in.  I noticed that the component
> uses js.  I thought wicket was just java and just html.  I do realize that
> is a little but of marketing hype but could this component have been
> implemented without any js?  I read this in the Palette.java source file:
> The palette itself cannot be ajaxified because it is a panel and therefore
> does not receive any javascript events.  I don't know what this means.  Does
> this mean that the click events to move data around could not be sent to the
> server?  Can this only be done using js?  Or was js selected because it
> would be too slow otherwise?  If I just need to RTFM just say so.  I would
> appreciate some insight if someone has time.  Thanks
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Any servlet filter- like WebRequest interceptor or filter ?

[Igor Vaynberg]

requestcycle.onbeginrequest

-igor

On Mon, Jan 11, 2010 at 2:40 AM, smallufo  wrote:
> For example :
> A Wicket application may have many WebPages or Wizards which are
> inter-connected ...
> The interceptor(or filter , whatever called) can monitor the user's cookie ,
> when some situation matches , he will be redirected to a specified page,
> after filling some forms , he will be redirect back to the original target
> page or wizard step...
>
> Is it possible in wicket ?
>
> 2010/1/11 smallufo 
>
>> Hi :
>>
>> I wonder if wicket has any servletFilter-like WebRequest interceptor or
>> filter ?
>> That the interceptor can intercept WebRequest or HttpSession and
>> pre-processing , and maybe redirect to some specified WebPage ...
>>
>> Thanks a lot.
>>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket Wizard and HTML Validator for XHTML Transitional

[Martin Makundi]

You will want that autocomplete=false there... regardless it's not
'standard'. You really don't want browser's own autocomplete
conflicting with autocompletetextfield.

**
Martin

2010/1/11  :
> We are a State agency  and using wicket. For us accessibility is a must.
> We are using following DTD
>      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
>
> HTML validator is generating 2 errors while using Wizard. This may change
> our decision for not using wicket in future projects. We will appreciate
> if we can get a solution for following.
>
> Wizard component is adding "".
> Throws error in HTML validator. Is it possible this markup is not
> generated.
> Second wizard is adding a span tag  as the top element . This throws
> another error of span can not contain div or form. If span can be replaced
> by div, this will solve our problem.
>
> 
> Error in HTML Validator
> Line 27, Column 350: Attribute "autocomplete" is not a valid attribute
> …en"> name="butto
> You have used the attribute named above in your document, but the document
> type you are using does not support that attribute for this element. This
> error is often caused by incorrect use of the "Strict" document type with
> a document that uses frames (e.g. you must use the "Transitional" document
> type to get the "target" attribute), or by using vendor proprietary
> extensions such as "marginheight" (this is usually fixed by using CSS to
> achieve the desired effect instead).
> This error may also result if the element itself is not supported in the
> document type you are using, as an undefined element will have no
> supported attributes; in this case, see the element-undefined error
> message for further information.
>
>
>
> Line 26, Column 118: document type does not allow element "form" here;
> missing one of "object", "applet", "map", "iframe", "ins", "del" start-tag
>
> …W6HS6hzs33mP32E1DHKLuZQKFw-y2fZVX5g"> type="h
> The mentioned element is not allowed to appear in the context in which
> you've placed it; the other mentioned elements are the only ones that are
> both allowed there and can contain the element mentioned. This might mean
> that you need a containing element, or possibly that you've forgotten to
> close a previous element.
> One possible cause for this message is that you have attempted to put a
> block-level element (such as "" or "") inside an inline element
> (such as "", "", or "").
>
>
>
>
> Notice: This communication, including any attachments, is intended solely
> for the use of the individual or entity to which it is addressed. This
> communication may contain information that is protected from disclosure
> under State and/or Federal law. Please notify the sender immediately if
> you have received this communication in error and delete this email from
> your system. If you are not the intended recipient, you are requested not
> to disclose, copy, distribute or take any action in reliance on the
> contents of this information.
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

[release] Wicket Security 1.3.1

[Martijn Dashorst]

We've just release Wicket Security 1.3.1.

The Wicket Security project's 1.3.x branch has been dormant ever since
Maurice's tragic accident. Today we finally dared to touch his code
and bring his changes to the world in a formal release.

Wicket Security 1.3.1 is available from the Wicket Stuff repository.

This release integrates all changes Maurice made on trunk after
branching 1.3.x and before making Wicket Security based upon Wicket
1.4. In effect it is the culmination of all his work on the 1.3.x
series.

For example using swarm you should include (or update to) the
following pom snippet:


org.apache.wicket.wicket-security
wicket-security
1.3.1


More information on the Wicket Security project is available here:

http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket-Security

Enjoy!

Emond & Martijn

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Help with Wicket Adoption Numbers

[Igor Vaynberg]

you mean you speak it pretty *well* :)

-igor

On Sun, Jan 10, 2010 at 11:58 PM, Eyal Golan  wrote:
> As my English is not my mother's tongue, even though I do speak it pretty
> good, what is the meaning of "pointy haired bosses"?
> I think I can understand it, but hey, I want to know if these are the kinds
> of bosses I encountered too often..
>
> Eyal Golan
> egola...@gmail.com
>
> Visit: http://jvdrums.sourceforge.net/
> LinkedIn: http://www.linkedin.com/in/egolan74
>
> P  Save a tree. Please don't print this e-mail unless it's really necessary
>
>
> On Fri, Jan 8, 2010 at 11:26 PM, Jonathan Locke 
> wrote:
>
>>
>>
>> honestly, your response is too thoughtful. these pointy haired bosses are
>> self-serving. they don't care about training costs or developer pain and
>> they don't really care if their org runs efficiently.  what they care about
>> is that if there is a failure, their choice didn't cause it.  which is why
>> the old saying goes "nobody ever got fired for buying IBM."  same seems to
>> go for struts.  an idiotic technology choice, but you won't get fired for
>> making the same idiotic choice everyone else is making.
>>
>>
>> Loritsch, Berin C. wrote:
>> >
>> > "But why choose an inferior technology just because of its adoption
>> > numbers?"
>> >
>> > The pointy haired bosses that do this believe in their heart of hearts
>> > that if you choose the same technology everyone else is using that they
>> > can turn thinking developers for mindless drones.  It has more to do
>> > with avoiding training costs and rational thought, and more to do with
>> > trying to turn software development into an assembly line process.
>> > Reality never fits this mold, but it doesn't stop the pointy haired boss
>> > from trying.  In this respect they are eternal optimists.
>> >
>> > -Original Message-
>> > From: leo.erlands...@tyringe.com [mailto:leo.erlands...@tyringe.com]
>> > Sent: Friday, January 08, 2010 4:09 AM
>> > To: users@wicket.apache.org
>> > Subject: Re: Help with Wicket Adoption Numbers
>> >
>> > Hi,
>> >
>> > We also had the same consideration when we chose Wicket. But why choose
>> > an
>> > inferior technology just because of it's Adoption Numbers? Also, Wicket
>> > is
>> > becoming more and more popular as people see the light :)
>> >
>> > Check out Jobs Trends (Relative Growth) here (JSF vs Struts vs Wicket):
>> > http://www.indeed.com/jobtrends?q=Struts%2C+JSF%2C+Wicket&l=&relative=1
>> >
>> > We have a couple of hundred customers and so far the feedback is great
>> > both from our Developers and our Software Architects. Customers like
>> > that
>> > the GUIs are faster due to the simplicity of Ajax Adoption in Wicket.
>> >
>> > I also know that several large privately held companies in Sweden are
>> > using Wicket, as well as large Government Agencies (e.g. the Swedish
>> > Immigration Office).
>> >
>> >
>> > Sincerely yours
>> > Leo Erlandsson
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> > For additional commands, e-mail: users-h...@wicket.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Help-with-Wicket-Adoption-Numbers-tp27069702p27082559.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket Wizard and HTML Validator for XHTML Transitional

[Igor Vaynberg]

you can always subclass the wizard and tweak the markup in any way you want.

-igor

On Mon, Jan 11, 2010 at 8:37 AM,   wrote:
> We are a State agency  and using wicket. For us accessibility is a must.
> We are using following DTD
>      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
>
> HTML validator is generating 2 errors while using Wizard. This may change
> our decision for not using wicket in future projects. We will appreciate
> if we can get a solution for following.
>
> Wizard component is adding "".
> Throws error in HTML validator. Is it possible this markup is not
> generated.
> Second wizard is adding a span tag  as the top element . This throws
> another error of span can not contain div or form. If span can be replaced
> by div, this will solve our problem.
>
> 
> Error in HTML Validator
> Line 27, Column 350: Attribute "autocomplete" is not a valid attribute
> …en"> name="butto
> You have used the attribute named above in your document, but the document
> type you are using does not support that attribute for this element. This
> error is often caused by incorrect use of the "Strict" document type with
> a document that uses frames (e.g. you must use the "Transitional" document
> type to get the "target" attribute), or by using vendor proprietary
> extensions such as "marginheight" (this is usually fixed by using CSS to
> achieve the desired effect instead).
> This error may also result if the element itself is not supported in the
> document type you are using, as an undefined element will have no
> supported attributes; in this case, see the element-undefined error
> message for further information.
>
>
>
> Line 26, Column 118: document type does not allow element "form" here;
> missing one of "object", "applet", "map", "iframe", "ins", "del" start-tag
>
> …W6HS6hzs33mP32E1DHKLuZQKFw-y2fZVX5g"> type="h
> The mentioned element is not allowed to appear in the context in which
> you've placed it; the other mentioned elements are the only ones that are
> both allowed there and can contain the element mentioned. This might mean
> that you need a containing element, or possibly that you've forgotten to
> close a previous element.
> One possible cause for this message is that you have attempted to put a
> block-level element (such as "" or "") inside an inline element
> (such as "", "", or "").
>
>
>
>
> Notice: This communication, including any attachments, is intended solely
> for the use of the individual or entity to which it is addressed. This
> communication may contain information that is protected from disclosure
> under State and/or Federal law. Please notify the sender immediately if
> you have received this communication in error and delete this email from
> your system. If you are not the intended recipient, you are requested not
> to disclose, copy, distribute or take any action in reliance on the
> contents of this information.
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

palette - default selected choices

[wic...@geofflancaster.com]

when using a palette is there a way to set a few items selected by default?


mail2web.com – What can On Demand Business Solutions do for you?
http://link.mail2web.com/Business/SharePoint



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: palette - default selected choices

[Igor Vaynberg]

put them into your model

-igor

On Mon, Jan 11, 2010 at 9:06 AM, wic...@geofflancaster.com
 wrote:
> when using a palette is there a way to set a few items selected by default?
>
> 
> mail2web.com – What can On Demand Business Solutions do for you?
> http://link.mail2web.com/Business/SharePoint
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Any servlet filter- like WebRequest interceptor or filter ?

[smallufo]

Hi

Do you mean override newRequestCycle() in WebApplication , and in the
returning WebRequestCycle, override onBeginRequest() ?

If so , how do I inject spring beans into Application ?
The SpringComponentInjector is injected into Application in init() , but
Spring beans is not available in this class.


2010/1/12 Igor Vaynberg 

> requestcycle.onbeginrequest
>
> -igor
>
> On Mon, Jan 11, 2010 at 2:40 AM, smallufo  wrote:
> > For example :
> > A Wicket application may have many WebPages or Wizards which are
> > inter-connected ...
> > The interceptor(or filter , whatever called) can monitor the user's
> cookie ,
> > when some situation matches , he will be redirected to a specified page,
> > after filling some forms , he will be redirect back to the original
> target
> > page or wizard step...
> >
> > Is it possible in wicket ?
> >
> > 2010/1/11 smallufo 
> >
> >> Hi :
> >>
> >> I wonder if wicket has any servletFilter-like WebRequest interceptor or
> >> filter ?
> >> That the interceptor can intercept WebRequest or HttpSession and
> >> pre-processing , and maybe redirect to some specified WebPage ...
> >>
> >> Thanks a lot.
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Any servlet filter- like WebRequest interceptor or filter ?

[Stijn Maller]

InjectorHolder.getInjector().inject(this);

2010/1/11 smallufo 

> Hi
>
> Do you mean override newRequestCycle() in WebApplication , and in the
> returning WebRequestCycle, override onBeginRequest() ?
>
> If so , how do I inject spring beans into Application ?
> The SpringComponentInjector is injected into Application in init() , but
> Spring beans is not available in this class.
>
>
>

Re: Any servlet filter- like WebRequest interceptor or filter ?

[smallufo]

Wow , thanks replying so soon.
I am just trying :

public RequestCycle newRequestCycle(Request request, Response response)
{
ServletWebRequest servletWebRequest = (ServletWebRequest) request;
HttpServletRequest hreq = servletWebRequest.getHttpServletRequest();
ServletContext context = hreq.getSession().getServletContext();
WebApplicationContext wac =
WebApplicationContextUtils.getWebApplicationContext(context);
final UserDao userDao = (UserDao) wac.getBean("userDao");

It works too , but it is much ugly...

2010/1/12 Stijn Maller 

> InjectorHolder.getInjector().inject(this);
>

Re: [release] Wicket Security 1.3.1

[nino martinez wael]

This is great news indeed !

regards Nino

2010/1/11 Martijn Dashorst :
> We've just release Wicket Security 1.3.1.
>
> The Wicket Security project's 1.3.x branch has been dormant ever since
> Maurice's tragic accident. Today we finally dared to touch his code
> and bring his changes to the world in a formal release.
>
> Wicket Security 1.3.1 is available from the Wicket Stuff repository.
>
> This release integrates all changes Maurice made on trunk after
> branching 1.3.x and before making Wicket Security based upon Wicket
> 1.4. In effect it is the culmination of all his work on the 1.3.x
> series.
>
> For example using swarm you should include (or update to) the
> following pom snippet:
>
> 
>        org.apache.wicket.wicket-security
>        wicket-security
>        1.3.1
> 
>
> More information on the Wicket Security project is available here:
>
> http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket-Security
>
> Enjoy!
>
> Emond & Martijn
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: about org.apache.wicket.extensions.markup.html.form.palette.Palette

[Chuck Brinkman]

Can you tell me what this means "The palette itself cannot be ajaxified
because it is a panel and therefore does not receive any javascript
events."?  Would a palette without javascript require full page loads?

On Mon, Jan 11, 2010 at 11:41 AM, Igor Vaynberg wrote:

> you can build a palette that works without javascript but the user
> experience will probably be poor
>
> -igor
>
> On Sun, Jan 10, 2010 at 11:41 PM, Chuck Brinkman 
> wrote:
> > As you can guess I'm new to wicket.  Seems very good so far.  I found
> this
> > Palette component and thought it might work well for me but I need to
> make
> > some modifications.  So I started to dig in.  I noticed that the
> component
> > uses js.  I thought wicket was just java and just html.  I do realize
> that
> > is a little but of marketing hype but could this component have been
> > implemented without any js?  I read this in the Palette.java source file:
> > The palette itself cannot be ajaxified because it is a panel and
> therefore
> > does not receive any javascript events.  I don't know what this means.
>  Does
> > this mean that the click events to move data around could not be sent to
> the
> > server?  Can this only be done using js?  Or was js selected because it
> > would be too slow otherwise?  If I just need to RTFM just say so.  I
> would
> > appreciate some insight if someone has time.  Thanks
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: about org.apache.wicket.extensions.markup.html.form.palette.Palette

[Igor Vaynberg]

you cannot do something like this:

palette.add(new ajaxformcomponentupdatingbehavior() {...})

instead you have to do it to one of the internal components which are
available via factory methods on Palette

-igor

On Mon, Jan 11, 2010 at 9:31 AM, Chuck Brinkman  wrote:
> Can you tell me what this means "The palette itself cannot be ajaxified
> because it is a panel and therefore does not receive any javascript
> events."?  Would a palette without javascript require full page loads?
>
> On Mon, Jan 11, 2010 at 11:41 AM, Igor Vaynberg 
> wrote:
>
>> you can build a palette that works without javascript but the user
>> experience will probably be poor
>>
>> -igor
>>
>> On Sun, Jan 10, 2010 at 11:41 PM, Chuck Brinkman 
>> wrote:
>> > As you can guess I'm new to wicket.  Seems very good so far.  I found
>> this
>> > Palette component and thought it might work well for me but I need to
>> make
>> > some modifications.  So I started to dig in.  I noticed that the
>> component
>> > uses js.  I thought wicket was just java and just html.  I do realize
>> that
>> > is a little but of marketing hype but could this component have been
>> > implemented without any js?  I read this in the Palette.java source file:
>> > The palette itself cannot be ajaxified because it is a panel and
>> therefore
>> > does not receive any javascript events.  I don't know what this means.
>>  Does
>> > this mean that the click events to move data around could not be sent to
>> the
>> > server?  Can this only be done using js?  Or was js selected because it
>> > would be too slow otherwise?  If I just need to RTFM just say so.  I
>> would
>> > appreciate some insight if someone has time.  Thanks
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Lazy loading

[Giovanni]

Is this technique working also with IE6?

I tried the suggestions given previously, but they are not working on IE6. They 
are working on Firefox.

Unfortunately, the standard browser of my client (big bank) is still IE6. :(

Do you know of some ways to make the "veil" work on IE6?

best regards
giovanni





From: Ilja Pavkovic 
To: users@wicket.apache.org
Cc: Douglas Ferguson 
Sent: Mon, January 11, 2010 5:33:01 PM
Subject: Re: Lazy loading

Dear Douglas,

> Do you mind sharing your JQuery?
no fancy stuff but as we already use jquery ...

You can play around with the fadeIn-fadeOut times, from a visual point of view 
it should not be too short or you will have flickering.

function showModalOverlay() {
//Set the css and fade in our overlay
$("#veil").css("opacity", 0.8).fadeIn(100);

}

function hideModalOverlay() {
// stop running animations and fadeOut
 $("#veil").stop().fadeOut(100);
}

window.wicketGlobalPreCallHandler = function() {
showModalOverlay();
};

window.wicketGlobalPostCallHandler = function() {
hideModalOverlay();
};

To show an  message just put something into the veil div:


wait for ajax call... 

or put some images inside, you can create some nice ajax load indicators at

http://www.ajaxload.info/

Best Regards,
Ilja Pavkovic



Am Montag, 11. Januar 2010 17:21:27 schrieb Douglas Ferguson:
> 
> On Jan 11, 2010, at 8:00 AM, Ilja Pavkovic wrote:
> > Hi,
> >
> > use a veil. You could use this one:
> >
> > http://wicketinaction.com/2008/12/preventing-double-ajax-requests-in-3-li
> >nes- of-code/
> >
> > or (as I personally think it bloats the ajax links)
> >
> > get familiar with some javascript, add
> >
> >  to your page with a style like
> >
> > #veil {
> >position: absolute;
> >z-index:1;
> >top: 0px;
> >left: 0px;
> >height:100%;
> >width:100%;
> >background: grey;
> >display: none;
> > }
> >
> > and add some javascript to your page like
> >
> > window.wicketGlobalPreCallHandler = function() {
> > window.getElementById("veil").style.display="block";
> > };
> >
> > window.wicketGlobalPostCallHandler = function() {
> > window.getElementById("veil").style.display="none";
> > };
> >
> > javascript may not work as I personally use jquery here to get some more
> > fance fadeIn fadeOut and I just wrote it down here :)
> >
> >
> > Best Regards,
> > Ilja Pavkovic
> >
> > Am Montag, 11. Januar 2010 14:43:42 schrieb Giovanni:
> >> In my current project, we have many situations in which we have to load
> >> a page, which is very slow. The slowness is not because of Wicket, but
> >> because there are heavy queries on the DB.
> >>
> >> In some of these situations, we used the AjaxLazyLoadPanel, when we have
> >> to load a "slow" panel.
> >>
> >> In some other situations, when we are not loading a panel, but a page,
> >> how can we do to prevent the user from "crazy clicking" on the
> >> application, because he is impatient with the slow loading?
> >>
> >> More generally, is there a standard way to disable all the links and
> >> click-able components of the application, while a new component is
> >> loading?
> >>
> >> best regards,
> >> giovanni
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 

-- 
binaere bauten gmbh · tempelhofer ufer 1a · 10961 berlin

   +49 · 171 · 9342 465

Handelsregister: HRB 115854 - Amtsgericht Charlottenburg
Geschäftsführer: Dipl.-Inform. Ilja Pavkovic, Dipl.-Inform. Jost Becker

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


  

Re: [release] Wicket Security 1.3.1

[Giovanni]

I'm very happy about this news.

My team and I are using Wicket Security successfully on our projects at the 
bank.

best regards
giovanni






From: Martijn Dashorst 
To: users@wicket.apache.org
Sent: Mon, January 11, 2010 5:49:25 PM
Subject: [release] Wicket Security 1.3.1

We've just release Wicket Security 1.3.1.

The Wicket Security project's 1.3.x branch has been dormant ever since
Maurice's tragic accident. Today we finally dared to touch his code
and bring his changes to the world in a formal release.

Wicket Security 1.3.1 is available from the Wicket Stuff repository.

This release integrates all changes Maurice made on trunk after
branching 1.3.x and before making Wicket Security based upon Wicket
1.4. In effect it is the culmination of all his work on the 1.3.x
series.

For example using swarm you should include (or update to) the
following pom snippet:


org.apache.wicket.wicket-security
wicket-security
1.3.1


More information on the Wicket Security project is available here:

http://wicketstuff.org/confluence/display/STUFFWIKI/Wicket-Security

Enjoy!

Emond & Martijn

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


  

Re: Lazy loading

[Ilja Pavkovic]

Hi,

> Is this technique working also with IE6?
> 
> I tried the suggestions given previously, but they are not working on IE6.
>  They are working on Firefox.
> 
> Unfortunately, the standard browser of my client (big bank) is still IE6.
>  :(
> 
> Do you know of some ways to make the "veil" work on IE6?
Perhaps one could use 

http://www.lmgtfy.com/?q=ie6+overlay+div

and read - for example - this post: 

http://interactivevolcano.com/grayed-out-overlays-with-jquery-and-css

The layout problem ist not a jquery nor wicket problem but IE6 specific. There 
are many people around offering solutions and/or ideas addressing this problem.

I must admit that I am in an IE6-ignore mode. Therefore further investigations 
must be done on your own.

Best Regards,
Ilja

> 
> best regards
> giovanni
> 
> 
> 
> 
> 
> From: Ilja Pavkovic 
> To: users@wicket.apache.org
> Cc: Douglas Ferguson 
> Sent: Mon, January 11, 2010 5:33:01 PM
> Subject: Re: Lazy loading
> 
> Dear Douglas,
> 
> > Do you mind sharing your JQuery?
> 
> no fancy stuff but as we already use jquery ...
> 
> You can play around with the fadeIn-fadeOut times, from a visual point of
>  view it should not be too short or you will have flickering.
> 
> function showModalOverlay() {
> //Set the css and fade in our overlay
> $("#veil").css("opacity", 0.8).fadeIn(100);
> 
> }
> 
> function hideModalOverlay() {
> // stop running animations and fadeOut
>  $("#veil").stop().fadeOut(100);
> }
> 
> window.wicketGlobalPreCallHandler = function() {
> showModalOverlay();
> };
> 
> window.wicketGlobalPostCallHandler = function() {
> hideModalOverlay();
> };
> 
> To show an  message just put something into the veil div:
> 
> 
> wait for ajax call...
> 
> or put some images inside, you can create some nice ajax load indicators at
> 
> http://www.ajaxload.info/
> 
> Best Regards,
> Ilja Pavkovic
> 
> Am Montag, 11. Januar 2010 17:21:27 schrieb Douglas Ferguson:
> > On Jan 11, 2010, at 8:00 AM, Ilja Pavkovic wrote:
> > > Hi,
> > >
> > > use a veil. You could use this one:
> > >
> > > http://wicketinaction.com/2008/12/preventing-double-ajax-requests-in-3-
> > >li nes- of-code/
> > >
> > > or (as I personally think it bloats the ajax links)
> > >
> > > get familiar with some javascript, add
> > >
> > >  to your page with a style like
> > >
> > > #veil {
> > >position: absolute;
> > >z-index:1;
> > >top: 0px;
> > >left: 0px;
> > >height:100%;
> > >width:100%;
> > >background: grey;
> > >display: none;
> > > }
> > >
> > > and add some javascript to your page like
> > >
> > > window.wicketGlobalPreCallHandler = function() {
> > > window.getElementById("veil").style.display="block";
> > > };
> > >
> > > window.wicketGlobalPostCallHandler = function() {
> > > window.getElementById("veil").style.display="none";
> > > };
> > >
> > > javascript may not work as I personally use jquery here to get some
> > > more fance fadeIn fadeOut and I just wrote it down here :)
> > >
> > >
> > > Best Regards,
> > > Ilja Pavkovic
> > >
> > > Am Montag, 11. Januar 2010 14:43:42 schrieb Giovanni:
> > >> In my current project, we have many situations in which we have to
> > >> load a page, which is very slow. The slowness is not because of
> > >> Wicket, but because there are heavy queries on the DB.
> > >>
> > >> In some of these situations, we used the AjaxLazyLoadPanel, when we
> > >> have to load a "slow" panel.
> > >>
> > >> In some other situations, when we are not loading a panel, but a page,
> > >> how can we do to prevent the user from "crazy clicking" on the
> > >> application, because he is impatient with the slow loading?
> > >>
> > >> More generally, is there a standard way to disable all the links and
> > >> click-able components of the application, while a new component is
> > >> loading?
> > >>
> > >> best regards,
> > >> giovanni
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> 

-- 
binaere bauten gmbh · tempelhofer ufer 1a · 10961 berlin

   +49 · 171 · 9342 465

Handelsregister: HRB 115854 - Amtsgericht Charlottenburg
Geschäftsführer: Dipl.-Inform. Ilja Pavkovic, Dipl.-Inform. Jost Becker

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

SV: Any servlet filter- like WebRequest interceptor or filter ?

[Wilhelmsen Tor Iver]

> public RequestCycle newRequestCycle(Request request, Response response)
> {
> ServletWebRequest servletWebRequest = (ServletWebRequest) request;
> HttpServletRequest hreq =
> servletWebRequest.getHttpServletRequest();
> ServletContext context = hreq.getSession().getServletContext();
> WebApplicationContext wac =
> WebApplicationContextUtils.getWebApplicationContext(context);
> final UserDao userDao = (UserDao) wac.getBean("userDao");
> 
> It works too , but it is much ugly...

I think it would improve if you instead did

@SpringBean
UserDAO userDAO;

to let the InjectorHelper do its magic.

- Tor Iver

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket Wizard previous

[Leszek Gawron]

nino martinez wael wrote:

Just empty the page map?


you can always try with:

WizardModel wizardModel = new WizardModel() {
  public boolean isPreviousAvailable() { return false; }
}

--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Help with Wicket Adoption Numbers

[Jonathan Locke]

that's because it's the number one rule!  nobody talks about Struts Club.


igor.vaynberg wrote:
> 
> here is an interesting tidbit
> 
> wicket is on the front page of nabble
> 
> http://old.nabble.com/
> 
> sorted by activity. we are there along maven, jquery, cxf, tomcat,
> etc. how is the adoption on those?
> 
> -igor
> 
> On Thu, Jan 7, 2010 at 6:19 PM, Lester Chua  wrote:
>> Thanks for the links.
>> I have already submitted them as part of the evaluation process.
>>
>> I'll take a look at the IBM links from scott.
>>
>> Regards,
>>
>> Lester
>>
>> Steve Swinsburg wrote:
>>>
>>> On the wiki there are some pages to help your cause:
>>> http://cwiki.apache.org/WICKET/websites-based-on-wicket.html
>>> http://cwiki.apache.org/WICKET/products-based-on-wicket.html
>>>
>>> as well as blogs talking about Wicket, and lots more useful PR info:
>>> http://cwiki.apache.org/WICKET/index.html
>>>
>>> All the best!
>>>
>>> cheers,
>>> Steve
>>>
>>>
>>>
>>> On 08/01/2010, at 11:43 AM, Lester Chua wrote:
>>>
>>>

 Hi,

 I am facing a hurdle that need crossing in my final attempt to push
 Wicket for use in an organization.
 I have:

 1) Prototyped a small size module
 2) Did 2-3 presentations on the key features and advantages of wicket

 No one is disputing my claims about productivity and good OO code that
 was the result.

 BUT, the technology evaluation committee is NOT recommending Wicket
 because of. of all things.
 - Wicket's Low Adoption Rate
 Can I find any numbers to blow this away?

 My alternative is to accept the finding and work with Struts 2. Which
 will mean the stack will need to expand to DWR
 (for security). I REALLY don't want to go there, and am even
 considering
 not taking part in this project due to the high risk involved, only 9
 months
 to introduce huge changes to a system that has lots of legacy problems
 (took
 about 3 years to build). I think a lot of those years were spent
 wrestling
 with the monster that is EJB 1.1. The only way I thought the project
 can
 even be on time is to scrap the entire presentation layer (aka Struts)
 and
 redo it in Wicket with 1 dedicated developer while the rest of the team
 work
 on killing the beast that is EJB 1.1 by refactoring the biz code.

 Sigh, my choices are stark. It's either to keep the job and plough
 ahead
 and probably fail spectacularly 9 months later or go hungry and explain
 to
 my wife why we need to spend less on the kid..

 It's easy to blame the tech committee but they did help me find wicket
 by
 rejecting my initial proposal to build the new system on a
 (JQuery+JSON+REST) framework, which can be very productive as well, if
 not
 as "clean" as Wicket.

 Sorry for rambling so much. Is there any way I can demolish the silly
 low
 adoption rate argument (omg I still don't believe it can be so lame)?

 Lester



 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org


>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 
> 

-- 
View this message in context: 
http://old.nabble.com/Help-with-Wicket-Adoption-Numbers-tp27069702p27118513.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: wicketTester.executeAjaxEvent not working

[Alexander Elsholz]

Hi,

wicket 1.4? 

try: 
((ServletWebRequest) baseWicketTester.getWicketRequest()).setAjax(true)

mfg alex




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Serious problem with swapping two items in a list (GAEJ/ JDO)

[Piotr Tarsa]

It doesn't work out of the box, because it creates copy of a list. That list
is backed by JDO and attached to PersistenceManager, so cloning it makes
straightforward persistence impossible.

I also want to make instant changes, ie. when I click "Move Down" I expect
the items be swapped in database before page reload (and the entire form
revalidated before swapping).

2010/1/8 Igor Vaynberg 

> it usually helps to describe the problem
>
> but out of curiousity is this applicable?
> http://wicketinaction.com/2008/10/building-a-listeditor-form-component/
>
> -igor
>
> On Fri, Jan 8, 2010 at 2:42 PM, Piotr Tarsa  wrote:
> > Hello,
> >
> > I've tried virtually everything. I'm looking for someone who has
> experience
> > with GAEJ.
> >
> > Running site is at: http://data-compression.appspot.com/
> > Source code (need wicket-guice):
> http://code.google.com/p/data-compression/
> >
> > Page address:
> > http://data-compression.appspot.com/Administration/HomePagePanel
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Help with Wicket Adoption Numbers

[Lester Chua]

With such nice groundwork laid out, it should be *easier* to sell it.
Congrats in advance =).

Ernesto Reinaldo Barreiro wrote:

Hi Lester,

What I have done is implement the same "mini" application in several
technologies:

-Struts + Spring + Hibernate
-Seam + JSF + Hibernate
-Wicket + Spring/Guice + Hibernate

With detailed explanations of how things work...

Additionally I have created  a more complex prototype of another
application, done in Wicket +Spring/Guice, which shows advanced
functionality like:

-Auto-CRUDs panels, generated out of annotated POJOs, with grids supporting
column reordering via drag-drop, export to Excel, PDF, etc.
-Workspace like functionality: a page where users can work with different
floating panels as in a desktop. One of these windows contains an AJAX
driven wizard and the others are search screens the user can use to check
information while using the wizard...
-Trees, Palettes, Grids, etc.

In a couple of weeks we have some training sessions... and after that a
decision will be taken...

Regards,

Ernesto

On Mon, Jan 11, 2010 at 10:28 AM, Lester Chua  wrote:

  

Hi Ernesto,

Cant offer much advise here myself. The others have already great tips as
well as morale support.
If you are up to it, you should do a fair-sized prototype (with
multi-forms/multi girds+ajax in typical pages) and just kick their arses.
In my situation, we did a mini project with it and were just blow away with
the results.
I find it frustrating when technical evaluators do not sit down and get
their hands dirty while making decisions that will affect whole companies'
competitiveness and productivity.
When making recommendations, we should do a detailed hands on the
technology and should not just cut and paste whatever we find off the web
and present it as having done our research. Doing tutorials only are also
dangerous as they typically cover only a small subset of use cases and
normally do not illustrate the complex UI's that can arises from users
requests.

Regards,

Lester


Ernesto Reinaldo Barreiro wrote:



Hi Lester,

Right now I'm in a similar situation: I'm working for a company that wants
to (possibly) change from struts 1.X to something else and it is my job
"present" the choices to the developers and managers, so that they can
decide which will be the next framework the company will adopt for WEB
development. I'm also trying to get Wicket adopted over the other
candidates
but that won't be easy...

I fully agree with Jonathan: the only thing PHBs care about is theirs own
personal interests... So, they pay special attention to keep themselves
"on
the safe side of the fence".

Cheers,

Ernesto

On Mon, Jan 11, 2010 at 8:17 AM, Lester Chua 
wrote:



  

Jonathan,

Bingo, I think you may have hit it on the spot.

Igor,

I have not managed to get a reply on how they determined Struts2 to be
better supported compared to Wicket. But I suspect the list of a approved
technologies is not very updated. I.e. the evaluation was probably done 2
years ago.

Thanks for all the responses. The anecdotes and points made were very
helpful and have helped out get out of my depression over the weekend.
And I
have written a long and hopefully thoughtful reply to the technical
committee and will keep you guys posted.

Lester



Jonathan Locke wrote:





honestly, your response is too thoughtful. these pointy haired bosses
are
self-serving. they don't care about training costs or developer pain and
they don't really care if their org runs efficiently.  what they care
about
is that if there is a failure, their choice didn't cause it.  which is
why
the old saying goes "nobody ever got fired for buying IBM."  same seems
to
go for struts.  an idiotic technology choice, but you won't get fired
for
making the same idiotic choice everyone else is making.


Loritsch, Berin C. wrote:




  

"But why choose an inferior technology just because of its adoption
numbers?"

The pointy haired bosses that do this believe in their heart of hearts
that if you choose the same technology everyone else is using that they
can turn thinking developers for mindless drones.  It has more to do
with avoiding training costs and rational thought, and more to do with
trying to turn software development into an assembly line process.
Reality never fits this mold, but it doesn't stop the pointy haired
boss
from trying.  In this respect they are eternal optimists.

-Original Message-
From: leo.erlands...@tyringe.com [mailto:leo.erlands...@tyringe.com]
Sent: Friday, January 08, 2010 4:09 AM
To: users@wicket.apache.org
Subject: Re: Help with Wicket Adoption Numbers

Hi,

We also had the same consideration when we chose Wicket. But why choose
an inferior technology just because of it's Adoption Numbers? Also,
Wicket
is becoming more and more popular as people see the light :)

Check out Jobs Trends (Relative Growth) here (JSF vs Struts vs Wicket):
http://www.indeed.com/jobtrends?q=Struts%2C+JSF%2C+Wicket&l=&relat

RE: enclosure changes in 1.4.4

[Chris Colman]

It seems like 1.4.4 will throw the error, as you say

"for *any* missing child declared inside enclosure's markup"

but unfortunately it appears to throw it even if the child is available
by a component resolver.

Version 1.4.2 does not throw an error if the child is found via the
component resolver mechanism but 1.4.5 does (not sure about intermediate
versions 1.4.3 & 1.4.4), seemingly breaking the fix that was made in
1.4.2 that allowed the component resolver mechanism to work really well
within enclosures.


> > i think you guys misunderstand.
> >
> > i believe what we are talking about here is the requirement for
> > presence of components *other* then the component specified by
> > enclosure's child attribute.
> >
> > essentially if i do this:
> >
> > add(new webmarkupcontainer("container").setvisible(false));
> > and have this in my markup:
> > 
> >
> > wicket will not throw an error even though i never added the
"foo"
> > component to my component hierarchy because as soon as it
> > determins
> > that the container div is not visible it will skip over until
the
> > closing tag.
> >
> > the enclosures, however, as of 1.4.4 *will* throw an error for
> > *any*
> > missing child declared inside enclosure's markup *even though*
the
> > enclosure has been determined as hidden.
> >
> > hope this clears it up somewhat
> >
> > -igor

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org