Re: Fix inconsistent naming for submit components

2007-06-17 Thread Al Maw
Frank Bille wrote: Hey We could also rename AjaxSubmitButton into AjaxButton. Then we have: Button, ImageButton and AjaxButton (and AjaxFallbackButton) and SubmitLink and AjaxSubmitLink Hmmm, that would be LinkButton and AjaxLinkButton, surely? :-) [Ajax[Fallback]]Submit[Foo] is the only t

Re: Fix inconsistent naming for submit components

2007-06-17 Thread Frank Bille
Hey We could also rename AjaxSubmitButton into AjaxButton. Then we have: Button, ImageButton and AjaxButton (and AjaxFallbackButton) and SubmitLink and AjaxSubmitLink I don't know whats best, yet. It's just a surgestion now that we play with names :) Frank On 6/18/07, Al Maw <[EMAIL PROTEC

Re: Fix inconsistent naming for submit components

2007-06-17 Thread Timo Rantalaiho
On Mon, 18 Jun 2007, Al Maw wrote: > It would make sense for me for everything to be based on the word > "Submit", so I think we should rename: Anyway there is IFormSubmittingComponent that is implemented by all of those, so I don't think there is a big problem. A type is always better than a

Fix inconsistent naming for submit components

2007-06-17 Thread Al Maw
Hello, I know we're in a feature freeze, and I'm aware this one is likely to be somewhat controversial, but I think we should rename a couple of the submit components, leaving behind @deprecated classes which extend the renamed ones. We currently have: Button, ImageButton, SubmitLink, AjaxS

Re: Example for Border use wrong in wiki...

2007-06-17 Thread Eelco Hillenius
In the case I was wanting to work with markup inheritance didn't really work right as I wanted to change the used border on the fly, in the end I just used object inheritance having the subclassed pages to call "border.add()" rather than add() directory (with the border defined/added by the base c

Re: Example for Border use wrong in wiki...

2007-06-17 Thread Mark Derricutt
On 6/18/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: Not so sure what to do with this. I think we should regard such use of borders as outdated, and that for such templating markup inheritance should be used. In the case I was wanting to work with markup inheritance didn't really work righ

Re: Example for Border use wrong in wiki...

2007-06-17 Thread Eelco Hillenius
On 6/8/07, Mark Derricutt <[EMAIL PROTECTED]> wrote: Hey all, Hey Mark, Just catching up on my wicket-foo and noticed that the wiki page on using borders is invalid for 1.3 as the add/removeAll/replace/autoAdd methods are all final. http://cwiki.apache.org/WICKET/consistent-page-layout-usin

Re: private inner class of compoundpropertymodel

2007-06-17 Thread Maurice Marrink
Ok. Maurice On 6/17/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > That is exactly what i am doing right now. And i have no problem if it > has to stay that way. However I thought i might be helpful for > everyone extending CompoundPropertyModel, and given the fact that none > of the methods

Re: private inner class of compoundpropertymodel

2007-06-17 Thread Eelco Hillenius
That is exactly what i am doing right now. And i have no problem if it has to stay that way. However I thought i might be helpful for everyone extending CompoundPropertyModel, and given the fact that none of the methods in AttachedCompoundPropertyModel are final or otherwise protected against over

Re: private inner class of compoundpropertymodel

2007-06-17 Thread Maurice Marrink
That is exactly what i am doing right now. And i have no problem if it has to stay that way. However I thought i might be helpful for everyone extending CompoundPropertyModel, and given the fact that none of the methods in AttachedCompoundPropertyModel are final or otherwise protected against over

Re: please help with finding and fixing stale documentation

2007-06-17 Thread Eelco Hillenius
Thanks, Eelco On 6/11/07, Remco Bos <[EMAIL PROTECTED]> wrote: Things like this? In Component.java, under "Hierarchy": "The [EMAIL PROTECTED] Component#isAncestorOf(Component)} method returns true if this Component is an ancestor of the given Component." "isAncestorOf" is deprecated now (

Re: private inner class of compoundpropertymodel

2007-06-17 Thread Eelco Hillenius
Can't you just create your own version of AttachedCompoundPropertyModel (you are after all thinking about extending it, and there isn't so much going on in that class) and overriding wrapOnInheritance and return an instance of your class? Eelco On 6/17/07, Maurice Marrink <[EMAIL PROTECTED]> wr

private inner class of compoundpropertymodel

2007-06-17 Thread Maurice Marrink
Hi, I am in the process of extending CompoundPropertyModel and its inner class AttachedCompoundPropertyModel. However since the last is a private inner class i am forced to copy the class definition in to my own creating some code duplication. In order to prevent this duplication it would be helpf

Re: A new proposal for Wicket Portlet support

2007-06-17 Thread Eelco Hillenius
Great news Ate! It would be interesting to read the experiences of those who have been playing with it in this thread. Is anyone considering using this for their projects yet? Cheers, Eelco On 6/14/07, Ate Douma <[EMAIL PROTECTED]> wrote: As promised a few weeks ago, I've created a separate