Re: ListViews in a form question

2008-06-12 Thread Martin Makundi
Hi!

I have come up with a work-around not to loose the form components
when having to rebuild a ListView (after .removeAll).

I built a hashmaper for reusing the formComponents and it works ;)

However, I wonder if this could/should be incorporated within the
repeaters - what do you think? Furthermore, into which repeater should
it be incorporated? Any design ideas?

Here is the separate tool and its usage:

populateItem(...) {...
TextAreaString descriptionField = new
TextAreaString(DESCRIPTION_EDITOR, ...);
descriptionField = (TextAreaString)
reuseManager.rememberOrReuse(task, DESCRIPTION_EDITOR,
descriptionField);
form.add(descriptionField);
}

And the reuseManager itself is simple as follows:

public class FormComponentReuseManager {
  private final MapObject, MapString, FormComponent? idMapRow =
new HashMapObject, MapString, FormComponent?();

  public FormComponent? rememberOrReuse(Object rowId, String
componentId, FormComponent? newComponent) {
MapString, FormComponent? rowMap = createOrReuse(rowId);

FormComponent? existingComponent = rowMap.get(componentId);

if (existingComponent == null) {
  rowMap.put(componentId, newComponent);
  return newComponent;
}

// else
return existingComponent;
  }

  private MapString, FormComponent? createOrReuse(Object rowId) {
MapString, FormComponent? rowMap = idMapRow.get(rowId);
if (rowMap == null) {
  rowMap = new HashMapString, FormComponent?();
  idMapRow.put(rowId, rowMap);
}

return rowMap;
  }
}




**
Martin



 Hi!

 What is the main difference between repeatingView and listView from
 this point of view?

 I can see ListView has many features I do not use such a s moving the
 rows up and down...

 **
 Martin

 2008/6/11 Al Maw [EMAIL PROTECTED]:
 This sort of stuff is definitely possible - people certainly have it working
 elsewhere.

 If you use setReuseItems(true) you need to call removeAll() if you change
 the backing model object.

 Timo is probably right that a RepeatingView may be easier to use in this
 kind of situation.

 Alastair

 2008/6/11 Martin Makundi [EMAIL PROTECTED]:

 Hi!

 I have nested listviews which draw a complex tabular form having
 variable colspans and rowspans depending on the state of the form.

 I have an Add button to add elements into one of the inner listviews.

 Problem:
 1. If I have setReuseItems true, the HTML table is not rendered
 properly (somehow the old table structure remains which should be
 restructured).
 2. If I have setReuseItems false, the form components loose their
 state (unsubmitted entries) whenever I press the button.

 So. In my understanding, I need to both a) redraw the html table (at
 least update the colspan and rowspan attributes) and still b) preserve
 the form component state :) Is there an out-of-the-box solution for
 this?

 **
 Martin

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Refresh ModalWindow - Impossible??

2008-06-12 Thread Milan Křápek
 Hi,
  I think I have a problem that cannot be solved. But I must ask about it.

What I have:
 I have some page with table. In table are stored names of some actions. Each 
action can be edited. When I edit the action I open new ModalWindow with 
following content: It contains some ListView with operations that describe the 
parent action. Operations are parent dependent. So any change made on some 
operation affect each child of it. Each operation can be changed or there can 
be added or removed next operation.

What I am trying to do: 
When I remove one row from operations in ModalWindow I try to add the whole 
modal window to Ajax target and refresh it. It looks good. When I do this all 
my LoadableDetachableModels are called and I load new data without the removed 
operation. On ListView is called method populateItem that should process this 
changes. But the content of Modal window does not change :o(. All I  need is to 
make ModalWindow to rerender and show the new reloaded content.

Where is the problem: 
The problem occurs when I am trying to add or remove some next operartion. 
Because when I do this I need to reload (reshow or resomething) the modalWindow 
to show content corectly. So I need to update number of lines of operations. 
But I think this is imposible. Because ModalWindow is provided by Ajax and ajax 
cannot change the HTML code. So when I delete one row I need it to be deleted 
and show new updated ListView , but all I can is to hide it.  

Possible solutiuons: 
1. I think if I remove this content from ModalWindow to normal WebPage all 
problems will be solved, but this is the last solution because it will disrupt 
the style of my pages and I will have to remake all my presentation layer, 
because my app is based on pages with informations and all modifications are 
made in ModalWindows
2. After any operation that cannot be solved by Ajax (rendering changes made by 
removing or adding items) I close the ModalWindow and when user will want to 
continue with editing he will have to open the modal window again. But I think 
this will bothet the user and will be user unfriendly. 
3. Or (and I dont know if it is possible) I will close current modal window, 
reload the page and then reopen modal window with new information.

I know my entry is quite long and there are not any clear questions, but I want 
to know your opinion to this issue.

Please if there is possibility to rerender only ModalWindow with new model, let 
me know. 
How would you solve my problem if you were on my place or which variant of my 
possible solutions will you choice?
Is it possible to implement solution 3. and how?

Thanks for any advices, responses and opinions.

Best regards

Milan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Tomcat 5.5.9 isn't running Quickstart

2008-06-12 Thread Martijn Dashorst
The quickstart works for me without modifications. It serves images,
etc. out of the box, every time.

Martijn

On Thu, Jun 12, 2008 at 12:54 AM, Frank Silbermann
[EMAIL PROTECTED] wrote:
 Searching for some clue as to why my modification of the QuickStart
 application is serving images when run in Tomcat but not when running in
 embedded Jetty via Eclipse, I found:

 http://osdir.com/ml/java.jetty.support/2003-03/msg00045.html -- titled
 Re: Re: jetty can't find images: msg#00045

 It says, You need the webdefaults file because it sets up the Default
 servlet which is what serves static resources like images.  You can also
 manually add the Default servlet if you want to avoid
 a webdefaults.xml file.

 I think this is a clue.  Looking at the console log when running Jetty
 in Eclipse I see:

 INFO  - log- NO JSP Support for /, did not find
 org.apache.jasper.servlet.JspServlet

 So what do I need to do to make it set up the Default servlet?  Is there
 a line I need to insert into Start.java to make it read the
 webdefaults.xml file?  I don't even have a webdefaults.xml file --
 unless it's buried somewhere inside one of the Jetty jars.

 Here's the complete console log when debugging Start.java to bring up
 Jetty (as demonstrated in
 http://herebebeasties.com/2007-10-07/wicket-quickstart/).

 INFO  - log- Logging to
 org.slf4j.impl.Log4jLoggerAdapter(org.mortbay.log) via
 org.mortbay.log.Slf4jLog
 STARTING EMBEDDED JETTY SERVER, PRESS ANY KEY TO STOP
 INFO  - log- jetty-6.1.4
 INFO  - log- NO JSP Support for /, did not find
 org.apache.jasper.servlet.JspServlet
 INFO  - log- No Transaction manager found - if
 your webapp requires one, please configure one.
 INFO  - Application- [TestApplication] init: Wicket core
 library initializer
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IBehaviorListener, method=public abstract
 void org.apache.wicket.behavior.IBehaviorListener.onRequest()]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IBehaviorListener, method=public abstract
 void org.apache.wicket.behavior.IBehaviorListener.onRequest()]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IFormSubmitListener, method=public
 abstract void
 org.apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted()
 ]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IFormSubmitListener, method=public
 abstract void
 org.apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted()
 ]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=ILinkListener, method=public abstract
 void org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=ILinkListener, method=public abstract
 void org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IOnChangeListener, method=public abstract
 void
 org.apache.wicket.markup.html.form.IOnChangeListener.onSelectionChanged(
 )]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IOnChangeListener, method=public abstract
 void
 org.apache.wicket.markup.html.form.IOnChangeListener.onSelectionChanged(
 )]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IRedirectListener, method=public abstract
 void org.apache.wicket.IRedirectListener.onRedirect()]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IRedirectListener, method=public abstract
 void org.apache.wicket.IRedirectListener.onRedirect()]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IResourceListener, method=public abstract
 void org.apache.wicket.IResourceListener.onResourceRequested()]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IResourceListener, method=public abstract
 void org.apache.wicket.IResourceListener.onResourceRequested()]
 INFO  - Application- [TestApplication] init: Wicket
 extensions initializer
 INFO  - WebApplication - [TestApplication] Started Wicket
 version 1.3.3 in development mode
 
 *** WARNING: Wicket is running in DEVELOPMENT mode.  ***
 ***   ^^^***
 *** Do NOT deploy to your live server(s) without changing this.  ***
 *** See Application#getConfigurationType() for more information. ***

Re: Refresh ModalWindow - Impossible??

2008-06-12 Thread Martin Makundi
Hi!

Did not quite get the big picture.

But, I have experienced problems when synchronizing between two
different pages because Wicket seems to serialize-deserialize the
session - object references change. I was debugging this for quite a
while as the underlaying page was updating models that remained only
original copies of the ones in the session (and used by the
popup-page).

My solution was to make a propertymodel that references the parent
page and invokes its getSession via reflection at runtime so that
whatever copy is active gets used.

Don't know if this is your situation, though.

**
Martin

