Re: Wicket 1.5.8 + EJB 3.1 - strange problem

2012-11-24 Thread Satrix
Cause Im eager to learn new things :)

Regards, Satrix



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Wicket-1-5-8-EJB-3-1-strange-problem-tp4653977p4654128.html
Sent from the Users forum mailing list archive at Nabble.com.

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



RE: Ideas on implementing dynamic addition of components that use AJAX?

2012-11-24 Thread Nick Pratt
Chris

Ive been following this thread with interest - what is the use case that
drives your need to add components dynamically - why can't you just add a
SytemPanel in the panel constructor - is your HTML markup being generated
outside of your Wicket app?

N
On Nov 24, 2012 1:26 AM, Chris Colman chr...@stepaheadsoftware.com
wrote:

 Wow! That was a bit too easy!

 Here's how to override onInitialize to dynamically add components to a
 page that are specified in the markup:

 protected void onInitialize()
 {
 super.onInitialize();

 IMarkupFragment markupElements = getMarkup();

 for (MarkupElement markupElement: markupElements)
 {
 if ( markupElement instanceof ComponentTag )
 {
 ComponentTag tag =
 (ComponentTag)markupElement;
 String tagId = tag.getId();
 System.out.println(Markup Element:  +
 tag.getName() +  ID:  + tagId);

 if ( tagId != null )
 {
 if (
 tagId.equals(systemPanel))
 {
 add(new
 SystemPanel(systemPanel));
 }
 }
 }
 }
 }

 In this example systemPanel represents the ID of a single component
 that should be added dynamically in onInitialize if it is discovered in
 the markup.

 It could be easily enhanced to support multiple dynamic components by
 providing a set of IDs that represent components that should be
 dynamically added and then add them when they are discovered during
 onInitialize.

 This could easily be applied to an application's Panel base class to
 work inside Panels in addition to pages.


 My only concern was that we're adding another iteration process to the
 page construction cycle - iterating through all MarkupElements of the
 markup of a component each time it's onInitialize is called but I guess
 it's not that much of an issue. I was hoping to 'piggy back' the
 processing onto some other process that is already iterating the markup
 elements but I haven't found a suitable spot for that yet.


 -Original Message-
 From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
 Sent: Saturday, 24 November 2012 12:33 PM
 To: users@wicket.apache.org
 Subject: Re: Ideas on implementing dynamic addition of components that
 use
 AJAX?
 
 On Thu, Nov 22, 2012 at 11:46 PM, Martin Grigorov
 mgrigo...@apache.org
 wrote:
  Hi,
 
 
  On Fri, Nov 23, 2012 at 9:33 AM, Chris Colman
  chr...@stepaheadsoftware.comwrote:
 
  starting with wicket 1.5, however, components are able to resole
 their
  markup earlier in their lifecycle. the reason auto resolved
 components
  are added so late and treated specially was because the markup was
  only available during render.  if you are using 1.5 or 6 you can
 build
  your own mechanism. something that kicks off a page/panel's
  oninitialize(), gets the markup, walks it, and adds any components
 -
 
  Would it be walking the markup as raw XHTML or will parsed element
  objects be available at this point?
 
 
  You have to use #getMarkup() or #getAssociatedMarkup(), so the result
 is
  already parsed (IMarkupFragment).
 
 
 
  If it walks the markup will Wicket also be walking it at some time
 later
  as well, kind of duplicating the markup walking process?
 
 
  Wicket walks the markup of the whole page for every render of the
 page.
  In Ajax requests only the markup of the repainted components is
 traversed.
 
 
 
  maybe ones you mark by special tags in your own namespace. the
 problem
  here is that even if you can find these components you may still
 not
  be able to put them into the right parent because in onInitialize()
  the parent may not yet be added to the container. so perhaps you
 
 
  I think this is not correct. In #onInitialize() you have access to
 the
  markup of the current component and access to the Page instance, i.e.
 you
  have access to all parents between the current component and the Page
  instance.
 
 it is correct. i am not talking about the component on which
 onInitialize() is being called... suppose you have a page that
 implements the mechanism and your markup is like this:
 
 bodydiv wicket:id=foowicket:something//div
 
 what i meant is that inside the page's onInitialize() the component
 foo may not have yet been added so the wicket:something component
 cannot be properly put into it
 
 in this case the page's subclass' onInitialize() may add foo or
 onConfigure() can add foo or some other component if the hierarchy
 is deeper.
 
 -igor
 
 
 
  should have some mechanism that kicks off when
 page#onComponentAdded()
  is called. you can pull the newly added component's markup, see 

