Re: Add Any option to DropDownChoice

2010-07-08 Thread Sven Meier

Actually it works without a null in your choices.

Sven
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Add-Any-option-to-DropDownChoice-tp2281498p2281887.html
Sent from the Wicket - User mailing list archive at Nabble.com.

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



Re: localize options DropDownChoice

2010-07-08 Thread Sven Meier

By default option values are indexed based and not part of
internationalization. Use IChoiceRenderer#getIdValue().

Sven
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/localize-options-DropDownChoice-tp2281778p2281892.html
Sent from the Wicket - User mailing list archive at Nabble.com.

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



SV: Internationalizing a DDC

2010-07-08 Thread Wilhelmsen Tor Iver
 option value=0Day/option
 option value=1Week /option
 option value=2Fortnight/option
 option value=3Month/option
 option value=4Year/option

If you really want to hardcode the options in the HTML like that, remember not 
to use DropDownChoice which will replace the markup, but make your own 
FormComponent subclass that preserves the entire markup. In this case, you 
could try

option value=0wicket:message key=period.1Day/wicket:message/option

But the DropDownChoice + ChoiceRenderer is a better option, even if the option 
list is static. In that case you just call getString(period.+idvalue) in 
getDisplayValue()

- Tor Iver

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



SV: Configuration Q re Maven Profiles and Start

2010-07-08 Thread Wilhelmsen Tor Iver
 Something like run org.mypackage.Start ?

http://mojo.codehaus.org/exec-maven-plugin/

mvn -Pwhatever -DmainClass=org.mypackage.Start exec:java 

- Tor Iver

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



AW: AW: Serialization of injected EJBs

2010-07-08 Thread Harald Wellmann
Yes, @EJB is still available, and it is still required in some cases. But the 
general approach to injection has changed with CDI. See 
http://seamframework.org/Community/InjectingWithEJBOrInject for a discussion.

My original question is about how to use Wicket with CDI (injecting EJBs and 
other beans), and your suggestion is not to use CDI, which does not really 
solve the problem...

By the way, the nice thing about @Inject is that you no longer have to use JNDI 
lookups or bean names in @EJB annotations.

And the specific problem is NOT that @Inject does not not work for EJBs, but 
the injected proxies fail to serialize properly.

If I understand the javaee-inject implementation correctly, it takes care not 
to serialize proxies but replaces them by references on serialization, looking 
up the same reference again on deserialization.

I suppose my problem would be solved if the CDI InjectionTarget were using this 
approach, but this is a CDI implementation detail and out of my control.

Anybody else out there using Wicket+CDI+EJB? Have you come across similar 
problems?

Best regards,

Harald

-Ursprüngliche Nachricht-
Von: Major Péter [mailto:majorpe...@sch.bme.hu] 
Gesendet: Mittwoch, 7. Juli 2010 19:43
An: users@wicket.apache.org
Betreff: Re: AW: Serialization of injected EJBs

Nope, it does not support CDI. AFAIK @EJB is not deprecated or
old-style, and it's still available in Java EE 6. The thread was about
injecting EJB's and JavaEE Inject does exactly that.
You can always use lookups for your beans/CDI stuff...

Regards,
Peter

2010-07-07 19:34 keltezéssel, Harald Wellmann írta:
 Does javaee-inject support CDI at all? I cannot find any @Inject annotations 
 in the examples you mentioned, they all seem to be in Java EE 5 style, not 
 Java EE 6.
 
 Regards,
 
 Harald

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



Re: ListView in a Form -- issue with properties

2010-07-08 Thread always_rick

hi, just add the form wicket id in property file.

e.g.
wicket:id=xxxForm
-wicket:id=valueListView
 -wicket:id=value

xxxForm.valueListView.value.Required=please enter the value




Trevor Baker-2 wrote:
 
 Hi,
 
 I have a form that has an ListView (wicket:id=”valueListView”) of a bunch
 of
 required text fields (wicket:id=”value”).
 
 In my WebApplication.properties, I have:
 
 form.valueListView.value.Required=Please enter the Value
 
 However when I submit the form, in my error feedback if the field is blank
 it always displays the default: Field 'value is required.
 
 What is the proper way to write the property so it displays my custom
 error
 feedback message?
 
 Thanks,
 Trev
 
 

-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/ListView-in-a-Form-issue-with-properties-tp2281199p2282008.html
Sent from the Wicket - User mailing list archive at Nabble.com.

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



RE: Single inheritence in parts

2010-07-08 Thread Chris Colman
This issue has come up many, many times before:

http://www.mail-archive.com/users@wicket.apache.org/msg06381.html
http://www.mail-archive.com/wicket-u...@lists.sourceforge.net/msg26247.h
tml

Unfortunately some people try to convince the group that proposals like
the one you have presented here are not in line with Java's 'single
inheritance' model and therefore must be 'multiple inheritance' but they
are clearly not understanding the issue properly. 

What you are suggesting here is not 'the horror of multiple
inheritance'. 

It is simply single inheritance with 'multiple overridable markup
sections' and therefore would IMHO be an excellent enhancement to
Wicket. Stefan and I were discussing multiple options more than a year
ago and Stefan even went to the effort of creating a Wicket patch that
implemented support for overriding multiple sections but I'm pretty sure
it hasn't yet been added to SVN.

Stefan raised a feature request for this in JIRA:

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