2008/6/12 Milan Křápek [EMAIL PROTECTED]:
  Hi,
  I think I have a problem that cannot be solved. But I must ask about it.

 What I have:
  I have some page with table. In table are stored names of some actions. Each 
 action can be edited. When I edit the action I open new ModalWindow with 
 following content: It contains some ListView with operations that describe 
 the parent action. Operations are parent dependent. So any change made on 
 some operation affect each child of it. Each operation can be changed or 
 there can be added or removed next operation.

 What I am trying to do:
 When I remove one row from operations in ModalWindow I try to add the whole 
 modal window to Ajax target and refresh it. It looks good. When I do this all 
 my LoadableDetachableModels are called and I load new data without the 
 removed operation. On ListView is called method populateItem that should 
 process this changes. But the content of Modal window does not change :o(. 
 All I  need is to make ModalWindow to rerender and show the new reloaded 
 content.

 Where is the problem:
 The problem occurs when I am trying to add or remove some next operartion. 
 Because when I do this I need to reload (reshow or resomething) the 
 modalWindow to show content corectly. So I need to update number of lines of 
 operations. But I think this is imposible. Because ModalWindow is provided by 
 Ajax and ajax cannot change the HTML code. So when I delete one row I need it 
 to be deleted and show new updated ListView , but all I can is to hide it.

 Possible solutiuons:
 1. I think if I remove this content from ModalWindow to normal WebPage all 
 problems will be solved, but this is the last solution because it will 
 disrupt the style of my pages and I will have to remake all my presentation 
 layer, because my app is based on pages with informations and all 
 modifications are made in ModalWindows
 2. After any operation that cannot be solved by Ajax (rendering changes made 
 by removing or adding items) I close the ModalWindow and when user will want 
 to continue with editing he will have to open the modal window again. But I 
 think this will bothet the user and will be user unfriendly.
 3. Or (and I dont know if it is possible) I will close current modal window, 
 reload the page and then reopen modal window with new information.

 I know my entry is quite long and there are not any clear questions, but I 
 want to know your opinion to this issue.

 Please if there is possibility to rerender only ModalWindow with new model, 
 let me know.
 How would you solve my problem if you were on my place or which variant of my 
 possible solutions will you choice?
 Is it possible to implement solution 3. and how?

 Thanks for any advices, responses and opinions.

 Best regards

 Milan

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




Re: Refresh ModalWindow - Impossible??

2008-06-12 Thread Milan Křápek
Hi, I think this is not my problem. I forgot mention it, but I pass to Panel 
that I show in modal window just one parameter. And it it the parent operation. 
When I render the modal window I allways read all operations form database. So 
I thing my model is allways up-to-date. I thing problem is that the ModalWindow 
can change values of its obejets, but cannot remove or add these objects.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Refresh ModalWindow - Impossible??

2008-06-12 Thread Nino Saturnino Martinez Vazquez Wael

Hi Milan

That assumption are not correct. Modal window are fully updateable 
however you want it to be. Under certain circumstances you do have to 
set it up correctly (allowing for the modal window to be refreshed in 
ajax operations). I dont have sniplet ready, but you can search the list 
for modalwindow , and I have pasted something about this earlier...


Milan K?ápek wrote:

Hi, I think this is not my problem. I forgot mention it, but I pass to Panel 
that I show in modal window just one parameter. And it it the parent operation. 
When I render the modal window I allways read all operations form database. So 
I thing my model is allways up-to-date. I thing problem is that the ModalWindow 
can change values of its obejets, but cannot remove or add these objects.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  


--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Modify model value before rendering

2008-06-12 Thread danielepiras

Hi,

I've an object with a boolean properties. I have mapped this object with a
wicket's label using a PropertyModel.
All work's fine but I read in the label true/false. Instead of this value, I
want to see another message (for example User enabled and User not
enabled. How can I do that?

Thank you very much for any help..
Daniele
-- 
View this message in context: 
http://www.nabble.com/Modify-model-value-before-rendering-tp17794855p17794855.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Making Component easier to Generify

2008-06-12 Thread Matej Knopp
Apart from the fact that this would be even more verbose than current
generics approach this would probably also radically increase
component memory footprint.

-Matej

On Thu, Jun 12, 2008 at 7:03 AM, cowwoc [EMAIL PROTECTED] wrote:


 Have you considered moving from subclassing to composition in Wicket using
 CallableT?

 Currently it is quite common for developers to subclass a component in order
 to override isVisible() and other properties. I am proposing that instead
 the component classes become final and properties may only be set using
 setter methods. The setter methods would take CallableT instead of T, so
 for example setVisible(boolean) would become setVisible(CallableBoolean)

 The benefit of this approach is that you could introduce static factory
 methods to the Wicket components which would make them much easier to use in
 their Generic form. You could then introduce various helper classes to
 create CallableT for constant values, such as Callable.valueOf(true) would
 return a CallableBoolean that always returns true.
 --
 View this message in context: 
 http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Modify model value before rendering

2008-06-12 Thread Martijn Dashorst
Either use a converter or create an adapter model that takes the
propertymodel and retrieves the nested model object, and returns the
appropriate string.

Martijn

On Thu, Jun 12, 2008 at 10:22 AM, danielepiras
[EMAIL PROTECTED] wrote:

 Hi,

 I've an object with a boolean properties. I have mapped this object with a
 wicket's label using a PropertyModel.
 All work's fine but I read in the label true/false. Instead of this value, I
 want to see another message (for example User enabled and User not
 enabled. How can I do that?

 Thank you very much for any help..
 Daniele
 --
 View this message in context: 
 http://www.nabble.com/Modify-model-value-before-rendering-tp17794855p17794855.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Modify model value before rendering

2008-06-12 Thread richardwilko

something like this might work (untested)

PropertyModel pm = new PropertyModel(this,){
@Override
public Object getObject()
{
return (Boolean) super.getObject() ? User 
enabled : User not
enabled;
}
};





danielepiras wrote:
 
 Hi,
 
 I've an object with a boolean properties. I have mapped this object with a
 wicket's label using a PropertyModel.
 All work's fine but I read in the label true/false. Instead of this value,
 I want to see another message (for example User enabled and User not
 enabled. How can I do that?
 
 Thank you very much for any help..
 Daniele
 

-- 
View this message in context: 
http://www.nabble.com/Modify-model-value-before-rendering-tp17794855p17795114.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Ajax Only application - ffeedback appriciated

2008-06-12 Thread Thomas Mäder
One thing I find interesting in Wicket is that it makes it easy again to
think about an application as a series of places where the user can be
(+/- versioning). The back/forward buttons navigate between places. Actions
manipulate what you see, you don't necessarily go anywhere else.

Thomas

On Sat, Jun 7, 2008 at 5:03 AM, Eelco Hillenius [EMAIL PROTECTED]
wrote:

  Ive been developing an ajax only application in wicket for a little more
  than 3 months. Users can open windows in a multidocument desktop-style
  fashion for various entities and in these windows/tabs perform
 different
  actions and apply different views. Further they can change views forth
 and
  back, close views, rearrange views. I almost NEVER do a page level
 GET/POST.
  The fun part is that its working really well. But Ive never seen
 something
  like this out on the web really (gmail/gcalendar ok.. but those are quite
  simple apps + they prolly got a big staff to tune every possible metric).
 
  Has anyone done something similar?

 Sure. We (Teachscape) are doing something like that. Not all Ajax
 (though we use that regularly as well), but we pretty much do
 everything in one page and implement navigation through panel swapping
 etc.

 When using Wicket like this, it is best to use the
 SecondLevelCacheSessionStore (the default in Wicket 1.3). Wicket 1.2
 and the HttpSessionStore keep recording deltas - which are smaller
 than serialized pages, but have enough versions and it adds up - as
 long as you stay on one page. At least, that's how it used to be (and
 one of the big refactorings of 1.3).

 Eelco


  Is this a dangerous track? What is most likely to stop me? How can I
 monitor
  the amout o memory a user session consumes? If I find the
  average-request-cpu-cycles *
  average_requests_per_user_during_some_duration.. is it straight forward
 to
  see how many simultaneous users I can accomodate?
 
  /Kalle
  --
  View this message in context:
 http://www.nabble.com/Ajax-Only-application---ffeedback-appriciated-tp17694786p17694786.html
  Sent from the Wicket - User mailing list archive at Nabble.com.
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




Re: Refresh ModalWindow - Impossible??

2008-06-12 Thread Milan Křápek
Thanks for that. It is great that ModalWindow is updateable. I am sorry for 
bothering you. I try to find any note how to do it on wicket forums and try to 
google it, but I was not able to find anything. Plase you said that you write 
something about it. Can you give me link?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: beginner question about models when having more than one component of the same type on the same page

2008-06-12 Thread Gwyn Evans
Just to come back to your original question (as I was intrigued  dug into
it), the reason why Wicket didn't find the properties as expected is that
the ResourceModel is relative to the component, so it was looking for
properties such as:
vacancyForm.hrContactPanel.nameLabel.nameLabel=HR Contact:

While that would have worked, a better solution would be to replace the
ResourceModel call by a new StringResourceModel(nameLabel, this, null),
where the 'this' would then be the parent ContactPanel.

Having said that, in my opinion the even better solution is the
wicket:message one you did find...

/Gwyn

On Thu, Jun 12, 2008 at 6:53 AM, Peter Eriksson [EMAIL PROTECTED] wrote:

 Thanks Timo for your very helpful suggestion!

 Best Regards,
 /Peter

 2008/6/11 Timo Rantalaiho [EMAIL PROTECTED]:

  On Wed, 11 Jun 2008, Peter Eriksson wrote:
   I will answer my own post, just in case somebody else is looking for a
   solution to the same problem. I have found two ways to get the resource
   loading to do exactly what I want (There are probably a lot more out
  there):
 
  Thanks for posting that, and cool that you found it out!
 
   add(new Label(nameLabel, new StringResourceModel(nameLabel,
   this, null)));
   add(new Label(name));
 
  These Label pairs smell like a custom component to me, e.g.
 
   public class LabeledText extends WebMarkupContainer {
   public LabeledText(String textId, MarkupContainer parent) {
   super(textId + Container);
   String labelId = textId + Label;
   add(new Label(labelId, new StringResourceModel(labelId, parent,
  null)));
   add(new Label(textId);
   }
   }
 
  Then in ContactPanel constructor you do
 
 add(new LabeledText(userName, this));
 add(new LabeledText(phone, this));
 add(new LabeledText(email, this));
 
  and change the markup accordingly (to something like
  wicket:panel
  table
  tr wicket:id=nameContainer
   tdspan wicket:id=nameLabel/span/td
  tdspan wicket:id=name/span/td
  /tr
...
  )
 
  Best wishes,
  Timo
 
  --
  Timo Rantalaiho
  Reaktor Innovations OyURL: http://www.ri.fi/ 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 



Re: Refresh ModalWindow - Impossible??

2008-06-12 Thread Nino Saturnino Martinez Vazquez Wael

http://www.nabble.com/Modal-Window-not-opening-the-second-time-td16850180.html#a16955689

And you are not bothering me. If I were bothered I'd just not answered::)

Milan K?ápek wrote:

Thanks for that. It is great that ModalWindow is updateable. I am sorry for 
bothering you. I try to find any note how to do it on wicket forums and try to 
google it, but I was not able to find anything. Plase you said that you write 
something about it. Can you give me link?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  


--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Refresh ModalWindow - Impossible??

2008-06-12 Thread Milan Křápek
Well I have it. 
 Thank you very very much. I give up the thing that I will refresh whole 
ModalWindow. I do not know why but I am not able to do. But I found another way 
how to do it. I do not update the whole modal window but only its content. I 
think this was the main problem.

Best regards

Milan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Refresh ModalWindow - Impossible??

2008-06-12 Thread Nino Saturnino Martinez Vazquez Wael
Yeah, I also only updated the contents of the modal window.. Thats the 
idea with ajax only to update as little as possible...


Milan K?ápek wrote:
Well I have it. 
 Thank you very very much. I give up the thing that I will refresh whole ModalWindow. I do not know why but I am not able to do. But I found another way how to do it. I do not update the whole modal window but only its content. I think this was the main problem.


Best regards

Milan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  


--
-Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: How to get context path

2008-06-12 Thread Hoover, William
It would be better if ContextImage was a behavior rather than an actual
component. For instance, if you have an html input of type=image (or a
link for that matter) you can still utilize the behavior whereas a
component you cannot ;o)

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 11, 2008 3:29 PM
To: users@wicket.apache.org
Subject: Re: How to get context path

see ContextImage

-igor

On Wed, Jun 11, 2008 at 12:10 PM, Patel, Sanjay [EMAIL PROTECTED]
wrote:
 Hi,

 my images in the application are in webapp/image folder. How to get 
 Context Path in wicket so I can prepend this path to display the
image.
 I am looking for something like this.

 getContextPath() + image/icon.gif;

 Please suggest how to do that.

 Thanks,
 Sanjay.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Localizer cache with 150.000+ entries causing OutOfMemory

2008-06-12 Thread Juha Alatalo
We are now using patched version of 1.3.X in a production environment 
and usage of memory seems to be much more stable.


Is there still some bug in PageWindowManager? Seems that size of 
idToWindowIndices increases every time WebPage is opened in a browser.


I run jmeter test during last night. It was simulating 50 users which 
opens a page once in a 0 - 60 seconds. Jprofiler was showing as many

IntHashMap$Entry instances as there were samples in jmeter.

- Juha



Igor Vaynberg wrote:

if someone can confirm that the patch works in a production env i will
be happy to commit it. i just havent had the time to test it myself
yet.

-igor

On Tue, Jun 10, 2008 at 7:09 AM, Juha Alatalo
[EMAIL PROTECTED] wrote:

Hi All,

I run our profiling tests (version 1.3.3) using Application.java and
Localizer.java patched by Stefan. Patch seems to be solving our memory
problems.

Is this patch coming to 1.3.4 and do you have any idea when 1.3.4 will be
released?

Best Regards
- Juha


Stefan Fußenegger wrote:

Hi Daniel,

I didn't put the patch into production yet, but I am quite confident, that
it will help. As you can see in the example I attached to the JIRA issue
(just attached a new version), the unpatched Localizer had 200 entries in
his cache, the patched Localizer only four - which is a Good Thing (tm),
as
there are only 4 different cached values!

Regards, Stefan



Daniel Frisk wrote:

So the patch did help?

I too have observed this problem but it was at the moment less of a
 problem than other heap eaters, now this is next in line. We have  added a
script which automatically restarts the server when repeated  OOME occurs
and are down to a couple of times per week without the  patch. But still,
who wouldn't want to see months of uptime...

// Daniel
jalbum.net


On 2008-06-10, at 11:29, Stefan Fußenegger wrote:


Hi Igor,

Thanks for your quick reply and the patch, sorry for not searching the
mailinglist only but not JIRA.

Your patch was for 1.4, I applied it to 1.3.3, created a quickstart
including JUnit test and attached it to the JIRA issue. Hope this  fix
gets
into the next maintenance release. I am to lazy to create a properly
 patched
jar and a MVN repo for my team right now ;)

Regards, Stefan



igor.vaynberg wrote:

try applying this patch and see if it helps

https://issues.apache.org/jira/browse/WICKET-1667

-igor

On Mon, Jun 9, 2008 at 8:11 AM, Stefan Fußenegger
[EMAIL PROTECTED] wrote:

I am just analysing a heap dump (god bless the
-XX:+HeapDumpOnOutOfMemoryError flag) of a recent application  cache
due
to
an OutOfMemoryError (GC overhead limit exceeded to be precise).
 Using
jhat, the 175456 instances of class
org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry
 immediately
got
my attention. While looking through the 107 instance of
ConcurrentHashMap, I
found one *really* big one: Localizer.cache has a hash table  length
of
262144, each of its 32 segments with about 5300 entries, where a  hash
key
is
a string, sometimes longer than 500 charactes, similar to (see
Localizer.getCacheKey(String,Component)):

fooTitle.bar-
org.apache.wicket.markup.html.link.BookmarkablePageLink:fooLink-
org.apache.wicket.markup.html.panel.Fragment:track-
org.apache.wicket.markup.html.list.ListItem:14-
my.company.FooListPanel$1:fooList-my.company.FooListPanel:foos-
org.apache.wicket.markup.html.list.ListItem:0-
my.company.BarListPanel$1:bars-my.company.FooListPanel:panel-
my.company.boxes.BodyBox:2-
org.apache.wicket.markup.repeater.RepeatingView:body-
my.company.layout.Border:border-my.company.pages.music.FoobarPage:
43-de-null

Those numbers pretty much convinced me: The localizer cache has  blown
away
my application.

Looking at this hash keys, I suspect the following problem: those
 strings
are constructed from the position of a localized String on a page,
which
is quite a bad thing if you use nested list views or repeating  views
to
construct your page. For instance, I have a panel with a long
 (pageable)
list of entries, might be  5000 entries which might appear on
 various
positions in a repeating view I use as a container for most of my
 pages.
Let's say there are 5 possible positions, this would cause 2500
 thousand
cached entries, each with a key of 300+ characters plus some more
characters
for the cached message - feel free to do the maths. From a quick
 estimate
I'd say: No wonder, this has blown away my app.

As a quick fix, I'd suggest to regularly clear the localizer  cache,
use a
more sophisticated cache (that expires old entries once in a  while!!)
or
to
disable the cache completely. However, don't try to overwrite
Localizer.newCache() and clear the cache regularly: clearCache()  will
replace your cache with a ConcurrentHashMap (not using
Localizer.newCache()). However, quite unlikely, that this will  happen
as
newCache() is private anyway ;) I am going to add some code to  clear
the
cache regularly.

Best regards, Stefan

PS: I'll also create a JIRA issue, but I am really short on time
 

Wicket Datepicker javascript not loaded in portlet environment

2008-06-12 Thread Serkan Camurcuoglu

Hi all,
I'm trying to use an 
org.apache.wicket.datetime.markup.html.form.DateTextField component 
which contains a org.apache.wicket.extensions.yui.calendar.DatePicker in 
my portlet application. The field is contained in a panel with the 
markup like:


wicket:panel
   input type=text wicket:id=dateInput/
/wicket:panel

and the panel is contained in a listview, which is also contained within 
a form. When I access the application directly, the date picker works 
fine. But when I access it as a portlet, the date picker is displayed 
correctly but it does not show the calendar when I click the icon. When 
I check with the javascript debugger, I see that wicket-event.js and 
yuiloader-beta.js files are loaded, but calendar.js and wicket-date.js 
are not loaded. I've included a related excerpt from the generated html 
page below. As far as I understand, these javascript files are 
dynamically included by YUI loader. But in a portlet environment they 
are not loaded, and I cannot use the venkman javascript debugger since 
this happens during page load. I'm using Wicket 1.3.3 and Firefox 2.0. 
Does anybody have any idea why these js files are not loaded? It would 
be great if anybody would tell me what could be wrong and give me some 
pointers on debugging this javascript code.


Best regards,

SerkanC


script type=text/javascript 
src=/subscriber-web/buyOffer/ps:681/resources/org.apache.wicket.extensions.yui.YuiLib/yuiloader-beta.js/script
script type=text/javascript 
src=/subscriber-web/buyOffer/ps:681/resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js/script
script type=text/javascript !--/*--![CDATA[/*!--*/
Wicket.Event.add(window, domready, function() { /*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements.  See the NOTICE file distributed with
* this work for additional information regarding copyright ownership.
* The ASF licenses this file to You under the Apache License, Version 2.0
* (the License); you may not use this file except in compliance with
* the License.  You may obtain a copy of the License at
*
*  http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
if (typeof wicketCalendarInits == 'undefined') {
wicketCalendarInits = new Array();
wicketCalendarInitFinished = false;
}

initdateInputjs__6818 = function() {
Wicket.DateTime.init( {
widgetId: dateInputjs__6818,
componentId: dateInputjs__6818, 
calendarInit: { 
WEEKDAYS_MEDIUM:[Sun,Mon,Tue,Wed,Thu,Fri,Sat],WEEKDAYS_1CHAR:[S,M,T,W,T,F,S],MONTHS_LONG:[January,February,March,April,May,June,July,August,September,October,November,December],WEEKDAYS_LONG:[Sunday,Monday,Tuesday,Wednesday,Thursday,Friday,Saturday],MONTHS_SHORT:[Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec],START_WEEKDAY:0,close:true,WEEKDAYS_SHORT:[Su,Mo,Tu,We,Th,Fr,Sa]
 },
datePattern: M/d/yy,
alignWithIcon: true,
fireChangeEvent: true,
hideOnSelect: true
});

};

if (wicketCalendarInitFinished) {
// when a DatePicker is added via ajax, the loader is already finished, 
so
// we call the init function directly.
initdateInputjs__6818();
} else {
// when page is rendered, all calendar components will be initialized 
after
// the required js libraries have been loaded.
wicketCalendarInits.push(initdateInputjs__6818);
}

if (typeof wicketYuiLoader == 'undefined')  {
wicketYuiLoader = new YAHOO.util.YUILoader({
		base: /subscriber-web/buyOffer/ps:681/resources/org.apache.wicket.extensions.yui.YuiLib/, 
		filter: RAW,

allowRollup: false,
require: [wicket-date], 
onSuccess: function() {
wicketCalendarInitFinished = true;  
while (wicketCalendarInits.length  0) {
wicketCalendarInits.pop()();
}   
}
});

wicketYuiLoader.addModule({
name: wicket-date,
type: js,
requires: [calendar],
		fullpath: /subscriber-web/buyOffer/ps:681/resources/org.apache.wicket.extensions.yui.calendar.DatePicker/wicket-date.js		   
	});

wicketYuiLoader.insert();
}

;});


/*--]]*//script


in the

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Replace a fragment with AjaxLink

2008-06-12 Thread vkbhaskar

How do I replace a fragment with an AjaxLink ?

I am trying something like this.

Fragment orig = new Fragment(container,original,this);
orig.setOutputMarkupId(true);
add(orig);
add(new AjaxLink(link) {
public void onClick(AjaxTarget target) {
   Fragment repl = new Fragment(container,replace,MyPage.this);
   repl.setOutputMarkupId(true);
   MyPage.this.replace(repl);
   target.add(repl);
}
}
);

But I am getting ArrayIndexOutofBoundsExceptions, when the link is clicked.
-- 
View this message in context: 
http://www.nabble.com/Replace-a-fragment-with-AjaxLink-tp17799454p17799454.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Replace a fragment with AjaxLink

2008-06-12 Thread Thomas Mäder
What's the stack trace?

On Thu, Jun 12, 2008 at 3:01 PM, vkbhaskar [EMAIL PROTECTED] wrote:


 How do I replace a fragment with an AjaxLink ?

 I am trying something like this.

 Fragment orig = new Fragment(container,original,this);
 orig.setOutputMarkupId(true);
 add(orig);
 add(new AjaxLink(link) {
public void onClick(AjaxTarget target) {
   Fragment repl = new Fragment(container,replace,MyPage.this);
   repl.setOutputMarkupId(true);
   MyPage.this.replace(repl);
   target.add(repl);
}
 }
 );

 But I am getting ArrayIndexOutofBoundsExceptions, when the link is clicked.
 --
 View this message in context:
 http://www.nabble.com/Replace-a-fragment-with-AjaxLink-tp17799454p17799454.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




Re: Making Component easier to Generify

2008-06-12 Thread Brill Pappin

on removing the finals

The final members are the worst thing I've had to deal with in Wicket  
so far.
Although I understand that there may be a reason for them, they are  
more a hinderance than anything else and seem to be trying to protect  
users from themselves.


- Brill Pappin


On 12-Jun-08, at 1:03 AM, cowwoc wrote:




Have you considered moving from subclassing to composition in Wicket  
using

CallableT?

Currently it is quite common for developers to subclass a component  
in order
to override isVisible() and other properties. I am proposing that  
instead
the component classes become final and properties may only be set  
using
setter methods. The setter methods would take CallableT instead of  
T, so
for example setVisible(boolean) would become  
setVisible(CallableBoolean)


The benefit of this approach is that you could introduce static  
factory
methods to the Wicket components which would make them much easier  
to use in

their Generic form. You could then introduce various helper classes to
create CallableT for constant values, such as  
Callable.valueOf(true) would

return a CallableBoolean that always returns true.
--
View this message in context: 
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Replace a fragment with AjaxLink

2008-06-12 Thread vkbhaskar

OK I figured out what the problem is.
If you want to replace one fragment with another over AJAX, then they must
have the same markupIds.
Otherwise it won't work.
I solved the problem by making orig fragment final.
And after repl.setOutputMarkupId(true); I added
repl.setMarkupId(orig.getMarkupId());

and then it works.

May be something for the WIKI.





Thomas Mäder wrote:
 
 What's the stack trace?
 
 On Thu, Jun 12, 2008 at 3:01 PM, vkbhaskar [EMAIL PROTECTED] wrote:
 

 How do I replace a fragment with an AjaxLink ?

 I am trying something like this.

 Fragment orig = new Fragment(container,original,this);
 orig.setOutputMarkupId(true);
 add(orig);
 add(new AjaxLink(link) {
public void onClick(AjaxTarget target) {
   Fragment repl = new Fragment(container,replace,MyPage.this);
   repl.setOutputMarkupId(true);
   MyPage.this.replace(repl);
   target.add(repl);
}
 }
 );

 But I am getting ArrayIndexOutofBoundsExceptions, when the link is
 clicked.
 --
 View this message in context:
 http://www.nabble.com/Replace-a-fragment-with-AjaxLink-tp17799454p17799454.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 

-- 
View this message in context: 
http://www.nabble.com/Replace-a-fragment-with-AjaxLink-tp17799454p17800094.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Localizer cache with 150.000+ entries causing OutOfMemory

2008-06-12 Thread Matej Knopp
I think that should be already fixed in SVN. We didn't remove the
entries on session expiration.

-Matej

On Thu, Jun 12, 2008 at 2:26 PM, Juha Alatalo
[EMAIL PROTECTED] wrote:
 We are now using patched version of 1.3.X in a production environment and
 usage of memory seems to be much more stable.

 Is there still some bug in PageWindowManager? Seems that size of
 idToWindowIndices increases every time WebPage is opened in a browser.

 I run jmeter test during last night. It was simulating 50 users which opens
 a page once in a 0 - 60 seconds. Jprofiler was showing as many
 IntHashMap$Entry instances as there were samples in jmeter.

 - Juha



 Igor Vaynberg wrote:

 if someone can confirm that the patch works in a production env i will
 be happy to commit it. i just havent had the time to test it myself
 yet.

 -igor

 On Tue, Jun 10, 2008 at 7:09 AM, Juha Alatalo
 [EMAIL PROTECTED] wrote:

 Hi All,

 I run our profiling tests (version 1.3.3) using Application.java and
 Localizer.java patched by Stefan. Patch seems to be solving our memory
 problems.

 Is this patch coming to 1.3.4 and do you have any idea when 1.3.4 will be
 released?

 Best Regards
 - Juha


 Stefan Fußenegger wrote:

 Hi Daniel,

 I didn't put the patch into production yet, but I am quite confident,
 that
 it will help. As you can see in the example I attached to the JIRA issue
 (just attached a new version), the unpatched Localizer had 200 entries
 in
 his cache, the patched Localizer only four - which is a Good Thing (tm),
 as
 there are only 4 different cached values!

 Regards, Stefan



 Daniel Frisk wrote:

 So the patch did help?

 I too have observed this problem but it was at the moment less of a
  problem than other heap eaters, now this is next in line. We have
  added a
 script which automatically restarts the server when repeated  OOME
 occurs
 and are down to a couple of times per week without the  patch. But
 still,
 who wouldn't want to see months of uptime...

 // Daniel
 jalbum.net


 On 2008-06-10, at 11:29, Stefan Fußenegger wrote:

 Hi Igor,

 Thanks for your quick reply and the patch, sorry for not searching the
 mailinglist only but not JIRA.

 Your patch was for 1.4, I applied it to 1.3.3, created a quickstart
 including JUnit test and attached it to the JIRA issue. Hope this  fix
 gets
 into the next maintenance release. I am to lazy to create a properly
  patched
 jar and a MVN repo for my team right now ;)

 Regards, Stefan



 igor.vaynberg wrote:

 try applying this patch and see if it helps

 https://issues.apache.org/jira/browse/WICKET-1667

 -igor

 On Mon, Jun 9, 2008 at 8:11 AM, Stefan Fußenegger
 [EMAIL PROTECTED] wrote:

 I am just analysing a heap dump (god bless the
 -XX:+HeapDumpOnOutOfMemoryError flag) of a recent application  cache
 due
 to
 an OutOfMemoryError (GC overhead limit exceeded to be precise).
  Using
 jhat, the 175456 instances of class
 org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry
  immediately
 got
 my attention. While looking through the 107 instance of
 ConcurrentHashMap, I
 found one *really* big one: Localizer.cache has a hash table  length
 of
 262144, each of its 32 segments with about 5300 entries, where a
  hash
 key
 is
 a string, sometimes longer than 500 charactes, similar to (see
 Localizer.getCacheKey(String,Component)):

 fooTitle.bar-
 org.apache.wicket.markup.html.link.BookmarkablePageLink:fooLink-
 org.apache.wicket.markup.html.panel.Fragment:track-
 org.apache.wicket.markup.html.list.ListItem:14-
 my.company.FooListPanel$1:fooList-my.company.FooListPanel:foos-
 org.apache.wicket.markup.html.list.ListItem:0-
 my.company.BarListPanel$1:bars-my.company.FooListPanel:panel-
 my.company.boxes.BodyBox:2-
 org.apache.wicket.markup.repeater.RepeatingView:body-
 my.company.layout.Border:border-my.company.pages.music.FoobarPage:
 43-de-null

 Those numbers pretty much convinced me: The localizer cache has
  blown
 away
 my application.

 Looking at this hash keys, I suspect the following problem: those
  strings
 are constructed from the position of a localized String on a page,
 which
 is quite a bad thing if you use nested list views or repeating
  views
 to
 construct your page. For instance, I have a panel with a long
  (pageable)
 list of entries, might be  5000 entries which might appear on
  various
 positions in a repeating view I use as a container for most of my
  pages.
 Let's say there are 5 possible positions, this would cause 2500
  thousand
 cached entries, each with a key of 300+ characters plus some more
 characters
 for the cached message - feel free to do the maths. From a quick
  estimate
 I'd say: No wonder, this has blown away my app.

 As a quick fix, I'd suggest to regularly clear the localizer  cache,
 use a
 more sophisticated cache (that expires old entries once in a
  while!!)
 or
 to
 disable the cache completely. However, don't try to overwrite
 Localizer.newCache() and clear the cache regularly: clearCache()
  will
 replace your 

Re: Making Component easier to Generify

2008-06-12 Thread cowwoc

Brill,

This is actually an API best practice. Classes fall into two categories:
ones designed for subclassing, and ones designed to be final. The same goes
for methods. Swing is full of examples of what goes wrong when people
override methods in classes that haven't been designed with subclassing in
mind.

Gili


Brill Pappin wrote:
 
 on removing the finals
 
 The final members are the worst thing I've had to deal with in Wicket  
 so far.
 Although I understand that there may be a reason for them, they are  
 more a hinderance than anything else and seem to be trying to protect  
 users from themselves.
 
 - Brill Pappin
 
 
 On 12-Jun-08, at 1:03 AM, cowwoc wrote:
 


 Have you considered moving from subclassing to composition in Wicket  
 using
 CallableT?

 Currently it is quite common for developers to subclass a component  
 in order
 to override isVisible() and other properties. I am proposing that  
 instead
 the component classes become final and properties may only be set  
 using
 setter methods. The setter methods would take CallableT instead of  
 T, so
 for example setVisible(boolean) would become  
 setVisible(CallableBoolean)

 The benefit of this approach is that you could introduce static  
 factory
 methods to the Wicket components which would make them much easier  
 to use in
 their Generic form. You could then introduce various helper classes to
 create CallableT for constant values, such as  
 Callable.valueOf(true) would
 return a CallableBoolean that always returns true.
 -- 
 View this message in context:
 http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Modifying QuickStart to serve static content in embedded Jetty (was: RE: Tomcat 5.5.9 isn't running Quickstart)

2008-06-12 Thread Frank Silbermann
Yes, the QuickStart itself works.  As for your ability to serve images,
it might depend whether these are images stored with the .html and .java
files for Wicket to pick up, versus images that are stored as static
objects.  I googled the INFO - log warning  - NO JSP Support for /, did
not find org.apache.jasper.servlet.JspServlet

and found http://code.google.com/p/run-jetty-run/wiki/GettingStarted
about running Wicket projects with Jetty in Eclipse.  It contains the
following comments:

Comment by angelo.mariano, Jan 02, 2008 
   When I try to launch it, I get the following error: 2008-01-02
10:11:55.191::INFO: Logging to STDERR  
   via org.mortbay.log.StdErrLog? 2008-01-02 10:11:55.300::INFO:
jetty-6.1.6 2008-01-02 
   10:11:55.441::INFO: NO JSP Support for /, did not find
org.apache.jasper.servlet.JspServlet? 
   2008-01-02 10:11:55.659:/:INFO: default: init 2008-01-02
10:11:55.659:/:INFO: jsp: init 2008-01-02 
   10:11:55.691::INFO: Started [EMAIL PROTECTED]:8080 

   and then I am not able to compile jsp. Do you know how to solve this
problem? Thank you 

Comment by eelco.hillenius, Jan 02, 2008 
   Ah, I probably have to include the appropriate libs to turn JSP
support on. Could you please file a 
   ticket? I'll get to it shortly. 



Eelco, could that discussion have anything to do with my problem?

-Original Message-
From: Martijn Dashorst [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 12, 2008 1:23 AM
To: users@wicket.apache.org
Subject: Re: Tomcat 5.5.9 isn't running Quickstart

The quickstart works for me without modifications. It serves images,
etc. out of the box, every time.

Martijn

On Thu, Jun 12, 2008 at 12:54 AM, Frank Silbermann
[EMAIL PROTECTED] wrote:
 Searching for some clue as to why my modification of the QuickStart 
 application is serving images when run in Tomcat but not when running 
 in embedded Jetty via Eclipse, I found:

 http://osdir.com/ml/java.jetty.support/2003-03/msg00045.html -- titled
 Re: Re: jetty can't find images: msg#00045

 It says, You need the webdefaults file because it sets up the Default

 servlet which is what serves static resources like images.  You can 
 also manually add the Default servlet if you want to avoid a 
 webdefaults.xml file.

 I think this is a clue.  Looking at the console log when running Jetty

 in Eclipse I see:

 INFO  - log- NO JSP Support for /, did not
find
 org.apache.jasper.servlet.JspServlet

 So what do I need to do to make it set up the Default servlet?  Is 
 there a line I need to insert into Start.java to make it read the 
 webdefaults.xml file?  I don't even have a webdefaults.xml file -- 
 unless it's buried somewhere inside one of the Jetty jars.

 Here's the complete console log when debugging Start.java to bring up 
 Jetty (as demonstrated in 
 http://herebebeasties.com/2007-10-07/wicket-quickstart/).

 INFO  - log- Logging to
 org.slf4j.impl.Log4jLoggerAdapter(org.mortbay.log) via 
 org.mortbay.log.Slf4jLog
 STARTING EMBEDDED JETTY SERVER, PRESS ANY KEY TO STOP
 INFO  - log- jetty-6.1.4
 INFO  - log- NO JSP Support for /, did not
find
 org.apache.jasper.servlet.JspServlet
 INFO  - log- No Transaction manager found - if
 your webapp requires one, please configure one.
 INFO  - Application- [TestApplication] init: Wicket
core
 library initializer
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IBehaviorListener, method=public 
 abstract void
org.apache.wicket.behavior.IBehaviorListener.onRequest()]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IBehaviorListener, method=public 
 abstract void
org.apache.wicket.behavior.IBehaviorListener.onRequest()]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IFormSubmitListener, method=public 
 abstract void
 org.apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted
 ()
 ]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IFormSubmitListener, method=public 
 abstract void
 org.apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted
 ()
 ]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=ILinkListener, method=public abstract 
 void org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=ILinkListener, method=public abstract 
 void org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IOnChangeListener, method=public 
 abstract void 
 org.apache.wicket.markup.html.form.IOnChangeListener.onSelectionChange
 d(
 )]
 INFO  - 

