Re: Run a standalone wicket app

2011-03-08 Thread nino martinez wael
you could also take a look at winstone: http://winstone.sourceforge.net/

2011/3/7 Mauro Ciancio maurocian...@gmail.com

 Hello all,
 I'd like to create a jar with a wicket application inside that can be
 run from the command line as it were a desktop application. I'm using
 maven and jetty and it would be great if jetty could start and listen
 on a port.

 Any hints or links would be really appreciated.

 Thanks in advance.
 Regards.
 --
 Mauro Ciancio
 http://about.me/maurociancio

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




Page reloading notification

2011-03-08 Thread Milan Křápek
Hi I have system based on wicket 1.3.2 (I know it is very old but it is still 
working good for me). Sometimes when I submit just local changes on page and 
operation with database take long time, It would be nice to show some 
notification that the request is processing and disable the whole page for next 
operations until the first finished.

Is there any support for this in wicket?

Thanks for any advice

Milan

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



Re: visural-wicket running on wicket 1.5?

2011-03-08 Thread Richard Nichols
Hi Nino,

The version in the public respository 1.5 branch is still a direct copy of
1.4 - sorry I haven't commited the WIP 1.5 changes yet.

I'll aim to get the WIP committed in this week.

cheers,
Richard.

On Mon, Mar 7, 2011 at 6:47 PM, nino martinez wael 
nino.martinez.w...@gmail.com wrote:

 Strange it compiles well, but does not work as wanted.. Any idea on which
 parts are causing the problems?  On my dropdowns the dropdowns are empty,
 and in my textfields both the text and the span are added if in view mode,
 and if not 2 textfields are added.

 2011/3/5 Richard Nichols r...@richardnichols.net

  I've created a 1.5 branch and it's in the works. 1.5 broke more stuff
  than expected :)
 
  Hopefully I can have a beta 1.5 branch functional within a few weeks
 
  Sent from my iPhone
 
  On 05/03/2011, at 6:15 AM, nino martinez wael
  nino.martinez.w...@gmail.com wrote:
 
   So does has anybody run it on wicket 1.5, or is there something in the
  works
   for it?
  
   regards Nino
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 




-- 
Richard Nichols
http://www.richardnichols.net/ :: http://onmydoorstep.com.au/


shift / ctrl / alt keys + ajax

2011-03-08 Thread Antoine van Wel
Hi,

when clicking an (ajax)link, or a checkbox, etc, on the server side
I'd like to know whether the shift, ctrl or alt keys are pressed at
the same time.

So I figure I need to fetch via JavaScript and adapt the ajax call
with some extra parameters.
Any thoughts how to do that in a nice  clean way in 1.5 without too
much hacking involved?


regards,
Antoine

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



[VOTE] WICKET-3218 - Component#onInitialize is broken for Pages

2011-03-08 Thread Maarten Billemont
Dear fellow wicket users,

Following is a call for your opinion and a vote on how Wicket should behave 
with regards to post-constructing components in 1.5.  The final solution that 
is chosen will affect the way you construct your components and your component 
hierarchies.



First, some background on what onInitialize is and why you should be using it.

THE PROBLEM

Historically, we've generally used our component constructors to build our 
component's hierarchy.  We call add() to put new components in our custom 
component from our component's constructor:

public class MyPanel extends Panel {

private final IModelString name = Model.of();

public MyPanel(String id) {

add(new TextFieldString(name, name));
}
}

This can cause problems, however, when initializing a component requires 
knowledge of the component's markup, or requires that the component's path in 
the hierarchy is known (during construction, the component is not yet added to 
any parent component).


THE SOLUTION

onInitialize was introduced to Component.  This gives us a place to initialize 
our component's hierarchy after our component has been added to its parent.  As 
a result, our component has a path to its page, making markup, parent and 
sibling components accessible.


THE BAD

The downside of initializing your component hierarchy in onInitialize as 
opposed to from the constructor, are:

1. You need to move all your component hierarchy initialization code into a 
separate method.  Usually, this is trivial work (cut/paste), but it is work 
that needs to be done nonetheless.
2. You cannot put your components in final instance fields anymore.
3. You should never do anything with components from custom methods.  You 
should only ever reference your components directly from overridden wicket 
methods, such as onConfigure, onBeforeRender, onSubmit, etc.

A little more on #3:

If you add custom methods to your component, eg.

void makeRequired() {
nameField.setRequired(true);
}

You allow things like: new MyPanel().makeRequired();
That would throw a NullPointerException, since nameField is no longer 
initialized in the constructor, but much later, before the component first gets 
rendered.

I would argue, though, that any custom methods that touch components are to be 
avoided at all cost.  Component behaviors should never be touched except from 
wicket lifecycle methods (you probably want onConfigure) or right after you 
construct it:  add(new TextFieldString(name, name).setRequired(true));  If 
you need a custom method such as makeRequired, it shouldn't touch components, 
it should set state that gets used by onConfigure:

void makeRequired() {

this.required = true;
}

void onConfigure() {

setRequired(required);
}

(Obviously, the example is rather silly..)



Fast-forward to https://issues.apache.org/jira/browse/WICKET-3218, it seems 
onInitialize has a problem.

THE PROBLEM

With regard to pages, if you add a component to a page from the constructor, 
onInitialize is invoked immediately.  As a result, onInitialize code is ran 
even though your instance hasn't been fully constructed yet.  This is bad.

The real issue here is that we can combine component hierarchy initialization 
with constructors and onInitialize in a single class.  However, doing so causes 
dangerous situations.  We really should do only one, not both at the same time.


THE SOLUTIONS

This is where we need your vote.  Currently, two proposed solutions exist:

1. Make onInitialize final for all Pages.  As a result, onInitialize will still 
get called when the page is constructed and components are added, but you won't 
be able to use it, avoiding the risk of you using it in a manner that requires 
your instance to be constructed.

2. Make adding components from the constructor illegal.  This would have to be 
by means of a runtime exception thrown whenever you try to add components to 
the hierarchy from the constructor.


THE GOOD

1. This will be least painful for existing code.  In all components, you can 
still mix constructor an onInitialize use, in pages, you can't use 
onInitialize, but in all likelihood, the largest amount of existing wicket code 
out there still uses constructors to create component hierarchies.

2. The safer onInitialize will always and consistently be used for any 
component hierarchy construction.  This also requires the good code habits that 
you shouldn't be doing anything with your components outside of wicket 
lifecycle methods.


THE BAD

1. Mixing constructor and onInitialize usage, whether it's within one class or 
between different classes in your type and component hierarchy, is and will 
always be dodgy.  You really shouldn't do it.  Also, to future-proof your code, 
you should really already be moving your initialization code into onInitialize. 
 Additionally, this introduces an API inconsistency: For pages, you cannot use 
onInitialize, for everything else, you should.  That's not very 

Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages

2011-03-08 Thread Maarten Billemont
Perhaps one question:

Why is onInitialize invoked immediately after a component is added to a page?  
Page#componentAdded(final Component component) (line 1603 in 1.4.15).  Is it 
really necessary to initialize the page here, and if so, why?  The only 
possibly useful thing I can see it doing is 
fireComponentInitializationListeners, but why can't that just happen later, 
before the first render?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: preferred php framework by wicketeers...

2011-03-08 Thread Martin Makundi
Hmm.. I would personally stay as close as possible from non statically
typed languages ;)

Ofcourse it depends on what you are making, if it is worth making and
so forth ;)

**
Martin

2011/3/8 Antoine van Wel antoine.van@gmail.com:
 Since you can't always have what you want..

 Is there any PHP framework out there which comes even close to Wicket;
 component based, strict separation between HTML and programming,
 stateful, out-of-the-box Ajax support, event handling, URL mapping,
 excellent testing features, and great community support?


 regards
 Antoine

 -
 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: preferred php framework by wicketeers...