The only thing extra that we discussed that you have not included in
your sample is that when we move from ONE overridable markup section to
MULTIPLE overridable sections (but still only a single super
class/markup!) we need to introduce and a way of identifying each
section (which obviously isn't required when you limit the number of
overridable sections to 1.

The great thing about identifying which section you are overriding is
that you can pick and choose which sections you override and which you
just 'default' to the markup of the super class/markup file.

I'm actually thinking that using specific wicket:extend and
wicket:child is a big hinderance to chaining in a hierarchy because
you have a different tag depending on whether you are providing a
'markup section' to be overridden or whether you are overriding a
'markup section'. This gets awkward and clumsy when it comes to flexible
'chaining' down an inheritance hierarchy and Java has no such
equivalent. We could probably have a single tag to be used consistently
in super or subclass to allow very simple syntax that supports fluid
inheritance down a markup hierarchy:

wicket:namedsection id=header (or whatever) 

Overriding is then optional: absence of a named section in a subclass
markup simply means that the markup from the closest superclass markup
should be used.

I really hope this gets implemented soon. The 'workaround' that is often
suggested is a 'component based' workaround rather than a truly object
oriented approach that allows multiple sections to be overridden. As a
hard line OOer that doesn't quite cut it.

I have even gone to the extent of creating a special markup preparser
that lets me write markup with multiple overridable sections which are
then compiled to 'flattened' markup for Wicket to process at run time.
It works extremely well and satisfies my needs but it would be nicer if
it was supported natively in Wicket.

-Original Message-
From: Arjun Dhar [mailto:dhar...@yahoo.com]
Sent: Monday, 5 July 2010 3:40 PM
To: users@wicket.apache.org
Subject: Single inheritence in parts


Hi,
 all the examples etc suggest that Single inheritence is possible but I
cant
break it up. The break up is essential when you want to merge common
parts
of your MARKUP with multiple specific parts of the Child page.

Example:


HTML
HEADtitleBASE TEMPLATE / PARENT PAGE/title/HEAD

BODY
   wicket:child /
   br /
   h2Some other Html common/h2
   wicket:child /
/BODY
/HTML


---

HTML
HEADtitleCHILD PAGE 1/title/HEAD

BODY
   wicket:extend
Part 1 specific to Child Page
/wicket:extend
Any HTML here can be ignored as conceptually anyway what
appears in
extend is what should be rendered from a child page.
   wicket:extend
Part 2 Specific to Child Page (will appear after
common
HTML in parent page)
/wicket:extend
/BODY
/HTML


I tried this, only the first part renders. I'm wondering if we can add
such
capability. Conceptually I don't see why not. If already possible do
let me
know or consider as a feature request?!

-Thanks Arjun
--
View this message in context: http://apache-
wicket.1842946.n4.nabble.com/Single-inheritence-in-parts-
tp2278064p2278064.html
Sent from the Wicket - User mailing list archive at Nabble.com.

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


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



RE: Single inheritence in parts

2010-07-08 Thread Chris Colman
Search the list for this and you'll find some quite long discussions.
Basically, it's not going to happen. This would be multiple
inheritance,
not single.
 
Hi Jeremy, I hope I don't sound confrontationalist when I say this but
this is clearly not a case of multiple inheritance.

For this request to be deemed to be multiple inheritance one
class/markup file would need to be inheriting from two separate super
classes/markup files. That is not what is requested here. There remains
only a single super class/markup file.

All that is requested here is for multiple markup sections to be
overridden in this single inheritance scenario - just like Java does not
restrict you to overriding only a single method in any Java class: You
can override as many methods as you like in a Java class but that does
not break Java's single inheritance model - which constrains the number
of base classes to ONE, not the number of methods you can override to
ONE.

All this user (and others before him) are asking is for wicket to
support the overriding of N markup sections without instead of the
arbitrarily imposed constraint of N = 1.


Jeremy Thomerson
-- sent from my smartphone - please excuse formatting and spelling
errors

On Jul 5, 2010 12:41 AM, Arjun Dhar dhar...@yahoo.com wrote:


Hi,
 all the examples etc suggest that Single inheritence is possible but I
cant
break it up. The break up is essential when you want to merge common
parts
of your MARKUP with multiple specific parts of the Child page.

Example:


HTML
HEADtitleBASE TEMPLATE / PARENT PAGE/title/HEAD

BODY
   wicket:child /
   br /
   h2Some other Html common/h2
   wicket:child /
/BODY
/HTML


---

HTML
HEADtitleCHILD PAGE 1/title/HEAD

BODY
   wicket:extend
   Part 1 specific to Child Page
   /wicket:extend
   Any HTML here can be ignored as conceptually anyway what appears
in
extend is what should be rendered from a child page.
   wicket:extend
   Part 2 Specific to Child Page (will appear after
common
HTML in parent page)
   /wicket:extend
/BODY
/HTML


I tried this, only the first part renders. I'm wondering if we can add
such
capability. Conceptually I don't see why not. If already possible do
let me
know or consider as a feature request?!

-Thanks Arjun
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Single-inheritence-in-parts-
tp2278064p2278064.html
Sent from the Wicket - User mailing list archive at Nabble.com.

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

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



Clash between AutoComplete request and Form submit request

2010-07-08 Thread Florian Wunderlich

Hi,

suppose there is a TextField with an AutoCompleteBehavior in a Form.

Pressing a key will create an Ajax RequestCycle to process the key, and 
will finally invoke RequestCycle.detach(), which will invoke 
WebSession.cleanupFeedbackMessages().


Pressing enter will create a normal RequestCycle to process the form, 
which will also invoke RequestCycle.detach(), and then 
WebSession.cleanupFeedbackMessages().



Now suppose there are other FormComponents in this Form, some taking a 
few ms to validate, and suppose the first field generated a FeedbackMessage.


It is obvious that now, there will be two threads running concurrently, 
one processing the Ajax RequestCycle (A), and one processing the Form 
submit RequestCycle (B).


While the second thread B is still processing the Form, the first thread 
A already finished and cleans up the FeedbackMessages - which the second 
thread B that added them didn't even have a chance to render yet!



This can be easily provoked if the text field is set as required, by 
entering a single character in the empty TextField, pressing Backspace 
and immediately Enter to submit the Form. This scenario should be quite 
common.


The result is that there are no feedback messages shown to the user, but 
in development mode the usual message that a Component-targetted 
feedback message was left unrendered is logged.



I have worked around this problem by using

  if (request.isAjax())
setAutomaticallyClearFeedbackMessages(false);

in a custom RequestCycle constructor.


If this is indeed as I suspect a bug in Wicket, I will file a bug for it.


It seems to me that it is wrong in any case that a RequestCycle cleans 
the FeedbackMessages from another RequestCycle.


In Session, there is documentation referring to flash messages, which 
I suppose is what feedback messages were called previously, and there is 
mention that these must persist across RequestCycles under some 
circumstances - which seems correct considering the condition in 
WebSession.cleanupFeedbackMessages().


Thus, direcly associating FeedbackMessages with a RequestCycle is not 
possible. But it should at least be possible to note which RequestCycle 
generated which FeedbackMessage, and then clean only those 
FeedbackMessages owned by the RequestCycle in the normal case, and only 
clean these persistent FeedbackMessages where necessary.



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



String not serializable exception coming for interned strings from Model with JRockit/Weblogic

2010-07-08 Thread Janos Cserep
Hi,

The following seems to be a bug with JRockit or Weblogic, but maybe
someone on this list has seen it before and has a better
workaround/solution.

We have been developing a Wicket application for a government agency
that is going to be used by 15k users. The application will be
deployed on a Weblogic cluster running on JRockit and Red Hat.

We have been experiencing strange Model object not serializable
exceptions coming from Model and traced it back to interned (by the
compiler) String  objects becoming not serializable after hitting the
server with a few hundred parallel users. Once the exception occurs
for a given String reference it keeps coming consistently for that
reference.

The current workaround is a custom Model class that has an overrided
setObject method which checks the object if it's instanceof
Serializable and if the check fails it sets new String(object) on the
Model. This eliminates the exceptions but would like a better solution
to the problem.

Has anyone seen anything like this?

Thanks and regards,

Janos

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



org.apache.wicket.WicketRuntimeException: Submit Button ... is not visible

2010-07-08 Thread Conny Kühne

I have an AjaxButton with

@Override
public boolean isVisible() {
  return  someFlag;
}

In a race condition, if user B sets someFlag to false, and then user A
clicks the button A gets the following exception

org.apache.wicket.WicketRuntimeException: Submit Button buttonName ... is
not visible

Any ideas how to circumvent this?

Conny

-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/org-apache-wicket-WicketRuntimeException-Submit-Button-is-not-visible-tp2282413p2282413.html
Sent from the Wicket - User mailing list archive at Nabble.com.

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



Using absolute URLs in Ajax-Forms, -buttons and -links

2010-07-08 Thread heapifyman

Hello all,

I'm trying to kind of embed a wicket app into another web page, meaning
that the wicket pages are included as part of the other web page. All
submits, links, buttons in the wicket pages are realised using wicket's
ajax features.

Unfortunately, the wicketSubmitFormById call in an Ajax form submit is
using a relative URL, like in the following example:

input id=compose74 type=submit value=Submit name=compose
onclick=wicketShow('compose74--ajax-indicator');var
wcall=wicketSubmitFormById('form77',
'?wicket:interface=:8:contentDiv:contentPanel:form:compose::IActivePageBehaviorListener:0:-1amp;wicket:ignoreIfNotActive=true',
'compose' ,function() {
;wicketHide('compose74--ajax-indicator');}.bind(this),function() {
;wicketHide('compose74--ajax-indicator');}.bind(this), function()
{return Wicket.$$(this)amp;amp;Wicket.$$('form77')}.bind(this));;;
return false;

This call fails of course if the wicket page is embedded into the
other web page. So, my question would be: is there a way to tell wicket
to use an absolute URL in this call to wicketSubmitFormById?

Thanks in advance,
Philip



signature.asc
Description: OpenPGP digital signature


Wicket wicket-contrib-tinymce populate Styles drop-down

2010-07-08 Thread Peter Miklosko
Can somebody please help me populate drop down menu for Styles?
Customer  decided to use this option and I have difficulties to figure out how 
to  do it.
Even in the wicket-contrib-tinymce examples this is not active.

Peter



  

Re: org.apache.wicket.WicketRuntimeException: Submit Button ... is not visible

2010-07-08 Thread vov

Hi!
It is not a best solutions but you can try it

ajaxButton.add(new AjaxSelfUpdatingTimerBehavior(Duration.milliseconds(1)));
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/org-apache-wicket-WicketRuntimeException-Submit-Button-is-not-visible-tp2282413p2282506.html
Sent from the Wicket - User mailing list archive at Nabble.com.

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



Re: org.apache.wicket.WicketRuntimeException: Submit Button ... is not visible

2010-07-08 Thread Pedro Santos
someFlag is an static variable?

2010/7/8 Conny Kühne conny.kue...@gmail.com


 I have an AjaxButton with

 @Override
 public boolean isVisible() {
  return  someFlag;
 }

 In a race condition, if user B sets someFlag to false, and then user A
 clicks the button A gets the following exception

 org.apache.wicket.WicketRuntimeException: Submit Button buttonName ... is
 not visible

 Any ideas how to circumvent this?

 Conny

 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/org-apache-wicket-WicketRuntimeException-Submit-Button-is-not-visible-tp2282413p2282413.html
 Sent from the Wicket - User mailing list archive at Nabble.com.

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




-- 
Pedro Henrique Oliveira dos Santos


Re: org.apache.wicket.WicketRuntimeException: Submit Button ... is not visible

2010-07-08 Thread Sven Meier

new AjaxButton() {
  private boolean available;

  onBeforeRender() {
available = someFlag();
 }

  isVisible() {
return available;
  }

  onSubmit() {
if (!available) {
  error(no longer available);
}
  }
}

Sven

On 07/08/2010 04:48 PM, Conny Kühne wrote:

I have an AjaxButton with

@Override
public boolean isVisible() {
   return  someFlag;
}

In a race condition, if user B sets someFlag to false, and then user A
clicks the button A gets the following exception

org.apache.wicket.WicketRuntimeException: Submit Button buttonName ... is
not visible

Any ideas how to circumvent this?

Conny

   



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



Re: org.apache.wicket.WicketRuntimeException: Submit Button ... is not visible

2010-07-08 Thread Conny Kühne

Thanks. That would have solved it. I am using setVisible(someFlag) now. Doh!
;)
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/org-apache-wicket-WicketRuntimeException-Submit-Button-is-not-visible-tp2282413p2282534.html
Sent from the Wicket - User mailing list archive at Nabble.com.

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