Problem with checkgroup and tree

2008-06-12 Thread DLLongo

Hello,

i have a tree and its works perfect, but when I load a gridview with the
respective data from a item, the checkgroup all doesn´t work! when I click
on the page 2 the on the navigation, checkgroup all works... why?

the page:

public class KeyPagingPanel extends Panel {

 /**
 * 
 */
private static final long serialVersionUID = 7966985858739652043L;
private static Logger logger = Logger.getLogger(KeyPagingPanel.class);

private KeyServico keyServico;
ListIModel list = new ArrayListIModel(); 

/**
 * constructor
 * @param KeyServico 
 */
public KeyPagingPanel(String id)
{
super(id);  
this.KeyServico =
((BidManagerWebApplication)getApplication()).getKeyServico();


DataView dataView = new DataView(pageable, new
KeysDataProvider(KeyServico))
{

/**
 * 
 */
private static final long serialVersionUID = 
-6643643064845215738L;



protected void populateItem(final Item item)
{
Key k = (Key)item.getModelObject();

item.add(new Check(checked,item.getModel()));
list.add(new PropertyModel(item.getModel(),checked));
item.add(new
Label(nome,k.getNome().getClasse().toString()));
//other attributes
item.add(new AttributeModifier(class, true, new
AbstractReadOnlyModel()
{
private static final long 
serialVersionUID = -708237272351206L;

public Object getObject()
{
return (item.getIndex() % 2 == 1) ? even : odd;
}
}));

}


};
Form form = new Form(KeyFormList);   
add(form);
dataView.setItemsPerPage(40);
CheckGroup checkGroup = new CheckGroup(checkgroup, list);
form.add(checkGroup);
checkGroup.add(new CheckGroupSelector(checkall));
checkGroup.add(dataView);
form.add(new PagingNavigator(navigator, dataView));
}
}

help...
thanks.
-- 
View this message in context: 
http://www.nabble.com/Problem-with-checkgroup-and-tree-tp17800883p17800883.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Modifying QuickStart to serve static content in embedded Jetty (was: RE: Tomcat 5.5.9 isn't running Quickstart)

2008-06-12 Thread Martijn Dashorst
No, because the JSP servlet is needed to compile JSPs into servlet
code. An unmodified configuration generated by the Wicket quickstart
on our website serves static images perfectly well. You really are
doing something funky.

Martijn

On Thu, Jun 12, 2008 at 4:07 PM, Frank Silbermann
[EMAIL PROTECTED] wrote:
 Yes, the QuickStart itself works.  As for your ability to serve images,
 it might depend whether these are images stored with the .html and .java
 files for Wicket to pick up, versus images that are stored as static
 objects.  I googled the INFO - log warning  - NO JSP Support for /, did
 not find org.apache.jasper.servlet.JspServlet

 and found http://code.google.com/p/run-jetty-run/wiki/GettingStarted
 about running Wicket projects with Jetty in Eclipse.  It contains the
 following comments:

 Comment by angelo.mariano, Jan 02, 2008
   When I try to launch it, I get the following error: 2008-01-02
 10:11:55.191::INFO: Logging to STDERR
   via org.mortbay.log.StdErrLog? 2008-01-02 10:11:55.300::INFO:
 jetty-6.1.6 2008-01-02
   10:11:55.441::INFO: NO JSP Support for /, did not find
 org.apache.jasper.servlet.JspServlet?
   2008-01-02 10:11:55.659:/:INFO: default: init 2008-01-02
 10:11:55.659:/:INFO: jsp: init 2008-01-02
   10:11:55.691::INFO: Started [EMAIL PROTECTED]:8080

   and then I am not able to compile jsp. Do you know how to solve this
 problem? Thank you

 Comment by eelco.hillenius, Jan 02, 2008
   Ah, I probably have to include the appropriate libs to turn JSP
 support on. Could you please file a
   ticket? I'll get to it shortly.



 Eelco, could that discussion have anything to do with my problem?

 -Original Message-
 From: Martijn Dashorst [mailto:[EMAIL PROTECTED]
 Sent: Thursday, June 12, 2008 1:23 AM
 To: users@wicket.apache.org
 Subject: Re: Tomcat 5.5.9 isn't running Quickstart

 The quickstart works for me without modifications. It serves images,
 etc. out of the box, every time.

 Martijn

 On Thu, Jun 12, 2008 at 12:54 AM, Frank Silbermann
 [EMAIL PROTECTED] wrote:
 Searching for some clue as to why my modification of the QuickStart
 application is serving images when run in Tomcat but not when running
 in embedded Jetty via Eclipse, I found:

 http://osdir.com/ml/java.jetty.support/2003-03/msg00045.html -- titled
 Re: Re: jetty can't find images: msg#00045

 It says, You need the webdefaults file because it sets up the Default

 servlet which is what serves static resources like images.  You can
 also manually add the Default servlet if you want to avoid a
 webdefaults.xml file.

 I think this is a clue.  Looking at the console log when running Jetty

 in Eclipse I see:

 INFO  - log- NO JSP Support for /, did not
 find
 org.apache.jasper.servlet.JspServlet

 So what do I need to do to make it set up the Default servlet?  Is
 there a line I need to insert into Start.java to make it read the
 webdefaults.xml file?  I don't even have a webdefaults.xml file --
 unless it's buried somewhere inside one of the Jetty jars.

 Here's the complete console log when debugging Start.java to bring up
 Jetty (as demonstrated in
 http://herebebeasties.com/2007-10-07/wicket-quickstart/).

 INFO  - log- Logging to
 org.slf4j.impl.Log4jLoggerAdapter(org.mortbay.log) via
 org.mortbay.log.Slf4jLog
 STARTING EMBEDDED JETTY SERVER, PRESS ANY KEY TO STOP
 INFO  - log- jetty-6.1.4
 INFO  - log- NO JSP Support for /, did not
 find
 org.apache.jasper.servlet.JspServlet
 INFO  - log- No Transaction manager found - if
 your webapp requires one, please configure one.
 INFO  - Application- [TestApplication] init: Wicket
 core
 library initializer
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IBehaviorListener, method=public
 abstract void
 org.apache.wicket.behavior.IBehaviorListener.onRequest()]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IBehaviorListener, method=public
 abstract void
 org.apache.wicket.behavior.IBehaviorListener.onRequest()]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IFormSubmitListener, method=public
 abstract void
 org.apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted
 ()
 ]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IFormSubmitListener, method=public
 abstract void
 org.apache.wicket.markup.html.form.IFormSubmitListener.onFormSubmitted
 ()
 ]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=ILinkListener, method=public abstract
 void org.apache.wicket.markup.html.link.ILinkListener.onLinkClicked()]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=ILinkListener, method=public abstract
 void 

AjaxSubmitLink refreshing problem

2008-06-12 Thread alesp

Hello!
Ok, this is the problem: I have the following wicket hierarchy:

Panel
   |
-- Form
|
 -- WebMarkupContainer (setOutputMarkupId(true))
||
|-- ListView (with a
LoadableDetachableModel)
|  |
|   -- { populateItem {
AjaxSubmitLink (to delete an element. Updates the WebMarkupContainer) } }
 -- AutoCompleteTextField
|
 -- AjaxSubmitLink (to add an element)