Re: InvalidBehaviorIdException on Ajax

2012-11-24 Thread Pierre Goupil
Good evening,

Let me reply to myself, please ! :-)

I've found the solution. The exception came from the fact that my
@Subscribe-annotated method responsible of adding the component to the
target was using a filter predicate. Remove that and it works!

Hope that could help someone in the future.

Regards,

Pierre




On Sat, Nov 24, 2012 at 4:05 AM, Pierre Goupil goupilpie...@gmail.comwrote:


 Good evening,

 On Ajax, with wicket-atmosphere, I more often that not got this exception:


 org.apache.wicket.behavior.InvalidBehaviorIdException: Cannot find
 behavior with id '1' on component
 'org.apache.wicket.markup.html.WebMarkupContainer:cardParent:playCardParentPlaceholdera6:cardPlaceholdera6'
 in page '[Page class = org.alienlabs.hatchetharry.view.page.HomePage, id =
 0, render count = 1]'. Perhaps the behavior did not properly implement
 getStatelessHint() and returned 'true' to indicate that it is stateless
 instead of returning 'false' to indicate that it is stateful.
 at org.apache.wicket.Behaviors.getBehaviorById(Behaviors.java:303)
 at org.apache.wicket.Component.getBehaviorById(Component.java:4479)
 at
 org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:246)
 at
 org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:226)
 at
 org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:830)



 I did set up getStatelessHint() but it keeps going on. I don't know which
 part of my code could be relevant, but one sure thing is that I do add
 Behaviors to the component. I don't understand why it happens only from
 times to times.

 I use Wicket 6.4.0-SNAPSHOT with Wicket-Atmosphere 0.6-SNAPSHOT. But it's
 the same in Wicket 6.2.0.

 I tried to isolate this in a quickstart but failed to reproduce it. On the
 opposite, it's pretty constant in my project.

 Thanks in advance for any help,

 Pierre


 --
 Le bonheur n'est pas une destination, mais une façon de voyager.

 Papa d'une petite Lou-Ann depuis le 30 juin.




-- 
Le bonheur n'est pas une destination, mais une façon de voyager.

Papa d'une petite Lou-Ann depuis le 30 juin.


Re: Ajax based panel replacement

2012-11-24 Thread Sven Meier

What is the problem?

Sven

On 11/24/2012 08:22 PM, Oliver Zemann wrote:

Hi,

i created a small wicket application to show my problem:
https://github.com/olze/WicketPanelReplace

The first panel gets displayed, after a few seconds it should be 
replaced by the second panel. Is there any way to achieve this 
behavior with that kind of architecture?


If not, how should a ajax based panel wizard work? Any recommendations?

Thanks in advance.

Oli

-
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: Ajax based panel replacement

2012-11-24 Thread Oliver Zemann
The problem is that this leads to a Page not found error. The problem is 
that the Panel which should be replaced is still looked up in the 
findPage() method. But findPage() returns null on that component, so 
this error is thrown.


Am 24.11.2012 21:48, schrieb Sven Meier:

What is the problem?

Sven

On 11/24/2012 08:22 PM, Oliver Zemann wrote:

Hi,

i created a small wicket application to show my problem:
https://github.com/olze/WicketPanelReplace

The first panel gets displayed, after a few seconds it should be 
replaced by the second panel. Is there any way to achieve this 
behavior with that kind of architecture?


If not, how should a ajax based panel wizard work? Any recommendations?

Thanks in advance.