Re: org.apache.wicket.WicketRuntimeException: Submit Button ... is not visible

2010-07-08 Thread vov

But question is still open:)

Look to example

public static boolean visibleFlag = true;

  public VisibilityButtonTest()
  {
FormVoid form = new FormVoid(form);
add(form);
AjaxButton ajaxButton = new AjaxButton(button1)
{
  @Override
  public boolean isVisible()
  {
return visibleFlag;
  }

  @Override
  protected void onSubmit(AjaxRequestTarget target, Form? form)
  {
// do nothing
  }
};
form.add(ajaxButton);
form.add(new AjaxButton(button2)
{
  @Override
  protected void onSubmit(AjaxRequestTarget target, Form? form)
  {
visibleFlag = false;
  }
});
  }

after open this page press to button2 and after to button1
-- 
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/org-apache-wicket-WicketRuntimeException-Submit-Button-is-not-visible-tp2282413p2282540.html
Sent from the Wicket - User mailing list archive at Nabble.com.

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



Re: Single inheritence in parts

2010-07-08 Thread Ben Tilford
class Page extends  Page {

abstract Component getPart1();
abstract Component getPart2();
}

html

div wicket:id=id4part1 /
wicket:child /
div wicket:id=id4part2 /

On Thu, Jul 8, 2010 at 5:49 AM, Chris Colman
chr...@stepaheadsoftware.comwrote:

 Search the list for this and you'll find some quite long discussions.
 Basically, it's not going to happen. This would be multiple
 inheritance,
 not single.

 Hi Jeremy, I hope I don't sound confrontationalist when I say this but
 this is clearly not a case of multiple inheritance.

 For this request to be deemed to be multiple inheritance one
 class/markup file would need to be inheriting from two separate super
 classes/markup files. That is not what is requested here. There remains
 only a single super class/markup file.

 All that is requested here is for multiple markup sections to be
 overridden in this single inheritance scenario - just like Java does not
 restrict you to overriding only a single method in any Java class: You
 can override as many methods as you like in a Java class but that does
 not break Java's single inheritance model - which constrains the number
 of base classes to ONE, not the number of methods you can override to
 ONE.

 All this user (and others before him) are asking is for wicket to
 support the overriding of N markup sections without instead of the
 arbitrarily imposed constraint of N = 1.

 
 Jeremy Thomerson
 -- sent from my smartphone - please excuse formatting and spelling
 errors
 
 On Jul 5, 2010 12:41 AM, Arjun Dhar dhar...@yahoo.com wrote:
 
 
 Hi,
  all the examples etc suggest that Single inheritence is possible but I
 cant
 break it up. The break up is essential when you want to merge common
 parts
 of your MARKUP with multiple specific parts of the Child page.
 
 Example:
 
 
 HTML
 HEADtitleBASE TEMPLATE / PARENT PAGE/title/HEAD
 
 BODY