The problem is that the add link (the AjaxSubmitLink at the bottom of the
diagram) is working fine, but the delete is not, and the code is pretty
the same (calling different methods). When I say it's not working I mean
that I click the delete link and nothing happens (internally the element
is removed properly but the page doesn't refresh the changes). The add
link works, I press add and the list is refreshed with the new element.
Trying to find out what's happening I copied the onSubmit method of the
delete AjaxSubmitLink to the add link and again the list was properly
refreshed, now with a delete action. So, I think that the problem is related
to the location of the links in the hierarchy and something that I'm missing
there.
Any idea?
-- 
View this message in context: 
http://www.nabble.com/AjaxSubmitLink-refreshing-problem-tp17801832p17801832.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Modify model value before rendering

2008-06-12 Thread Igor Vaynberg
or just write your own model in an inner class...

-igor

On Thu, Jun 12, 2008 at 1:45 AM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
 Either use a converter or create an adapter model that takes the
 propertymodel and retrieves the nested model object, and returns the
 appropriate string.

 Martijn

 On Thu, Jun 12, 2008 at 10:22 AM, danielepiras
 [EMAIL PROTECTED] wrote:

 Hi,

 I've an object with a boolean properties. I have mapped this object with a
 wicket's label using a PropertyModel.
 All work's fine but I read in the label true/false. Instead of this value, I
 want to see another message (for example User enabled and User not
 enabled. How can I do that?

 Thank you very much for any help..
 Daniele
 --
 View this message in context: 
 http://www.nabble.com/Modify-model-value-before-rendering-tp17794855p17794855.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.3.3 is released
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Making Component easier to Generify

2008-06-12 Thread Brill Pappin
I understand the reasoning, however I think best practice can be  
debated.
To use your example Swing allows the user to override quite a bit, and  
it doesn't make any (or very few) assumptions on what should and  
should not be done.


I don't like API's that assume I'm an idiot and prevent me from  
manipulating them how I see fit. If I cause a bug that I have to deal  
with, thats *my* problem to resolve.


In my book (and I'm not the only one) excessive use of final is an  
anti-pattern.


- Brill Pappin

On 12-Jun-08, at 10:01 AM, cowwoc wrote:



Brill,

This is actually an API best practice. Classes fall into two  
categories:
ones designed for subclassing, and ones designed to be final. The  
same goes

for methods. Swing is full of examples of what goes wrong when people
override methods in classes that haven't been designed with  
subclassing in

mind.

Gili


Brill Pappin wrote:


on removing the finals

The final members are the worst thing I've had to deal with in Wicket
so far.
Although I understand that there may be a reason for them, they are
more a hinderance than anything else and seem to be trying to  
protect

users from themselves.

- Brill Pappin


On 12-Jun-08, at 1:03 AM, cowwoc wrote:




Have you considered moving from subclassing to composition in Wicket
using
CallableT?

Currently it is quite common for developers to subclass a component
in order
to override isVisible() and other properties. I am proposing that
instead
the component classes become final and properties may only be set
using
setter methods. The setter methods would take CallableT instead of
T, so
for example setVisible(boolean) would become
setVisible(CallableBoolean)

The benefit of this approach is that you could introduce static
factory
methods to the Wicket components which would make them much easier
to use in
their Generic form. You could then introduce various helper  
classes to

create CallableT for constant values, such as
Callable.valueOf(true) would
return a CallableBoolean that always returns true.
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
View this message in context: 
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



wicket-datetime's DatePicker uses a static SimpleDateFormat

2008-06-12 Thread vkbhaskar

wicket-datetimes DatePicker.java uses a static instance of SimpleDateFormat,
but
SimpleDateFormat is not tread safe.
Should this be fixed ?
-- 
View this message in context: 
http://www.nabble.com/wicket-datetime%27s-DatePicker-uses-a-static-SimpleDateFormat-tp17802346p17802346.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AjaxSubmitLink refreshing problem

2008-06-12 Thread jchappelle

The ListView class has a method called removeLink that returns a Link that
will remove the item from the list. I have never used it but I just figured
I would point it out to you. Maybe looking at the source code of that method
could help.

Also, make sure you are adding your WebMarkupContainer to the
AjaxRequestTarget. Otherwise the Ajax call will not update that section of
your markup.

Josh


alesp wrote:
 
 Hello!
 Ok, this is the problem: I have the following wicket hierarchy:
 
 Panel
|
 -- Form
 |
  -- WebMarkupContainer (setOutputMarkupId(true))
 ||
 |-- ListView (with a
 LoadableDetachableModel)
 |  |
 |   -- { populateItem {
 AjaxSubmitLink (to delete an element. Updates the WebMarkupContainer) }
 }
  -- AutoCompleteTextField
 |
  -- AjaxSubmitLink (to add an element)
 
 The problem is that the add link (the AjaxSubmitLink at the bottom of
 the diagram) is working fine, but the delete is not, and the code is
 pretty the same (calling different methods). When I say it's not working I
 mean that I click the delete link and nothing happens (internally the
 element is removed properly but the page doesn't refresh the changes). The
 add link works, I press add and the list is refreshed with the new
 element.
 Trying to find out what's happening I copied the onSubmit method of the
 delete AjaxSubmitLink to the add link and again the list was properly
 refreshed, now with a delete action. So, I think that the problem is
 related to the location of the links in the hierarchy and something that
 I'm missing there.
 Any idea?
 

-- 
View this message in context: 
http://www.nabble.com/AjaxSubmitLink-refreshing-problem-tp17801832p17802380.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Making Component easier to Generify

2008-06-12 Thread James Carman
On Thu, Jun 12, 2008 at 11:08 AM, Brill Pappin [EMAIL PROTECTED] wrote:
 I understand the reasoning, however I think best practice can be debated.
 To use your example Swing allows the user to override quite a bit, and it
 doesn't make any (or very few) assumptions on what should and should not be
 done.

 I don't like API's that assume I'm an idiot and prevent me from manipulating
 them how I see fit. If I cause a bug that I have to deal with, thats *my*
 problem to resolve.

 In my book (and I'm not the only one) excessive use of final is an
 anti-pattern.

While I agree that using final all over the place is in general a bad
idea, there are other reasons to use the final modifier on a method.
It can also help performance (although these particular cases might
not be good examples of where you'd want to squeeze every last bit of
performance out at the cost of disallowing extensibility).

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Making Component easier to Generify

2008-06-12 Thread Martijn Dashorst
Without the use of final wicket would not have made it this far.

Martijn

On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin [EMAIL PROTECTED] wrote:
 I understand the reasoning, however I think best practice can be debated.
 To use your example Swing allows the user to override quite a bit, and it
 doesn't make any (or very few) assumptions on what should and should not be
 done.

 I don't like API's that assume I'm an idiot and prevent me from manipulating
 them how I see fit. If I cause a bug that I have to deal with, thats *my*
 problem to resolve.

 In my book (and I'm not the only one) excessive use of final is an
 anti-pattern.

 - Brill Pappin

 On 12-Jun-08, at 10:01 AM, cowwoc wrote:


 Brill,

 This is actually an API best practice. Classes fall into two categories:
 ones designed for subclassing, and ones designed to be final. The same
 goes
 for methods. Swing is full of examples of what goes wrong when people
 override methods in classes that haven't been designed with subclassing in
 mind.

 Gili


 Brill Pappin wrote:

 on removing the finals

 The final members are the worst thing I've had to deal with in Wicket
 so far.
 Although I understand that there may be a reason for them, they are
 more a hinderance than anything else and seem to be trying to protect
 users from themselves.

 - Brill Pappin


 On 12-Jun-08, at 1:03 AM, cowwoc wrote:



 Have you considered moving from subclassing to composition in Wicket
 using
 CallableT?

 Currently it is quite common for developers to subclass a component
 in order
 to override isVisible() and other properties. I am proposing that
 instead
 the component classes become final and properties may only be set
 using
 setter methods. The setter methods would take CallableT instead of
 T, so
 for example setVisible(boolean) would become
 setVisible(CallableBoolean)

 The benefit of this approach is that you could introduce static
 factory
 methods to the Wicket components which would make them much easier
 to use in
 their Generic form. You could then introduce various helper classes to
 create CallableT for constant values, such as
 Callable.valueOf(true) would
 return a CallableBoolean that always returns true.
 --
 View this message in context:

 http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 --
 View this message in context:
 http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: AjaxSubmitLink refreshing problem

2008-06-12 Thread alesp

Hello jchappelle.
Yes, I'm adding the WebMarkupContainer to the AjaxRequestTarget, but I'm
going to look that method you mentioned, maybe the solution is there.
Thanks.


jchappelle wrote:
 
 The ListView class has a method called removeLink that returns a Link that
 will remove the item from the list. I have never used it but I just
 figured I would point it out to you. Maybe looking at the source code of
 that method could help.
 
 Also, make sure you are adding your WebMarkupContainer to the
 AjaxRequestTarget. Otherwise the Ajax call will not update that section of
 your markup.
 
 Josh
 
 
 alesp wrote:
 
 Hello!
 Ok, this is the problem: I have the following wicket hierarchy:
 
 Panel
|
 -- Form
 |
  -- WebMarkupContainer (setOutputMarkupId(true))
 ||
 |-- ListView (with a
 LoadableDetachableModel)
 |  |
 |   -- { populateItem {
 AjaxSubmitLink (to delete an element. Updates the WebMarkupContainer) }
 }
  -- AutoCompleteTextField
 |
  -- AjaxSubmitLink (to add an element)
 
 The problem is that the add link (the AjaxSubmitLink at the bottom of
 the diagram) is working fine, but the delete is not, and the code is
 pretty the same (calling different methods). When I say it's not working
 I mean that I click the delete link and nothing happens (internally the
 element is removed properly but the page doesn't refresh the changes).
 The add link works, I press add and the list is refreshed with the
 new element.
 Trying to find out what's happening I copied the onSubmit method of the
 delete AjaxSubmitLink to the add link and again the list was properly
 refreshed, now with a delete action. So, I think that the problem is
 related to the location of the links in the hierarchy and something that
 I'm missing there.
 Any idea?
 
 
 

-- 
View this message in context: 
http://www.nabble.com/AjaxSubmitLink-refreshing-problem-tp17801832p17802573.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: How to get context path

2008-06-12 Thread Igor Vaynberg
jira is your friend

-igor

On Thu, Jun 12, 2008 at 4:46 AM, Hoover, William [EMAIL PROTECTED] wrote:
 It would be better if ContextImage was a behavior rather than an actual
 component. For instance, if you have an html input of type=image (or a
 link for that matter) you can still utilize the behavior whereas a
 component you cannot ;o)

 -Original Message-
 From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, June 11, 2008 3:29 PM
 To: users@wicket.apache.org
 Subject: Re: How to get context path

 see ContextImage

 -igor

 On Wed, Jun 11, 2008 at 12:10 PM, Patel, Sanjay [EMAIL PROTECTED]
 wrote:
 Hi,

 my images in the application are in webapp/image folder. How to get
 Context Path in wicket so I can prepend this path to display the
 image.
 I am looking for something like this.

 getContextPath() + image/icon.gif;

 Please suggest how to do that.

 Thanks,
 Sanjay.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Making Component easier to Generify

2008-06-12 Thread Igor Vaynberg
indeed. i wouldnt mind if final was the default in java :)

-igor

On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
 Without the use of final wicket would not have made it this far.

 Martijn

 On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin [EMAIL PROTECTED] wrote:
 I understand the reasoning, however I think best practice can be debated.
 To use your example Swing allows the user to override quite a bit, and it
 doesn't make any (or very few) assumptions on what should and should not be
 done.

 I don't like API's that assume I'm an idiot and prevent me from manipulating
 them how I see fit. If I cause a bug that I have to deal with, thats *my*
 problem to resolve.

 In my book (and I'm not the only one) excessive use of final is an
 anti-pattern.

 - Brill Pappin

 On 12-Jun-08, at 10:01 AM, cowwoc wrote:


 Brill,

 This is actually an API best practice. Classes fall into two categories:
 ones designed for subclassing, and ones designed to be final. The same
 goes
 for methods. Swing is full of examples of what goes wrong when people
 override methods in classes that haven't been designed with subclassing in
 mind.

 Gili


 Brill Pappin wrote:

 on removing the finals

 The final members are the worst thing I've had to deal with in Wicket
 so far.
 Although I understand that there may be a reason for them, they are
 more a hinderance than anything else and seem to be trying to protect
 users from themselves.

 - Brill Pappin


 On 12-Jun-08, at 1:03 AM, cowwoc wrote:



 Have you considered moving from subclassing to composition in Wicket
 using
 CallableT?

 Currently it is quite common for developers to subclass a component
 in order
 to override isVisible() and other properties. I am proposing that
 instead
 the component classes become final and properties may only be set
 using
 setter methods. The setter methods would take CallableT instead of
 T, so
 for example setVisible(boolean) would become
 setVisible(CallableBoolean)

 The benefit of this approach is that you could introduce static
 factory
 methods to the Wicket components which would make them much easier
 to use in
 their Generic form. You could then introduce various helper classes to
 create CallableT for constant values, such as
 Callable.valueOf(true) would
 return a CallableBoolean that always returns true.
 --
 View this message in context:

 http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 --
 View this message in context:
 http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.3.3 is released
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Making Component easier to Generify

2008-06-12 Thread James Carman
You mean like C++?

On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
 indeed. i wouldnt mind if final was the default in java :)

 -igor

 On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst
 [EMAIL PROTECTED] wrote:
 Without the use of final wicket would not have made it this far.

 Martijn

 On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin [EMAIL PROTECTED] wrote:
 I understand the reasoning, however I think best practice can be debated.
 To use your example Swing allows the user to override quite a bit, and it
 doesn't make any (or very few) assumptions on what should and should not be
 done.

 I don't like API's that assume I'm an idiot and prevent me from manipulating
 them how I see fit. If I cause a bug that I have to deal with, thats *my*
 problem to resolve.

 In my book (and I'm not the only one) excessive use of final is an
 anti-pattern.

 - Brill Pappin

 On 12-Jun-08, at 10:01 AM, cowwoc wrote:


 Brill,

 This is actually an API best practice. Classes fall into two categories:
 ones designed for subclassing, and ones designed to be final. The same
 goes
 for methods. Swing is full of examples of what goes wrong when people
 override methods in classes that haven't been designed with subclassing in
 mind.

 Gili


 Brill Pappin wrote:

 on removing the finals

 The final members are the worst thing I've had to deal with in Wicket
 so far.
 Although I understand that there may be a reason for them, they are
 more a hinderance than anything else and seem to be trying to protect
 users from themselves.

 - Brill Pappin


 On 12-Jun-08, at 1:03 AM, cowwoc wrote:



 Have you considered moving from subclassing to composition in Wicket
 using
 CallableT?

 Currently it is quite common for developers to subclass a component
 in order
 to override isVisible() and other properties. I am proposing that
 instead
 the component classes become final and properties may only be set
 using
 setter methods. The setter methods would take CallableT instead of
 T, so
 for example setVisible(boolean) would become
 setVisible(CallableBoolean)

 The benefit of this approach is that you could introduce static
 factory
 methods to the Wicket components which would make them much easier
 to use in
 their Generic form. You could then introduce various helper classes to
 create CallableT for constant values, such as
 Callable.valueOf(true) would
 return a CallableBoolean that always returns true.
 --
 View this message in context:

 http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 --
 View this message in context:
 http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.3.3 is released
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Making Component easier to Generify

2008-06-12 Thread Igor Vaynberg
i mean generally, for methods, fields, and func args :) most of this
stuff can stay final, but people dont bother doing it because its
extra typing.

-igor

On Thu, Jun 12, 2008 at 8:38 AM, James Carman
[EMAIL PROTECTED] wrote:
 You mean like C++?

 On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
 indeed. i wouldnt mind if final was the default in java :)

 -igor

 On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst
 [EMAIL PROTECTED] wrote:
 Without the use of final wicket would not have made it this far.

 Martijn

 On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin [EMAIL PROTECTED] wrote:
 I understand the reasoning, however I think best practice can be debated.
 To use your example Swing allows the user to override quite a bit, and it
 doesn't make any (or very few) assumptions on what should and should not be
 done.

 I don't like API's that assume I'm an idiot and prevent me from 
 manipulating
 them how I see fit. If I cause a bug that I have to deal with, thats *my*
 problem to resolve.

 In my book (and I'm not the only one) excessive use of final is an
 anti-pattern.

 - Brill Pappin

 On 12-Jun-08, at 10:01 AM, cowwoc wrote:


 Brill,

 This is actually an API best practice. Classes fall into two categories:
 ones designed for subclassing, and ones designed to be final. The same
 goes
 for methods. Swing is full of examples of what goes wrong when people
 override methods in classes that haven't been designed with subclassing in
 mind.

 Gili


 Brill Pappin wrote:

 on removing the finals

 The final members are the worst thing I've had to deal with in Wicket
 so far.
 Although I understand that there may be a reason for them, they are
 more a hinderance than anything else and seem to be trying to protect
 users from themselves.

 - Brill Pappin


 On 12-Jun-08, at 1:03 AM, cowwoc wrote:



 Have you considered moving from subclassing to composition in Wicket
 using
 CallableT?

 Currently it is quite common for developers to subclass a component
 in order
 to override isVisible() and other properties. I am proposing that
 instead
 the component classes become final and properties may only be set
 using
 setter methods. The setter methods would take CallableT instead of
 T, so
 for example setVisible(boolean) would become
 setVisible(CallableBoolean)

 The benefit of this approach is that you could introduce static
 factory
 methods to the Wicket components which would make them much easier
 to use in
 their Generic form. You could then introduce various helper classes to
 create CallableT for constant values, such as
 Callable.valueOf(true) would
 return a CallableBoolean that always returns true.
 --
 View this message in context:

 http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 --
 View this message in context:
 http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.3.3 is released
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Making Component easier to Generify

2008-06-12 Thread James Carman
That's funny.  By default I make every local variable final if I can.
I guess it's just out of habit.  I usually do the same for method
parameters, too (I'm less diligent about that one).  For methods, I
usually just leave them be until I know for sure that I need them to
be final.

On Thu, Jun 12, 2008 at 11:42 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
 i mean generally, for methods, fields, and func args :) most of this
 stuff can stay final, but people dont bother doing it because its
 extra typing.

 -igor

 On Thu, Jun 12, 2008 at 8:38 AM, James Carman
 [EMAIL PROTECTED] wrote:
 You mean like C++?

 On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
 indeed. i wouldnt mind if final was the default in java :)

 -igor

 On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst
 [EMAIL PROTECTED] wrote:
 Without the use of final wicket would not have made it this far.

 Martijn

 On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin [EMAIL PROTECTED] wrote:
 I understand the reasoning, however I think best practice can be 
 debated.
 To use your example Swing allows the user to override quite a bit, and it
 doesn't make any (or very few) assumptions on what should and should not 
 be
 done.

 I don't like API's that assume I'm an idiot and prevent me from 
 manipulating
 them how I see fit. If I cause a bug that I have to deal with, thats *my*
 problem to resolve.

 In my book (and I'm not the only one) excessive use of final is an
 anti-pattern.

 - Brill Pappin

 On 12-Jun-08, at 10:01 AM, cowwoc wrote:


 Brill,

 This is actually an API best practice. Classes fall into two 
 categories:
 ones designed for subclassing, and ones designed to be final. The same
 goes
 for methods. Swing is full of examples of what goes wrong when people
 override methods in classes that haven't been designed with subclassing 
 in
 mind.

 Gili


 Brill Pappin wrote:

 on removing the finals

 The final members are the worst thing I've had to deal with in Wicket
 so far.
 Although I understand that there may be a reason for them, they are
 more a hinderance than anything else and seem to be trying to protect
 users from themselves.

 - Brill Pappin


 On 12-Jun-08, at 1:03 AM, cowwoc wrote:



 Have you considered moving from subclassing to composition in Wicket
 using
 CallableT?

 Currently it is quite common for developers to subclass a component
 in order
 to override isVisible() and other properties. I am proposing that
 instead
 the component classes become final and properties may only be set
 using
 setter methods. The setter methods would take CallableT instead of
 T, so
 for example setVisible(boolean) would become
 setVisible(CallableBoolean)

 The benefit of this approach is that you could introduce static
 factory
 methods to the Wicket components which would make them much easier
 to use in
 their Generic form. You could then introduce various helper classes to
 create CallableT for constant values, such as
 Callable.valueOf(true) would
 return a CallableBoolean that always returns true.
 --
 View this message in context:

 http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 --
 View this message in context:
 http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.3.3 is released
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For 

RE: Making Component easier to Generify

2008-06-12 Thread Zappaterrini, Larry
It is not about assuming anyone is an idiot. It is about preserving
maintainability and allowing an API to evolve without breaking client
code. The best approach is to mark members as final unless there is a
compelling reason not to. Final is a safeguard for APIs to know what
behavior is guaranteed to persist as development and evolution of the
API is carried out. Occasionally a user can come up with a good argument
for removing the final restriction and makes their case, affecting a
change.

It is very easy to create an evolutionary dead end for an API by
allowing everything to be overridden. So either deprecate and start over
or risk breaking client code and have your users hate you for it :)

-Original Message-
From: Brill Pappin [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 12, 2008 11:09 AM
To: users@wicket.apache.org
Subject: Re: Making Component easier to Generify

I understand the reasoning, however I think best practice can be  
debated.
To use your example Swing allows the user to override quite a bit, and  
it doesn't make any (or very few) assumptions on what should and  
should not be done.

I don't like API's that assume I'm an idiot and prevent me from  
manipulating them how I see fit. If I cause a bug that I have to deal  
with, thats *my* problem to resolve.

In my book (and I'm not the only one) excessive use of final is an  
anti-pattern.

- Brill Pappin

On 12-Jun-08, at 10:01 AM, cowwoc wrote:


 Brill,

 This is actually an API best practice. Classes fall into two  
 categories:
 ones designed for subclassing, and ones designed to be final. The  
 same goes
 for methods. Swing is full of examples of what goes wrong when people
 override methods in classes that haven't been designed with  
 subclassing in
 mind.

 Gili


 Brill Pappin wrote:

 on removing the finals

 The final members are the worst thing I've had to deal with in Wicket
 so far.
 Although I understand that there may be a reason for them, they are
 more a hinderance than anything else and seem to be trying to  
 protect
 users from themselves.

 - Brill Pappin


 On 12-Jun-08, at 1:03 AM, cowwoc wrote:



 Have you considered moving from subclassing to composition in Wicket
 using
 CallableT?

 Currently it is quite common for developers to subclass a component
 in order
 to override isVisible() and other properties. I am proposing that
 instead
 the component classes become final and properties may only be set
 using
 setter methods. The setter methods would take CallableT instead of
 T, so
 for example setVisible(boolean) would become
 setVisible(CallableBoolean)

 The benefit of this approach is that you could introduce static
 factory
 methods to the Wicket components which would make them much easier
 to use in
 their Generic form. You could then introduce various helper  
 classes to
 create CallableT for constant values, such as
 Callable.valueOf(true) would
 return a CallableBoolean that always returns true.
 -- 
 View this message in context:

http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-yo
ur-take-on-generics-with-Wicket-tp17589984p17792488.html
 Sent from the Wicket - User mailing list archive at Nabble.com.



-
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 -- 
 View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-yo
ur-take-on-generics-with-Wicket-tp17589984p17800710.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Making Component easier to Generify

2008-06-12 Thread cowwoc


Actually, it's the other way around. Authors make methods final not because
*you* might make a mistake but rather because *they* might. Using final
methods simplifies their design a lot because they don't have to do all the
work you mentioned. Secondly, it leaves the API open to extension (without
breaking backwards compatibility) in a way that would be lost if anyone
could override the methods.

I personally agree with your approach with the following major caveat: if
developers are able to override any method then it must be understood that
any implementation making assumptions not guaranteed by the API
specification is liable to break in future releases. Keep in mind that very
few things ever are guaranteed by the specification, so practically speaking
this means that your code is very likely to break as new releases come out.

To be honest, I personally prefer approach #2 over final methods for public
projects because (in my experience) even open-source projects take forever
to fix bugs or add features that you might need right away. I'm a strong
believer that implementations that make incorrect assumptions deserve to
break in subsequent releases. One final benefit of #1 worth mentioning,
however, is that incorrect assumptions end up in a compile-time error
(roughly speaking) and even smart developers make mistakes every once in a
while. Consider what happens if you override foo() and forget to invoke
super.foo() by mistake. Those kinds of mistakes happen all the time. I'm
toying with the idea that approach #1 makes sense for in-house projects
where you are a co-owner and can make changes very quickly while approach #2
makes sense for public projects when developers can't afford to wait on the
project owner. Put another way, maybe #1 makes sense for mature APIs whereas
#2 makes sense for experimental APIs (used to flesh out the various
use-cases you need to support).

Gili


Brill Pappin wrote:
 
 I understand the reasoning, however I think best practice can be  
 debated.
 To use your example Swing allows the user to override quite a bit, and  
 it doesn't make any (or very few) assumptions on what should and  
 should not be done.
 
 I don't like API's that assume I'm an idiot and prevent me from  
 manipulating them how I see fit. If I cause a bug that I have to deal  
 with, thats *my* problem to resolve.
 
 In my book (and I'm not the only one) excessive use of final is an  
 anti-pattern.
 
 - Brill Pappin
 
 On 12-Jun-08, at 10:01 AM, cowwoc wrote:
 

 Brill,

 This is actually an API best practice. Classes fall into two  
 categories:
 ones designed for subclassing, and ones designed to be final. The  
 same goes
 for methods. Swing is full of examples of what goes wrong when people
 override methods in classes that haven't been designed with  
 subclassing in
 mind.

 Gili


 Brill Pappin wrote:

 on removing the finals

 The final members are the worst thing I've had to deal with in Wicket
 so far.
 Although I understand that there may be a reason for them, they are
 more a hinderance than anything else and seem to be trying to  
 protect
 users from themselves.

 - Brill Pappin


 On 12-Jun-08, at 1:03 AM, cowwoc wrote:



 Have you considered moving from subclassing to composition in Wicket
 using
 CallableT?

 Currently it is quite common for developers to subclass a component
 in order
 to override isVisible() and other properties. I am proposing that
 instead
 the component classes become final and properties may only be set
 using
 setter methods. The setter methods would take CallableT instead of
 T, so
 for example setVisible(boolean) would become
 setVisible(CallableBoolean)

 The benefit of this approach is that you could introduce static
 factory
 methods to the Wicket components which would make them much easier
 to use in
 their Generic form. You could then introduce various helper  
 classes to
 create CallableT for constant values, such as
 Callable.valueOf(true) would
 return a CallableBoolean that always returns true.
 -- 
 View this message in context:
 http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 -- 
 View this message in context:
 http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

 

Re: Making Component easier to Generify

2008-06-12 Thread Brill Pappin
That is the most compelling argument I have ever heard  
(maintainability going forward).
saying i like this by default as most have done is no argument at  
all :)


However I disagree best is final by default... it should be the  
other way around, where things are only marked final if there is a  
good and immediate reason to do so.


Although the debate is long and about as convoluted as the debate of  
hungarian notation was, personal experience suggests that everything  
final causes more problems than it's worth (I consider the Quartz API  
to be poor for that reason also).


However, I am *in no way asking* the developers to reverse the final  
policy. its working, and working fairly well. I think I may have  
started a thread here that is less than productive and unless others  
feel that there needs to be a debate on the issue, I'll let it drop.


- Brill Pappin

On 12-Jun-08, at 11:50 AM, Zappaterrini, Larry wrote:


It is not about assuming anyone is an idiot. It is about preserving
maintainability and allowing an API to evolve without breaking client
code. The best approach is to mark members as final unless there is a
compelling reason not to. Final is a safeguard for APIs to know what
behavior is guaranteed to persist as development and evolution of the
API is carried out. Occasionally a user can come up with a good  
argument

for removing the final restriction and makes their case, affecting a
change.

It is very easy to create an evolutionary dead end for an API by
allowing everything to be overridden. So either deprecate and start  
over

or risk breaking client code and have your users hate you for it :)

-Original Message-
From: Brill Pappin [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 12, 2008 11:09 AM
To: users@wicket.apache.org
Subject: Re: Making Component easier to Generify

I understand the reasoning, however I think best practice can be
debated.
To use your example Swing allows the user to override quite a bit, and
it doesn't make any (or very few) assumptions on what should and
should not be done.

I don't like API's that assume I'm an idiot and prevent me from
manipulating them how I see fit. If I cause a bug that I have to deal
with, thats *my* problem to resolve.

In my book (and I'm not the only one) excessive use of final is an
anti-pattern.

- Brill Pappin

On 12-Jun-08, at 10:01 AM, cowwoc wrote:



Brill,

This is actually an API best practice. Classes fall into two
categories:
ones designed for subclassing, and ones designed to be final. The
same goes
for methods. Swing is full of examples of what goes wrong when people
override methods in classes that haven't been designed with
subclassing in
mind.

Gili


Brill Pappin wrote:


on removing the finals

The final members are the worst thing I've had to deal with in  
Wicket

so far.
Although I understand that there may be a reason for them, they are
more a hinderance than anything else and seem to be trying to
protect
users from themselves.

- Brill Pappin


On 12-Jun-08, at 1:03 AM, cowwoc wrote:




Have you considered moving from subclassing to composition in  
Wicket

using
CallableT?

Currently it is quite common for developers to subclass a component
in order
to override isVisible() and other properties. I am proposing that
instead
the component classes become final and properties may only be set
using
setter methods. The setter methods would take CallableT instead  
of

T, so
for example setVisible(boolean) would become
setVisible(CallableBoolean)

The benefit of this approach is that you could introduce static
factory
methods to the Wicket components which would make them much easier
to use in
their Generic form. You could then introduce various helper
classes to
create CallableT for constant values, such as
Callable.valueOf(true) would
return a CallableBoolean that always returns true.
--
View this message in context:


http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-yo
ur-take-on-generics-with-Wicket-tp17589984p17792488.html

Sent from the Wicket - User mailing list archive at Nabble.com.




-

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
View this message in context:

http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-yo
ur-take-on-generics-with-Wicket-tp17589984p17800710.html

Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Making Component easier to Generify

2008-06-12 Thread Brill Pappin
Very thoughtful and some good points, I don't entirely disagree with  
that.


- Brill

On 12-Jun-08, at 11:54 AM, cowwoc wrote:




[...]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Making Component easier to Generify

2008-06-12 Thread James Carman
If you override a method and your implementation violates the Liskov
Substitution Principle, then it's your fault! :)


On Thu, Jun 12, 2008 at 11:54 AM, cowwoc [EMAIL PROTECTED] wrote:


 Actually, it's the other way around. Authors make methods final not because
 *you* might make a mistake but rather because *they* might. Using final
 methods simplifies their design a lot because they don't have to do all the
 work you mentioned. Secondly, it leaves the API open to extension (without
 breaking backwards compatibility) in a way that would be lost if anyone
 could override the methods.

 I personally agree with your approach with the following major caveat: if
 developers are able to override any method then it must be understood that
 any implementation making assumptions not guaranteed by the API
 specification is liable to break in future releases. Keep in mind that very
 few things ever are guaranteed by the specification, so practically speaking
 this means that your code is very likely to break as new releases come out.

 To be honest, I personally prefer approach #2 over final methods for public
 projects because (in my experience) even open-source projects take forever
 to fix bugs or add features that you might need right away. I'm a strong
 believer that implementations that make incorrect assumptions deserve to
 break in subsequent releases. One final benefit of #1 worth mentioning,
 however, is that incorrect assumptions end up in a compile-time error
 (roughly speaking) and even smart developers make mistakes every once in a
 while. Consider what happens if you override foo() and forget to invoke
 super.foo() by mistake. Those kinds of mistakes happen all the time. I'm
 toying with the idea that approach #1 makes sense for in-house projects
 where you are a co-owner and can make changes very quickly while approach #2
 makes sense for public projects when developers can't afford to wait on the
 project owner. Put another way, maybe #1 makes sense for mature APIs whereas
 #2 makes sense for experimental APIs (used to flesh out the various
 use-cases you need to support).

 Gili


 Brill Pappin wrote:

 I understand the reasoning, however I think best practice can be
 debated.
 To use your example Swing allows the user to override quite a bit, and
 it doesn't make any (or very few) assumptions on what should and
 should not be done.

 I don't like API's that assume I'm an idiot and prevent me from
 manipulating them how I see fit. If I cause a bug that I have to deal
 with, thats *my* problem to resolve.

 In my book (and I'm not the only one) excessive use of final is an
 anti-pattern.

 - Brill Pappin

 On 12-Jun-08, at 10:01 AM, cowwoc wrote:


 Brill,

 This is actually an API best practice. Classes fall into two
 categories:
 ones designed for subclassing, and ones designed to be final. The
 same goes
 for methods. Swing is full of examples of what goes wrong when people
 override methods in classes that haven't been designed with
 subclassing in
 mind.

 Gili


 Brill Pappin wrote:

 on removing the finals

 The final members are the worst thing I've had to deal with in Wicket
 so far.
 Although I understand that there may be a reason for them, they are
 more a hinderance than anything else and seem to be trying to
 protect
 users from themselves.

 - Brill Pappin


 On 12-Jun-08, at 1:03 AM, cowwoc wrote:



 Have you considered moving from subclassing to composition in Wicket
 using
 CallableT?

 Currently it is quite common for developers to subclass a component
 in order
 to override isVisible() and other properties. I am proposing that
 instead
 the component classes become final and properties may only be set
 using
 setter methods. The setter methods would take CallableT instead of
 T, so
 for example setVisible(boolean) would become
 setVisible(CallableBoolean)

 The benefit of this approach is that you could introduce static
 factory
 methods to the Wicket components which would make them much easier
 to use in
 their Generic form. You could then introduce various helper
 classes to
 create CallableT for constant values, such as
 Callable.valueOf(true) would
 return a CallableBoolean that always returns true.
 --
 View this message in context:
 http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 --
 View this message in context:
 http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html
 Sent from the Wicket - User mailing list archive 

RE: Modifying QuickStart to serve static content in embedded Jetty (was: RE: Tomcat 5.5.9 isn't running Quickstart)

2008-06-12 Thread Frank Silbermann
Well, I guess the only thing to do is try and minimally modify the
QuickStart project with code that exhibits the problem and let others
try it.  Should I submit it as a JIRA issue (to be closed when it is
determined what I'm doing wrong), or should I attach the .zip to a
mailing list message?  Should I mvn clean it before zipping it to save
space?

-Original Message-
From: Martijn Dashorst [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 12, 2008 9:11 AM
To: users@wicket.apache.org
Subject: Re: Modifying QuickStart to serve static content in embedded
Jetty (was: RE: Tomcat 5.5.9 isn't running Quickstart)

No, because the JSP servlet is needed to compile JSPs into servlet code.
An unmodified configuration generated by the Wicket quickstart on our
website serves static images perfectly well. You really are doing
something funky.

Martijn

On Thu, Jun 12, 2008 at 4:07 PM, Frank Silbermann
[EMAIL PROTECTED] wrote:
 Yes, the QuickStart itself works.  As for your ability to serve 
 images, it might depend whether these are images stored with the .html

 and .java files for Wicket to pick up, versus images that are stored 
 as static objects.  I googled the INFO - log warning  - NO JSP 
 Support for /, did not find org.apache.jasper.servlet.JspServlet

 and found http://code.google.com/p/run-jetty-run/wiki/GettingStarted
 about running Wicket projects with Jetty in Eclipse.  It contains the 
 following comments:

 Comment by angelo.mariano, Jan 02, 2008
   When I try to launch it, I get the following error: 2008-01-02
 10:11:55.191::INFO: Logging to STDERR
   via org.mortbay.log.StdErrLog? 2008-01-02 10:11:55.300::INFO:
 jetty-6.1.6 2008-01-02
   10:11:55.441::INFO: NO JSP Support for /, did not find 
 org.apache.jasper.servlet.JspServlet?
   2008-01-02 10:11:55.659:/:INFO: default: init 2008-01-02
 10:11:55.659:/:INFO: jsp: init 2008-01-02
   10:11:55.691::INFO: Started [EMAIL PROTECTED]:8080

   and then I am not able to compile jsp. Do you know how to solve this

 problem? Thank you

 Comment by eelco.hillenius, Jan 02, 2008
   Ah, I probably have to include the appropriate libs to turn JSP 
 support on. Could you please file a
   ticket? I'll get to it shortly.



 Eelco, could that discussion have anything to do with my problem?

 -Original Message-
 From: Martijn Dashorst [mailto:[EMAIL PROTECTED]
 Sent: Thursday, June 12, 2008 1:23 AM
 To: users@wicket.apache.org
 Subject: Re: Tomcat 5.5.9 isn't running Quickstart

 The quickstart works for me without modifications. It serves images, 
 etc. out of the box, every time.

 Martijn

 On Thu, Jun 12, 2008 at 12:54 AM, Frank Silbermann 
 [EMAIL PROTECTED] wrote:
 Searching for some clue as to why my modification of the QuickStart 
 application is serving images when run in Tomcat but not when running

 in embedded Jetty via Eclipse, I found:

 http://osdir.com/ml/java.jetty.support/2003-03/msg00045.html -- 
 titled
 Re: Re: jetty can't find images: msg#00045

 It says, You need the webdefaults file because it sets up the 
 Default

 servlet which is what serves static resources like images.  You can 
 also manually add the Default servlet if you want to avoid a 
 webdefaults.xml file.

 I think this is a clue.  Looking at the console log when running 
 Jetty

 in Eclipse I see:

 INFO  - log- NO JSP Support for /, did not
 find
 org.apache.jasper.servlet.JspServlet

 So what do I need to do to make it set up the Default servlet?  Is 
 there a line I need to insert into Start.java to make it read the 
 webdefaults.xml file?  I don't even have a webdefaults.xml file -- 
 unless it's buried somewhere inside one of the Jetty jars.

 Here's the complete console log when debugging Start.java to bring up

 Jetty (as demonstrated in 
 http://herebebeasties.com/2007-10-07/wicket-quickstart/).

 INFO  - log- Logging to
 org.slf4j.impl.Log4jLoggerAdapter(org.mortbay.log) via 
 org.mortbay.log.Slf4jLog
 STARTING EMBEDDED JETTY SERVER, PRESS ANY KEY TO STOP
 INFO  - log- jetty-6.1.4
 INFO  - log- NO JSP Support for /, did not
 find
 org.apache.jasper.servlet.JspServlet
 INFO  - log- No Transaction manager found -
if
 your webapp requires one, please configure one.
 INFO  - Application- [TestApplication] init: Wicket
 core
 library initializer
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IBehaviorListener, method=public 
 abstract void
 org.apache.wicket.behavior.IBehaviorListener.onRequest()]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IBehaviorListener, method=public 
 abstract void
 org.apache.wicket.behavior.IBehaviorListener.onRequest()]
 INFO  - RequestListenerInterface   - registered listener interface
 [RequestListenerInterface name=IFormSubmitListener, method=public 
 abstract void 
 

Re: How to add a TextField in a Dynamically created DefaultDataTable

2008-06-12 Thread galbelli

Not sure I understand how to accomplish this. Even if I wrap it in a panel
won't it be looking for markup? 

My current markup for the dynamic table is as follows: 

html xmlns:wicket=http://wicket.apache.org/;

head
titlePrices by Source/title
/head
body
wicket:panel
br
form wicket:id=form
Portfolio: select wicket:id=portfolioSelect/select

table class=dataview cellspacing=0 wicket:id=table
/table
 
/form 
/wicket:panel
/body
/html

And the code


ListIColumn columns = new ArrayListIColumn();

columns.add(new PropertyColumn(new Model(CUSIP), cusip,
cusip));
columns.add(new PropertyColumn(new Model(Description),
description, description));

PropertyColumn aPropertyColumn = new PropertyColumn(new
Model(Override), overridePrice, overridePrice)
{
public void populateItem(Item item, String componentId, IModel
model)
{
TextField aTextField = new TextField(componentId);
item.add(aTextField );
}  

};
columns.add(aPropertyColumn);

   DefaultDataTable aDefaultDataTable = new DefaultDataTable(table,
columns, portfolioProvider, 8);








igor.vaynberg wrote:
 
 wrap the textfield in a fragment or a panel
 
 -igor
 
 On Wed, Jun 11, 2008 at 3:39 PM, galbelli [EMAIL PROTECTED]
 wrote:

 I am creating a DefaultDataTable dynamically as I only know the number of
 columns at runtime. All is working nicely but I now need to have one of
 the
 columns contain a TextField and not a Label. I am receiving the following
 error:

 WicketMessage: Component cell must be applied to a tag of type 'input',
 not
 '' (line 0, column 0)

 How can I control the markup so I may change the HTML from span to input?
 --
 View this message in context:
 http://www.nabble.com/How-to-add-a-TextField-in-a-Dynamically-created-DefaultDataTable-tp17788822p17788822.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/How-to-add-a-TextField-in-a-Dynamically-created-DefaultDataTable-tp17788822p17804562.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Making Component easier to Generify

2008-06-12 Thread Eelco Hillenius
 However, I am *in no way asking* the developers to reverse the final
 policy.

We actually relaxed that way more as we felt more confident about
Wicket's API and as motivated requests came in. Personally, I think
using final or not should be a deliberate choice (not automatic). If
you never use it, you can arrive to that evolutionary dead-end pretty
quickly (or indeed will have to break clients all the time), but if
you over-use it, your framework will lack flexibility. Anyway, IF you
stumble upon a final in a place where you'd like to see it go, you can
always send a motivated request for that. We've typically been willing
to remove finals when a good motivation was given.

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: How to add a TextField in a Dynamically created DefaultDataTable

2008-06-12 Thread James Carman
The markup for the datatable uses div (or maybe span) for each
cell's item.  So, you need to give it something that it can put on a
span.  That would be a panel or fragment (as suggested).  Did you see
my earlier post about a FragmentColumn class?  It might be useful in
your case.

On Thu, Jun 12, 2008 at 12:50 PM, galbelli [EMAIL PROTECTED] wrote:

 Not sure I understand how to accomplish this. Even if I wrap it in a panel
 won't it be looking for markup?

 My current markup for the dynamic table is as follows:

 html xmlns:wicket=http://wicket.apache.org/;

head
titlePrices by Source/title
/head
body
wicket:panel
br
form wicket:id=form
Portfolio: select 
 wicket:id=portfolioSelect/select

table class=dataview cellspacing=0 wicket:id=table
/table

/form
/wicket:panel
/body
 /html

 And the code


ListIColumn columns = new ArrayListIColumn();

columns.add(new PropertyColumn(new Model(CUSIP), cusip,
 cusip));
columns.add(new PropertyColumn(new Model(Description),
 description, description));

PropertyColumn aPropertyColumn = new PropertyColumn(new
 Model(Override), overridePrice, overridePrice)
{
public void populateItem(Item item, String componentId, IModel
 model)
{
TextField aTextField = new TextField(componentId);
item.add(aTextField );
}

};
columns.add(aPropertyColumn);

   DefaultDataTable aDefaultDataTable = new DefaultDataTable(table,
 columns, portfolioProvider, 8);








 igor.vaynberg wrote:

 wrap the textfield in a fragment or a panel

 -igor

 On Wed, Jun 11, 2008 at 3:39 PM, galbelli [EMAIL PROTECTED]
 wrote:

 I am creating a DefaultDataTable dynamically as I only know the number of
 columns at runtime. All is working nicely but I now need to have one of
 the
 columns contain a TextField and not a Label. I am receiving the following
 error:

 WicketMessage: Component cell must be applied to a tag of type 'input',
 not
 '' (line 0, column 0)

 How can I control the markup so I may change the HTML from span to input?
 --
 View this message in context:
 http://www.nabble.com/How-to-add-a-TextField-in-a-Dynamically-created-DefaultDataTable-tp17788822p17788822.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 --
 View this message in context: 
 http://www.nabble.com/How-to-add-a-TextField-in-a-Dynamically-created-DefaultDataTable-tp17788822p17804562.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



styling option tag in dropdownlist

2008-06-12 Thread Mathias P.W Nilsson

Hi!

How can I style a certain option in a select list? I want to provide
diffrent colors for main categories in a drop down list. 
-- 
View this message in context: 
http://www.nabble.com/styling-option-tag-in-dropdownlist-tp17804741p17804741.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Modifying QuickStart to serve static content in embedded Jetty (was: RE: Tomcat 5.5.9 isn't running Quickstart)

2008-06-12 Thread Gwyn Evans
JIRA issue  mvn clean, I'd say...
/Gwyn

On Thu, Jun 12, 2008 at 5:28 PM, Frank Silbermann 
[EMAIL PROTECTED] wrote:

 Well, I guess the only thing to do is try and minimally modify the
 QuickStart project with code that exhibits the problem and let others
 try it.  Should I submit it as a JIRA issue (to be closed when it is
 determined what I'm doing wrong), or should I attach the .zip to a
 mailing list message?  Should I mvn clean it before zipping it to save
 space?

 -Original Message-
 From: Martijn Dashorst [mailto:[EMAIL PROTECTED]
 Sent: Thursday, June 12, 2008 9:11 AM
 To: users@wicket.apache.org
 Subject: Re: Modifying QuickStart to serve static content in embedded
 Jetty (was: RE: Tomcat 5.5.9 isn't running Quickstart)

 No, because the JSP servlet is needed to compile JSPs into servlet code.
 An unmodified configuration generated by the Wicket quickstart on our
 website serves static images perfectly well. You really are doing
 something funky.

 Martijn

 On Thu, Jun 12, 2008 at 4:07 PM, Frank Silbermann
 [EMAIL PROTECTED] wrote:
  Yes, the QuickStart itself works.  As for your ability to serve
  images, it might depend whether these are images stored with the .html

  and .java files for Wicket to pick up, versus images that are stored
  as static objects.  I googled the INFO - log warning  - NO JSP
  Support for /, did not find org.apache.jasper.servlet.JspServlet
 
  and found http://code.google.com/p/run-jetty-run/wiki/GettingStarted
  about running Wicket projects with Jetty in Eclipse.  It contains the
  following comments:
 
  Comment by angelo.mariano, Jan 02, 2008
When I try to launch it, I get the following error: 2008-01-02
  10:11:55.191::INFO: Logging to STDERR
via org.mortbay.log.StdErrLog? 2008-01-02 10:11:55.300::INFO:
  jetty-6.1.6 2008-01-02
10:11:55.441::INFO: NO JSP Support for /, did not find
  org.apache.jasper.servlet.JspServlet?
2008-01-02 10:11:55.659:/:INFO: default: init 2008-01-02
  10:11:55.659:/:INFO: jsp: init 2008-01-02
10:11:55.691::INFO: Started [EMAIL PROTECTED]:8080
 
and then I am not able to compile jsp. Do you know how to solve this

  problem? Thank you
 
  Comment by eelco.hillenius, Jan 02, 2008
Ah, I probably have to include the appropriate libs to turn JSP
  support on. Could you please file a
ticket? I'll get to it shortly.
 
 
 
  Eelco, could that discussion have anything to do with my problem?
 
  -Original Message-
  From: Martijn Dashorst [mailto:[EMAIL PROTECTED]
  Sent: Thursday, June 12, 2008 1:23 AM
  To: users@wicket.apache.org
  Subject: Re: Tomcat 5.5.9 isn't running Quickstart
 
  The quickstart works for me without modifications. It serves images,
  etc. out of the box, every time.
 
  Martijn
 
  On Thu, Jun 12, 2008 at 12:54 AM, Frank Silbermann
  [EMAIL PROTECTED] wrote:
  Searching for some clue as to why my modification of the QuickStart
  application is serving images when run in Tomcat but not when running

  in embedded Jetty via Eclipse, I found:
 
  http://osdir.com/ml/java.jetty.support/2003-03/msg00045.html --
  titled
  Re: Re: jetty can't find images: msg#00045
 
  It says, You need the webdefaults file because it sets up the
  Default
 
  servlet which is what serves static resources like images.  You can
  also manually add the Default servlet if you want to avoid a
  webdefaults.xml file.
 
  I think this is a clue.  Looking at the console log when running
  Jetty
 
  in Eclipse I see:
 
  INFO  - log- NO JSP Support for /, did not
  find
  org.apache.jasper.servlet.JspServlet
 
  So what do I need to do to make it set up the Default servlet?  Is
  there a line I need to insert into Start.java to make it read the
  webdefaults.xml file?  I don't even have a webdefaults.xml file --
  unless it's buried somewhere inside one of the Jetty jars.
 
  Here's the complete console log when debugging Start.java to bring up

  Jetty (as demonstrated in
  http://herebebeasties.com/2007-10-07/wicket-quickstart/).
 
  INFO  - log- Logging to
  org.slf4j.impl.Log4jLoggerAdapter(org.mortbay.log) via
  org.mortbay.log.Slf4jLog
  STARTING EMBEDDED JETTY SERVER, PRESS ANY KEY TO STOP
  INFO  - log- jetty-6.1.4
  INFO  - log- NO JSP Support for /, did not
  find
  org.apache.jasper.servlet.JspServlet
  INFO  - log- No Transaction manager found -
 if
  your webapp requires one, please configure one.
  INFO  - Application- [TestApplication] init: Wicket
  core
  library initializer
  INFO  - RequestListenerInterface   - registered listener interface
  [RequestListenerInterface name=IBehaviorListener, method=public
  abstract void
  org.apache.wicket.behavior.IBehaviorListener.onRequest()]
  INFO  - RequestListenerInterface   - registered listener interface
  [RequestListenerInterface name=IBehaviorListener, method=public
  abstract void
  

RE: How to get context path

2008-06-12 Thread Hoover, William
Done: https://issues.apache.org/jira/browse/WICKET-1700 

-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 12, 2008 11:32 AM
To: users@wicket.apache.org
Subject: Re: How to get context path

jira is your friend

-igor

On Thu, Jun 12, 2008 at 4:46 AM, Hoover, William [EMAIL PROTECTED]
wrote:
 It would be better if ContextImage was a behavior rather than an 
 actual component. For instance, if you have an html input of 
 type=image (or a link for that matter) you can still utilize the 
 behavior whereas a component you cannot ;o)

 -Original Message-
 From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, June 11, 2008 3:29 PM
 To: users@wicket.apache.org
 Subject: Re: How to get context path

 see ContextImage

 -igor

 On Wed, Jun 11, 2008 at 12:10 PM, Patel, Sanjay [EMAIL PROTECTED]
 wrote:
 Hi,

 my images in the application are in webapp/image folder. How to get 
 Context Path in wicket so I can prepend this path to display the
 image.
 I am looking for something like this.

 getContextPath() + image/icon.gif;

 Please suggest how to do that.

 Thanks,
 Sanjay.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Making Component easier to Generify

2008-06-12 Thread Igor Vaynberg
On Thu, Jun 12, 2008 at 9:00 AM, Brill Pappin [EMAIL PROTECTED] wrote:
 That is the most compelling argument I have ever heard (maintainability
 going forward).
 saying i like this by default as most have done is no argument at all :)

i suppose whenever you write any method that is consumed by hundreds
of other developers you put a lot of thought and analysis into all the
usecases for which those hundreds of developers will override this
method. you think of all the corner cases, and all the things that can
go wrong. you do all this by default right? no, you dont? then it is
much better to make the method final by default, and once you have
done all of the above and made sure that it will all work then remove
the final.

-igor


 However I disagree best is final by default... it should be the other way
 around, where things are only marked final if there is a good and immediate
 reason to do so.

 Although the debate is long and about as convoluted as the debate of
 hungarian notation was, personal experience suggests that everything final
 causes more problems than it's worth (I consider the Quartz API to be poor
 for that reason also).

 However, I am *in no way asking* the developers to reverse the final
 policy. its working, and working fairly well. I think I may have started a
 thread here that is less than productive and unless others feel that there
 needs to be a debate on the issue, I'll let it drop.

 - Brill Pappin

 On 12-Jun-08, at 11:50 AM, Zappaterrini, Larry wrote:

 It is not about assuming anyone is an idiot. It is about preserving
 maintainability and allowing an API to evolve without breaking client
 code. The best approach is to mark members as final unless there is a
 compelling reason not to. Final is a safeguard for APIs to know what
 behavior is guaranteed to persist as development and evolution of the
 API is carried out. Occasionally a user can come up with a good argument
 for removing the final restriction and makes their case, affecting a
 change.

 It is very easy to create an evolutionary dead end for an API by
 allowing everything to be overridden. So either deprecate and start over
 or risk breaking client code and have your users hate you for it :)

 -Original Message-
 From: Brill Pappin [mailto:[EMAIL PROTECTED]
 Sent: Thursday, June 12, 2008 11:09 AM
 To: users@wicket.apache.org
 Subject: Re: Making Component easier to Generify

 I understand the reasoning, however I think best practice can be
 debated.
 To use your example Swing allows the user to override quite a bit, and
 it doesn't make any (or very few) assumptions on what should and
 should not be done.

 I don't like API's that assume I'm an idiot and prevent me from
 manipulating them how I see fit. If I cause a bug that I have to deal
 with, thats *my* problem to resolve.

 In my book (and I'm not the only one) excessive use of final is an
 anti-pattern.

 - Brill Pappin

 On 12-Jun-08, at 10:01 AM, cowwoc wrote:


 Brill,

 This is actually an API best practice. Classes fall into two
 categories:
 ones designed for subclassing, and ones designed to be final. The
 same goes
 for methods. Swing is full of examples of what goes wrong when people
 override methods in classes that haven't been designed with
 subclassing in
 mind.

 Gili


 Brill Pappin wrote:

 on removing the finals

 The final members are the worst thing I've had to deal with in Wicket
 so far.
 Although I understand that there may be a reason for them, they are
 more a hinderance than anything else and seem to be trying to
 protect
 users from themselves.

 - Brill Pappin


 On 12-Jun-08, at 1:03 AM, cowwoc wrote:



 Have you considered moving from subclassing to composition in Wicket
 using
 CallableT?

 Currently it is quite common for developers to subclass a component
 in order
 to override isVisible() and other properties. I am proposing that
 instead
 the component classes become final and properties may only be set
 using
 setter methods. The setter methods would take CallableT instead of
 T, so
 for example setVisible(boolean) would become
 setVisible(CallableBoolean)

 The benefit of this approach is that you could introduce static
 factory
 methods to the Wicket components which would make them much easier
 to use in
 their Generic form. You could then introduce various helper
 classes to
 create CallableT for constant values, such as
 Callable.valueOf(true) would
 return a CallableBoolean that always returns true.
 --
 View this message in context:

 http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-yo
 ur-take-on-generics-with-Wicket-tp17589984p17792488.html

 Sent from the Wicket - User mailing list archive at Nabble.com.



 -

 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL 

Re: styling option tag in dropdownlist

2008-06-12 Thread Igor Vaynberg
use Select/SelectOption components rather then dropdownchoice

-igor

On Thu, Jun 12, 2008 at 9:57 AM, Mathias P.W Nilsson
[EMAIL PROTECTED] wrote:

 Hi!

 How can I style a certain option in a select list? I want to provide
 diffrent colors for main categories in a drop down list.
 --
 View this message in context: 
 http://www.nabble.com/styling-option-tag-in-dropdownlist-tp17804741p17804741.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: How to add a TextField in a Dynamically created DefaultDataTable

2008-06-12 Thread galbelli

Thanks, the Fragment example did help in that I have the table rendering
properly. When I attempt to submit the form I get the following error: 

WicketMessage: Method onFormSubmitted of interface
org.apache.wicket.markup.html.form.IFormSubmitListener targeted at component
[MarkupContainer [Component id = form, page =
com.apollo.pricing.ui.HomePage, path =
0:tabs:panel:form.PricingBySourcePanel$1, isVisible = true, isVersioned =
true]] threw an exception

Root cause:

java.lang.IllegalStateException: Attempt to set model object on null model
of component: tabs:panel:form:table:rows:4:cells:11:cell:edit
at org.apache.wicket.Component.setModelObject(Component.java:2510)
at
org.apache.wicket.markup.html.form.FormComponent.updateModel(FormComponent.java:1002)
at org.apache.wicket.markup.html.form.Form$14.validate(Form.java:1642)
at
org.apache.wicket.markup.html.form.Form$ValidationVisitor.formComponent(Form.java:160)
at
org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper(FormComponent.java:403)

Any ideas?





jwcarman wrote:
 
 The markup for the datatable uses div (or maybe span) for each
 cell's item.  So, you need to give it something that it can put on a
 span.  That would be a panel or fragment (as suggested).  Did you see
 my earlier post about a FragmentColumn class?  It might be useful in
 your case.
 
 On Thu, Jun 12, 2008 at 12:50 PM, galbelli [EMAIL PROTECTED]
 wrote:

 Not sure I understand how to accomplish this. Even if I wrap it in a
 panel
 won't it be looking for markup?

 My current markup for the dynamic table is as follows:

 html xmlns:wicket=http://wicket.apache.org/;

head
titlePrices by Source/title
/head
body
wicket:panel
br
form wicket:id=form
Portfolio: select
 wicket:id=portfolioSelect/select

table class=dataview cellspacing=0
 wicket:id=table
/table

/form
/wicket:panel
/body
 /html

 And the code


ListIColumn columns = new ArrayListIColumn();

columns.add(new PropertyColumn(new Model(CUSIP), cusip,
 cusip));
columns.add(new PropertyColumn(new Model(Description),
 description, description));

PropertyColumn aPropertyColumn = new PropertyColumn(new
 Model(Override), overridePrice, overridePrice)
{
public void populateItem(Item item, String componentId, IModel
 model)
{
TextField aTextField = new TextField(componentId);
item.add(aTextField );
}

};
columns.add(aPropertyColumn);

   DefaultDataTable aDefaultDataTable = new DefaultDataTable(table,
 columns, portfolioProvider, 8);








 igor.vaynberg wrote:

 wrap the textfield in a fragment or a panel

 -igor

 On Wed, Jun 11, 2008 at 3:39 PM, galbelli [EMAIL PROTECTED]
 wrote:

 I am creating a DefaultDataTable dynamically as I only know the number
 of
 columns at runtime. All is working nicely but I now need to have one of
 the
 columns contain a TextField and not a Label. I am receiving the
 following
 error:

 WicketMessage: Component cell must be applied to a tag of type 'input',
 not
 '' (line 0, column 0)

 How can I control the markup so I may change the HTML from span to
 input?
 --
 View this message in context:
 http://www.nabble.com/How-to-add-a-TextField-in-a-Dynamically-created-DefaultDataTable-tp17788822p17788822.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 --
 View this message in context:
 http://www.nabble.com/How-to-add-a-TextField-in-a-Dynamically-created-DefaultDataTable-tp17788822p17804562.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/How-to-add-a-TextField-in-a-Dynamically-created-DefaultDataTable-tp17788822p17806187.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: How to add a TextField in a Dynamically created DefaultDataTable

2008-06-12 Thread Igor Vaynberg
your textfield doesnt have a model

-igor

On Thu, Jun 12, 2008 at 11:06 AM, galbelli [EMAIL PROTECTED] wrote:

 Thanks, the Fragment example did help in that I have the table rendering
 properly. When I attempt to submit the form I get the following error:

 WicketMessage: Method onFormSubmitted of interface
 org.apache.wicket.markup.html.form.IFormSubmitListener targeted at component
 [MarkupContainer [Component id = form, page =
 com.apollo.pricing.ui.HomePage, path =
 0:tabs:panel:form.PricingBySourcePanel$1, isVisible = true, isVersioned =
 true]] threw an exception

 Root cause:

 java.lang.IllegalStateException: Attempt to set model object on null model
 of component: tabs:panel:form:table:rows:4:cells:11:cell:edit
 at org.apache.wicket.Component.setModelObject(Component.java:2510)
 at
 org.apache.wicket.markup.html.form.FormComponent.updateModel(FormComponent.java:1002)
 at org.apache.wicket.markup.html.form.Form$14.validate(Form.java:1642)
 at
 org.apache.wicket.markup.html.form.Form$ValidationVisitor.formComponent(Form.java:160)
 at
 org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrderHelper(FormComponent.java:403)

 Any ideas?





 jwcarman wrote:

 The markup for the datatable uses div (or maybe span) for each
 cell's item.  So, you need to give it something that it can put on a
 span.  That would be a panel or fragment (as suggested).  Did you see
 my earlier post about a FragmentColumn class?  It might be useful in
 your case.

 On Thu, Jun 12, 2008 at 12:50 PM, galbelli [EMAIL PROTECTED]
 wrote:

 Not sure I understand how to accomplish this. Even if I wrap it in a
 panel
 won't it be looking for markup?

 My current markup for the dynamic table is as follows:

 html xmlns:wicket=http://wicket.apache.org/;

head
titlePrices by Source/title
/head
body
wicket:panel
br
form wicket:id=form
Portfolio: select
 wicket:id=portfolioSelect/select

table class=dataview cellspacing=0
 wicket:id=table
/table

/form
/wicket:panel
/body
 /html

 And the code


ListIColumn columns = new ArrayListIColumn();

columns.add(new PropertyColumn(new Model(CUSIP), cusip,
 cusip));
columns.add(new PropertyColumn(new Model(Description),
 description, description));

PropertyColumn aPropertyColumn = new PropertyColumn(new
 Model(Override), overridePrice, overridePrice)
{
public void populateItem(Item item, String componentId, IModel
 model)
{
TextField aTextField = new TextField(componentId);
item.add(aTextField );
}

};
columns.add(aPropertyColumn);

   DefaultDataTable aDefaultDataTable = new DefaultDataTable(table,
 columns, portfolioProvider, 8);








 igor.vaynberg wrote:

 wrap the textfield in a fragment or a panel

 -igor

 On Wed, Jun 11, 2008 at 3:39 PM, galbelli [EMAIL PROTECTED]
 wrote:

 I am creating a DefaultDataTable dynamically as I only know the number
 of
 columns at runtime. All is working nicely but I now need to have one of
 the
 columns contain a TextField and not a Label. I am receiving the
 following
 error:

 WicketMessage: Component cell must be applied to a tag of type 'input',
 not
 '' (line 0, column 0)

 How can I control the markup so I may change the HTML from span to
 input?
 --
 View this message in context:
 http://www.nabble.com/How-to-add-a-TextField-in-a-Dynamically-created-DefaultDataTable-tp17788822p17788822.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 --
 View this message in context:
 http://www.nabble.com/How-to-add-a-TextField-in-a-Dynamically-created-DefaultDataTable-tp17788822p17804562.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 --
 View this message in context: 
 http://www.nabble.com/How-to-add-a-TextField-in-a-Dynamically-created-DefaultDataTable-tp17788822p17806187.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




Re: AjaxSubmitLink refreshing problem

2008-06-12 Thread Timo Rantalaiho
On Thu, 12 Jun 2008, alesp wrote:
 Panel
|
 -- Form
 |
  -- WebMarkupContainer (setOutputMarkupId(true))
 ||
 |-- ListView (with a
 LoadableDetachableModel)
 |  |
 |   -- { populateItem {
 AjaxSubmitLink (to delete an element. Updates the WebMarkupContainer) } }
  -- AutoCompleteTextField
 |
  -- AjaxSubmitLink (to add an element)
 
 The problem is that the add link (the AjaxSubmitLink at the bottom of the
 diagram) is working fine, but the delete is not, and the code is pretty

What a cool diagram :) Have you called setReuseItems(true)
for the ListView by any change? (If you have, I understand
you should call removeAll to get the model changes to show:
  http://www.nabble.com/Re%3A-ListViews-in-a-form-question-p17786806.html 
) Have you checked that the stuff that the
LoadableDetachableModel returns for the ListView is correct
after the delete? Have you checked that the ListView reads
the contents from the model on rendering for the ajax update?

Putting a Thread.dumpStack() in the load implementation of
your LoadableDetachableModel will probably show easily when
the ListView refreshes its contents.

Best wishes,
Timo

-- 
Timo Rantalaiho   
Reaktor Innovations OyURL: http://www.ri.fi/ 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Making Component easier to Generify

2008-06-12 Thread Zappaterrini, Larry
Could I dig this one back up then ;)

http://www.nabble.com/Creating-Custom-Form-Components-td16159841.html#a1
6159841

Basically my request was to remove final from
FormComponent.add(IValidator...) to aid in creating custom form
component subclasses based on precedent with Component.add(IBehavior...)

-Original Message-
From: Eelco Hillenius [mailto:[EMAIL PROTECTED] 
Sent: Thursday, June 12, 2008 12:51 PM
To: users@wicket.apache.org
Subject: Re: Making Component easier to Generify

 However, I am *in no way asking* the developers to reverse the final
 policy.

We actually relaxed that way more as we felt more confident about
Wicket's API and as motivated requests came in. Personally, I think
using final or not should be a deliberate choice (not automatic). If
you never use it, you can arrive to that evolutionary dead-end pretty
quickly (or indeed will have to break clients all the time), but if
you over-use it, your framework will lack flexibility. Anyway, IF you
stumble upon a final in a place where you'd like to see it go, you can
always send a motivated request for that. We've typically been willing
to remove finals when a good motivation was given.

Eelco

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

__

The information contained in this message is proprietary and/or confidential. 
If you are not the 
intended recipient, please: (i) delete the message and all copies; (ii) do not 
disclose, 
distribute or use the message in any manner; and (iii) notify the sender 
immediately. In addition, 
please be aware that any message addressed to our domain is subject to 
archiving and review by 
persons other than the intended recipient. Thank you.
_

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Making Component easier to Generify

2008-06-12 Thread Matthijs Wensveen
Some useful design patterns like Decorator don't work with final 
methods. Wicket components sometimes have overridable factory methods 
for child components. The decorator pattern could be very useful here, 
because you'd be able to decorate the original component with some extra 
functionality (Link.onClick for example). Unfortunately this doesn't 
work because some methods are final.


Matthijs

Igor Vaynberg wrote:

i mean generally, for methods, fields, and func args :) most of this
stuff can stay final, but people dont bother doing it because its
extra typing.

-igor

On Thu, Jun 12, 2008 at 8:38 AM, James Carman
[EMAIL PROTECTED] wrote:
  

You mean like C++?

On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:


indeed. i wouldnt mind if final was the default in java :)

-igor

On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
  

Without the use of final wicket would not have made it this far.

Martijn

On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin [EMAIL PROTECTED] wrote:


I understand the reasoning, however I think best practice can be debated.
To use your example Swing allows the user to override quite a bit, and it
doesn't make any (or very few) assumptions on what should and should not be
done.

I don't like API's that assume I'm an idiot and prevent me from manipulating
them how I see fit. If I cause a bug that I have to deal with, thats *my*
problem to resolve.

In my book (and I'm not the only one) excessive use of final is an
anti-pattern.

- Brill Pappin

On 12-Jun-08, at 10:01 AM, cowwoc wrote:

  

Brill,

This is actually an API best practice. Classes fall into two categories:
ones designed for subclassing, and ones designed to be final. The same
goes
for methods. Swing is full of examples of what goes wrong when people
override methods in classes that haven't been designed with subclassing in
mind.

Gili


Brill Pappin wrote:


on removing the finals

The final members are the worst thing I've had to deal with in Wicket
so far.
Although I understand that there may be a reason for them, they are
more a hinderance than anything else and seem to be trying to protect
users from themselves.

- Brill Pappin


On 12-Jun-08, at 1:03 AM, cowwoc wrote:

  

Have you considered moving from subclassing to composition in Wicket
using
CallableT?

Currently it is quite common for developers to subclass a component
in order
to override isVisible() and other properties. I am proposing that
instead
the component classes become final and properties may only be set
using
setter methods. The setter methods would take CallableT instead of
T, so
for example setVisible(boolean) would become
setVisible(CallableBoolean)

The benefit of this approach is that you could introduce static
factory
methods to the Wicket components which would make them much easier
to use in
their Generic form. You could then introduce various helper classes to
create CallableT for constant values, such as
Callable.valueOf(true) would
return a CallableBoolean that always returns true.
--
View this message in context:

http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



  

--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  


--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






ValueMap, NullSafeKeyComparator and WicketNotSerializableException

2008-06-12 Thread Matthew Hanlon
I'm getting a WicketNotSerializableException on a couple of my pages.  The
field that seems to be not serializable appears to be a Wicket class,
org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator.  Any
suggestions?  I saw a posting on the list earlier today that I though may
have something to do with it, but I cannot find the reference now.

Here's the stacktrace for the exception I'm getting:

ERROR Objects:1114 - Error serializing object class
com.mycompany.MyPage[object=[Page class = com.mycompany.MyPage, id = 3,
version = 0, ajax = 0]]
org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException:
Unable to serialize class:
org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator
Field hierarchy is:
  3 [class=com.mycompany.MyPage, path=3]
java.lang.Object org.apache.wicket.Component.data
[class=[Ljava.lang.Object;]
  private org.apache.wicket.spring.ISpringContextLocator
org.apache.wicket.spring.SpringBeanLocator.springContextLocator[1]
[class=[Lorg.apache.wicket.MetaDataEntry;]
private org.apache.wicket.spring.ISpringContextLocator
org.apache.wicket.spring.SpringBeanLocator.springContextLocator[1][0]
[class=org.apache.wicket.MetaDataEntry]
  java.lang.Object org.apache.wicket.MetaDataEntry.object
[class=org.apache.wicket.PageParameters]
private java.util.Comparator java.util.TreeMap.comparator
[class=org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator] -
field that is not serializable
at
org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:349)
at
org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618)
at
org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541)
at
org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618)
at
org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541)
at
org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:395)
at
org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:395)
at
org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618)
at
org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541)
at
org.apache.wicket.util.io.SerializableChecker.writeObjectOverride(SerializableChecker.java:687)
at java.io.ObjectOutputStream.writeObject(Unknown Source)
at
org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:127)
at java.io.ObjectOutputStream.writeObject(Unknown Source)
at
org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1100)
at
org.apache.wicket.protocol.http.pagestore.AbstractPageStore.serializePage(AbstractPageStore.java:200)
at
org.apache.wicket.protocol.http.pagestore.DiskPageStore.storePage(DiskPageStore.java:814)
at
org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.put(SecondLevelCacheSessionStore.java:327)
at org.apache.wicket.Session.requestDetached(Session.java:1391)
at org.apache.wicket.RequestCycle.detach(RequestCycle.java:1113)
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1384)
at org.apache.wicket.RequestCycle.request(RequestCycle.java:499)
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:387)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:199)
at
org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:334)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:174)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77)
at
org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:334)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:286)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:558)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1714)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:507)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1664)
at org.mortbay.http.HttpServer.service(HttpServer.java:863)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:775)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:939)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:792)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:201)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:455)
Caused by: java.io.NotSerializableException:
org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator
at 