2011-03-08 Thread Martin Makundi
Sorry..not close but far...maybe I meant keep enemies closer ;)

**
Martin

2011/3/8 Martin Makundi martin.maku...@koodaripalvelut.com:
 Hmm.. I would personally stay as close as possible from non statically
 typed languages ;)

 Ofcourse it depends on what you are making, if it is worth making and
 so forth ;)

 **
 Martin

 2011/3/8 Antoine van Wel antoine.van@gmail.com:
 Since you can't always have what you want..

 Is there any PHP framework out there which comes even close to Wicket;
 component based, strict separation between HTML and programming,
 stateful, out-of-the-box Ajax support, event handling, URL mapping,
 excellent testing features, and great community support?


 regards
 Antoine

 -
 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: preferred php framework by wicketeers...

2011-03-08 Thread Robert Dahlström
+1 for Symfony, probably as good as you can get for PHP. But no, it 
won't work like wicket. Afaik there are no stateful PHP frameworks out 
there (but I could be wrong).


/Robert

On 03/08/2011 01:30 PM, Martin Makundi wrote:

Sorry..not close but far...maybe I meant keep enemies closer ;)

**
Martin

2011/3/8 Martin Makundimartin.maku...@koodaripalvelut.com:

Hmm.. I would personally stay as close as possible from non statically
typed languages ;)

Ofcourse it depends on what you are making, if it is worth making and
so forth ;)

**
Martin

2011/3/8 Antoine van Welantoine.van@gmail.com:

Since you can't always have what you want..

Is there any PHP framework out there which comes even close to Wicket;
component based, strict separation between HTML and programming,
stateful, out-of-the-box Ajax support, event handling, URL mapping,
excellent testing features, and great community support?


regards
Antoine

-
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: Attribute Inheritance or Copying?

2011-03-08 Thread Yves-Marie LAINÉ
Hi,

I quickly wrote this, it seems to work.. But, does anyone know if is there a
better (wicket) way to do it ?

Regards,
Yves-Marie

class CopyAttributesBehavior extends AbstractBehavior {

private static final long serialVersionUID = 1L;
private IValueMap attributes;

@Override
public void onComponentTag(Component component, ComponentTag tag) {
if (attributes != null)
tag.getAttributes().putAll(attributes);
}

public IValueMap getAttributes() {
return attributes;
}
public void setAttributes(IValueMap attributes) {
this.attributes = attributes;
}
}

public class TestPanelT extends Panel {

private CopyAttributesBehavior copyAttributesBehavior;
private Label label;

public TestPanel(String id, IModel? extends T model) {
super(id, model);
label = new Label(label, model);
label.add(copyAttributesBehavior = new CopyAttributesBehavior());
setRenderBodyOnly(true);
add(label);
}

@Override
protected void onComponentTag(ComponentTag tag) {
super.onComponentTag(tag);
copyAttributesBehavior.setAttributes(tag.getAttributes());
}
}


2011/3/3 Hans Lesmeister 2 hans.lesmeis...@lessy-software.de



  I've to access the ComponentTag of my Panel but dont know how, except
  iam in onComponentTag.
 

 Yes, in onComponentTag of the surrounding WebmarkupContainer, you can get
 and preserve the desired attributes and then remove them.

 In onComponentTag of the TextArea you add the previously preserved
 attributes.


 -
 --
 Regards,
 Hans

 http://cantaa.de

 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Attribute-Inheritance-or-Copying-tp3332828p014.html
 Sent from the Users forum 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




-- 
Yves-Marie LAINÉ


Re: preferred php framework by wicketeers...

2011-03-08 Thread Martijn Dashorst
2011/3/8 Josh Kamau joshnet2...@gmail.com:
 I dont know of any. If you prefer scripting languages, there is a
 scala+wicket integration. Just google it if you are interested.

I would not call scala a scripting language. It is a statically typed,
compiled JVM language. It's a scripting language in the same sense
Java is a scripting language.

Martijn

-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

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



Re: preferred php framework by wicketeers...

2011-03-08 Thread Christian Grobmeier
 Sadly reality is that PHP is more widely adopted. Apache comes almost
 by default with PHP. So I was wondering, does anything come close to
 Wicket, to ease the pain.. Or to have a stronger case for Wicket in
 discussions.

Do you know Zeta Components which entered the apache incubator for a while?
http://incubator.apache.org/projects/zetacomponents.html
They have some MVC stuff inside. Thsi is mostly used in PHP world
(unfortunately)

An other approach is piwi:
http://code.google.com/a/apache-extras.org/p/piwi/
I am involved in this project, so this i my first choice. But you
should know that it's in an early state. Helping hands welcome.

Anything like Wicket in PHP world is unknown to me. I am not sure if
it makes sense tough

Cheers
Christian


 So Scala is not an option either... it's on my wish-list to learn
 though. I'm aware of the Scala/Wicket integration.


 Antoine


 2011/3/8 Josh Kamau joshnet2...@gmail.com:
 I dont know of any. If you prefer scripting languages, there is a
 scala+wicket integration. Just google it if you are interested.

 Josh.


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





-- 
http://www.grobmeier.de

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



Re: preferred php framework by wicketeers...

2011-03-08 Thread shetc
I don't think you are going to get all that from a PHP-based framework.
I have used CakePHP, which is sorta Rails-like, for production projects.
It's pretty nifty and has good community support.

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/preferred-php-framework-by-wicketeers-tp3341212p3341401.html
Sent from the Users forum 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: How to stop concurrent logins?

2011-03-08 Thread shetc
Sorry Igor, I think I'm missing something obvious here. Won't the GUID from
the cookie and session
always match as the cookie was generated from the equivalent session?

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/How-to-stop-concurrent-logins-tp3332127p3341407.html
Sent from the Users forum 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: Page reloading notification

2011-03-08 Thread Zoltán Nagy
Hi!

If you use ajax, you can register js functions into wicket ajax js
framework to show and hide notification and mask off layer:

Wicket.Ajax.registerPreCallHandler(showBusysign);
Wicket.Ajax.registerPostCallHandler(hideBusysign);
Wicket.Ajax.registerFailureHandler(hideBusysign);

You can use it as per component by adding IAjaxIndicatorAware
interface to your component.

But I don't know if these were implemented in wicket 1.3.



2011/3/8 Milan Křápek hellb...@seznam.cz:
 Hi I have system based on wicket 1.3.2 (I know it is very old but it is still 
 working good for me). Sometimes when I submit just local changes on page and 
 operation with database take long time, It would be nice to show some 
 notification that the request is processing and disable the whole page for 
 next operations until the first finished.

 Is there any support for this in wicket?

 Thanks for any advice

 Milan

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





-- 
Zoltán Nagy

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



Re: preferred php framework by wicketeers...

2011-03-08 Thread Frank van Lankvelt
On Tue, Mar 8, 2011 at 1:21 PM, Antoine van Wel
antoine.van@gmail.comwrote:

 Since you can't always have what you want..

 Is there any PHP framework out there which comes even close to Wicket;
 component based, strict separation between HTML and programming,
 stateful, out-of-the-box Ajax support, event handling, URL mapping,
 excellent testing features, and great community support?


 it would probably have turned up in your google search if it existed ;-)

A prototype is easy to make though; you should get a lot of benefits already
from adopting the wicket session mgmt, component  rendering model to php.
 In fact, I built something like this for fun some time ago.  No ajax, url
mapping, models, other fancy stuff.  But event handling and markup/code
separation is pretty easy to accomplish.