wicket:child /
br /
h2Some other Html common/h2
wicket:child /
 /BODY
 /HTML
 
 
 ---
 
 HTML
 HEADtitleCHILD PAGE 1/title/HEAD
 
 BODY
wicket:extend
Part 1 specific to Child Page
/wicket:extend
Any HTML here can be ignored as conceptually anyway what appears
 in
 extend is what should be rendered from a child page.
wicket:extend
Part 2 Specific to Child Page (will appear after
 common
 HTML in parent page)
/wicket:extend
 /BODY
 /HTML
 
 
 I tried this, only the first part renders. I'm wondering if we can add
 such
 capability. Conceptually I don't see why not. If already possible do
 let me
 know or consider as a feature request?!
 
 -Thanks Arjun
 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Single-inheritence-in-parts-
 tp2278064p2278064.html
 Sent from the Wicket - User mailing list archive at Nabble.com.
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org

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




AW: AW: Serialization of injected EJBs

2010-07-08 Thread Harald Wellmann
In theory, yes...

The proxies returned by Weld 1.0.1.SP3 (the version used in Glassfish 3.0.1) 
are serializable, but after serializing and deserializing the proxy, the method 
handler is broken and you get a null pointer exception when invoking any method 
of the proxy. i verified this in a simple test case, independent of Wicket. 
This looks like the problem fixed in https://jira.jboss.org/browse/JASSIST-97, 
though I'm not fully sure that this is exactly the same issue.

Anyway, I patched my Glassfish version with the most recent release of 
Javassist containing the bugfix. With this fix, I already get a 
NotSerializableException from Wicket when the current page is about to be moved 
to the page store:

   protected java.lang.reflect.InvocationHandler java.lang.reflect.Proxy.h 
[class=com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate] - 
field that is not serializable

It seems that the stateless session bean implementation is wrapped in at least 
two proxies, one generated by Glassfish (for getting the session bean into the 
CDI context, equivalent to @EJB injection) and another one, generated by Weld 
using Javassist, filling the @Inject injection point in my Wicket component. 
The outer proxy is ok with the newer Javassist version, but the inner proxy 
simply is not serializable because of EJBLocalObjectInvocationHandlerDelegate.

Using @EJB instead of @Inject, I just get the inner proxy, with the same 
problem caused by EJBLocalObjectInvocationHandlerDelegate.

So my impression is that Glassfish simply breaks the contract of my 
serializable session bean interface. On the other hand, I wouldn't be surprised 
if there was a paragraph somewhere in the Java EE specs stating that EJBs shall 
not be serialized by the application (i.e. Wicket) because the container takes 
care of passivation anyway...

Has anybody tried Wicket+CDI+EJB on other app servers? (There aren't so many 
supporting Java EE 6)

Regards,
Harald



Von: Igor Vaynberg [igor.vaynb...@gmail.com]
Gesendet: Donnerstag, 8. Juli 2010 17:54
An: users@wicket.apache.org
Betreff: Re: AW: Serialization of injected EJBs

im not sure if this is in a CDI spec or not, but afaik Weld will
return serializable proxies when you manually inject objects. so that
should work out of the box.

-igor


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



RE: Single inheritence in parts

2010-07-08 Thread Chris Colman
class Page extends  Page {

abstract Component getPart1();
abstract Component getPart2();
}

html

div wicket:id=id4part1 /
wicket:child /
div wicket:id=id4part2 /

That's the component based workaround that I mentioned which IMHO isn't
really the pure markup OO solution we're proposing. I'm hoping for true
markup inheritance that supports multiple overridable sections that
doesn't mandate a Java side coding change each time a markup editor adds
or removes a particular overridable section. 


On Thu, Jul 8, 2010 at 5:49 AM, Chris Colman
chr...@stepaheadsoftware.comwrote:

 Search the list for this and you'll find some quite long
discussions.
 Basically, it's not going to happen. This would be multiple
 inheritance,
 not single.

 Hi Jeremy, I hope I don't sound confrontationalist when I say this
but
 this is clearly not a case of multiple inheritance.

 For this request to be deemed to be multiple inheritance one
 class/markup file would need to be inheriting from two separate super
 classes/markup files. That is not what is requested here. There
remains
 only a single super class/markup file.

 All that is requested here is for multiple markup sections to be
 overridden in this single inheritance scenario - just like Java does
not
 restrict you to overriding only a single method in any Java class:
You
 can override as many methods as you like in a Java class but that
does
 not break Java's single inheritance model - which constrains the
number
 of base classes to ONE, not the number of methods you can override to
 ONE.

 All this user (and others before him) are asking is for wicket to
 support the overriding of N markup sections without instead of the
 arbitrarily imposed constraint of N = 1.

 
 Jeremy Thomerson
 -- sent from my smartphone - please excuse formatting and spelling
 errors
 
 On Jul 5, 2010 12:41 AM, Arjun Dhar dhar...@yahoo.com wrote:
 
 
 Hi,
  all the examples etc suggest that Single inheritence is possible
but I
 cant
 break it up. The break up is essential when you want to merge common
 parts
 of your MARKUP with multiple specific parts of the Child page.
 
 Example:
 
 
 HTML
 HEADtitleBASE TEMPLATE / PARENT PAGE/title/HEAD
 
 BODY
wicket:child /
br /
h2Some other Html common/h2
wicket:child /
 /BODY
 /HTML
 
 
 ---
 
 HTML
 HEADtitleCHILD PAGE 1/title/HEAD
 
 BODY
wicket:extend
Part 1 specific to Child Page
/wicket:extend
Any HTML here can be ignored as conceptually anyway what
appears
 in
 extend is what should be rendered from a child page.
wicket:extend
Part 2 Specific to Child Page (will appear after
 common
 HTML in parent page)
/wicket:extend
 /BODY
 /HTML
 
 
 I tried this, only the first part renders. I'm wondering if we can
add
 such
 capability. Conceptually I don't see why not. If already possible do
 let me
 know or consider as a feature request?!
 
 -Thanks Arjun
 --
 View this message in context:

http://apache-wicket.1842946.n4.nabble.com/Single-inheritence-in-parts-
 tp2278064p2278064.html
 Sent from the Wicket - User mailing list archive at Nabble.com.
 

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

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



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