Re: ValueMap, NullSafeKeyComparator and WicketNotSerializableException

2008-06-12 Thread Matthew Hanlon
Sorry, forgot to mention that I'm using wicket 1.4-SNAPSHOT, rev 667063.

On Thu, Jun 12, 2008 at 4:18 PM, Matthew Hanlon [EMAIL PROTECTED] wrote:

 I'm getting a WicketNotSerializableException on a couple of my pages.  The
 field that seems to be not serializable appears to be a Wicket class,
 org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator.  Any
 suggestions?  I saw a posting on the list earlier today that I though may
 have something to do with it, but I cannot find the reference now.

 Here's the stacktrace for the exception I'm getting:

 ERROR Objects:1114 - Error serializing object class
 com.mycompany.MyPage[object=[Page class = com.mycompany.MyPage, id = 3,
 version = 0, ajax = 0]]
 org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException:
 Unable to serialize class:
 org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator
 Field hierarchy is:
   3 [class=com.mycompany.MyPage, path=3]
 java.lang.Object org.apache.wicket.Component.data
 [class=[Ljava.lang.Object;]
   private org.apache.wicket.spring.ISpringContextLocator
 org.apache.wicket.spring.SpringBeanLocator.springContextLocator[1]
 [class=[Lorg.apache.wicket.MetaDataEntry;]
 private org.apache.wicket.spring.ISpringContextLocator
 org.apache.wicket.spring.SpringBeanLocator.springContextLocator[1][0]
 [class=org.apache.wicket.MetaDataEntry]
   java.lang.Object org.apache.wicket.MetaDataEntry.object
 [class=org.apache.wicket.PageParameters]
 private java.util.Comparator java.util.TreeMap.comparator
 [class=org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator] -
 field that is not serializable
 at
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:349)
 at
 org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618)
 at
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541)
 at
 org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618)
 at
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541)
 at
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:395)
 at
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:395)
 at
 org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618)
 at
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541)
 at
 org.apache.wicket.util.io.SerializableChecker.writeObjectOverride(SerializableChecker.java:687)
 at java.io.ObjectOutputStream.writeObject(Unknown Source)
 at
 org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:127)
 at java.io.ObjectOutputStream.writeObject(Unknown Source)
 at
 org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1100)
 at
 org.apache.wicket.protocol.http.pagestore.AbstractPageStore.serializePage(AbstractPageStore.java:200)
 at
 org.apache.wicket.protocol.http.pagestore.DiskPageStore.storePage(DiskPageStore.java:814)
 at
 org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.put(SecondLevelCacheSessionStore.java:327)
 at org.apache.wicket.Session.requestDetached(Session.java:1391)
 at org.apache.wicket.RequestCycle.detach(RequestCycle.java:1113)
 at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1384)
 at org.apache.wicket.RequestCycle.request(RequestCycle.java:499)
 at
 org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:387)
 at
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:199)
 at
 org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:334)
 at
 org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:174)
 at
 org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77)
 at
 org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:334)
 at
 org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:286)
 at
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:558)
 at org.mortbay.http.HttpContext.handle(HttpContext.java:1714)
 at
 org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:507)
 at org.mortbay.http.HttpContext.handle(HttpContext.java:1664)
 at org.mortbay.http.HttpServer.service(HttpServer.java:863)
 at org.mortbay.http.HttpConnection.service(HttpConnection.java:775)
 at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:939)
 at org.mortbay.http.HttpConnection.handle(HttpConnection.java:792)
 at
 org.mortbay.http.SocketListener.handleConnection(SocketListener.java:201)
 at 