Oli

-
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: Ajax based panel replacement

2012-11-24 Thread Sven Meier
After the timer has fired, AbstractAjaxTimerBehavior automatically 
registers another timeout for the form inside PanelOne.
But at that point PanelOne is no longer in the component tree, it's 
replaced by PanelTwo already.


I'd recommend adding the behavor to the container instead:

final WebMarkupContainer wmc = new WebMarkupContainer(container);
wmc.add(new AbstractAjaxTimerBehavior(Duration.seconds(5)) {
@Override
protected void onTimer(AjaxRequestTarget target) {
PanelTwo two = new PanelTwo(panel);
wmc.addOrReplace(two);
target.add(wmc);

stop(target);
}
});
add(wmc);

wmc.add(new PanelOne(panel));

This way you won't have to pass 'wmc' to PanelOne any longer.

Sven

On 11/24/2012 10:04 PM, Oliver Zemann wrote:
The problem is that this leads to a Page not found error. The problem 
is that the Panel which should be replaced is still looked up in the 
findPage() method. But findPage() returns null on that component, so 
this error is thrown.


Am 24.11.2012 21:48, schrieb Sven Meier:

What is the problem?

Sven

On 11/24/2012 08:22 PM, Oliver Zemann wrote:

Hi,

i created a small wicket application to show my problem:
https://github.com/olze/WicketPanelReplace

The first panel gets displayed, after a few seconds it should be 
replaced by the second panel. Is there any way to achieve this 
behavior with that kind of architecture?


If not, how should a ajax based panel wizard work? Any recommendations?

Thanks in advance.

Oli

-
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: Ajax based panel replacement

2012-11-24 Thread Oliver Zemann
Unfortunately this is not a solution as i have about 30 different 
panels. And i guess at least 10 of them should later use JS. With the 
approach you suggested i would have to check which panel should be 
displayed and load that (switch/case with 10 different panels). I guess 
that would also lead in heavy mixing the panels with the HomePage 
(BasePage) (destroying reusability).


There is also no way for me to create a flow based dialogue as this is 
done in the backend controller which only tells me which panel to load.


So there is no other way to go?

Am 24.11.2012 22:57, schrieb Sven Meier:
After the timer has fired, AbstractAjaxTimerBehavior automatically 
registers another timeout for the form inside PanelOne.
But at that point PanelOne is no longer in the component tree, it's 
replaced by PanelTwo already.


I'd recommend adding the behavor to the container instead:

final WebMarkupContainer wmc = new 
WebMarkupContainer(container);

wmc.add(new AbstractAjaxTimerBehavior(Duration.seconds(5)) {
@Override
protected void onTimer(AjaxRequestTarget target) {
PanelTwo two = new PanelTwo(panel);
wmc.addOrReplace(two);
target.add(wmc);

stop(target);
}
});
add(wmc);

wmc.add(new PanelOne(panel));

This way you won't have to pass 'wmc' to PanelOne any longer.

Sven

On 11/24/2012 10:04 PM, Oliver Zemann wrote:
The problem is that this leads to a Page not found error. The problem 
is that the Panel which should be replaced is still looked up in the 
findPage() method. But findPage() returns null on that component, so 
this error is thrown.


Am 24.11.2012 21:48, schrieb Sven Meier:

What is the problem?

Sven

On 11/24/2012 08:22 PM, Oliver Zemann wrote:

Hi,

i created a small wicket application to show my problem:
https://github.com/olze/WicketPanelReplace

The first panel gets displayed, after a few seconds it should be 
replaced by the second panel. Is there any way to achieve this 
behavior with that kind of architecture?


If not, how should a ajax based panel wizard work? Any 
recommendations?


Thanks in advance.

Oli

-
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: Ideas on implementing dynamic addition of components that use AJAX?

2012-11-24 Thread Chris Colman
Chris

Ive been following this thread with interest - what is the use case
that
drives your need to add components dynamically - why can't you just add
a
SytemPanel in the panel constructor - is your HTML markup being
generated
outside of your Wicket app?