Re: AW: Serialization of injected EJBs

2010-07-08 Thread Igor Vaynberg
hrm, if thats the case you can always use wicket-ioc module to build
the proxy yourself just like we do for spring and guice, it should
only be a couple of hours effort.

-igor

On Thu, Jul 8, 2010 at 10:34 AM, Harald Wellmann
harald.wellm...@multi-m.de wrote:
 In theory, yes...

 The proxies returned by Weld 1.0.1.SP3 (the version used in Glassfish 3.0.1) 
 are serializable, but after serializing and deserializing the proxy, the 
 method handler is broken and you get a null pointer exception when invoking 
 any method of the proxy. i verified this in a simple test case, independent 
 of Wicket. This looks like the problem fixed in 
 https://jira.jboss.org/browse/JASSIST-97, though I'm not fully sure that this 
 is exactly the same issue.

 Anyway, I patched my Glassfish version with the most recent release of 
 Javassist containing the bugfix. With this fix, I already get a 
 NotSerializableException from Wicket when the current page is about to be 
 moved to the page store:

   protected java.lang.reflect.InvocationHandler java.lang.reflect.Proxy.h 
 [class=com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate] - 
 field that is not serializable

 It seems that the stateless session bean implementation is wrapped in at 
 least two proxies, one generated by Glassfish (for getting the session bean 
 into the CDI context, equivalent to @EJB injection) and another one, 
 generated by Weld using Javassist, filling the @Inject injection point in my 
 Wicket component. The outer proxy is ok with the newer Javassist version, but 
 the inner proxy simply is not serializable because of 
 EJBLocalObjectInvocationHandlerDelegate.

 Using @EJB instead of @Inject, I just get the inner proxy, with the same 
 problem caused by EJBLocalObjectInvocationHandlerDelegate.

 So my impression is that Glassfish simply breaks the contract of my 
 serializable session bean interface. On the other hand, I wouldn't be 
 surprised if there was a paragraph somewhere in the Java EE specs stating 
 that EJBs shall not be serialized by the application (i.e. Wicket) because 
 the container takes care of passivation anyway...

 Has anybody tried Wicket+CDI+EJB on other app servers? (There aren't so many 
 supporting Java EE 6)

 Regards,
 Harald


 
 Von: Igor Vaynberg [igor.vaynb...@gmail.com]
 Gesendet: Donnerstag, 8. Juli 2010 17:54
 An: users@wicket.apache.org
 Betreff: Re: AW: Serialization of injected EJBs

 im not sure if this is in a CDI spec or not, but afaik Weld will
 return serializable proxies when you manually inject objects. so that
 should work out of the box.

 -igor


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



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



Re: Single inheritence in parts

2010-07-08 Thread James Carman
And, this method doesn't really work very well either.  You can't
reliably call those abstract methods from the superclass' constructor.

On Thu, Jul 8, 2010 at 2:47 PM, Chris Colman
chr...@stepaheadsoftware.com wrote:
class Page extends  Page {

abstract Component getPart1();
abstract Component getPart2();
}

html

div wicket:id=id4part1 /
wicket:child /
div wicket:id=id4part2 /

 That's the component based workaround that I mentioned which IMHO isn't
 really the pure markup OO solution we're proposing. I'm hoping for true
 markup inheritance that supports multiple overridable sections that
 doesn't mandate a Java side coding change each time a markup editor adds
 or removes a particular overridable section.


On Thu, Jul 8, 2010 at 5:49 AM, Chris Colman
chr...@stepaheadsoftware.comwrote:

 Search the list for this and you'll find some quite long
 discussions.
 Basically, it's not going to happen. This would be multiple
 inheritance,
 not single.

 Hi Jeremy, I hope I don't sound confrontationalist when I say this
 but
 this is clearly not a case of multiple inheritance.

 For this request to be deemed to be multiple inheritance one
 class/markup file would need to be inheriting from two separate super
 classes/markup files. That is not what is requested here. There
 remains
 only a single super class/markup file.

 All that is requested here is for multiple markup sections to be
 overridden in this single inheritance scenario - just like Java does
 not
 restrict you to overriding only a single method in any Java class:
 You
 can override as many methods as you like in a Java class but that
 does
 not break Java's single inheritance model - which constrains the
 number
 of base classes to ONE, not the number of methods you can override to
 ONE.

 All this user (and others before him) are asking is for wicket to
 support the overriding of N markup sections without instead of the
 arbitrarily imposed constraint of N = 1.

 
 Jeremy Thomerson
 -- sent from my smartphone - please excuse formatting and spelling
 errors
 
 On Jul 5, 2010 12:41 AM, Arjun Dhar dhar...@yahoo.com wrote:
 
 
 Hi,
  all the examples etc suggest that Single inheritence is possible
 but I
 cant
 break it up. The break up is essential when you want to merge common
 parts
 of your MARKUP with multiple specific parts of the Child page.
 
 Example:
 
 
 HTML
 HEADtitleBASE TEMPLATE / PARENT PAGE/title/HEAD
 
 BODY
        wicket:child /
        br /
        h2Some other Html common/h2
        wicket:child /
 /BODY
 /HTML
 
 
 ---
 
 HTML
 HEADtitleCHILD PAGE 1/title/HEAD
 
 BODY
        wicket:extend
                    Part 1 specific to Child Page
        /wicket:extend
        Any HTML here can be ignored as conceptually anyway what
 appears
 in
 extend is what should be rendered from a child page.
        wicket:extend
                    Part 2 Specific to Child Page (will appear after
 common
 HTML in parent page)
        /wicket:extend
 /BODY
 /HTML
 
 
 I tried this, only the first part renders. I'm wondering if we can
 add
 such
 capability. Conceptually I don't see why not. If already possible do
 let me
 know or consider as a feature request?!
 
 -Thanks Arjun
 --
 View this message in context:

http://apache-wicket.1842946.n4.nabble.com/Single-inheritence-in-parts-
 tp2278064p2278064.html
 Sent from the Wicket - User mailing list archive at Nabble.com.
 

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

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



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



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



Re: Single inheritence in parts

2010-07-08 Thread Igor Vaynberg
class Page extends  Page {

abstract Component getPart1(String id);
abstract Component getPart2(String id);

onBeforeRender() {
  if (get(part1)==null) { add(getPart1(part1)); }
  if (get(part2)==null) { add(getPart2(part1)); }
}}

in 1.5 it would be done like this

class Page extends  Page {

abstract Component getPart1(String id);
abstract Component getPart2(String id);

onInitialize() {
  add(getPart1(part1));
  add(getPart2(part1));
}}

-igor