Re: when to save shopping basket for registered and anonymous users?

2008-06-12 Thread Marcus Mattila
Hi!

Simply because I don't want to do an if - else everytime an Object is
added to the Basket. Basket can consist of many different Domain
Objects.

-Marcus


On Wed, Jun 11, 2008 at 10:51 PM, Martin Makundi
[EMAIL PROTECTED] wrote:
 Hi!

 Why do you want to save the basket at a specific technical occurrence
 such as .detach?

 If you want, you can always persist changes for a registered user
 and on the other hand never persist them for anonymous users.

 Whenever the anonymous user becomes registered - the basket is persisted.

 **
 Martin

 2008/6/11 Marcus Mattila [EMAIL PROTECTED]:
 Hi!

 We are developing a shopping basket in our Wicket application. We
 would like to persist the basket as late as possible, and for
 anonymous users only if they sign up to the service. We don't want to
 save lots of anonymous Baskets to the database. We use Wicket 1.3.3
 and Databinder (as a Hibernate bridge). What would be a good save
 point for the Basket-object?

 One potential solution is this:
 Override Session.detach() and save Basket there, if user is registered
 and Basket is dirty..
 If user is anonymous, save when user has signed up and the User
 -domain object is created.

 Possibly in the next version:
 For anonymous users, create a cookiebased solution Amazon-style.

 Any glaring holes in our solution? Other ways of fulfilling this need?

 br,
 Marcus

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: ValueMap, NullSafeKeyComparator and WicketNotSerializableException

2008-06-12 Thread Frank Bille
https://issues.apache.org/jira/browse/WICKET-1694


On Thu, Jun 12, 2008 at 11:20 PM, Matthew Hanlon [EMAIL PROTECTED] wrote:

 Sorry, forgot to mention that I'm using wicket 1.4-SNAPSHOT, rev 667063.

 On Thu, Jun 12, 2008 at 4:18 PM, Matthew Hanlon [EMAIL PROTECTED]
 wrote:

  I'm getting a WicketNotSerializableException on a couple of my pages.
  The
  field that seems to be not serializable appears to be a Wicket class,
  org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator.  Any
  suggestions?  I saw a posting on the list earlier today that I though may
  have something to do with it, but I cannot find the reference now.
 
  Here's the stacktrace for the exception I'm getting:
 
  ERROR Objects:1114 - Error serializing object class
  com.mycompany.MyPage[object=[Page class = com.mycompany.MyPage, id = 3,
  version = 0, ajax = 0]]
 
 org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException:
  Unable to serialize class:
  org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator
  Field hierarchy is:
3 [class=com.mycompany.MyPage, path=3]
  java.lang.Object org.apache.wicket.Component.data
  [class=[Ljava.lang.Object;]
private org.apache.wicket.spring.ISpringContextLocator
  org.apache.wicket.spring.SpringBeanLocator.springContextLocator[1]
  [class=[Lorg.apache.wicket.MetaDataEntry;]
  private org.apache.wicket.spring.ISpringContextLocator
  org.apache.wicket.spring.SpringBeanLocator.springContextLocator[1][0]
  [class=org.apache.wicket.MetaDataEntry]
java.lang.Object org.apache.wicket.MetaDataEntry.object
  [class=org.apache.wicket.PageParameters]
  private java.util.Comparator java.util.TreeMap.comparator
  [class=org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator]
 -
  field that is not serializable
  at
 
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:349)
  at
 
 org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618)
  at
 
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541)
  at
 
 org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618)
  at
 
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541)
  at
 
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:395)
  at
 
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:395)
  at
 
 org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618)
  at
 
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541)
  at
 
 org.apache.wicket.util.io.SerializableChecker.writeObjectOverride(SerializableChecker.java:687)
  at java.io.ObjectOutputStream.writeObject(Unknown Source)
  at
 
 org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:127)
  at java.io.ObjectOutputStream.writeObject(Unknown Source)
  at
  org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1100)
  at
 
 org.apache.wicket.protocol.http.pagestore.AbstractPageStore.serializePage(AbstractPageStore.java:200)
  at
 
 org.apache.wicket.protocol.http.pagestore.DiskPageStore.storePage(DiskPageStore.java:814)
  at
 
 org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.put(SecondLevelCacheSessionStore.java:327)
  at org.apache.wicket.Session.requestDetached(Session.java:1391)
  at org.apache.wicket.RequestCycle.detach(RequestCycle.java:1113)
  at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1384)
  at org.apache.wicket.RequestCycle.request(RequestCycle.java:499)
  at
  org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:387)
  at
 
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:199)
  at
 
 org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:334)
  at
 
 org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:174)
  at
 
 org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77)
  at
 
 org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:334)
  at
 
 org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:286)
  at
  org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:558)
  at org.mortbay.http.HttpContext.handle(HttpContext.java:1714)
  at
 
 org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:507)
  at org.mortbay.http.HttpContext.handle(HttpContext.java:1664)
  at org.mortbay.http.HttpServer.service(HttpServer.java:863)
  at org.mortbay.http.HttpConnection.service(HttpConnection.java:775)
  at
 

PasswordTextField model?

2008-06-12 Thread David Nedrow
Given the following from the wicket security quickstart (1.3- 
SNAPSHOT)...


add(new PasswordTextField(password).setOutputMarkupId(false));

glassfish generates the following message

Couldn't resolve model type of  
Model:classname=[org.apache.wicket.model.CompoundPropertyModel 
$ 
AttachedCompoundPropertyModel 
]:nestedModel 
= 
[Model:classname 
=[org.apache.wicket.model.CompoundPropertyModel]:nestedModel=[username  
= regular]] for [MarkupContainer [Component id = password, page =  
com.vzbi.ncs.argfrp.webapp.FilterRequest.app.LoginPage, path =  
0:signInPanel:signInForm:password.PasswordTextField, isVisible = true,  
isVersioned = false]], please set the type yourself.


Not setting the model does not seem to create a problem, but it would  
seem that the system would prefer that models be set where applicable.


Is that the case? I have to admit, I'm a little anal about clearing  
all warnings in my apps.


What would an appropriate model be for the above PasswordTextField()?

Models seem to be the most poorly exampled Wicket feature, in that  
examples of Models rarely tell one why they are needed and what role  
they perform. It's generally, here's an example to make your code  
work. Clearly, in most cases the model contains the data for the  
markup. But what would that data be for a PasswordTextField()? One  
isn't normally going to pre-fill a password field, correct?


Thanks,

David

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: The component(s) below failed to render

2008-06-12 Thread greeklinux

Do you add the DropDownChoice to the markup and forgott the wicket id?



Michael_Bo wrote:
 
 Hi,
 
 i have a problem with some Components. I'm using Wicket Web beans.
 If tried to add an additional form to a beanFrom. Then I get The following
 Error:
 
 WicketMessage: The component(s) below failed to render. A common problem
 is that you have added a component in code but forgot to reference it in
 the markup (thus the component will never be rendered).
 
 1. [MarkupContainer [Component id = beanRForm, page = metaWicket.EditPage,
 path = 2:beanForm:beanRForm.TkDataBeanEditPanel$TkbeanForm, isVisible =
 true, isVersioned = true]]
 2. [MarkupContainer [Component id = beanDropDown, page =
 metaWicket.EditPage, path =
 2:beanForm:beanRForm:beanDropDown.DropDownChoice, isVisible = true,
 isVersioned = false]]
 
 Root cause:
 
 org.apache.wicket.WicketRuntimeException: The component(s) below failed to
 render. A common problem is that you have added a component in code but
 forgot to reference it in the markup (thus the component will never be
 rendered).
 
 1. [MarkupContainer [Component id = beanRForm, page = metaWicket.EditPage,
 path = 2:beanForm:beanRForm.TkDataBeanEditPanel$TkbeanForm, isVisible =
 true, isVersioned = true]]
 2. [MarkupContainer [Component id = beanDropDown, page =
 metaWicket.EditPage, path =
 2:beanForm:beanRForm:beanDropDown.DropDownChoice, isVisible = true,
 isVersioned = false]]
 
 at org.apache.wicket.Page.checkRendering(Page.java:1116)
 at org.apache.wicket.Page.renderPage(Page.java:914)
 at
 org.apache.wicket.protocol.http.WebRequestCycle.redirectTo(WebRequestCycle.java:163)
 at
 org.apache.wicket.request.target.component.PageRequestTarget.respond(PageRequestTarget.java:58)
 at
 org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:104)
 at
 org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1172)
 at org.apache.wicket.RequestCycle.step(RequestCycle.java:1243)
 at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1330)
 at org.apache.wicket.RequestCycle.request(RequestCycle.java:493)
 at
 org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:358)
 at
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:194)
 at
 org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
 at
 org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
 at
 org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
 at
 org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
 at
 org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
 at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
 at
 org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
 at org.mortbay.jetty.Server.handle(Server.java:295)
 at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:503)
 at
 org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:827)
 at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:511)
 at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:210)
 at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:379)
 at
 org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
 at
 org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
 
 What I want is an Additional Dropdownchoice in my beanFrom because the
 beanFrom gets its field from a Bean. 
 I don't really know in what .html file I have to put this additional Bean
 
 chears
 Michael
 

-- 
View this message in context: 
http://www.nabble.com/The-component%28s%29-below-failed-to-render-tp17803377p17810721.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: ValueMap, NullSafeKeyComparator and WicketNotSerializableException

2008-06-12 Thread Frank Bille
Fixed

On Thu, Jun 12, 2008 at 11:47 PM, Frank Bille [EMAIL PROTECTED] wrote:

 https://issues.apache.org/jira/browse/WICKET-1694



 On Thu, Jun 12, 2008 at 11:20 PM, Matthew Hanlon [EMAIL PROTECTED]
 wrote:

 Sorry, forgot to mention that I'm using wicket 1.4-SNAPSHOT, rev 667063.

 On Thu, Jun 12, 2008 at 4:18 PM, Matthew Hanlon [EMAIL PROTECTED]
 wrote:

  I'm getting a WicketNotSerializableException on a couple of my pages.
  The
  field that seems to be not serializable appears to be a Wicket class,
  org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator.  Any
  suggestions?  I saw a posting on the list earlier today that I though
 may
  have something to do with it, but I cannot find the reference now.
 
  Here's the stacktrace for the exception I'm getting:
 
  ERROR Objects:1114 - Error serializing object class
  com.mycompany.MyPage[object=[Page class = com.mycompany.MyPage, id = 3,
  version = 0, ajax = 0]]
 
 org.apache.wicket.util.io.SerializableChecker$WicketNotSerializableException:
  Unable to serialize class:
  org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator
  Field hierarchy is:
3 [class=com.mycompany.MyPage, path=3]
  java.lang.Object org.apache.wicket.Component.data
  [class=[Ljava.lang.Object;]
private org.apache.wicket.spring.ISpringContextLocator
  org.apache.wicket.spring.SpringBeanLocator.springContextLocator[1]
  [class=[Lorg.apache.wicket.MetaDataEntry;]
  private org.apache.wicket.spring.ISpringContextLocator
  org.apache.wicket.spring.SpringBeanLocator.springContextLocator[1][0]
  [class=org.apache.wicket.MetaDataEntry]
java.lang.Object org.apache.wicket.MetaDataEntry.object
  [class=org.apache.wicket.PageParameters]
  private java.util.Comparator java.util.TreeMap.comparator
  [class=org.apache.wicket.util.value.ValueMap$NullSafeKeyComparator]
 -
  field that is not serializable
  at
 
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:349)
  at
 
 org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618)
  at
 
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541)
  at
 
 org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618)
  at
 
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541)
  at
 
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:395)
  at
 
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:395)
  at
 
 org.apache.wicket.util.io.SerializableChecker.checkFields(SerializableChecker.java:618)
  at
 
 org.apache.wicket.util.io.SerializableChecker.check(SerializableChecker.java:541)
  at
 
 org.apache.wicket.util.io.SerializableChecker.writeObjectOverride(SerializableChecker.java:687)
  at java.io.ObjectOutputStream.writeObject(Unknown Source)
  at
 
 org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:127)
  at java.io.ObjectOutputStream.writeObject(Unknown Source)
  at
  org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1100)
  at
 
 org.apache.wicket.protocol.http.pagestore.AbstractPageStore.serializePage(AbstractPageStore.java:200)
  at
 
 org.apache.wicket.protocol.http.pagestore.DiskPageStore.storePage(DiskPageStore.java:814)
  at
 
 org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.put(SecondLevelCacheSessionStore.java:327)
  at org.apache.wicket.Session.requestDetached(Session.java:1391)
  at org.apache.wicket.RequestCycle.detach(RequestCycle.java:1113)
  at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1384)
  at org.apache.wicket.RequestCycle.request(RequestCycle.java:499)
  at
 
 org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:387)
  at
 
 org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:199)
  at
 
 org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:334)
  at
 
 org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:174)
  at
 
 org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77)
  at
 
 org.mortbay.jetty.servlet.WebApplicationHandler$Chain.doFilter(WebApplicationHandler.java:334)
  at
 
 org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:286)
  at
  org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:558)
  at org.mortbay.http.HttpContext.handle(HttpContext.java:1714)
  at
 
 org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:507)
  at org.mortbay.http.HttpContext.handle(HttpContext.java:1664)
  at org.mortbay.http.HttpServer.service(HttpServer.java:863)
  at 

Re: PasswordTextField model?

2008-06-12 Thread Timo Rantalaiho
On Thu, 12 Jun 2008, David Nedrow wrote:
 Couldn't resolve model type of  
 Model:classname=[org.apache.wicket.model.CompoundPropertyModel 
 $ 
 AttachedCompoundPropertyModel 
 ]:nestedModel 
 = 
 [Model:classname 
 =[org.apache.wicket.model.CompoundPropertyModel]:nestedModel=[username  
 = regular]] for [MarkupContainer [Component id = password, page =  
 com.vzbi.ncs.argfrp.webapp.FilterRequest.app.LoginPage, path =  
 0:signInPanel:signInForm:password.PasswordTextField, isVisible = true,  
 isVersioned = false]], please set the type yourself.
 
 Not setting the model does not seem to create a problem, but it would  
 seem that the system would prefer that models be set where applicable.

I think that the problem is not actually the lack of model, 
but that Wicket cannot figure out to what type of object the
model of the formcomponent is supposed to contain. 

Calling passwordField.setType(TypeOfMyPasswordObject.class)
might help. The type can also be supplied in the constructor.

 Is that the case? I have to admit, I'm a little anal about clearing  
 all warnings in my apps.

I know the feeling :)

Best wishes,
Timo

-- 
Timo Rantalaiho   
Reaktor Innovations OyURL: http://www.ri.fi/ 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: users, please give us your opinion: what is your take on generics with Wicket

2008-06-12 Thread Jon Laidler



Eelco Hillenius wrote:
 
 Hi all,
 
 We have had several threads in this and the dev list, and some
 discussions in the public on how to incorporate generics in Wicket.
 
 I'd like to use this thread to gather the opinions of as many regular
 Wicket users as we can. Please help us get an impression of what our
 users think about the issue by completing this simple survey. Note
 that it is not a vote; we only want to get an idea of what you think.
 
 1) Generifying* Wicket
[x] Can best be done like currently in the 1.4 branch, where models
 and components are both generified. I care most about the improved
 static type checking generified models and components give Wicket.
[ ] Can best be done in a limited fashion, where we only generify
 IModel but not components. I care more about what generifying can do
 for API clarity (declaring a component to only accept certain models
 for instance) than static type checking.
[ ] Should be avoided, I prefer the way 1.3 works. Because... (fill
 in your opinion here).
[ ]  (anything other than these choices?)
 
 2) How strongly do you feel about your choice above?
[x ] Whatever choice ultimately made, I'll happily convert/ start
 using 1.4 and up.
[ ] I might rethink upgrading if my choice doesn't win.
[ ] I definitively won't be using 1.4. if Wicket doesn't go for my
 preference.
 
 Thanks in advance for everyone participating, and pls feel free to
 explain yourself further beyond just answering these questions!
 
 Eelco
 
 p.s. I suggest that the core devs and most active participants and
 previous discussions wait a few days before giving their opinions so
 that we don't flood the thread right from the start.
 
 * Parameterizing would probably be the better word to use, but
 generifying seems to be the word that many people use.
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17811756.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Making Component easier to Generify

2008-06-12 Thread igor . vaynberg
decorators only work with interfaces, component class is not. This is
part of the reason why we have behaviors

-igor

On 6/12/08, Matthijs Wensveen [EMAIL PROTECTED] wrote:
 Some useful design patterns like Decorator don't work with final
 methods. Wicket components sometimes have overridable factory methods
 for child components. The decorator pattern could be very useful here,
 because you'd be able to decorate the original component with some extra
 functionality (Link.onClick for example). Unfortunately this doesn't
 work because some methods are final.

 Matthijs

 Igor Vaynberg wrote:
 i mean generally, for methods, fields, and func args :) most of this
 stuff can stay final, but people dont bother doing it because its
 extra typing.

 -igor

 On Thu, Jun 12, 2008 at 8:38 AM, James Carman
 [EMAIL PROTECTED] wrote:

 You mean like C++?

 On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg [EMAIL PROTECTED]
 wrote:

 indeed. i wouldnt mind if final was the default in java :)

 -igor

 On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst
 [EMAIL PROTECTED] wrote:

 Without the use of final wicket would not have made it this far.

 Martijn

 On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin [EMAIL PROTECTED] wrote:

 I understand the reasoning, however I think best practice can be
 debated.
 To use your example Swing allows the user to override quite a bit, and
 it
 doesn't make any (or very few) assumptions on what should and should
 not be
 done.

 I don't like API's that assume I'm an idiot and prevent me from
 manipulating
 them how I see fit. If I cause a bug that I have to deal with, thats
 *my*
 problem to resolve.

 In my book (and I'm not the only one) excessive use of final is an
 anti-pattern.

 - Brill Pappin

 On 12-Jun-08, at 10:01 AM, cowwoc wrote:


 Brill,

 This is actually an API best practice. Classes fall into two
 categories:
 ones designed for subclassing, and ones designed to be final. The
 same
 goes
 for methods. Swing is full of examples of what goes wrong when people
 override methods in classes that haven't been designed with
 subclassing in
 mind.

 Gili


 Brill Pappin wrote:

 on removing the finals

 The final members are the worst thing I've had to deal with in
 Wicket
 so far.
 Although I understand that there may be a reason for them, they are
 more a hinderance than anything else and seem to be trying to
 protect
 users from themselves.

 - Brill Pappin


 On 12-Jun-08, at 1:03 AM, cowwoc wrote:


 Have you considered moving from subclassing to composition in
 Wicket
 using
 CallableT?

 Currently it is quite common for developers to subclass a component
 in order
 to override isVisible() and other properties. I am proposing that
 instead
 the component classes become final and properties may only be set
 using
 setter methods. The setter methods would take CallableT instead
 of
 T, so
 for example setVisible(boolean) would become
 setVisible(CallableBoolean)

 The benefit of this approach is that you could introduce static
 factory
 methods to the Wicket components which would make them much easier
 to use in
 their Generic form. You could then introduce various helper classes
 to
 create CallableT for constant values, such as
 Callable.valueOf(true) would
 return a CallableBoolean that always returns true.
 --
 View this message in context:

 http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 --
 View this message in context:
 http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html
 Sent from the Wicket - User mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 --
 Become a Wicket expert, learn from the best: http://wicketinaction.com
 Apache Wicket 1.3.3 is released
 Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 

Re: Making Component easier to Generify

2008-06-12 Thread Matthijs Wensveen
Why would the decorator design pattern only work with interfaces? Maybe 
we're talking about two different this here? (I'm talking about this 
one: http://en.wikipedia.org/wiki/Decorator_pattern)


I can see why behaviors were introduced. A simple example: a factory 
method creates a link. In my subclass I want the same link with the same 
onClick behavior but I also want hello to be outputted to System.out. 
How would I go about doing this with a Behavior? I couldn't figure it 
out... (which isn't saying it's impossible).


Matthijs

[EMAIL PROTECTED] wrote:

decorators only work with interfaces, component class is not. This is
part of the reason why we have behaviors

-igor

On 6/12/08, Matthijs Wensveen [EMAIL PROTECTED] wrote:
  

Some useful design patterns like Decorator don't work with final
methods. Wicket components sometimes have overridable factory methods
for child components. The decorator pattern could be very useful here,
because you'd be able to decorate the original component with some extra
functionality (Link.onClick for example). Unfortunately this doesn't
work because some methods are final.

Matthijs

Igor Vaynberg wrote:


i mean generally, for methods, fields, and func args :) most of this
stuff can stay final, but people dont bother doing it because its
extra typing.

-igor

On Thu, Jun 12, 2008 at 8:38 AM, James Carman
[EMAIL PROTECTED] wrote:

  

You mean like C++?

On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg [EMAIL PROTECTED]
wrote:



indeed. i wouldnt mind if final was the default in java :)

-igor

On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst
[EMAIL PROTECTED] wrote:

  

Without the use of final wicket would not have made it this far.

Martijn

On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin [EMAIL PROTECTED] wrote:



I understand the reasoning, however I think best practice can be
debated.
To use your example Swing allows the user to override quite a bit, and
it
doesn't make any (or very few) assumptions on what should and should
not be
done.

I don't like API's that assume I'm an idiot and prevent me from
manipulating
them how I see fit. If I cause a bug that I have to deal with, thats
*my*
problem to resolve.