Our use case is as follows:

We have a core framework (100% Java) that supports a fully hosted web
site creation and hosting cloud app. The framework includes content
management facilities (rendered by Wicket) plus sophisticated
authentication  authorization (organization context aware), entity
product management, workflow/BPM, the works etc., 

We also build specialized web apps for corporations who want to get to
market ASAP by leveraging our framework. The CMS capabilities of the
framework, rendered by Wicket allow the web devs at the various
corporations to design their own markup.

Wicket's separation of concerns between Java  Markup is perfect for
this and so long as the corporate web devs are careful not to delete the
bindings we place in their HTML (i.e. wicket:id=firstName ... etc.,)
they can continue to edit their HTML pretty much at will.

While hard coding the component hierarchy (Panels etc.,) works for many
simple scenarios we find the external web devs often want to arrange
their HTML in ways that we hadn't thought of. 

e.g. the framework provides a whole lot of small components/modules
designed to fit in a side bar. We don't want to dictate the collection
of modules they must include in the side bar. With a static component
hierarchy a side bar has a static collection of modules.

With our dynamic component hierarchy the web devs can add/remove modules
to the side bar with the simple addition/exclusion of panels via

div wicket:id=socialNetworking/
div wicket:id=latestNews/
Etc.,

And no changes to the Java framework is required.

A recent requirement was for a log in/account panel to be located in
different locations in the page for different clients - we didn't want
to have to assemble different Java component hierarchies for different
clients.

Some clients want a log in/account panel as a separate panel 'somewhere'
and others want it embedded in the main menu.

The dynamic assembling of the component hierarchy makes for much
cleaner, elegant and more maintainable Java code. To stick with a static
model but still support the layout/markup compositions required by many
different clients we would have to build in a hell of a lot of
conditional Java code that would need to become aware of the individual
client for which the page is being assembled - yuck!

I'm not 100% sure that Wicket was designed with this level of
flexibility from dynamic component assembly in mind but that fact that
we can pull this off speaks volumes for the Wicket architects.


N
On Nov 24, 2012 1:26 AM, Chris Colman chr...@stepaheadsoftware.com
wrote:

 Wow! That was a bit too easy!

 Here's how to override onInitialize to dynamically add components to
a
 page that are specified in the markup:

 protected void onInitialize()
 {
 super.onInitialize();

 IMarkupFragment markupElements = getMarkup();

 for (MarkupElement markupElement: markupElements)
 {
 if ( markupElement instanceof ComponentTag )
 {
 ComponentTag tag =
 (ComponentTag)markupElement;
 String tagId = tag.getId();
 System.out.println(Markup Element: 
+
 tag.getName() +  ID:  + tagId);

 if ( tagId != null )
 {
 if (
 tagId.equals(systemPanel))
 {
 add(new
 SystemPanel(systemPanel));
 }
 }
 }
 }
 }

 In this example systemPanel represents the ID of a single component
 that should be added dynamically in onInitialize if it is discovered
in
 the markup.

 It could be easily enhanced to support multiple dynamic components by
 providing a set of IDs that represent components that should be
 dynamically added and then add them when they are discovered during
 onInitialize.

 This could easily be applied to an application's Panel base class to
 work inside Panels in addition to pages.


 My only concern was that we're adding another iteration process to
the
 page construction cycle - iterating through all MarkupElements of the
 markup of a component each time it's onInitialize is called but I
guess
 it's not that much of an issue. I was hoping to 'piggy back' the
 processing onto some other process that is already iterating the
markup
 elements but I haven't found a suitable spot for that yet.


 -Original Message-
 From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com]
 

initial bean validation integration checked into experimental module

2012-11-24 Thread Igor Vaynberg
just checked in a first pass on bean validation (jsr 303) integration.
see this commit for details:

https://git-wip-us.apache.org/repos/asf?p=wicket.git;a=commitdiff;h=580a8dd9;hp=2d47bf340875f6053aa2a3b69c4f442f2fbb03e1

feedback is welome.

-igor

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