On Thu, Jul 8, 2010 at 2:23 PM, James Carman ja...@carmanconsulting.com wrote:
 And, this method doesn't really work very well either.  You can't
 reliably call those abstract methods from the superclass' constructor.

 On Thu, Jul 8, 2010 at 2:47 PM, Chris Colman
 chr...@stepaheadsoftware.com wrote:
class Page extends  Page {

abstract Component getPart1();
abstract Component getPart2();
}

html

div wicket:id=id4part1 /
wicket:child /
div wicket:id=id4part2 /

 That's the component based workaround that I mentioned which IMHO isn't
 really the pure markup OO solution we're proposing. I'm hoping for true
 markup inheritance that supports multiple overridable sections that
 doesn't mandate a Java side coding change each time a markup editor adds
 or removes a particular overridable section.


On Thu, Jul 8, 2010 at 5:49 AM, Chris Colman
chr...@stepaheadsoftware.comwrote:

 Search the list for this and you'll find some quite long
 discussions.
 Basically, it's not going to happen. This would be multiple
 inheritance,
 not single.

 Hi Jeremy, I hope I don't sound confrontationalist when I say this
 but
 this is clearly not a case of multiple inheritance.

 For this request to be deemed to be multiple inheritance one
 class/markup file would need to be inheriting from two separate super
 classes/markup files. That is not what is requested here. There
 remains
 only a single super class/markup file.

 All that is requested here is for multiple markup sections to be
 overridden in this single inheritance scenario - just like Java does
 not
 restrict you to overriding only a single method in any Java class:
 You
 can override as many methods as you like in a Java class but that
 does
 not break Java's single inheritance model - which constrains the
 number
 of base classes to ONE, not the number of methods you can override to
 ONE.

 All this user (and others before him) are asking is for wicket to
 support the overriding of N markup sections without instead of the
 arbitrarily imposed constraint of N = 1.

 
 Jeremy Thomerson
 -- sent from my smartphone - please excuse formatting and spelling
 errors
 
 On Jul 5, 2010 12:41 AM, Arjun Dhar dhar...@yahoo.com wrote:
 
 
 Hi,
  all the examples etc suggest that Single inheritence is possible
 but I
 cant
 break it up. The break up is essential when you want to merge common
 parts
 of your MARKUP with multiple specific parts of the Child page.
 
 Example:
 
 
 HTML
 HEADtitleBASE TEMPLATE / PARENT PAGE/title/HEAD
 
 BODY
        wicket:child /
        br /
        h2Some other Html common/h2
        wicket:child /
 /BODY
 /HTML
 
 
 ---
 
 HTML
 HEADtitleCHILD PAGE 1/title/HEAD
 
 BODY
        wicket:extend
                    Part 1 specific to Child Page
        /wicket:extend
        Any HTML here can be ignored as conceptually anyway what
 appears
 in
 extend is what should be rendered from a child page.
        wicket:extend
                    Part 2 Specific to Child Page (will appear after
 common
 HTML in parent page)
        /wicket:extend
 /BODY
 /HTML
 
 
 I tried this, only the first part renders. I'm wondering if we can
 add
 such
 capability. Conceptually I don't see why not. If already possible do
 let me
 know or consider as a feature request?!
 
 -Thanks Arjun
 --
 View this message in context:

http://apache-wicket.1842946.n4.nabble.com/Single-inheritence-in-parts-
 tp2278064p2278064.html
 Sent from the Wicket - User mailing list archive at Nabble.com.
 

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

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



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



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



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



Re: Single inheritence in parts

2010-07-08 Thread Ben Tilford
Use a pre render listener to call your render method. The constructor
stuff is pretty bad though. If you have the listener look for the
@PostConstruct annotation it even looks like its supposed to work that way.
imo if multiple markup section inheritance were implemented you would really
limit how your allowed to use the framework. As it is its simple (ignoring
constructor/rendering pains) and in your control not the frameworks.

On Thu, Jul 8, 2010 at 5:23 PM, James Carman ja...@carmanconsulting.comwrote:

 And, this method doesn't really work very well either.  You can't
 reliably call those abstract methods from the superclass' constructor.

 On Thu, Jul 8, 2010 at 2:47 PM, Chris Colman
 chr...@stepaheadsoftware.com wrote:
 class Page extends  Page {
 
 abstract Component getPart1();
 abstract Component getPart2();
 }
 
 html
 
 div wicket:id=id4part1 /
 wicket:child /
 div wicket:id=id4part2 /
 
  That's the component based workaround that I mentioned which IMHO isn't
  really the pure markup OO solution we're proposing. I'm hoping for true
  markup inheritance that supports multiple overridable sections that
  doesn't mandate a Java side coding change each time a markup editor adds
  or removes a particular overridable section.
 
 
 On Thu, Jul 8, 2010 at 5:49 AM, Chris Colman
 chr...@stepaheadsoftware.comwrote:
 
  Search the list for this and you'll find some quite long
  discussions.
  Basically, it's not going to happen. This would be multiple
  inheritance,
  not single.
 
  Hi Jeremy, I hope I don't sound confrontationalist when I say this
  but
  this is clearly not a case of multiple inheritance.
 
  For this request to be deemed to be multiple inheritance one
  class/markup file would need to be inheriting from two separate super
  classes/markup files. That is not what is requested here. There
  remains
  only a single super class/markup file.
 
  All that is requested here is for multiple markup sections to be
  overridden in this single inheritance scenario - just like Java does
  not
  restrict you to overriding only a single method in any Java class:
  You
  can override as many methods as you like in a Java class but that
  does
  not break Java's single inheritance model - which constrains the
  number
  of base classes to ONE, not the number of methods you can override to
  ONE.
 
  All this user (and others before him) are asking is for wicket to
  support the overriding of N markup sections without instead of the
  arbitrarily imposed constraint of N = 1.
 
  
  Jeremy Thomerson
  -- sent from my smartphone - please excuse formatting and spelling
  errors
  
  On Jul 5, 2010 12:41 AM, Arjun Dhar dhar...@yahoo.com wrote:
  
  
  Hi,
   all the examples etc suggest that Single inheritence is possible
  but I
  cant
  break it up. The break up is essential when you want to merge common
  parts
  of your MARKUP with multiple specific parts of the Child page.
  
  Example:
  
  
  HTML
  HEADtitleBASE TEMPLATE / PARENT PAGE/title/HEAD
  
  BODY
 wicket:child /
 br /
 h2Some other Html common/h2
 wicket:child /
  /BODY
  /HTML
  
  
  ---
  
  HTML
  HEADtitleCHILD PAGE 1/title/HEAD
  
  BODY
 wicket:extend
 Part 1 specific to Child Page
 /wicket:extend
 Any HTML here can be ignored as conceptually anyway what
  appears
  in
  extend is what should be rendered from a child page.
 wicket:extend
 Part 2 Specific to Child Page (will appear after
  common
  HTML in parent page)
 /wicket:extend
  /BODY
  /HTML
  
  
  I tried this, only the first part renders. I'm wondering if we can
  add
  such
  capability. Conceptually I don't see why not. If already possible do
  let me
  know or consider as a feature request?!
  
  -Thanks Arjun
  --
  View this message in context:
 
 http://apache-wicket.1842946.n4.nabble.com/Single-inheritence-in-parts-
  tp2278064p2278064.html
  Sent from the Wicket - User mailing list archive at Nabble.com.
  
 
 -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 

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