In my book (and I'm not the only one) excessive use of final is an
anti-pattern.

- Brill Pappin

On 12-Jun-08, at 10:01 AM, cowwoc wrote:


  

Brill,

This is actually an API best practice. Classes fall into two
categories:
ones designed for subclassing, and ones designed to be final. The
same
goes
for methods. Swing is full of examples of what goes wrong when people
override methods in classes that haven't been designed with
subclassing in
mind.

Gili


Brill Pappin wrote:



on removing the finals

The final members are the worst thing I've had to deal with in
Wicket
so far.
Although I understand that there may be a reason for them, they are
more a hinderance than anything else and seem to be trying to
protect
users from themselves.

- Brill Pappin


On 12-Jun-08, at 1:03 AM, cowwoc wrote:


  

Have you considered moving from subclassing to composition in
Wicket
using
CallableT?

Currently it is quite common for developers to subclass a component
in order
to override isVisible() and other properties. I am proposing that
instead
the component classes become final and properties may only be set
using
setter methods. The setter methods would take CallableT instead
of
T, so
for example setVisible(boolean) would become
setVisible(CallableBoolean)

The benefit of this approach is that you could introduce static
factory
methods to the Wicket components which would make them much easier
to use in
their Generic form. You could then introduce various helper classes
to
create CallableT for constant values, such as
Callable.valueOf(true) would
return a CallableBoolean that always returns true.
--
View this message in context:

http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




  

--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: 

Re: PasswordTextField model?

2008-06-12 Thread Igor Vaynberg
no, you dont typically initialize the field. but you do want to
retrieve the result right? so you need to give the field a model.
wicket might not call model.getobject() on it, but it will call
model.setobject() when the form is submitted.

models do not contain data for markup, but for components.

-igor

On Thu, Jun 12, 2008 at 3:04 PM, David Nedrow [EMAIL PROTECTED] wrote:
 Given the following from the wicket security quickstart (1.3-SNAPSHOT)...

 add(new PasswordTextField(password).setOutputMarkupId(false));

 glassfish generates the following message

 Couldn't resolve model type of
 Model:classname=[org.apache.wicket.model.CompoundPropertyModel$AttachedCompoundPropertyModel]:nestedModel=[Model:classname=[org.apache.wicket.model.CompoundPropertyModel]:nestedModel=[username
 = regular]] for [MarkupContainer [Component id = password, page =
 com.vzbi.ncs.argfrp.webapp.FilterRequest.app.LoginPage, path =
 0:signInPanel:signInForm:password.PasswordTextField, isVisible = true,
 isVersioned = false]], please set the type yourself.

 Not setting the model does not seem to create a problem, but it would seem
 that the system would prefer that models be set where applicable.

 Is that the case? I have to admit, I'm a little anal about clearing all
 warnings in my apps.

 What would an appropriate model be for the above PasswordTextField()?

 Models seem to be the most poorly exampled Wicket feature, in that
 examples of Models rarely tell one why they are needed and what role they
 perform. It's generally, here's an example to make your code work. Clearly,
 in most cases the model contains the data for the markup. But what would
 that data be for a PasswordTextField()? One isn't normally going to pre-fill
 a password field, correct?

 Thanks,

 David

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Making Component easier to Generify

2008-06-12 Thread Igor Vaynberg
look at the java example. notice Window is an interface.

eg you cant do: add(new DecoratedComponent(someOtherComponent));

-igor

On Thu, Jun 12, 2008 at 5:05 PM, Matthijs Wensveen [EMAIL PROTECTED] wrote:
 Why would the decorator design pattern only work with interfaces? Maybe
 we're talking about two different this here? (I'm talking about this one:
 http://en.wikipedia.org/wiki/Decorator_pattern)

 I can see why behaviors were introduced. A simple example: a factory method
 creates a link. In my subclass I want the same link with the same onClick
 behavior but I also want hello to be outputted to System.out. How would I
 go about doing this with a Behavior? I couldn't figure it out... (which
 isn't saying it's impossible).

 Matthijs

 [EMAIL PROTECTED] wrote:

 decorators only work with interfaces, component class is not. This is
 part of the reason why we have behaviors

 -igor

 On 6/12/08, Matthijs Wensveen [EMAIL PROTECTED] wrote:


 Some useful design patterns like Decorator don't work with final
 methods. Wicket components sometimes have overridable factory methods
 for child components. The decorator pattern could be very useful here,
 because you'd be able to decorate the original component with some extra
 functionality (Link.onClick for example). Unfortunately this doesn't
 work because some methods are final.

 Matthijs

 Igor Vaynberg wrote:


 i mean generally, for methods, fields, and func args :) most of this
 stuff can stay final, but people dont bother doing it because its
 extra typing.

 -igor

 On Thu, Jun 12, 2008 at 8:38 AM, James Carman
 [EMAIL PROTECTED] wrote:



 You mean like C++?

 On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg
 [EMAIL PROTECTED]
 wrote:



 indeed. i wouldnt mind if final was the default in java :)

 -igor

 On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst
 [EMAIL PROTECTED] wrote:



 Without the use of final wicket would not have made it this far.

 Martijn

 On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin [EMAIL PROTECTED]
 wrote:



 I understand the reasoning, however I think best practice can be
 debated.
 To use your example Swing allows the user to override quite a bit,
 and
 it
 doesn't make any (or very few) assumptions on what should and should
 not be
 done.

 I don't like API's that assume I'm an idiot and prevent me from
 manipulating
 them how I see fit. If I cause a bug that I have to deal with, thats
 *my*
 problem to resolve.

 In my book (and I'm not the only one) excessive use of final is an
 anti-pattern.

 - Brill Pappin

 On 12-Jun-08, at 10:01 AM, cowwoc wrote:




 Brill,

 This is actually an API best practice. Classes fall into two
 categories:
 ones designed for subclassing, and ones designed to be final. The
 same
 goes
 for methods. Swing is full of examples of what goes wrong when
 people
 override methods in classes that haven't been designed with
 subclassing in
 mind.

 Gili


 Brill Pappin wrote:



 on removing the finals

 The final members are the worst thing I've had to deal with in
 Wicket
 so far.
 Although I understand that there may be a reason for them, they
 are
 more a hinderance than anything else and seem to be trying to
 protect
 users from themselves.

 - Brill Pappin


 On 12-Jun-08, at 1:03 AM, cowwoc wrote:




 Have you considered moving from subclassing to composition in
 Wicket
 using
 CallableT?

 Currently it is quite common for developers to subclass a
 component
 in order
 to override isVisible() and other properties. I am proposing that
 instead
 the component classes become final and properties may only be set
 using
 setter methods. The setter methods would take CallableT instead
 of
 T, so
 for example setVisible(boolean) would become
 setVisible(CallableBoolean)

 The benefit of this approach is that you could introduce static
 factory
 methods to the Wicket components which would make them much
 easier
 to use in
 their Generic form. You could then introduce various helper
 classes
 to
 create CallableT for constant values, such as
 Callable.valueOf(true) would
 return a CallableBoolean that always returns true.
 --
 View this message in context:


 http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17792488.html
 Sent from the Wicket - User mailing list archive at Nabble.com.



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]





 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]






 --
 View this message in context:

 http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17800710.html
 Sent from the Wicket - User mailing list archive at Nabble.com.



 -
 To 

Re: Making Component easier to Generify

2008-06-12 Thread Matthijs Wensveen

Igor Vaynberg wrote:

look at the java example. notice Window is an interface.
  


Yeah, but that's just because it's good practice to use the interface 
when there is one. Notice that the actually decorated class is a new 
SimpleWindow() in DecoratedWindowTest. Window might as well have been an 
abstract class, or even a concrete one. The idea is that the contract of 
the class you wrap is maintained, if that is an interface your decorator 
implements that, when it's a class your decorator extends it. Same idea. 
Of course, interfaces are cleaner and you can even decorate more then 
one interface when you want to, but decorating a class is not uncommon 
practice (at least where I come from).


Example: http://www.onjava.com/pub/a/onjava/2003/02/05/decorator.html


eg you cant do: add(new DecoratedComponent(someOtherComponent));
  


No, because component has final methods that you can't override so you 
can't delegate to them (that whas my point), but not because you can't 
decorate a class.


Matthijs.

PS. If you insist on that you can only decorate an interface, I'll call 
it wrap-extend or something :)



-igor

On Thu, Jun 12, 2008 at 5:05 PM, Matthijs Wensveen [EMAIL PROTECTED] wrote:
  

Why would the decorator design pattern only work with interfaces? Maybe
we're talking about two different this here? (I'm talking about this one:
http://en.wikipedia.org/wiki/Decorator_pattern)

I can see why behaviors were introduced. A simple example: a factory method
creates a link. In my subclass I want the same link with the same onClick
behavior but I also want hello to be outputted to System.out. How would I
go about doing this with a Behavior? I couldn't figure it out... (which
isn't saying it's impossible).

Matthijs

[EMAIL PROTECTED] wrote:


decorators only work with interfaces, component class is not. This is
part of the reason why we have behaviors

-igor

On 6/12/08, Matthijs Wensveen [EMAIL PROTECTED] wrote:

  

Some useful design patterns like Decorator don't work with final
methods. Wicket components sometimes have overridable factory methods
for child components. The decorator pattern could be very useful here,
because you'd be able to decorate the original component with some extra
functionality (Link.onClick for example). Unfortunately this doesn't
work because some methods are final.

Matthijs

Igor Vaynberg wrote:



i mean generally, for methods, fields, and func args :) most of this
stuff can stay final, but people dont bother doing it because its
extra typing.

-igor

On Thu, Jun 12, 2008 at 8:38 AM, James Carman
[EMAIL PROTECTED] wrote:


  

You mean like C++?

On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg
[EMAIL PROTECTED]
wrote:




indeed. i wouldnt mind if final was the default in java :)

-igor

On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst
[EMAIL PROTECTED] wrote:


  

Without the use of final wicket would not have made it this far.

Martijn

On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin [EMAIL PROTECTED]
wrote:




I understand the reasoning, however I think best practice can be
debated.
To use your example Swing allows the user to override quite a bit,
and
it
doesn't make any (or very few) assumptions on what should and should
not be
done.

I don't like API's that assume I'm an idiot and prevent me from
manipulating
them how I see fit. If I cause a bug that I have to deal with, thats
*my*
problem to resolve.

In my book (and I'm not the only one) excessive use of final is an
anti-pattern.

- Brill Pappin

On 12-Jun-08, at 10:01 AM, cowwoc wrote:



  

Brill,

This is actually an API best practice. Classes fall into two
categories:
ones designed for subclassing, and ones designed to be final. The
same
goes
for methods. Swing is full of examples of what goes wrong when
people
override methods in classes that haven't been designed with
subclassing in
mind.

Gili


Brill Pappin wrote:




on removing the finals

The final members are the worst thing I've had to deal with in
Wicket
so far.
Although I understand that there may be a reason for them, they
are
more a hinderance than anything else and seem to be trying to
protect
users from themselves.

- Brill Pappin


On 12-Jun-08, at 1:03 AM, cowwoc wrote:



  

Have you considered moving from subclassing to composition in
Wicket
using
CallableT?

Currently it is quite common for developers to subclass a
component
in order
to override isVisible() and other properties. I am proposing that
instead
the component classes become final and properties may only be set
using
setter methods. The setter methods would take CallableT instead
of
T, so
for example setVisible(boolean) would become
setVisible(CallableBoolean)

The benefit of this approach is that you could introduce static
factory
methods to the Wicket components which would make them much
easier
to use in
their Generic form. You could then introduce 

Re: Default Focus Behavior?

2008-06-12 Thread Rod Good
Hi,
 
I'm trying to set the 'focus on load' to an AutoCompleteTextField within
a form.
 
I tried extending the technique outlined by James Carman (see link) to
extend AbstractDefaultAjaxBehavior, without success.
 
Any thoughts on how to do this ?
 
Thanks,
Rod.
 
http://cwiki.apache.org/confluence/display/WICKET/Request+Focus+on+a+Spe
cific+Form+Component

NOTICE
This e-mail and any attachments are confidential and may contain copyright 
material of Macquarie Group Limited or third parties. If you are not the 
intended recipient of this email you should not read, print, re-transmit, store 
or act in reliance on this e-mail or any attachments, and should destroy all 
copies of them. Macquarie Group Limited does not guarantee the integrity of any 
emails or any attached files. The views or opinions expressed are the author's 
own and may not reflect the views or opinions of Macquarie Group Limited.



RE: Default Focus Behavior?

2008-06-12 Thread Rod Good
Here's that link ...

http://cwiki.apache.org/confluence/display/WICKET/Request+Focus+on+a+Spe
cific+Form+Component

Note that the technique outlined does set the focus correctly, but after
I use the autocomplete box it throws a runtime exception : 

Root cause:
java.lang.IllegalStateException: No behavior listener found with
behaviorId 4; Component: [MarkupContainer [Component id = ac, page =
au.com.macquarie.hr.edms.web.ed.EDMainPage, path =
6:edSelectionPanel:form:ac.EDSelectionPanel$EdSelectionForm$1, isVisible
= true, isVersioned = false]] 
at
org.apache.wicket.request.target.component.listener.BehaviorRequestTarge
t.processEvents(BehaviorRequestTarget.java:95) 
at
org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(Ab
stractRequestCycleProcessor.java:91) 
at
org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java
:1171) 
at org.apache.wicket.RequestCycle.step(RequestCycle.java:1248) 
at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1349) 
at org.apache.wicket.RequestCycle.request(RequestCycle.java:493) 
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:387
) 
at
org.apache.wicket.protocol.http.WicketServlet.doPost(WicketServlet.java:
145) 
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) 
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) 
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:252) 
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:173) 
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFil
terInternal(OpenSessionInViewFilter.java:198) 
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequ
estFilter.java:75) 
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
tionFilterChain.java:202) 
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
erChain.java:173) 
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
e.java:213) 
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
e.java:178) 
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
:126) 
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
:105) 
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
java:107) 
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1
48) 
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:86
9) 
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.proc
essConnection(Http11BaseProtocol.java:667) 
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint
.java:527) 
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollow
erWorkerThread.java:80) 
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
.java:684) 
at java.lang.Thread.run(Thread.java:619)
 

-Original Message-
From: Rod Good 
Sent: Friday, 13 June 2008 1:06 PM
To: users@wicket.apache.org
Subject: Re: Default Focus Behavior?

Hi,
 
I'm trying to set the 'focus on load' to an AutoCompleteTextField within
a form.
 
I tried extending the technique outlined by James Carman (see link) to
extend AbstractDefaultAjaxBehavior, without success.
 
Any thoughts on how to do this ?
 
Thanks,
Rod.
 
http://cwiki.apache.org/confluence/display/WICKET/Request+Focus+on+a+Spe
cific+Form+Component

NOTICE
This e-mail and any attachments are confidential and may contain
copyright material of Macquarie Group Limited or third parties. If you
are not the intended recipient of this email you should not read, print,
re-transmit, store or act in reliance on this e-mail or any attachments,
and should destroy all copies of them. Macquarie Group Limited does not
guarantee the integrity of any emails or any attached files. The views
or opinions expressed are the author's own and may not reflect the views
or opinions of Macquarie Group Limited.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Making Component easier to Generify

2008-06-12 Thread Igor Vaynberg
right. so when you would do it with a class you will actually have to
rewire all the methods to forward to the delegate instead of calling
super. that is pure insanity and does not make any sense when methods
hold logic. that is why it works with an interface, no logic for you
to override and forward to the delegate, only the message dispatch
itself. sure, technically you can do it even with a concrete class,
but you can also do a lot of other things that dont make sense.

-igor

On Thu, Jun 12, 2008 at 5:54 PM, Matthijs Wensveen [EMAIL PROTECTED] wrote:
 Igor Vaynberg wrote:

 look at the java example. notice Window is an interface.


 Yeah, but that's just because it's good practice to use the interface when
 there is one. Notice that the actually decorated class is a new
 SimpleWindow() in DecoratedWindowTest. Window might as well have been an
 abstract class, or even a concrete one. The idea is that the contract of the
 class you wrap is maintained, if that is an interface your decorator
 implements that, when it's a class your decorator extends it. Same idea. Of
 course, interfaces are cleaner and you can even decorate more then one
 interface when you want to, but decorating a class is not uncommon practice
 (at least where I come from).

 Example: http://www.onjava.com/pub/a/onjava/2003/02/05/decorator.html

 eg you cant do: add(new DecoratedComponent(someOtherComponent));


 No, because component has final methods that you can't override so you can't
 delegate to them (that whas my point), but not because you can't decorate a
 class.

 Matthijs.

 PS. If you insist on that you can only decorate an interface, I'll call it
 wrap-extend or something :)

 -igor

 On Thu, Jun 12, 2008 at 5:05 PM, Matthijs Wensveen [EMAIL PROTECTED]
 wrote:


 Why would the decorator design pattern only work with interfaces? Maybe
 we're talking about two different this here? (I'm talking about this one:
 http://en.wikipedia.org/wiki/Decorator_pattern)

 I can see why behaviors were introduced. A simple example: a factory
 method
 creates a link. In my subclass I want the same link with the same onClick
 behavior but I also want hello to be outputted to System.out. How would
 I
 go about doing this with a Behavior? I couldn't figure it out... (which
 isn't saying it's impossible).

 Matthijs

 [EMAIL PROTECTED] wrote:


 decorators only work with interfaces, component class is not. This is
 part of the reason why we have behaviors

 -igor

 On 6/12/08, Matthijs Wensveen [EMAIL PROTECTED] wrote:



 Some useful design patterns like Decorator don't work with final
 methods. Wicket components sometimes have overridable factory methods
 for child components. The decorator pattern could be very useful here,
 because you'd be able to decorate the original component with some
 extra
 functionality (Link.onClick for example). Unfortunately this doesn't
 work because some methods are final.

 Matthijs

 Igor Vaynberg wrote:



 i mean generally, for methods, fields, and func args :) most of this
 stuff can stay final, but people dont bother doing it because its
 extra typing.

 -igor

 On Thu, Jun 12, 2008 at 8:38 AM, James Carman
 [EMAIL PROTECTED] wrote:




 You mean like C++?

 On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg
 [EMAIL PROTECTED]
 wrote:




 indeed. i wouldnt mind if final was the default in java :)

 -igor

 On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst
 [EMAIL PROTECTED] wrote:




 Without the use of final wicket would not have made it this far.

 Martijn

 On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin [EMAIL PROTECTED]
 wrote:




 I understand the reasoning, however I think best practice can be
 debated.
 To use your example Swing allows the user to override quite a bit,
 and
 it
 doesn't make any (or very few) assumptions on what should and
 should
 not be
 done.

 I don't like API's that assume I'm an idiot and prevent me from
 manipulating
 them how I see fit. If I cause a bug that I have to deal with,
 thats
 *my*
 problem to resolve.

 In my book (and I'm not the only one) excessive use of final is an
 anti-pattern.

 - Brill Pappin

 On 12-Jun-08, at 10:01 AM, cowwoc wrote:





 Brill,

 This is actually an API best practice. Classes fall into two
 categories:
 ones designed for subclassing, and ones designed to be final. The
 same
 goes
 for methods. Swing is full of examples of what goes wrong when
 people
 override methods in classes that haven't been designed with
 subclassing in
 mind.

 Gili


 Brill Pappin wrote:




 on removing the finals

 The final members are the worst thing I've had to deal with in
 Wicket
 so far.
 Although I understand that there may be a reason for them, they
 are
 more a hinderance than anything else and seem to be trying to
 protect
 users from themselves.

 - Brill Pappin


 On 12-Jun-08, at 1:03 AM, cowwoc wrote:





 Have you considered moving from subclassing to composition in
 Wicket
 using
 CallableT?

 Currently it is quite common for developers to 

Re: Making Component easier to Generify

2008-06-12 Thread Igor Vaynberg
looked over the article. what they do is a ui decorator, it is not the
software decorator pattern. there is no method delegation to the child
component. what they create is a composite, you can do the same thing
in wicket with a Border.

-igor

On Thu, Jun 12, 2008 at 9:55 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
 right. so when you would do it with a class you will actually have to
 rewire all the methods to forward to the delegate instead of calling
 super. that is pure insanity and does not make any sense when methods
 hold logic. that is why it works with an interface, no logic for you
 to override and forward to the delegate, only the message dispatch
 itself. sure, technically you can do it even with a concrete class,
 but you can also do a lot of other things that dont make sense.

 -igor

 On Thu, Jun 12, 2008 at 5:54 PM, Matthijs Wensveen [EMAIL PROTECTED] wrote:
 Igor Vaynberg wrote:

 look at the java example. notice Window is an interface.


 Yeah, but that's just because it's good practice to use the interface when
 there is one. Notice that the actually decorated class is a new
 SimpleWindow() in DecoratedWindowTest. Window might as well have been an
 abstract class, or even a concrete one. The idea is that the contract of the
 class you wrap is maintained, if that is an interface your decorator
 implements that, when it's a class your decorator extends it. Same idea. Of
 course, interfaces are cleaner and you can even decorate more then one
 interface when you want to, but decorating a class is not uncommon practice
 (at least where I come from).

 Example: http://www.onjava.com/pub/a/onjava/2003/02/05/decorator.html

 eg you cant do: add(new DecoratedComponent(someOtherComponent));


 No, because component has final methods that you can't override so you can't
 delegate to them (that whas my point), but not because you can't decorate a
 class.

 Matthijs.

 PS. If you insist on that you can only decorate an interface, I'll call it
 wrap-extend or something :)

 -igor

 On Thu, Jun 12, 2008 at 5:05 PM, Matthijs Wensveen [EMAIL PROTECTED]
 wrote:


 Why would the decorator design pattern only work with interfaces? Maybe
 we're talking about two different this here? (I'm talking about this one:
 http://en.wikipedia.org/wiki/Decorator_pattern)

 I can see why behaviors were introduced. A simple example: a factory
 method
 creates a link. In my subclass I want the same link with the same onClick
 behavior but I also want hello to be outputted to System.out. How would
 I
 go about doing this with a Behavior? I couldn't figure it out... (which
 isn't saying it's impossible).

 Matthijs

 [EMAIL PROTECTED] wrote:


 decorators only work with interfaces, component class is not. This is
 part of the reason why we have behaviors

 -igor

 On 6/12/08, Matthijs Wensveen [EMAIL PROTECTED] wrote:



 Some useful design patterns like Decorator don't work with final
 methods. Wicket components sometimes have overridable factory methods
 for child components. The decorator pattern could be very useful here,
 because you'd be able to decorate the original component with some
 extra
 functionality (Link.onClick for example). Unfortunately this doesn't
 work because some methods are final.

 Matthijs

 Igor Vaynberg wrote:



 i mean generally, for methods, fields, and func args :) most of this
 stuff can stay final, but people dont bother doing it because its
 extra typing.

 -igor

 On Thu, Jun 12, 2008 at 8:38 AM, James Carman
 [EMAIL PROTECTED] wrote:




 You mean like C++?

 On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg
 [EMAIL PROTECTED]
 wrote:




 indeed. i wouldnt mind if final was the default in java :)

 -igor

 On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst
 [EMAIL PROTECTED] wrote:




 Without the use of final wicket would not have made it this far.

 Martijn

 On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin [EMAIL PROTECTED]
 wrote:




 I understand the reasoning, however I think best practice can be
 debated.
 To use your example Swing allows the user to override quite a bit,
 and
 it
 doesn't make any (or very few) assumptions on what should and
 should
 not be
 done.

 I don't like API's that assume I'm an idiot and prevent me from
 manipulating
 them how I see fit. If I cause a bug that I have to deal with,
 thats
 *my*
 problem to resolve.

 In my book (and I'm not the only one) excessive use of final is an
 anti-pattern.

 - Brill Pappin

 On 12-Jun-08, at 10:01 AM, cowwoc wrote:





 Brill,

 This is actually an API best practice. Classes fall into two
 categories:
 ones designed for subclassing, and ones designed to be final. The
 same
 goes
 for methods. Swing is full of examples of what goes wrong when
 people
 override methods in classes that haven't been designed with
 subclassing in
 mind.

 Gili


 Brill Pappin wrote:




 on removing the finals

 The final members are the worst thing I've had to deal with in
 Wicket
 so far.
 Although I understand that there may be a