You'ld probably want to use smarty for the rendering though.  It doesn't
make a lot of sense to parse html on each request and smarty probably has
the best tooling for php templating.

cheers, Frank



 regards
 Antoine

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




-- 
Hippo Europe  •  Amsterdam  Oosteinde 11  •  1017 WT Amsterdam  •  +31 (0)20
522 4466
USA  • San Francisco 755 Baywood Drive, Second Floor •  Petaluma, CA. 94954
•  +1 877 414 4776 (toll free)
Canada•   Montréal  5369 Boulevard St-Laurent #430 •  Montréal QC H2T
1S5  •  +1 (514) 316 8966
www.onehippo.com  •  www.onehippo.org  •  i...@onehippo.com

This e-mail may be privileged and/or confidential, and the sender does
not waive any related rights and obligations. Any distribution, use or
copying of this e-mail or the information it contains by other than an
intended recipient is unauthorized. If you received this e-mail in
error, please advise me (by return e-mail or otherwise) immediately.


Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages

2011-03-08 Thread Jim Pinkham
Interesting problem.

It helped me visualize the issue when I tried to suggest:

myPage() {
   add(new Thing(this,...)); // 'this' doesn't exist yet
}

I think building component hierarchy from constructors feels natural and
it's going to be a hard sell to change to support this use case where some
components might need to know their parents.

I thought I was keeping pretty much up-to-speed on 1.5 changes, but I'm kind
of surprised this is the first I'm noticing this fairly substantial API
change.

Sorry if something like this has already been shot down - I didn't look -
but just off the top of my head, seems like there could be a way to have the
framework (as it is about to add a page to it's map or at some other
convenient early point) go back down thru the hierarchy and visit all the
components to offer them a parent reference?   Maybe guarantee it would
happen before the first onBeforeRender or something like that?

Then, we could let these visitors 'vote' on when the hierarchy is finished
changing -  (i.e. components could use this information to make additional
changes to the hierarchy) by returning a value.   Perhaps call this new
component visitor something like int onParentChanged(Component parent) -
return flags that would let the framework interrupt and restart, repeat
after finish, or just continue visiting (or maybe just return boolean repeat
flag).

-- Jim Pinkham
TogetherAuction.com

On Tue, Mar 8, 2011 at 8:33 AM, Zoltán Nagy zberke...@gmail.com wrote:

 Hi!

 My idea is this: Somewhere in the future (for example in wicket 1.6)
 adding copmonents from the constructor will be prohibited, but till
 than it should be allowed.

 --
 Zoltán Nagy

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




DataProvider calling a Service/Dao that requires a domain object

2011-03-08 Thread fernandospr
Hi,

I have a DataProvider that implements IDataProvider, and for example in the
size method I need to call the service as follows:

public int size() {
return service.countAllByDomainObjectY(domainObjectY);
}

DomainObjectX contains a manytoone relationship with DomainObjectY.
So, this countAllByDomainObjectY internally searches by the domainObjectY's
id and returns the count of DomainObjectX associated with that specific
domainObjectY.

Now, in order to do this I would need to have domainObjectY as a property of
the DataProvider which I think it is not good because it would be
serialized.

Should I change the service to receive just the domainObjectY's id and only
save this id as a property of the DataProvider?

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/DataProvider-calling-a-Service-Dao-that-requires-a-domain-object-tp3341572p3341572.html
Sent from the Users forum 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: DataProvider calling a Service/Dao that requires a domain object

2011-03-08 Thread Michael O'Cleirigh

Hi,

Pass an IModelDomainObjectmodel into your dataprovider instead of the 
DomainObject itself.


e.g.

class MyPanel

private final IModelDomainObjectmodel;