Re: Single inheritence in parts

2010-07-08 Thread James Carman
Right, it's doable, but there's a bit of homework you have to do to
make sure it all works correctly.  You have to solve the whole
onFirstRender problem in a reliable way.  Our base page has an
overridable onFirstRender() method that subclasses can override if
they wish to do this sort of initialization.  I like the
onInitialize() method name better, though.

On Thu, Jul 8, 2010 at 5:29 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
 class Page extends  Page {

 abstract Component getPart1(String id);
 abstract Component getPart2(String id);

 onBeforeRender() {
  if (get(part1)==null) { add(getPart1(part1)); }
  if (get(part2)==null) { add(getPart2(part1)); }
 }}

 in 1.5 it would be done like this

 class Page extends  Page {

 abstract Component getPart1(String id);
 abstract Component getPart2(String id);

 onInitialize() {
  add(getPart1(part1));
  add(getPart2(part1));
 }}

 -igor

 On Thu, Jul 8, 2010 at 2:23 PM, James Carman ja...@carmanconsulting.com 
 wrote:
 And, this method doesn't really work very well either.  You can't
 reliably call those abstract methods from the superclass' constructor.

 On Thu, Jul 8, 2010 at 2:47 PM, Chris Colman
 chr...@stepaheadsoftware.com wrote:
class Page extends  Page {

abstract Component getPart1();
abstract Component getPart2();
}

html

div wicket:id=id4part1 /
wicket:child /
div wicket:id=id4part2 /

 That's the component based workaround that I mentioned which IMHO isn't
 really the pure markup OO solution we're proposing. I'm hoping for true
 markup inheritance that supports multiple overridable sections that
 doesn't mandate a Java side coding change each time a markup editor adds
 or removes a particular overridable section.


On Thu, Jul 8, 2010 at 5:49 AM, Chris Colman
chr...@stepaheadsoftware.comwrote:

 Search the list for this and you'll find some quite long
 discussions.
 Basically, it's not going to happen. This would be multiple
 inheritance,
 not single.

 Hi Jeremy, I hope I don't sound confrontationalist when I say this
 but
 this is clearly not a case of multiple inheritance.

 For this request to be deemed to be multiple inheritance one
 class/markup file would need to be inheriting from two separate super
 classes/markup files. That is not what is requested here. There
 remains
 only a single super class/markup file.

 All that is requested here is for multiple markup sections to be
 overridden in this single inheritance scenario - just like Java does
 not
 restrict you to overriding only a single method in any Java class:
 You
 can override as many methods as you like in a Java class but that
 does
 not break Java's single inheritance model - which constrains the
 number
 of base classes to ONE, not the number of methods you can override to
 ONE.

 All this user (and others before him) are asking is for wicket to
 support the overriding of N markup sections without instead of the
 arbitrarily imposed constraint of N = 1.

 
 Jeremy Thomerson
 -- sent from my smartphone - please excuse formatting and spelling
 errors
 
 On Jul 5, 2010 12:41 AM, Arjun Dhar dhar...@yahoo.com wrote:
 
 
 Hi,
  all the examples etc suggest that Single inheritence is possible
 but I
 cant
 break it up. The break up is essential when you want to merge common
 parts
 of your MARKUP with multiple specific parts of the Child page.
 
 Example:
 
 
 HTML
 HEADtitleBASE TEMPLATE / PARENT PAGE/title/HEAD
 
 BODY
        wicket:child /
        br /
        h2Some other Html common/h2
        wicket:child /
 /BODY
 /HTML
 
 
 ---
 
 HTML
 HEADtitleCHILD PAGE 1/title/HEAD
 
 BODY
        wicket:extend
                    Part 1 specific to Child Page
        /wicket:extend
        Any HTML here can be ignored as conceptually anyway what
 appears
 in
 extend is what should be rendered from a child page.
        wicket:extend
                    Part 2 Specific to Child Page (will appear after
 common
 HTML in parent page)
        /wicket:extend
 /BODY
 /HTML
 
 
 I tried this, only the first part renders. I'm wondering if we can
 add
 such
 capability. Conceptually I don't see why not. If already possible do
 let me
 know or consider as a feature request?!
 
 -Thanks Arjun
 --
 View this message in context:

http://apache-wicket.1842946.n4.nabble.com/Single-inheritence-in-parts-
 tp2278064p2278064.html
 Sent from the Wicket - User mailing list archive at Nabble.com.
 

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

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



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

Re: Single inheritence in parts

2010-07-08 Thread James Carman
Right, well put then. :)

On Thu, Jul 8, 2010 at 5:41 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
 my point was simply that it is trivial to solve, it has a well known
 solution, and this is not the only usecase where it applies. you will
 need to do your homework no matter which way you go.

 -igor

 On Thu, Jul 8, 2010 at 2:35 PM, James Carman ja...@carmanconsulting.com 
 wrote:
 Right, it's doable, but there's a bit of homework you have to do to
 make sure it all works correctly.  You have to solve the whole
 onFirstRender problem in a reliable way.  Our base page has an
 overridable onFirstRender() method that subclasses can override if
 they wish to do this sort of initialization.  I like the
 onInitialize() method name better, though.

 On Thu, Jul 8, 2010 at 5:29 PM, Igor Vaynberg igor.vaynb...@gmail.com 
 wrote:
 class Page extends  Page {

 abstract Component getPart1(String id);
 abstract Component getPart2(String id);

 onBeforeRender() {
  if (get(part1)==null) { add(getPart1(part1)); }
  if (get(part2)==null) { add(getPart2(part1)); }
 }}

 in 1.5 it would be done like this

 class Page extends  Page {

 abstract Component getPart1(String id);
 abstract Component getPart2(String id);

 onInitialize() {
  add(getPart1(part1));
  add(getPart2(part1));
 }}

 -igor

 On Thu, Jul 8, 2010 at 2:23 PM, James Carman ja...@carmanconsulting.com 
 wrote:
 And, this method doesn't really work very well either.  You can't
 reliably call those abstract methods from the superclass' constructor.

 On Thu, Jul 8, 2010 at 2:47 PM, Chris Colman
 chr...@stepaheadsoftware.com wrote:
class Page extends  Page {

abstract Component getPart1();
abstract Component getPart2();
}

html