public MyPanel (String id) {
super (id);

model = new LoadableDetachableModel() {
protected DomainObject load() {// return object
}


add (new DataTable (table, columns, new DomainObjectAwareProvider 
(model), ...);


}
  protected void detatchModels() {
model.detatch();
super.detatchModels();
 }
}

The detachment of the model can be managed by the panel that creates the 
model and you can just use the object returned from the model within 
your data provider.  This is better than passing the ID because your 
provider can just work against the DomainObject without also having to 
be responsible for loading it.


Regards,

Mike


Hi,

I have a DataProvider that implements IDataProvider, and for example in the
size method I need to call the service as follows:

 public int size() {
 return service.countAllByDomainObjectY(domainObjectY);
 }

DomainObjectX contains a manytoone relationship with DomainObjectY.
So, this countAllByDomainObjectY internally searches by the domainObjectY's
id and returns the count of DomainObjectX associated with that specific
domainObjectY.

Now, in order to do this I would need to have domainObjectY as a property of
the DataProvider which I think it is not good because it would be
serialized.

Should I change the service to receive just the domainObjectY's id and only
save this id as a property of the DataProvider?

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/DataProvider-calling-a-Service-Dao-that-requires-a-domain-object-tp3341572p3341572.html
Sent from the Users forum 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: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages

2011-03-08 Thread Pedro Santos
I vote for solution 3: postpone the onInitialize call, possible to the first
Component#configure execution. Then the problem of initialization code being
executed for not  fully constructed components go away.
If it is really important to have a callback method for path cognizant
components, than the API can be improved adding one more method like the awt
Component#addNotify, but with one change: this method needs to be called
again if the component is remove / re added and it will not be a good place
to add children.

- 1 for solution 2, it is up to user decide how to code objects, the related
problems in this thread can be addressed in different way, like I voted
before.

On Tue, Mar 8, 2011 at 8:11 AM, Maarten Billemont lhun...@gmail.com wrote:

 Dear fellow wicket users,

 Following is a call for your opinion and a vote on how Wicket should behave
 with regards to post-constructing components in 1.5.  The final solution
 that is chosen will affect the way you construct your components and your
 component hierarchies.



 First, some background on what onInitialize is and why you should be using
 it.

 THE PROBLEM

 Historically, we've generally used our component constructors to build our
 component's hierarchy.  We call add() to put new components in our custom
 component from our component's constructor:

 public class MyPanel extends Panel {

private final IModelString name = Model.of();

public MyPanel(String id) {

add(new TextFieldString(name, name));
}
 }

 This can cause problems, however, when initializing a component requires
 knowledge of the component's markup, or requires that the component's path
 in the hierarchy is known (during construction, the component is not yet
 added to any parent component).


 THE SOLUTION

 onInitialize was introduced to Component.  This gives us a place to
 initialize our component's hierarchy after our component has been added to
 its parent.  As a result, our component has a path to its page, making
 markup, parent and sibling components accessible.


 THE BAD

 The downside of initializing your component hierarchy in onInitialize as
 opposed to from the constructor, are:

 1. You need to move all your component hierarchy initialization code into a
 separate method.  Usually, this is trivial work (cut/paste), but it is work
 that needs to be done nonetheless.
 2. You cannot put your components in final instance fields anymore.
 3. You should never do anything with components from custom methods.  You
 should only ever reference your components directly from overridden wicket
 methods, such as onConfigure, onBeforeRender, onSubmit, etc.

 A little more on #3:

 If you add custom methods to your component, eg.

 void makeRequired() {
nameField.setRequired(true);
 }

 You allow things like: new MyPanel().makeRequired();
 That would throw a NullPointerException, since nameField is no longer
 initialized in the constructor, but much later, before the component first
 gets rendered.

 I would argue, though, that any custom methods that touch components are to
 be avoided at all cost.  Component behaviors should never be touched except
 from wicket lifecycle methods (you probably want onConfigure) or right after
 you construct it:  add(new TextFieldString(name,
 name).setRequired(true));  If you need a custom method such as makeRequired,
 it shouldn't touch components, it should set state that gets used by
 onConfigure:

 void makeRequired() {

this.required = true;
 }

 void onConfigure() {

setRequired(required);
 }

 (Obviously, the example is rather silly..)



 Fast-forward to https://issues.apache.org/jira/browse/WICKET-3218, it
 seems onInitialize has a problem.

 THE PROBLEM

 With regard to pages, if you add a component to a page from the
 constructor, onInitialize is invoked immediately.  As a result, onInitialize
 code is ran even though your instance hasn't been fully constructed yet.
  This is bad.

 The real issue here is that we can combine component hierarchy
 initialization with constructors and onInitialize in a single class.
  However, doing so causes dangerous situations.  We really should do only
 one, not both at the same time.


 THE SOLUTIONS

 This is where we need your vote.  Currently, two proposed solutions exist:

 1. Make onInitialize final for all Pages.  As a result, onInitialize will
 still get called when the page is constructed and components are added, but
 you won't be able to use it, avoiding the risk of you using it in a manner
 that requires your instance to be constructed.

 2. Make adding components from the constructor illegal.  This would have to
 be by means of a runtime exception thrown whenever you try to add components
 to the hierarchy from the constructor.


 THE GOOD

 1. This will be least painful for existing code.  In all components, you
 can still mix constructor an onInitialize use, in pages, you can't use
 onInitialize, but in all likelihood, the largest amount of existing 

Storing and loading escaped special characters.

2011-03-08 Thread Henrique Boregio
Hi, quick question.
Wicket automatically escapes special characters so when I type in:
This is my house.

What gets stored in my database is: This is quot;myquot; house

When I try to display it using a Label, like:
new Label(label, DAO.getValue(id));

It does not convert the quot; to quotes.

Is there a way to automatically do this or do I have to manually check
and convert everything?

Thanks.

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



Re: How to stop concurrent logins?

2011-03-08 Thread Igor Vaynberg
wont the user have two or more sessions if they are logged in concurrently?

-igor

On Tue, Mar 8, 2011 at 5:52 AM, shetc sh...@bellsouth.net wrote:
 Sorry Igor, I think I'm missing something obvious here. Won't the GUID from
 the cookie and session
 always match as the cookie was generated from the equivalent session?

 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/How-to-stop-concurrent-logins-tp3332127p3341407.html
 Sent from the Users forum 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: Storing and loading escaped special characters.

2011-03-08 Thread Igor Vaynberg
call setescapemodelstrings(false) on the textfields to disable escaping.

-igor

On Tue, Mar 8, 2011 at 7:48 AM, Henrique Boregio hbore...@gmail.com wrote:
 Hi, quick question.
 Wicket automatically escapes special characters so when I type in:
 This is my house.

 What gets stored in my database is: This is quot;myquot; house

 When I try to display it using a Label, like:
 new Label(label, DAO.getValue(id));

 It does not convert the quot; to quotes.

 Is there a way to automatically do this or do I have to manually check
 and convert everything?

 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: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages

2011-03-08 Thread Hans Lesmeister 2
+1 for making Page.onInitialize() non-final. Since 1.4.12 we have migrated a
lot of code moving construction of the component hierarchies to
onInitialize. We are really very happy with the way it is now in 1.4. 

+1 for clear documentation/Javadoc explaining proper use of onInitialize.
(Developers who don't want to follow that explanation do also not have to be
protected agains themselves)

-1 for throwing an exception if add(..) is called from within a constructor
(but maybe logging a warning instead?)

I would also not have a problem with an alternative onInitialize()-method
for the Pages.


-
-- 
Regards, 
Hans 

http://cantaa.de 

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/VOTE-WICKET-3218-Component-onInitialize-is-broken-for-Pages-tp3341090p3341741.html
Sent from the Users forum 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: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages

2011-03-08 Thread Maarten Billemont
On 08 Mar 2011, at 16:39, Pedro Santos wrote:
 
 I vote for solution 3: postpone the onInitialize call, possible to the first
 Component#configure execution. Then the problem of initialization code being
 executed for not  fully constructed components go away.

I actually also thought of that, which is why I asked for the reason as to why 
initialize() is invoked as a result of components being added to a page.  If it 
ends up not being necessary (delay the onInitialize to when it's called for any 
other component) then perhaps that's a fair middle ground.  People can still 
use constructors if they like (though really, the only single *advantage* I can 
think of for this is that it means you don't have to go back and fix your 
existing codebase), and others are free to use onInitialize.

Doing your work post-construct is a very common thing in Java.  That's the 
whole point of there being a javax.annotation.PostConstruct, for example.  
Anyone that claims doing this is bad or counter-intuitive probably hasn't seen 
enough Java code yet.

We're stuck with a legacy of how we used to do things in Wicket.  And yes, that 
is a burden we should consider.  But at some point, in favor of a clean API and 
consistency, you need to be able to give up legacy.  Perhaps 1.5 is that time, 
perhaps it should be 1.6, but kid yourself not: it will be all that much harder 
the longer we wait.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages

2011-03-08 Thread Maarten Billemont
On 08 Mar 2011, at 17:38, Hans Lesmeister 2 wrote:
 
 +1 for making Page.onInitialize() non-final. Since 1.4.12 we have migrated a
 lot of code moving construction of the component hierarchies to
 onInitialize. We are really very happy with the way it is now in 1.4. 
 
 -1 for throwing an exception if add(..) is called from within a constructor
 (but maybe logging a warning instead?)

This is a valid vote if we can come up with a way of not having random failure 
side-effects from mixing the two (which is the whole reason the the issue 
exists in the first place), without a final onInitialize and an exception in 
add().

If such a solution is not suggested in this thread, we're gonna need either a 
final onInitialize or an exception in add().  You can't have your cake and eat 
it too.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: DataProvider calling a Service/Dao that requires a domain object

2011-03-08 Thread fernandospr
Thanks Michael for your quick response.

Let me know if I got it correctly:

I created the following generic model:
public class GenericDetachableModel extends LoadableDetachableModel {
private final long id;
private final Service service;

public GenericDetachableModel(T object, Service service) {
this(object, object.getId(), service);
}

public GenericDetachableModel(T object, long id, Service service) {
super(object);
if (id == 0) {
throw new IllegalArgumentException();
}
this.id = id;
this.service = service;
}

@Override
protected T load() {
return (T) service.find(id);
}
}


Now, when I create the DataProvider in my page I can use:

  myModel = new GenericDetachableModel( domainObjectY, aService );
  ...
  myDataProv = new MyDataProvider( myModel, aService );

And then inside MyDataProvider I can use:

  public MyDataProvider(IModel myModel, Service aService) {
  this.myModel = myModel;
  this.aService = aService;
  }

  public int size() { 
  return service.countAllByDomainObjectY( myModel.getObject() ); 
  } 

  public void detach() {
  myModel.detach();
  }

Is this ok?
Should myModel property in MyDataProvider be @Transient?
Is it ok to call myModel.detach() inside the MyDataProvider's detach? or
should I do it outside? (I mean, from the page where I created the
DataProvider)

Thanks in advance!


--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/DataProvider-calling-a-Service-Dao-that-requires-a-domain-object-tp3341572p3341770.html
Sent from the Users forum 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: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages

2011-03-08 Thread Carl-Eric Menzel
On Tue, 8 Mar 2011 17:43:29 +0100
Maarten Billemont lhun...@gmail.com wrote:

 On 08 Mar 2011, at 16:39, Pedro Santos wrote:
  
  I vote for solution 3: postpone the onInitialize call, possible to
  the first Component#configure execution. Then the problem of
  initialization code being executed for not  fully constructed
  components go away.

Fun fact: There is already a patch for that...

 I actually also thought of that, which is why I asked for the reason
 as to why initialize() is invoked as a result of components being
 added to a page.  If it ends up not being necessary (delay the
 onInitialize to when it's called for any other component) then
 perhaps that's a fair middle ground.  People can still use
 constructors if they like (though really, the only single *advantage*
 I can think of for this is that it means you don't have to go back
 and fix your existing codebase), and others are free to use
 onInitialize.

I would like to use onInitialize for things that *need* to be done
outside of the constructor.

However, there are much better arguments than existing codebase for
still allowing constructors. First, constructors are natural places to
do stuff like that. Yes, they have limitations, and yes, PostConstruct
exists for a reason, but that doesn't render constructors obsolete.

Second, if you need to use any kind of parameters for stuff you do in
onInitialize, you *must* store them in instance variables, even if you
need them just once and could have long let them be garbage collected.
Going purely post-construct would be a very bad idea for this reason.

Carl-Eric
www.wicketbuch.de

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



Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages

2011-03-08 Thread Carl-Eric Menzel
On Tue, 8 Mar 2011 17:46:26 +0100
Maarten Billemont lhun...@gmail.com wrote:

 This is a valid vote if we can come up with a way of not having
 random failure side-effects from mixing the two (which is the whole
 reason the the issue exists in the first place), without a final
 onInitialize and an exception in add().
 
 If such a solution is not suggested in this thread, we're gonna need
 either a final onInitialize or an exception in add().  You can't have
 your cake and eat it too.

I think there are good arguments for both constructors and
onInitialize. But the developer needs to know what he/she is doing. I
think that both options are useful and valid. This is certainly not a
case of having the cake and eating it too.

Constructor-only makes some initializations more difficult (though of
course you can still use onBeforeRender or onConfigure, as we do now,
after my patch had been rejected originally).

onInitialize-only increases memory footprint and introduces
conceptually unnecessary state by forcing you to carry *every*
parameter via an instance field.

Having both lets the developer choose the most appropriate strategy for
the component at hand.

Carl-Eric
www.wicketbuch.de

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



RE: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages

2011-03-08 Thread GOODWIN, MATTHEW (ATTCORP)
+1 for clear documentation/Javadoc explaining proper use of
onInitialize.

Does this exist somewhere? As someone new to Wicket I'm trying to learn
as fast as I can and a lot of examples (almost exclusively) I see out
there show the add(..) from within the constructor - which is apparently
an anti-pattern from the sound of this thread.

Thanks,

Matt


-Original Message-
From: Hans Lesmeister 2 [mailto:hans.lesmeis...@lessy-software.de] 
Sent: Tuesday, March 08, 2011 11:38 AM
To: users@wicket.apache.org
Subject: Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for
Pages

+1 for making Page.onInitialize() non-final. Since 1.4.12 we have
migrated a
lot of code moving construction of the component hierarchies to
onInitialize. We are really very happy with the way it is now in 1.4. 

+1 for clear documentation/Javadoc explaining proper use of
onInitialize.
(Developers who don't want to follow that explanation do also not have
to be
protected agains themselves)

-1 for throwing an exception if add(..) is called from within a
constructor
(but maybe logging a warning instead?)

I would also not have a problem with an alternative
onInitialize()-method
for the Pages.


-
-- 
Regards, 
Hans 

http://cantaa.de 

--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/VOTE-WICKET-3218-Component-on
Initialize-is-broken-for-Pages-tp3341090p3341741.html
Sent from the Users forum 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: visural-wicket running on wicket 1.5?

2011-03-08 Thread nino martinez wael
ok great.. I'll probably take at look at it monday then..

2011/3/8 Richard Nichols r...@visural.com

 Hi Nino,

 The version in the public respository 1.5 branch is still a direct copy of
 1.4 - sorry I haven't commited the WIP 1.5 changes yet.

 I'll aim to get the WIP committed in this week.

 cheers,
 Richard.

 On Mon, Mar 7, 2011 at 6:47 PM, nino martinez wael 
 nino.martinez.w...@gmail.com wrote:

  Strange it compiles well, but does not work as wanted.. Any idea on which
  parts are causing the problems?  On my dropdowns the dropdowns are empty,
  and in my textfields both the text and the span are added if in view
 mode,
  and if not 2 textfields are added.
 
  2011/3/5 Richard Nichols r...@richardnichols.net
 
   I've created a 1.5 branch and it's in the works. 1.5 broke more stuff
   than expected :)
  
   Hopefully I can have a beta 1.5 branch functional within a few weeks
  
   Sent from my iPhone
  
   On 05/03/2011, at 6:15 AM, nino martinez wael
   nino.martinez.w...@gmail.com wrote:
  
So does has anybody run it on wicket 1.5, or is there something in
 the
   works
for it?
   
regards Nino
  
   -
   To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
   For additional commands, e-mail: users-h...@wicket.apache.org
  
  
 



 --
 Richard Nichols
 http://www.richardnichols.net/ :: http://onmydoorstep.com.au/



Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages

2011-03-08 Thread Maarten Billemont
On 08 Mar 2011, at 17:54, Carl-Eric Menzel wrote:
 
 
 However, there are much better arguments than existing codebase for
 still allowing constructors. First, constructors are natural places to
 do stuff like that. Yes, they have limitations, and yes, PostConstruct
 exists for a reason, but that doesn't render constructors obsolete.

Your constructors are the perfect place to initialize your instance, at least 
at the level of your constructor's type.  Build all your instance variables 
there, handle your page parameters, and that stuff.

Just like EJBs, you should be careful about how much interaction you do beyond 
your object's scope within the constructor.  Your component doesn't have a 
hierarchy, getPage() cannot be accessed, none of your subclass constructors 
have been invoked and therefore your instance is not properly initialized and 
ready for use.  You really shouldn't be doing anything in your constructor that 
is NOT related to initializing your constructor type's instance variables.  
Touch anything else, invoke any methods, and you are opening pandora's box.

It's important to understand *what* constructors are a natural place for.

 Second, if you need to use any kind of parameters for stuff you do in
 onInitialize, you *must* store them in instance variables, even if you
 need them just once and could have long let them be garbage collected.
 Going purely post-construct would be a very bad idea for this reason.

Sorry?  Parameters?  You mean arguments to your components' constructor?  Of 
course, but you really shouldn't ever need these in onInitialize if they're not 
state.  And yes, your component's state belongs in its instance variables.  If 
this is an issue, could you enlighten me?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages

2011-03-08 Thread Martijn Dashorst
On Tue, Mar 8, 2011 at 6:03 PM, GOODWIN, MATTHEW (ATTCORP)
mg0...@att.com wrote:
 +1 for clear documentation/Javadoc explaining proper use of
 onInitialize.

 Does this exist somewhere? As someone new to Wicket I'm trying to learn
 as fast as I can and a lot of examples (almost exclusively) I see out
 there show the add(..) from within the constructor - which is apparently
 an anti-pattern from the sound of this thread.

It is most certainly not an antipattern in my book. I find the
reaction of the anti-constructor folks too strong and am trying to
formulate a civil reaction to this whole anti constructor rant.

Martijn

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



Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages

2011-03-08 Thread Igor Vaynberg
On Tue, Mar 8, 2011 at 11:42 AM, Maarten Billemont lhun...@gmail.com wrote:
 On 08 Mar 2011, at 17:54, Carl-Eric Menzel wrote:


 However, there are much better arguments than existing codebase for
 still allowing constructors. First, constructors are natural places to
 do stuff like that. Yes, they have limitations, and yes, PostConstruct
 exists for a reason, but that doesn't render constructors obsolete.

 Your constructors are the perfect place to initialize your instance, at least 
 at the level of your constructor's type.  Build all your instance variables 
 there, handle your page parameters, and that stuff.

 Just like EJBs, you should be careful about how much interaction you do 
 beyond your object's scope within the constructor.  Your component doesn't 
 have a hierarchy, getPage() cannot be accessed, none of your subclass 
 constructors have been invoked and therefore your instance is not properly 
 initialized and ready for use.

not really sure what you mean by subclass constructors or how they
come into play when constructing an instance...

  You really shouldn't be doing anything in your constructor that is NOT 
 related to initializing your constructor type's instance variables.  Touch 
 anything else, invoke any methods, and you are opening pandora's box.
 It's important to understand *what* constructors are a natural place for.

i think code like this should be possible:

NameEditor e=new NameEditor(name, firstNameModel, lastNameModel);
e.getFirstNameEditor().setRequired(true);
e.getLastNameEditor().setEnabled(false);

its simply the good citizen pattern where once you have an instance
that instance is fully constructed and is ready to use. i think this
applies to most components. i think there are much fewer components
that need a page or their environment to work, and most of them are
application-specific. wicket is all about reusability, and we should
not hinder how easy and convenient it is to create and use reusable
components.

 Second, if you need to use any kind of parameters for stuff you do in
 onInitialize, you *must* store them in instance variables, even if you
 need them just once and could have long let them be garbage collected.
 Going purely post-construct would be a very bad idea for this reason.

 Sorry?  Parameters?  You mean arguments to your components' constructor?  Of 
 course, but you really shouldn't ever need these in onInitialize if they're 
 not state.  And yes, your component's state belongs in its instance 
 variables.  If this is an issue, could you enlighten me?

taking the previous example of a name editor, with constructor we have:

class nameeditor extends panel {
  public nameeditor(...) {
 add(new textfield(first,..);
 add(new textifled(last, ...);
  }
  public textfield getfirst() { return get(first); }
  public textfield getlast() { return get(last); }
}

without constructing components i would have to do this:

class nameeditor extends panel {
  private boolean firstNameRequired, lastNameRequired;
  private boolean firstNameEnabled, lastNameEnabled;

  protected void oninitialize() {
 add(new textfield(first,..);
 add(new textifled(last, ...);
  }

  protected void onconfigure() {
 first.setrequired(firstNameRequired).setEnabled(firstNameEnabled);
 last.setrequired(lastNameRequired).setEnabled(lastNameEnabled);
  }

  public void setFirstNameRequired(value) { firstNameRequired=value; }
  public void setLastNameRequired(value) { lastNameRequired=value; }
  public void setFirstNameEnabled(value) { firstNameEnabled=value; }
  public void setLastNameEnabled(value) { lastNameEnabled=value; }
}

notice the verbosity, and four extra and redundant slots that this
component now takes up in memory and when serialized...

-igor


 -
 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



Choice of Resource for my Image component

2011-03-08 Thread Ian Marshall
Hello,

I have been a naughty boy; I designed my form without using a
LoadableDetachableModel. Serves me right. I have now changed my page's
domain object so that it is used in the form and the form's WebPage using a
LoadableDetachableModel.

So far so good, but I have a problem with my Image component. I used to use
my page's domain object to populate my image component's model like this:

ByteArrayResource resImage = null;
if ((g_pidData.sUploadFileContentType != null)
  (g_pidData.baUploadFileData != null))
  resImage = new ByteArrayResource(g_pidData.sUploadFileContentType,
   g_pidData.baUploadFileData);

Image g_imgImage = new Image(imgImage, resImage);
frmForm.add(g_imgImage);

Basically, I used the return value of

  ByteArrayResource(String sUploadFileContentType, byte[] baUploadFileData);

as the model of my Image component, with g_pidData as my domain object.

Now I have replaced my domain object with a LoadableDetachableModel. This
model's load() method returns a ByteArrayResource instance, created by using
the data members of a g_pidData instance which is local to the page's
constructor. I copy the byte array using Arrays.copyOf(...) before
constructing my ByteArrayResource instance.

I now get the following exception once my page has shown:

  08-Mar-2011 21:24:15 org.apache.wicket.RequestCycle logRuntimeException
  SEVERE: Unable to write the response
  org.apache.wicket.WicketRuntimeException: Unable to write the response
at org.apache.wicket.Response.handleException(Response.java:286)
at org.apache.wicket.Response.write(Response.java:310)
...
  Caused by: java.io.IOException: Closed
at
org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:629)
at
org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:579)
at org.apache.wicket.util.io.Streams.copy(Streams.java:159)
at org.apache.wicket.util.io.Streams.copy(Streams.java:126)
at org.apache.wicket.Response.write(Response.java:306)
... 32 more


Am I using the correct resource for my image component, or should I use a
better one?

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Choice-of-Resource-for-my-Image-component-tp3342289p3342289.html
Sent from the Users forum 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: Run a standalone wicket app

2011-03-08 Thread Nitnatsnok
To create a runnable .war file with just a maven plugin I used this tool:

http://simplericity.com/2009/11.html

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Run-a-standalone-wicket-app-tp3339521p3342507.html
Sent from the Users forum 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: Run a standalone wicket app

2011-03-08 Thread Mauro Ciancio
Hello all!
Nice replies, I really appreciate them.

I liked the maven plugin, that was exactly what i was looking for.
Winstone also looked like a good alternative.

Thanks for the replies.
Regards!

On Tue, Mar 8, 2011 at 9:02 PM, Nitnatsnok bestan...@gmail.com wrote:
 To create a runnable .war file with just a maven plugin I used this tool:

 http://simplericity.com/2009/11.html

 --
 View this message in context: 
 http://apache-wicket.1842946.n4.nabble.com/Run-a-standalone-wicket-app-tp3339521p3342507.html
 Sent from the Users forum 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





-- 
Mauro Ciancio
http://about.me/maurociancio

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



Re: visural-wicket running on wicket 1.5?

2011-03-08 Thread Richard Nichols
I've committed what appears to be a mostly working visural-wicket with 1.5
(rc2) compatibility.

http://code.google.com/p/visural-wicket/source/browse/#svn%2Fbranches%2F1.5

If there are any issues found, please report them at
http://code.google.com/p/visural-wicket/

cheers,
Richard.

On Wed, Mar 9, 2011 at 4:30 AM, nino martinez wael 
nino.martinez.w...@gmail.com wrote:

 ok great.. I'll probably take at look at it monday then..

 2011/3/8 Richard Nichols r...@visural.com

  Hi Nino,
 
  The version in the public respository 1.5 branch is still a direct copy
 of
  1.4 - sorry I haven't commited the WIP 1.5 changes yet.
 
  I'll aim to get the WIP committed in this week.
 
  cheers,
  Richard.
 
  On Mon, Mar 7, 2011 at 6:47 PM, nino martinez wael 
  nino.martinez.w...@gmail.com wrote:
 
   Strange it compiles well, but does not work as wanted.. Any idea on
 which
   parts are causing the problems?  On my dropdowns the dropdowns are
 empty,
   and in my textfields both the text and the span are added if in view
  mode,
   and if not 2 textfields are added.
  
   2011/3/5 Richard Nichols r...@richardnichols.net
  
I've created a 1.5 branch and it's in the works. 1.5 broke more stuff
than expected :)
   
Hopefully I can have a beta 1.5 branch functional within a few weeks
   
Sent from my iPhone
   
On 05/03/2011, at 6:15 AM, nino martinez wael
nino.martinez.w...@gmail.com wrote:
   
 So does has anybody run it on wicket 1.5, or is there something in
  the
works
 for it?

 regards Nino
   
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
   
   
  
 
 
 
  --
  Richard Nichols
  http://www.richardnichols.net/ :: http://onmydoorstep.com.au/
 




-- 
Richard Nichols
http://www.richardnichols.net/ :: http://onmydoorstep.com.au/


Not bookmarkable setResponsePage(new MyPage(pageParameters, extraParam1, extraParam2))

2011-03-08 Thread Alec Swan
Hello,

I have a form which calls the following statement in its onSubmit() method:

setResponsePage(new MyPage(pageParameters, extraParam1, extraParam2))

NOTE: The MyPage construtor calls WebPage constructor as
super(pageParameters) and then adds extraParam1 and extraParam2 to
WebPage.getPageParameters() map.

The end-result is that a user is redirected to a URL that has no parameters
in it, which means it cannot be bookmarked by the user.

The goal is to have onSubmit() redirect the user to a page that has all
pageParameters encoded in the URL.

What are we doing wrong and what is the recommended way to do this?

Thanks


Re: Not bookmarkable setResponsePage(new MyPage(pageParameters, extraParam1, extraParam2))

2011-03-08 Thread Igor Vaynberg
you cannot have a bookmarkable url for a page instance, only for a
page class with parameters, so

setResponsePage(MyPage.class, somePageParameters) will give you a
bookmarkable url

-igor

On Tue, Mar 8, 2011 at 8:09 PM, Alec Swan alecs...@gmail.com wrote:
 Hello,

 I have a form which calls the following statement in its onSubmit() method:

 setResponsePage(new MyPage(pageParameters, extraParam1, extraParam2))

 NOTE: The MyPage construtor calls WebPage constructor as
 super(pageParameters) and then adds extraParam1 and extraParam2 to
 WebPage.getPageParameters() map.

 The end-result is that a user is redirected to a URL that has no parameters
 in it, which means it cannot be bookmarked by the user.

 The goal is to have onSubmit() redirect the user to a page that has all
 pageParameters encoded in the URL.

 What are we doing wrong and what is the recommended way to do this?

 Thanks


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



Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages

2011-03-08 Thread Bertrand Guay-Paquet

On 08/03/2011 4:07 PM, Igor Vaynberg wrote:

On Tue, Mar 8, 2011 at 11:42 AM, Maarten Billemontlhun...@gmail.com  wrote:

On 08 Mar 2011, at 17:54, Carl-Eric Menzel wrote:


However, there are much better arguments than existing codebase for
still allowing constructors. First, constructors are natural places to
do stuff like that. Yes, they have limitations, and yes, PostConstruct
exists for a reason, but that doesn't render constructors obsolete.

Your constructors are the perfect place to initialize your instance, at least 
at the level of your constructor's type.  Build all your instance variables 
there, handle your page parameters, and that stuff.

Just like EJBs, you should be careful about how much interaction you do beyond 
your object's scope within the constructor.  Your component doesn't have a 
hierarchy, getPage() cannot be accessed, none of your subclass constructors 
have been invoked and therefore your instance is not properly initialized and 
ready for use.

not really sure what you mean by subclass constructors or how they
come into play when constructing an instance...

If I understand correctly, here is an example of what he means :
class A extends Panel {
public A() {
super(anID);
add(new Label(ALabel));
}

// Hypothetic method called when a component is added
@Override
protected void onComponentAdd(Component component) {
// do stuff
}
}

class B extends A {
private final Label label;
public B() {
label = new Label(BLabel);
// etc.
}

@Override
protected void onComponentAdd(Component component) {
super.onComponentAdd(component);
// do stuff, accessing member label = NULL pointer exception
}
}

When an instance of B is created, the B part of the object is not 
constructed yet and B#onComponentAdd() is called anyway.


I have a c++ background and this kind of problem is even more dangerous 
in c++ (virtual calls don't work as normal in constructors). In Java 
also, I think making this known to the outside world before it is 
fully constructed is unsafe, as illustrated above.


Regarding the problem of storing Page or Panel constructor parameters:
Would it be possible to add a factory method to create Panels and Pages 
in Wicket like so :
public static T extends Panel T initPanel(T instance, PageParameters 
parameters) {

instance.initialize(parameters); // new method used to add() components
instance.onInitialize();
}

This could be used like this :
setResponsePage(WicketClassSomewhere.initPanel(new MyPanel(id), 
parameters);


I'm not crazy about this construct, but I'm pitching it anyway to maybe 
inspire someone else.


As an aside, I also just learned with this thread that I should not be 
adding components to a Page or Panel in the constructor but rather do it 
in onInitialize(). I based this design on examples, Wicket in Action and 
also read the 1.5 migration notes. I must have missed that somewhere!


Regards,
Bertrand Guay-Paquet


  You really shouldn't be doing anything in your constructor that is NOT 
related to initializing your constructor type's instance variables.  Touch 
anything else, invoke any methods, and you are opening pandora's box.
It's important to understand *what* constructors are a natural place for.

i think code like this should be possible:

NameEditor e=new NameEditor(name, firstNameModel, lastNameModel);
e.getFirstNameEditor().setRequired(true);
e.getLastNameEditor().setEnabled(false);

its simply the good citizen pattern where once you have an instance
that instance is fully constructed and is ready to use. i think this
applies to most components. i think there are much fewer components
that need a page or their environment to work, and most of them are
application-specific. wicket is all about reusability, and we should
not hinder how easy and convenient it is to create and use reusable
components.


Second, if you need to use any kind of parameters for stuff you do in
onInitialize, you *must* store them in instance variables, even if you
need them just once and could have long let them be garbage collected.
Going purely post-construct would be a very bad idea for this reason.

Sorry?  Parameters?  You mean arguments to your components' constructor?  Of 
course, but you really shouldn't ever need these in onInitialize if they're not 
state.  And yes, your component's state belongs in its instance variables.  If 
this is an issue, could you enlighten me?

taking the previous example of a name editor, with constructor we have:

class nameeditor extends panel {
   public nameeditor(...) {
  add(new textfield(first,..);
  add(new textifled(last, ...);
   }
   public textfield getfirst() { return get(first); }
   public textfield getlast() { return get(last); }
}

without constructing components i would have to do this:

class nameeditor extends panel {
   private boolean firstNameRequired, lastNameRequired;
   private boolean 

Re: shift / ctrl / alt keys + ajax

2011-03-08 Thread Richard Nichols
You can do this on the client side relatively easily.

Just bind a javascript event handler to the onkeydown event in the browser.

When these key(s) are depressed change a form input to indicate which keys
are pressed.

When your Ajax event submits, you can check the model of the component the
input is bound to to determine if the key(s) were pressed.

cheers,
Richard.

On Tue, Mar 8, 2011 at 9:59 PM, Antoine van Wel
antoine.van@gmail.comwrote:

 Hi,

 when clicking an (ajax)link, or a checkbox, etc, on the server side
 I'd like to know whether the shift, ctrl or alt keys are pressed at
 the same time.

 So I figure I need to fetch via JavaScript and adapt the ajax call
 with some extra parameters.
 Any thoughts how to do that in a nice  clean way in 1.5 without too
 much hacking involved?


 regards,
 Antoine

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




-- 
Richard Nichols
http://www.richardnichols.net/ :: http://onmydoorstep.com.au/


Re: visural-wicket running on wicket 1.5?

2011-03-08 Thread nino martinez wael
Thanks. I'll give feedback if needed
On Mar 9, 2011 4:22 AM, Richard Nichols r...@visural.com wrote:
 I've committed what appears to be a mostly working visural-wicket with 1.5
 (rc2) compatibility.


http://code.google.com/p/visural-wicket/source/browse/#svn%2Fbranches%2F1.5

 If there are any issues found, please report them at
 http://code.google.com/p/visural-wicket/

 cheers,
 Richard.

 On Wed, Mar 9, 2011 at 4:30 AM, nino martinez wael 
 nino.martinez.w...@gmail.com wrote:

 ok great.. I'll probably take at look at it monday then..

 2011/3/8 Richard Nichols r...@visural.com

  Hi Nino,
 
  The version in the public respository 1.5 branch is still a direct copy
 of
  1.4 - sorry I haven't commited the WIP 1.5 changes yet.
 
  I'll aim to get the WIP committed in this week.
 
  cheers,
  Richard.
 
  On Mon, Mar 7, 2011 at 6:47 PM, nino martinez wael 
  nino.martinez.w...@gmail.com wrote:
 
   Strange it compiles well, but does not work as wanted.. Any idea on
 which
   parts are causing the problems? On my dropdowns the dropdowns are
 empty,
   and in my textfields both the text and the span are added if in view
  mode,
   and if not 2 textfields are added.
  
   2011/3/5 Richard Nichols r...@richardnichols.net
  
I've created a 1.5 branch and it's in the works. 1.5 broke more
stuff
than expected :)
   
Hopefully I can have a beta 1.5 branch functional within a few
weeks
   
Sent from my iPhone
   
On 05/03/2011, at 6:15 AM, nino martinez wael
nino.martinez.w...@gmail.com wrote:
   
 So does has anybody run it on wicket 1.5, or is there something
in
  the
works
 for it?

 regards Nino
   
   
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
   
   
  
 
 
 
  --
  Richard Nichols
  http://www.richardnichols.net/ :: http://onmydoorstep.com.au/
 




 --
 Richard Nichols
 http://www.richardnichols.net/ :: http://onmydoorstep.com.au/


Re: Not bookmarkable setResponsePage(new MyPage(pageParameters, extraParam1, extraParam2))

2011-03-08 Thread Martijn Dashorst
Wicket only knows how to construct bookmarkable pages when they have
either a default constructor or a constructor taking *only*
pageparameters. Any other constructor is outside the realm of wicket's
capabilities and responsibility.

In your case, how could Wicket construct the page when it is directly
navigated to without going through the form? That is bookmarkability.

The only way is to add those extra parameters to the PageParameters
object and use setResponsePage(MyPage.class, parameters)

Martijn


On Wed, Mar 9, 2011 at 5:09 AM, Alec Swan alecs...@gmail.com wrote:
 Hello,

 I have a form which calls the following statement in its onSubmit() method:

 setResponsePage(new MyPage(pageParameters, extraParam1, extraParam2))

 NOTE: The MyPage construtor calls WebPage constructor as
 super(pageParameters) and then adds extraParam1 and extraParam2 to
 WebPage.getPageParameters() map.

 The end-result is that a user is redirected to a URL that has no parameters
 in it, which means it cannot be bookmarked by the user.

 The goal is to have onSubmit() redirect the user to a page that has all
 pageParameters encoded in the URL.

 What are we doing wrong and what is the recommended way to do this?

 Thanks




-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

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



Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages

2011-03-08 Thread Maarten Billemont
 
 Just like EJBs, you should be careful about how much interaction you do 
 beyond your object's scope within the constructor.  Your component doesn't 
 have a hierarchy, getPage() cannot be accessed, none of your subclass 
 constructors have been invoked and therefore your instance is not properly 
 initialized and ready for use.
 not really sure what you mean by subclass constructors or how they
 come into play when constructing an instance...
 If I understand correctly, here is an example of what he means :


Exactly.  If B extends A and I do something in A's constructor that goes beyond 
the scope of setting up A's instance variables, then I risk a side-effect that 
relies on the instance to be constructed at B's level as well.  There's nothing 
in the JVM that prevents this and these bugs are very hard to see and debug.  
They should be avoided by good coding practices.

On 08 Mar 2011, at 22:07, Igor Vaynberg wrote:
 
 i think code like this should be possible:
 
 NameEditor e=new NameEditor(name, firstNameModel, lastNameModel);
 e.getFirstNameEditor().setRequired(true);
 e.getLastNameEditor().setEnabled(false);

 taking the previous example of a name editor, with constructor we have:
 
 class nameeditor extends panel {
  public nameeditor(...) {
 add(new textfield(first,..);
 add(new textifled(last, ...);
  }
  public textfield getfirst() { return get(first); }
  public textfield getlast() { return get(last); }
 }

Firstly, it's my opinion that you really shouldn't be doing anything to 
components directly, especially not from outside your class.  As for why, see 
Encapsulation and Law of Demeter.

But if you really wanted to use this pattern, it really wouldn't have to be as 
cumbersome as you make it out to be.  Also, I really don't like condoning 
get(String), it's nasty and very type-unfriendly.  It also breaks as soon as 
you do any refactoring in your component hierarchy.

class NameEditor extends Panel {
TextFieldString firstField;
TextFieldString lastField;
@Override protected void onInitialize() { super.onInitialize(); 
add(getFirst(), getLast()); }
public textfield getFirst() { if (firstField == null) firstField = new 
TextFieldString(); return firstField; }
public textfield getLast() { if (lastField == null) lastField = new 
TextFieldString(); return lastField; }
}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Models doco page typo?

2011-03-08 Thread Coleman, Chris
At the bottom of this page:

https://cwiki.apache.org/WICKET/working-with-wicket-models.html

it says that the IModel interface was simplified in Wicket 2.0... should that 
really be Wicket 1.2?

Never heard of Wicket 2 and I can see the 'new' style interface in Javadocs for 
1.5.



DISCLAIMER:---
This e-mail transmission and any documents, files and previous e-mail messages
attached to it are private and confidential. They may contain proprietary or 
copyright
material or information that is subject to legal professional privilege. They 
are for
the use of the intended recipient only.  Any unauthorised viewing, use, 
disclosure,
copying, alteration, storage or distribution of, or reliance on, this message is
strictly prohibited. No part may be reproduced, adapted or transmitted without 
the
written permission of the owner. If you have received this transmission in 
error, or
are not an authorised recipient, please immediately notify the sender by return 
email,
delete this message and all copies from your e-mail system, and destroy any 
printed
copies. Receipt by anyone other than the intended recipient should not be 
deemed a
waiver of any privilege or protection. Thales Australia does not warrant or 
represent
that this e-mail or any documents, files and previous e-mail messages attached 
are
error or virus free.
--



CompoundPropertyModel deprecated in 1.5 - what is the replacement?

2011-03-08 Thread Coleman, Chris
I noticed that CompoundPropertyModel is deprecated in 1.5 but I can't find 
anything relating to this on the Migration to Wicket 1.5 page.

What is meant to be used instead of this class?



DISCLAIMER:---
This e-mail transmission and any documents, files and previous e-mail messages
attached to it are private and confidential. They may contain proprietary or 
copyright
material or information that is subject to legal professional privilege. They 
are for
the use of the intended recipient only.  Any unauthorised viewing, use, 
disclosure,
copying, alteration, storage or distribution of, or reliance on, this message is
strictly prohibited. No part may be reproduced, adapted or transmitted without 
the
written permission of the owner. If you have received this transmission in 
error, or
are not an authorised recipient, please immediately notify the sender by return 
email,
delete this message and all copies from your e-mail system, and destroy any 
printed
copies. Receipt by anyone other than the intended recipient should not be 
deemed a
waiver of any privilege or protection. Thales Australia does not warrant or 
represent
that this e-mail or any documents, files and previous e-mail messages attached 
are
error or virus free.
--