div wicket:id=id4part1 /
wicket:child /
div wicket:id=id4part2 /

 That's the component based workaround that I mentioned which IMHO isn't
 really the pure markup OO solution we're proposing. I'm hoping for true
 markup inheritance that supports multiple overridable sections that
 doesn't mandate a Java side coding change each time a markup editor adds
 or removes a particular overridable section.


On Thu, Jul 8, 2010 at 5:49 AM, Chris Colman
chr...@stepaheadsoftware.comwrote:

 Search the list for this and you'll find some quite long
 discussions.
 Basically, it's not going to happen. This would be multiple
 inheritance,
 not single.

 Hi Jeremy, I hope I don't sound confrontationalist when I say this
 but
 this is clearly not a case of multiple inheritance.

 For this request to be deemed to be multiple inheritance one
 class/markup file would need to be inheriting from two separate super
 classes/markup files. That is not what is requested here. There
 remains
 only a single super class/markup file.

 All that is requested here is for multiple markup sections to be
 overridden in this single inheritance scenario - just like Java does
 not
 restrict you to overriding only a single method in any Java class:
 You
 can override as many methods as you like in a Java class but that
 does
 not break Java's single inheritance model - which constrains the
 number
 of base classes to ONE, not the number of methods you can override to
 ONE.

 All this user (and others before him) are asking is for wicket to
 support the overriding of N markup sections without instead of the
 arbitrarily imposed constraint of N = 1.

 
 Jeremy Thomerson
 -- sent from my smartphone - please excuse formatting and spelling
 errors
 
 On Jul 5, 2010 12:41 AM, Arjun Dhar dhar...@yahoo.com wrote:
 
 
 Hi,
  all the examples etc suggest that Single inheritence is possible
 but I
 cant
 break it up. The break up is essential when you want to merge common
 parts
 of your MARKUP with multiple specific parts of the Child page.
 
 Example:
 
 
 HTML
 HEADtitleBASE TEMPLATE / PARENT PAGE/title/HEAD
 
 BODY
        wicket:child /
        br /
        h2Some other Html common/h2
        wicket:child /
 /BODY
 /HTML
 
 
 ---
 
 HTML
 HEADtitleCHILD PAGE 1/title/HEAD
 
 BODY
        wicket:extend
                    Part 1 specific to Child Page
        /wicket:extend
        Any HTML here can be ignored as conceptually anyway what
 appears
 in
 extend is what should be rendered from a child page.
        wicket:extend
                    Part 2 Specific to Child Page (will appear after
 common
 HTML in parent page)
        /wicket:extend
 /BODY
 /HTML
 
 
 I tried this, only the first part renders. I'm wondering if we can
 add
 such
 capability. Conceptually I don't see why not. If already possible do
 let me
 know or consider as a feature request?!
 
 -Thanks Arjun
 --
 View this message in context:

http://apache-wicket.1842946.n4.nabble.com/Single-inheritence-in-parts-
 tp2278064p2278064.html
 Sent from the Wicket - User mailing list archive at Nabble.com.
 

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

How to combine a form and a link that submit the same page?

2010-07-08 Thread Kevin Stembridge
Hi folks,

I'm trying to write a page that displays search results. The page contains a
form allowing the user to input search criteria. It also displays the list
of results with links for paging back and forth through the result set.

I'm having a bit of trouble because the pageParameters coming from the form
can be in conflict with the pageParameters coming from the paging navigation
links.

For example:
A user enters a name in the form, submits it and the results are displayed.
If they then use the paging navigation link to display the second page, the
query parameters will contain the name first entered in the form. If the
user enters a new name in the form and submits it again, the page parameters
will contain both names.

So the question is, when I submit the form, how do I ignore any
pageParameters that weren't actually from the form?

Cheers,
Kevin


Re: How to combine a form and a link that submit the same page?

2010-07-08 Thread Martin Makundi
Hi!

Few points to consider:

1. I hope you do not parse pageParameters manually, let wicket handle
that for simple cases.

2. Don't allow your paging buttons to submit data, set
button.setDefaultFormProcessing(false);

3. Separate your search form and other forms from each other:

form search form
search criteria
/form

div other content
  form some other forms.../form
/div


**
Martin


2010/7/9 Kevin Stembridge kevin.stembri...@gmail.com:
 Hi folks,

 I'm trying to write a page that displays search results. The page contains a
 form allowing the user to input search criteria. It also displays the list
 of results with links for paging back and forth through the result set.

 I'm having a bit of trouble because the pageParameters coming from the form
 can be in conflict with the pageParameters coming from the paging navigation
 links.

 For example:
 A user enters a name in the form, submits it and the results are displayed.
 If they then use the paging navigation link to display the second page, the
 query parameters will contain the name first entered in the form. If the
 user enters a new name in the form and submits it again, the page parameters
 will contain both names.

 So the question is, when I submit the form, how do I ignore any
 pageParameters that weren't actually from the form?

 Cheers,
 Kevin


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



AjaxButton documentation error?

2010-07-08 Thread Chris Colman
The JavaDoc for AjaxButton (and AjaxSubmitButton) says:

A button that submits the form via ajax. Since this button takes the
form as a constructor argument it does not need to be added to it unlike
the Button component.

Well I've just spent a good amount of time putting that theory to the
test. I use the constructor that takes the form as its second parameter.
Basically the form fails with an error saying wicket can't find the
button component unless I explicitly add the AjaxButton object to the
form object, seemingly contradicting the above doco quote. The Wicket
example explicitly adds the button to the form too - which also seems to
go against the above doco declaration.

Maybe it's a rare case where reading the documentation is not a good
idea =}


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



about treeLink

2010-07-08 Thread 蔡茂昌
is there any complete sample or demo of the  treeLink

thank you.

-


Re: about treeLink

2010-07-08 Thread Jeremy Thomerson
http://www.wicket-library.com/wicket-examples/nested/

On Thu, Jul 8, 2010 at 9:09 PM, 蔡茂昌 caimaochang.c...@gmail.com wrote:

 is there any complete sample or demo of the  treeLink

 thank you.

 -




-- 
Jeremy Thomerson
http://www.wickettraining.com


RE: about treeLink

2010-07-08 Thread Chris Colman
Can the wicket trees support context menus? (eg., right click on a node and a 
pop up menu appears near where the mouse went down)


-Original Message-
From: Jeremy Thomerson [mailto:jer...@wickettraining.com]
Sent: Friday, 9 July 2010 2:14 PM
To: users@wicket.apache.org
Subject: Re: about treeLink

http://www.wicket-library.com/wicket-examples/nested/

On Thu, Jul 8, 2010 at 9:09 PM, 蔡茂昌 caimaochang.c...@gmail.com wrote:

 is there any complete sample or demo of the  treeLink

 thank you.

 -




--
Jeremy Thomerson
http://www.wickettraining.com

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