Re: Issue regarding refresh a wicket page portlet in Jetspeed portal
Arun: See my comment. On Wed May 27,2009 04:01 pm, Arun Wagle wrote: Hello , I have an issue with refreshing the portlet in jetspeed. I will try to explain the issue below I have a navigation in Jetspeed which point to a psml file. This psml file will bring up a wicket portlet. In the wicket portlet, I am having multiple pages. So when we click on the navigation link(psml url), I get to the home page of the wicket portlet. I do some action on the home page(Page A) and then use setResponsePage method of the Component class to redirect to a different page(Page B) Now when I click on the navigation page again, instead of going to the home page(Page A) it goes to the Page B directly. I want that whenever I click on the navigation link (which points to a psml file), it should always go to home page(Page A) and not to any intermediate page (Page B in this case) I think what is happenning here is, whenever I click on the navigation link, the last rendered response is rendered by the portlet. I agree with you here. The last url is the render response, and it gets reloaded when you refresh. It sounds a bit strange (at least to me); loading another page when refreshing a page ?! Any how, I think this can be done with javascript, by modifying the variable window.location.href . I haven't tested this. Let me know if more details are needed. Regards, Arun Wagle - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [announce] WicketStuff Artwork new release
True.. The link's in the source :) But here is it : http://www.ruzee.com/content/liquid-canvas 2009/5/27 Erik van Oosten e.vanoos...@grons.nl: Hi Nino, Nice stuff. Do you have a link to liquid? Its not a nice google word. Regards, Erik. nino martinez wael wrote: Hi Guys Just wanted to tell that theres a new release of wicketstuff artwork out. This time including niftycornerscube... - 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: unit test of AjaxLazyLoadPanel and ModalWindow
Thanks for the info Frank. Any tips on how to do so? Frank Bille wrote: On Thu, Apr 24, 2008 at 8:10 PM, qk wuhanqiangk...@gmail.com wrote: 1. after the page was rendered using WicketTester.startPage(), the real content (the one that returned by getLazyLoadComponent()) was not loaded by default. I always got an empty panel. Is there a way that I can have the real content rendered? Wicket tester doesn't parse javascript, so it can't execute the ajax callback. You have to do that yourself. Frank - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - ___ http://stubbisms.wordpress.com http://stubbisms.wordpress.com -- View this message in context: http://www.nabble.com/unit-test-of-AjaxLazyLoadPanel-and-ModalWindow-tp16851306p23756926.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: RequestLogger and session invalidation
On Thu, May 28, 2009 at 6:49 AM, Jeremy Thomerson jer...@wickettraining.com wrote: Please open a JIRA so this doesn't get lost. I haven't looked, but it sounds wrong if it truly recreates an invalidated session in some end-of-request logging, even if it doesn't bind the session. Post the link back here. I found out what's causing the problem, I was using Session.invalidateNow() which invalidates the session before it's logged. With Session.invalidate() the problem doesn't exist. I created a JIRA issue about it: https://issues.apache.org/jira/browse/WICKET-2291 Regards, Taneli Korri
Re: RequestLogger and session invalidation
why are you using invalidateNow? On Thu, May 28, 2009 at 10:11, Taneli Korri tko...@gmail.com wrote: On Thu, May 28, 2009 at 6:49 AM, Jeremy Thomerson jer...@wickettraining.com wrote: Please open a JIRA so this doesn't get lost. I haven't looked, but it sounds wrong if it truly recreates an invalidated session in some end-of-request logging, even if it doesn't bind the session. Post the link back here. I found out what's causing the problem, I was using Session.invalidateNow() which invalidates the session before it's logged. With Session.invalidate() the problem doesn't exist. I created a JIRA issue about it: https://issues.apache.org/jira/browse/WICKET-2291 Regards, Taneli Korri
AutoCompleteTextField and IE8, javascript error thrown
Dear all,
I have a problem using AutoCompleteTextField: when I type something into it,
the choices list is not shown, and the following javascript error is thrown:
Webpage error details
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0;
.NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR
3.0.04506.648)
Timestamp: Thu, 28 May 2009 08:19:40 UTC
Message: Invalid argument.
Line: 253
Char: 1
Code: 0
URI:
http://localhost:8080/TADinfo/analysis/resources/org.apache.wicket.extensions
.ajax.markup.html.autocomplete.AutoCompleteBehavior/wicket-autocomplete.js
This problem occurs only with IE8 (with IE7, IE6 and Firefox works), and
Wicket 1.3.6 (with version 1.3.4 works).
Can anybody help me?
Thank you in advance!
Here is the code:
private class LocalitiesAutoCompleteTextField extends
AutoCompleteTextField{
private int type;
private final static int MIN_CHAR = 0;
private final static int MAX_RES = 10;
private Object selectedObject;
public LocalitiesAutoCompleteTextField(String id, int type, final
IModel model){
super(id, model);//, new LocalityListRenderer());
this.type = type;
}
public Object getSelectedObject(){
return selectedObject;
}
@Override
public String getModelValue(){
return super.getModelValue();
}
@Override
public Iterator getChoices(String input) {
if (!Strings.isEmpty(input)){
List choices = new ArrayList();
if (input.length() = MIN_CHAR){
int i=0;
switch(type){
case LAYER0:
for (Layer0
layer0:facade.selectLayer0ByDisplayNameStartingWith(input)){
if (++i MAX_RES){
break;
}
choices.add(layer0);
}
for (Layer0
layer0:facade.selectLayer0ByDisplayNameContaining(input)){
if (++i MAX_RES){
break;
}
choices.add(layer0);
}
if (iMAX_RES){
choices.add(MORE);
}
break;
case LAYER1:
for (Layer1
layer1:facade.selectLayer1ByDisplayNameStartingWith(input)){
if (++i MAX_RES){
break;
}
choices.add(layer1);
}
for (Layer1
layer1:facade.selectLayer1ByDisplayNameContaining(input)){
if (++i MAX_RES){
break;
}
choices.add(layer1);
}
if (iMAX_RES){
choices.add(MORE);
}
break;
case LAYER2:
for (Layer2
layer2:facade.selectLayer2ByDisplayNameStartingWith(input)){
if (++i MAX_RES){
break;
}
choices.add(layer2);
}
for (Layer2
layer2:facade.selectLayer2ByDisplayNameContaining(input)){
if (++i MAX_RES){
break;
}
choices.add(layer2);
}
if (iMAX_RES){
choices.add(MORE);
}
break;
case LOCALITY:
for (Localitydb
locality:facade.selectLocalityByDisplayNameStartingWith(input)){
if (++i MAX_RES){
break;
}
choices.add(locality);
}
for (Localitydb
locality:facade.selectLocalityByDisplayNameContaining(input)){
if (++i MAX_RES){
break;
}
choices.add(locality);
}
if (iMAX_RES){
choices.add(MORE);
}
AutoCompleteTextField and IE8, javascript error thrown
Dear all,
I have a problem using AutoCompleteTextField: when I type something into it,
the choices list is not shown, and the following javascript error is thrown:
Webpage error details
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0;
.NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR
3.0.04506.648)
Timestamp: Thu, 28 May 2009 08:19:40 UTC
Message: Invalid argument.
Line: 253
Char: 1
Code: 0
URI:
http://localhost:8080/TADinfo/analysis/resources/org.apache.wicket.extension
s.ajax.markup.html.autocomplete.AutoCompleteBehavior/wicket-autocomplete.js
This problem occurs only with IE8 (with IE7, IE6 and Firefox works), and
Wicket 1.3.6 (with version 1.3.4 works).
Can anybody help me?
Thank you in advance!
Here is the code:
private class LocalitiesAutoCompleteTextField extends
AutoCompleteTextField{
private int type;
private final static int MIN_CHAR = 0;
private final static int MAX_RES = 10;
private Object selectedObject;
public LocalitiesAutoCompleteTextField(String id, int type, final
IModel model){
super(id, model);//, new LocalityListRenderer());
this.type = type;
}
public Object getSelectedObject(){
return selectedObject;
}
@Override
public String getModelValue(){
return super.getModelValue();
}
@Override
public Iterator getChoices(String input) {
if (!Strings.isEmpty(input)){
List choices = new ArrayList();
if (input.length() = MIN_CHAR){
int i=0;
switch(type){
case LAYER0:
for (Layer0
layer0:facade.selectLayer0ByDisplayNameStartingWith(input)){
if (++i MAX_RES){
break;
}
choices.add(layer0);
}
for (Layer0
layer0:facade.selectLayer0ByDisplayNameContaining(input)){
if (++i MAX_RES){
break;
}
choices.add(layer0);
}
if (iMAX_RES){
choices.add(MORE);
}
break;
case LAYER1:
for (Layer1
layer1:facade.selectLayer1ByDisplayNameStartingWith(input)){
if (++i MAX_RES){
break;
}
choices.add(layer1);
}
for (Layer1
layer1:facade.selectLayer1ByDisplayNameContaining(input)){
if (++i MAX_RES){
break;
}
choices.add(layer1);
}
if (iMAX_RES){
choices.add(MORE);
}
break;
case LAYER2:
for (Layer2
layer2:facade.selectLayer2ByDisplayNameStartingWith(input)){
if (++i MAX_RES){
break;
}
choices.add(layer2);
}
for (Layer2
layer2:facade.selectLayer2ByDisplayNameContaining(input)){
if (++i MAX_RES){
break;
}
choices.add(layer2);
}
if (iMAX_RES){
choices.add(MORE);
}
break;
case LOCALITY:
for (Localitydb
locality:facade.selectLocalityByDisplayNameStartingWith(input)){
if (++i MAX_RES){
break;
}
choices.add(locality);
}
for (Localitydb
locality:facade.selectLocalityByDisplayNameContaining(input)){
if (++i MAX_RES){
break;
}
choices.add(locality);
}
if (iMAX_RES){
choices.add(MORE);
}
Re: Example of ModalWindow misleading
Should I open a jira for this ? 2009/5/21 Matej Knopp matej.kn...@gmail.com: I think modal window example could be fixed by using getPageReference() to pass page reference between pages instead of page instance. -Matej On Wed, May 20, 2009 at 10:29 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: http://www.wicket-library.com/wicket-examples/ajax/modal-window.1 is pretty misleading : passing components between components/page is quite broken as can be seen in the past discussion on the mailing list (serialization issue can arise and makes both sides using different references of the same object logically speaking). True. I have found that the only safe way to pass references is via getSession().xxx so now all my (not all, but generally relevant ones) models are in session instead of being page-scoped. Not heavy models but selection models such that indicate what the user is operating on. However. Instead of changing the documentation, I would rather change the implementation such that the serialization would not break. The same offect, however, occurs if you have some other kind of pop-up window it would be nice to be able to continue using the underlying page in sync with the pop-up. ** Martin However, as it is in the example, I first used it considering that it should be ok to do so. Could it be changed in some way ? On the bigger picture, I guess it raises again the issue of the recommended way of communicating between the page and the modal window, which currently doesn't exist (session, database...??). However, this example is currently completely misleading, so even so comments to explicit the issue would be welcomed. thanks again nono - 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
[BUG ? ] Disabling AjaxSelfUpdatingTimerBehavior
I am trying to disable AjaxSelfUpdatingTimerBehavior which I have added to some component disable it when something happens. I found that no matter what the isEnabled method of the behaviour returns, the behaviour remains enabled. Is this a bug or I am doing something wrong? Alex Objelean - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
LogoutPage: PageParameters not set after redirecting to LoginPage
hi all, we are having a strange problem with page parameters. when the user logs out we call LogoutPage: ... PageParameters parameters = new PageParameters(); parameters.put(client, signature); setResponsePage(LoginPage.class, parameters); in LoginPage we do: ... String signature = params.getString(client); ... but signature is empty ... any idea how this can happen? thanks in advance, roman - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model?
Hi, Our current architecture: --- We're currently using a 3-tier architecture (presentation, service/business and persistence) consisting of Wicket (+ a little Spring), Spring and Spring + Hibernate: Wicket: Does presentation, we're not inside a transaction / Hibernate session so all used fields must be loaded by Spring. We call Spring singleton beans and annotate those fields with @SpringBean. Spring: In the service layer we have Spring singleton beans, services, which are called from the Wicket layer. We have our transaction / Hibernate session boundary at this layer. We call DAO's from this layer. Spring + Hibernate: Our DAO's are Spring singleton beans which performs database operations using HibernateTemplate. And common to all the layers are our entities. We use the @Entity annotation on them (not XML), from the Wicket layer we just use the accessor methods making sure that the relevant fields are loaded (as we would get an exception if they were Lazy and not yet loaded). Our entities are stupid, they lack logic and are used mostly like a struct in C/C++. I think the general pattern is pretty common for Java EE and Spring based web applications (feel free to disagree!). Yet it's classified as an anti-pattern by Martin Fowler as we are using mostly procedural programming and have an anemic domain model ( http://en.wikipedia.org/wiki/Anemic_Domain_Model ). What I would like: --- I would like to use a more OOP approach and have logic in our current entities, creating a rich domain model. For that to work in all cases they need to be able to load and save data. I would still use a Spring singleton bean's for different services. But instead of changing the entities like structs they would be rich objects capable of chaning themself's and other objects. I found this article very interesting: http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860 But how would something like that work with Wicket? Could I just use @SpringBean like I'm currently doing but use it on both entities and Spring singleton services? For me this has a purely practical benefit, as I could use some inheritance in the domain object model to create different variations of logic and not just data. Wicket feels quite agile and nice to work with, but I still feel that the current architecture is a bit stale and seldom supports elegant OO solutions (that said, of course things can still be solved elegantly, I just think it would be easier if I could do it in a more OO oriented way). Comments? What are the pros and cons of this kind of architecture? All comments are greatly appreciated! Best regards, Kent - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model?
In your entities, you don't use @SpringBean. You use @Configurable/@Autowire. On Thu, May 28, 2009 at 9:38 AM, Kent Larsson kent.lars...@gmail.com wrote: Hi, Our current architecture: --- We're currently using a 3-tier architecture (presentation, service/business and persistence) consisting of Wicket (+ a little Spring), Spring and Spring + Hibernate: Wicket: Does presentation, we're not inside a transaction / Hibernate session so all used fields must be loaded by Spring. We call Spring singleton beans and annotate those fields with @SpringBean. Spring: In the service layer we have Spring singleton beans, services, which are called from the Wicket layer. We have our transaction / Hibernate session boundary at this layer. We call DAO's from this layer. Spring + Hibernate: Our DAO's are Spring singleton beans which performs database operations using HibernateTemplate. And common to all the layers are our entities. We use the @Entity annotation on them (not XML), from the Wicket layer we just use the accessor methods making sure that the relevant fields are loaded (as we would get an exception if they were Lazy and not yet loaded). Our entities are stupid, they lack logic and are used mostly like a struct in C/C++. I think the general pattern is pretty common for Java EE and Spring based web applications (feel free to disagree!). Yet it's classified as an anti-pattern by Martin Fowler as we are using mostly procedural programming and have an anemic domain model ( http://en.wikipedia.org/wiki/Anemic_Domain_Model ). What I would like: --- I would like to use a more OOP approach and have logic in our current entities, creating a rich domain model. For that to work in all cases they need to be able to load and save data. I would still use a Spring singleton bean's for different services. But instead of changing the entities like structs they would be rich objects capable of chaning themself's and other objects. I found this article very interesting: http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860 But how would something like that work with Wicket? Could I just use @SpringBean like I'm currently doing but use it on both entities and Spring singleton services? For me this has a purely practical benefit, as I could use some inheritance in the domain object model to create different variations of logic and not just data. Wicket feels quite agile and nice to work with, but I still feel that the current architecture is a bit stale and seldom supports elegant OO solutions (that said, of course things can still be solved elegantly, I just think it would be easier if I could do it in a more OO oriented way). Comments? What are the pros and cons of this kind of architecture? All comments are greatly appreciated! Best regards, Kent - 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: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model?
No, I mean @Configurable/@Autowired http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/beans/factory/annotation/Configurable.html http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/beans/factory/annotation/Autowired.html With these, you can also use AspectJ to set things up. There are aspects in spring-aspects.jar that takes care of it. You have to introduce the AspectJ compiler into your build, but I believe that's done for you in my wicket-advanced example application. On Thu, May 28, 2009 at 9:49 AM, Kent Larsson kent.lars...@gmail.com wrote: You mean @SpringConfigured(something) like in the linked article? On Thu, May 28, 2009 at 3:41 PM, James Carman jcar...@carmanconsulting.com wrote: In your entities, you don't use @SpringBean. You use @Configurable/@Autowire. On Thu, May 28, 2009 at 9:38 AM, Kent Larsson kent.lars...@gmail.com wrote: Hi, Our current architecture: --- We're currently using a 3-tier architecture (presentation, service/business and persistence) consisting of Wicket (+ a little Spring), Spring and Spring + Hibernate: Wicket: Does presentation, we're not inside a transaction / Hibernate session so all used fields must be loaded by Spring. We call Spring singleton beans and annotate those fields with @SpringBean. Spring: In the service layer we have Spring singleton beans, services, which are called from the Wicket layer. We have our transaction / Hibernate session boundary at this layer. We call DAO's from this layer. Spring + Hibernate: Our DAO's are Spring singleton beans which performs database operations using HibernateTemplate. And common to all the layers are our entities. We use the @Entity annotation on them (not XML), from the Wicket layer we just use the accessor methods making sure that the relevant fields are loaded (as we would get an exception if they were Lazy and not yet loaded). Our entities are stupid, they lack logic and are used mostly like a struct in C/C++. I think the general pattern is pretty common for Java EE and Spring based web applications (feel free to disagree!). Yet it's classified as an anti-pattern by Martin Fowler as we are using mostly procedural programming and have an anemic domain model ( http://en.wikipedia.org/wiki/Anemic_Domain_Model ). What I would like: --- I would like to use a more OOP approach and have logic in our current entities, creating a rich domain model. For that to work in all cases they need to be able to load and save data. I would still use a Spring singleton bean's for different services. But instead of changing the entities like structs they would be rich objects capable of chaning themself's and other objects. I found this article very interesting: http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860 But how would something like that work with Wicket? Could I just use @SpringBean like I'm currently doing but use it on both entities and Spring singleton services? For me this has a purely practical benefit, as I could use some inheritance in the domain object model to create different variations of logic and not just data. Wicket feels quite agile and nice to work with, but I still feel that the current architecture is a bit stale and seldom supports elegant OO solutions (that said, of course things can still be solved elegantly, I just think it would be easier if I could do it in a more OO oriented way). Comments? What are the pros and cons of this kind of architecture? All comments are greatly appreciated! Best regards, Kent - 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
How to find that component is being updated by AjaxFormComponentUpdatingBehavior?
Hello community! I have created component, which supports text code input by which it then finds corresponding value in DB. If user deletes code and leaves input component, AjaxFormComponentUpdatingBehavior takes it's turn and removes previously fetched value (if any). The problem is, that removing current value is valid operation even if component marked as required. So, I need to maintain two component states - single value update via AJAX and complete form submit, which in turn also can be AJAX'ified. I just didn't find any robust solution yet. Currently my component returns true from checkRequired() method in case of AJAX request target, but if form will be submitted via AJAX component could end up in invalid state. Would be very grateful for advices!
Re: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model?
Do you have a separation between domain objects and DTO's? It sounds like you don't (and there is nothing wrong with that), but if you do, how do you inject the DTO into the entity? In my case each DTO is a Spring singleton bean. On Thu, May 28, 2009 at 4:17 PM, Will Jaynes w...@jaynes.org wrote: I use the same setup as you, but I add the use of the OpenEntityManagerInViewFilter. I still use only Spring services from within Wicket (as much as possible), but the domain objects can be as full featured as needed because a Hibernate session is always open when Wicket is using the services. On Thu, May 28, 2009 at 9:49 AM, Kent Larsson kent.lars...@gmail.comwrote: You mean @SpringConfigured(something) like in the linked article? On Thu, May 28, 2009 at 3:41 PM, James Carman jcar...@carmanconsulting.com wrote: In your entities, you don't use @SpringBean. You use @Configurable/@Autowire. On Thu, May 28, 2009 at 9:38 AM, Kent Larsson kent.lars...@gmail.com wrote: Hi, Our current architecture: --- We're currently using a 3-tier architecture (presentation, service/business and persistence) consisting of Wicket (+ a little Spring), Spring and Spring + Hibernate: Wicket: Does presentation, we're not inside a transaction / Hibernate session so all used fields must be loaded by Spring. We call Spring singleton beans and annotate those fields with @SpringBean. Spring: In the service layer we have Spring singleton beans, services, which are called from the Wicket layer. We have our transaction / Hibernate session boundary at this layer. We call DAO's from this layer. Spring + Hibernate: Our DAO's are Spring singleton beans which performs database operations using HibernateTemplate. And common to all the layers are our entities. We use the @Entity annotation on them (not XML), from the Wicket layer we just use the accessor methods making sure that the relevant fields are loaded (as we would get an exception if they were Lazy and not yet loaded). Our entities are stupid, they lack logic and are used mostly like a struct in C/C++. I think the general pattern is pretty common for Java EE and Spring based web applications (feel free to disagree!). Yet it's classified as an anti-pattern by Martin Fowler as we are using mostly procedural programming and have an anemic domain model ( http://en.wikipedia.org/wiki/Anemic_Domain_Model ). What I would like: --- I would like to use a more OOP approach and have logic in our current entities, creating a rich domain model. For that to work in all cases they need to be able to load and save data. I would still use a Spring singleton bean's for different services. But instead of changing the entities like structs they would be rich objects capable of chaning themself's and other objects. I found this article very interesting: http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860 But how would something like that work with Wicket? Could I just use @SpringBean like I'm currently doing but use it on both entities and Spring singleton services? For me this has a purely practical benefit, as I could use some inheritance in the domain object model to create different variations of logic and not just data. Wicket feels quite agile and nice to work with, but I still feel that the current architecture is a bit stale and seldom supports elegant OO solutions (that said, of course things can still be solved elegantly, I just think it would be easier if I could do it in a more OO oriented way). Comments? What are the pros and cons of this kind of architecture? All comments are greatly appreciated! Best regards, Kent - 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: Example of ModalWindow misleading
yes -igor On Thu, May 28, 2009 at 3:09 AM, Live Nono liven...@gmail.com wrote: Should I open a jira for this ? 2009/5/21 Matej Knopp matej.kn...@gmail.com: I think modal window example could be fixed by using getPageReference() to pass page reference between pages instead of page instance. -Matej On Wed, May 20, 2009 at 10:29 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: http://www.wicket-library.com/wicket-examples/ajax/modal-window.1 is pretty misleading : passing components between components/page is quite broken as can be seen in the past discussion on the mailing list (serialization issue can arise and makes both sides using different references of the same object logically speaking). True. I have found that the only safe way to pass references is via getSession().xxx so now all my (not all, but generally relevant ones) models are in session instead of being page-scoped. Not heavy models but selection models such that indicate what the user is operating on. However. Instead of changing the documentation, I would rather change the implementation such that the serialization would not break. The same offect, however, occurs if you have some other kind of pop-up window it would be nice to be able to continue using the underlying page in sync with the pop-up. ** Martin However, as it is in the example, I first used it considering that it should be ok to do so. Could it be changed in some way ? On the bigger picture, I guess it raises again the issue of the recommended way of communicating between the page and the modal window, which currently doesn't exist (session, database...??). However, this example is currently completely misleading, so even so comments to explicit the issue would be welcomed. thanks again nono - 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: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model?
this is why i built salve.googlecode.com you can easily hook it into spring and have all your objects (doman objects or wicket components) injected via @Dependency without worrying about serialization issues or eager injection - eg if you load a result set of 1000 hibernate entities that need injection you dont want all those injected for no reason. -igor On Thu, May 28, 2009 at 6:38 AM, Kent Larsson kent.lars...@gmail.com wrote: Hi, Our current architecture: --- We're currently using a 3-tier architecture (presentation, service/business and persistence) consisting of Wicket (+ a little Spring), Spring and Spring + Hibernate: Wicket: Does presentation, we're not inside a transaction / Hibernate session so all used fields must be loaded by Spring. We call Spring singleton beans and annotate those fields with @SpringBean. Spring: In the service layer we have Spring singleton beans, services, which are called from the Wicket layer. We have our transaction / Hibernate session boundary at this layer. We call DAO's from this layer. Spring + Hibernate: Our DAO's are Spring singleton beans which performs database operations using HibernateTemplate. And common to all the layers are our entities. We use the @Entity annotation on them (not XML), from the Wicket layer we just use the accessor methods making sure that the relevant fields are loaded (as we would get an exception if they were Lazy and not yet loaded). Our entities are stupid, they lack logic and are used mostly like a struct in C/C++. I think the general pattern is pretty common for Java EE and Spring based web applications (feel free to disagree!). Yet it's classified as an anti-pattern by Martin Fowler as we are using mostly procedural programming and have an anemic domain model ( http://en.wikipedia.org/wiki/Anemic_Domain_Model ). What I would like: --- I would like to use a more OOP approach and have logic in our current entities, creating a rich domain model. For that to work in all cases they need to be able to load and save data. I would still use a Spring singleton bean's for different services. But instead of changing the entities like structs they would be rich objects capable of chaning themself's and other objects. I found this article very interesting: http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860 But how would something like that work with Wicket? Could I just use @SpringBean like I'm currently doing but use it on both entities and Spring singleton services? For me this has a purely practical benefit, as I could use some inheritance in the domain object model to create different variations of logic and not just data. Wicket feels quite agile and nice to work with, but I still feel that the current architecture is a bit stale and seldom supports elegant OO solutions (that said, of course things can still be solved elegantly, I just think it would be easier if I could do it in a more OO oriented way). Comments? What are the pros and cons of this kind of architecture? All comments are greatly appreciated! Best regards, Kent - 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: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model?
Are you talking about DAOs (data access objects) and not DTOs (data transfer objects)? DTOs are typically not singletons. Nor are they set up via spring. On Thu, May 28, 2009 at 11:20 AM, Kent Larsson kent.lars...@gmail.com wrote: Do you have a separation between domain objects and DTO's? It sounds like you don't (and there is nothing wrong with that), but if you do, how do you inject the DTO into the entity? In my case each DTO is a Spring singleton bean. On Thu, May 28, 2009 at 4:17 PM, Will Jaynes w...@jaynes.org wrote: I use the same setup as you, but I add the use of the OpenEntityManagerInViewFilter. I still use only Spring services from within Wicket (as much as possible), but the domain objects can be as full featured as needed because a Hibernate session is always open when Wicket is using the services. On Thu, May 28, 2009 at 9:49 AM, Kent Larsson kent.lars...@gmail.comwrote: You mean @SpringConfigured(something) like in the linked article? On Thu, May 28, 2009 at 3:41 PM, James Carman jcar...@carmanconsulting.com wrote: In your entities, you don't use @SpringBean. You use @Configurable/@Autowire. On Thu, May 28, 2009 at 9:38 AM, Kent Larsson kent.lars...@gmail.com wrote: Hi, Our current architecture: --- We're currently using a 3-tier architecture (presentation, service/business and persistence) consisting of Wicket (+ a little Spring), Spring and Spring + Hibernate: Wicket: Does presentation, we're not inside a transaction / Hibernate session so all used fields must be loaded by Spring. We call Spring singleton beans and annotate those fields with @SpringBean. Spring: In the service layer we have Spring singleton beans, services, which are called from the Wicket layer. We have our transaction / Hibernate session boundary at this layer. We call DAO's from this layer. Spring + Hibernate: Our DAO's are Spring singleton beans which performs database operations using HibernateTemplate. And common to all the layers are our entities. We use the @Entity annotation on them (not XML), from the Wicket layer we just use the accessor methods making sure that the relevant fields are loaded (as we would get an exception if they were Lazy and not yet loaded). Our entities are stupid, they lack logic and are used mostly like a struct in C/C++. I think the general pattern is pretty common for Java EE and Spring based web applications (feel free to disagree!). Yet it's classified as an anti-pattern by Martin Fowler as we are using mostly procedural programming and have an anemic domain model ( http://en.wikipedia.org/wiki/Anemic_Domain_Model ). What I would like: --- I would like to use a more OOP approach and have logic in our current entities, creating a rich domain model. For that to work in all cases they need to be able to load and save data. I would still use a Spring singleton bean's for different services. But instead of changing the entities like structs they would be rich objects capable of chaning themself's and other objects. I found this article very interesting: http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860 But how would something like that work with Wicket? Could I just use @SpringBean like I'm currently doing but use it on both entities and Spring singleton services? For me this has a purely practical benefit, as I could use some inheritance in the domain object model to create different variations of logic and not just data. Wicket feels quite agile and nice to work with, but I still feel that the current architecture is a bit stale and seldom supports elegant OO solutions (that said, of course things can still be solved elegantly, I just think it would be easier if I could do it in a more OO oriented way). Comments? What are the pros and cons of this kind of architecture? All comments are greatly appreciated! Best regards, Kent - 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: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model?
Oops! Yes I'm talking about DAO's, not DTO's as I wrote. I guess I shouldn't write acronyms after a long work day. ;-) Thanks for spotting it! Best regards, Kent On Thu, May 28, 2009 at 6:07 PM, James Carman jcar...@carmanconsulting.com wrote: Are you talking about DAOs (data access objects) and not DTOs (data transfer objects)? DTOs are typically not singletons. Nor are they set up via spring. On Thu, May 28, 2009 at 11:20 AM, Kent Larsson kent.lars...@gmail.com wrote: Do you have a separation between domain objects and DTO's? It sounds like you don't (and there is nothing wrong with that), but if you do, how do you inject the DTO into the entity? In my case each DTO is a Spring singleton bean. On Thu, May 28, 2009 at 4:17 PM, Will Jaynes w...@jaynes.org wrote: I use the same setup as you, but I add the use of the OpenEntityManagerInViewFilter. I still use only Spring services from within Wicket (as much as possible), but the domain objects can be as full featured as needed because a Hibernate session is always open when Wicket is using the services. On Thu, May 28, 2009 at 9:49 AM, Kent Larsson kent.lars...@gmail.comwrote: You mean @SpringConfigured(something) like in the linked article? On Thu, May 28, 2009 at 3:41 PM, James Carman jcar...@carmanconsulting.com wrote: In your entities, you don't use @SpringBean. You use @Configurable/@Autowire. On Thu, May 28, 2009 at 9:38 AM, Kent Larsson kent.lars...@gmail.com wrote: Hi, Our current architecture: --- We're currently using a 3-tier architecture (presentation, service/business and persistence) consisting of Wicket (+ a little Spring), Spring and Spring + Hibernate: Wicket: Does presentation, we're not inside a transaction / Hibernate session so all used fields must be loaded by Spring. We call Spring singleton beans and annotate those fields with @SpringBean. Spring: In the service layer we have Spring singleton beans, services, which are called from the Wicket layer. We have our transaction / Hibernate session boundary at this layer. We call DAO's from this layer. Spring + Hibernate: Our DAO's are Spring singleton beans which performs database operations using HibernateTemplate. And common to all the layers are our entities. We use the @Entity annotation on them (not XML), from the Wicket layer we just use the accessor methods making sure that the relevant fields are loaded (as we would get an exception if they were Lazy and not yet loaded). Our entities are stupid, they lack logic and are used mostly like a struct in C/C++. I think the general pattern is pretty common for Java EE and Spring based web applications (feel free to disagree!). Yet it's classified as an anti-pattern by Martin Fowler as we are using mostly procedural programming and have an anemic domain model ( http://en.wikipedia.org/wiki/Anemic_Domain_Model ). What I would like: --- I would like to use a more OOP approach and have logic in our current entities, creating a rich domain model. For that to work in all cases they need to be able to load and save data. I would still use a Spring singleton bean's for different services. But instead of changing the entities like structs they would be rich objects capable of chaning themself's and other objects. I found this article very interesting: http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860 But how would something like that work with Wicket? Could I just use @SpringBean like I'm currently doing but use it on both entities and Spring singleton services? For me this has a purely practical benefit, as I could use some inheritance in the domain object model to create different variations of logic and not just data. Wicket feels quite agile and nice to work with, but I still feel that the current architecture is a bit stale and seldom supports elegant OO solutions (that said, of course things can still be solved elegantly, I just think it would be easier if I could do it in a more OO oriented way). Comments? What are the pros and cons of this kind of architecture? All comments are greatly appreciated! Best regards, Kent - 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
Re: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model?
Nice! I think Salve looks great! And it solves more than this problem, I like the design by contract module too as it allows me to validate parameters in a bit more declarative way. Do you think Salve is ready to be used in production? I'm a bit concerned by Although already usable, Salve is still in its infancy. Not all features have been implemented and not all problems worked out.. I only see one open issue and it doesn't seem too major for me to pick it up. If I'm not mistaken Salve may be used (for lots of things, but one is) to solve serialization issues with Spring beans in Wicket components? But isn't that the same issue that the Wicket IOC and it's @SpringBean annotation solves? If that's the case: Could I use Spring to inject my entities with DAO's for now, and use the @SpringBean annotation on those as well in my Wicket components (In those cases I have entities as class vars)? And the @SpringBean will solve the serialization issue? By just looking at Salve a bit it seems I could migrate to Salve in two steps that way. And it might be a pretty smooth path to take? It would mean that I inject 1000 entities for no good reason. But if I see a performance problem in doing so I could just migrate to Salve? By smooth path I mean that I would have access to my DAO's in my entities and would essentially only change the dependency annotations and setup Salve. Of course, if Salve is production ready. Then could I throw out Wicket IOC and the @SpringBean annotation and use Salve instead to solve serialization issues? In this case I would use Salve for my presentation/Wicket -layer as well as dependency injection in my entities and Spring as I already do for my service/business -layer and my persistence/DTO -layer. Or would it be nicer to have Salve handle dependencies in the last two layers as well? A lot of questions and text. Thanks for reading this far! :-) Best regards, Kent On Thu, May 28, 2009 at 5:36 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: this is why i built salve.googlecode.com you can easily hook it into spring and have all your objects (doman objects or wicket components) injected via @Dependency without worrying about serialization issues or eager injection - eg if you load a result set of 1000 hibernate entities that need injection you dont want all those injected for no reason. -igor On Thu, May 28, 2009 at 6:38 AM, Kent Larsson kent.lars...@gmail.com wrote: Hi, Our current architecture: --- We're currently using a 3-tier architecture (presentation, service/business and persistence) consisting of Wicket (+ a little Spring), Spring and Spring + Hibernate: Wicket: Does presentation, we're not inside a transaction / Hibernate session so all used fields must be loaded by Spring. We call Spring singleton beans and annotate those fields with @SpringBean. Spring: In the service layer we have Spring singleton beans, services, which are called from the Wicket layer. We have our transaction / Hibernate session boundary at this layer. We call DAO's from this layer. Spring + Hibernate: Our DAO's are Spring singleton beans which performs database operations using HibernateTemplate. And common to all the layers are our entities. We use the @Entity annotation on them (not XML), from the Wicket layer we just use the accessor methods making sure that the relevant fields are loaded (as we would get an exception if they were Lazy and not yet loaded). Our entities are stupid, they lack logic and are used mostly like a struct in C/C++. I think the general pattern is pretty common for Java EE and Spring based web applications (feel free to disagree!). Yet it's classified as an anti-pattern by Martin Fowler as we are using mostly procedural programming and have an anemic domain model ( http://en.wikipedia.org/wiki/Anemic_Domain_Model ). What I would like: --- I would like to use a more OOP approach and have logic in our current entities, creating a rich domain model. For that to work in all cases they need to be able to load and save data. I would still use a Spring singleton bean's for different services. But instead of changing the entities like structs they would be rich objects capable of chaning themself's and other objects. I found this article very interesting: http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860 But how would something like that work with Wicket? Could I just use @SpringBean like I'm currently doing but use it on both entities and Spring singleton services? For me this has a purely practical benefit, as I could use some inheritance in the domain object model to create different variations of logic and not just data. Wicket feels quite agile and nice to work with, but I still feel that the current architecture is a bit stale and seldom supports elegant OO solutions (that said, of course things can still be solved elegantly, I just think it would be easier if I could do it in a more OO
Re: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model?
On Thu, May 28, 2009 at 10:09 AM, Kent Larsson kent.lars...@gmail.com wrote: Nice! I think Salve looks great! And it solves more than this problem, I like the design by contract module too as it allows me to validate parameters in a bit more declarative way. Do you think Salve is ready to be used in production? I'm a bit concerned by Although already usable, Salve is still in its infancy. Not all features have been implemented and not all problems worked out.. I only see one open issue and it doesn't seem too major for me to pick it up. we have been using it in production for a while without any problems. i just need to find the time to update the website text :) If I'm not mistaken Salve may be used (for lots of things, but one is) to solve serialization issues with Spring beans in Wicket components? But isn't that the same issue that the Wicket IOC and it's @SpringBean annotation solves? wicket ioc can only take it so far. because it has to generate a proxy there are limitations to what classes can be proxies - eg no final methods, default constructor, etc. salve doesnt use a proxy so it doesnt have any problems. although small, wicket ioc does have an overhead of having to serialize the proxy with the componnet. since salve removes the field it has no such overhead, this is more important when you are returning large resultsets of entities that use dependencies. If that's the case: Could I use Spring to inject my entities with DAO's for now, and use the @SpringBean annotation on those as well in my Wicket components (In those cases I have entities as class vars)? And the @SpringBean will solve the serialization issue? you can use whatever works for you. salve is an alternative :) By just looking at Salve a bit it seems I could migrate to Salve in two steps that way. And it might be a pretty smooth path to take? It would mean that I inject 1000 entities for no good reason. But if I see a performance problem in doing so I could just migrate to Salve? By smooth path I mean that I would have access to my DAO's in my entities and would essentially only change the dependency annotations and setup Salve. as long as you do not use spring-specific injection rules you should be fine. salve uses lookup by type primarily, but also does have @SpringBeanId that can be used as a qualifier. Of course, if Salve is production ready. Then could I throw out Wicket IOC and the @SpringBean annotation and use Salve instead to solve serialization issues? In this case I would use Salve for my presentation/Wicket -layer as well as dependency injection in my entities and Spring as I already do for my service/business -layer and my persistence/DTO -layer. Or would it be nicer to have Salve handle dependencies in the last two layers as well? we use salve to inject across all layers. it gives you a consistent approach to use and mock in unit tests. we have a spring context that contains true services - eg session factory, mail sender, credit card processor, etc. all of our domain model then uses salve to inject these wherever needed. -igor A lot of questions and text. Thanks for reading this far! :-) Best regards, Kent On Thu, May 28, 2009 at 5:36 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: this is why i built salve.googlecode.com you can easily hook it into spring and have all your objects (doman objects or wicket components) injected via @Dependency without worrying about serialization issues or eager injection - eg if you load a result set of 1000 hibernate entities that need injection you dont want all those injected for no reason. -igor On Thu, May 28, 2009 at 6:38 AM, Kent Larsson kent.lars...@gmail.com wrote: Hi, Our current architecture: --- We're currently using a 3-tier architecture (presentation, service/business and persistence) consisting of Wicket (+ a little Spring), Spring and Spring + Hibernate: Wicket: Does presentation, we're not inside a transaction / Hibernate session so all used fields must be loaded by Spring. We call Spring singleton beans and annotate those fields with @SpringBean. Spring: In the service layer we have Spring singleton beans, services, which are called from the Wicket layer. We have our transaction / Hibernate session boundary at this layer. We call DAO's from this layer. Spring + Hibernate: Our DAO's are Spring singleton beans which performs database operations using HibernateTemplate. And common to all the layers are our entities. We use the @Entity annotation on them (not XML), from the Wicket layer we just use the accessor methods making sure that the relevant fields are loaded (as we would get an exception if they were Lazy and not yet loaded). Our entities are stupid, they lack logic and are used mostly like a struct in C/C++. I think the general pattern is pretty common for Java EE and Spring based web applications (feel free to disagree!). Yet it's classified as an anti-pattern by
Update rules in PackageResourceGuard
Hi, I added my own subclass of PackageResourceGuard to my application which provides a configurable interface to the extensions and file names blacklist. After a while I noticed that if I put e.g. 'xml' on my blacklist, the new rule works for all resources which I have not requested before, but already delivered resources are still available. I guess this must be due to some kind of caching? How can I enforce a new rule on resources even if they have been delivered before? Cheers, Martin -- --- / http://herbert.the-little-red-haired-girl.org / - =+= Was ist ein Cluster? Wenn vier Bratscher unisono spielen. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Update rules in PackageResourceGuard
clear your browser cache. -igor On Thu, May 28, 2009 at 11:28 AM, Martin Dietze d...@fh-wedel.de wrote: Hi, I added my own subclass of PackageResourceGuard to my application which provides a configurable interface to the extensions and file names blacklist. After a while I noticed that if I put e.g. 'xml' on my blacklist, the new rule works for all resources which I have not requested before, but already delivered resources are still available. I guess this must be due to some kind of caching? How can I enforce a new rule on resources even if they have been delivered before? Cheers, Martin -- --- / http://herbert.the-little-red-haired-girl.org / - =+= Was ist ein Cluster? Wenn vier Bratscher unisono spielen. - 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: Update rules in PackageResourceGuard
On Thu, May 28, 2009, Igor Vaynberg wrote: can I enforce a new rule on resources even if they have been delivered before? clear your browser cache. Hmm, that was my first guess, I even accessed the page using a different browser. Cheers, Martin -- --- / http://herbert.the-little-red-haired-girl.org / - =+= Tower: Hoehe und Position? Pilot: Ich bin 1.80m und sitze vorne links. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
singletons, pools, wicket, web services and architecture
I've got a few questions that are somewhat general to web development, but since we've chosen Wicket as one of our front-end frameworks, I thought I would ask here first for pointers...especially where there may be a wicket way of doing things that we need to be aware of. The system we're developing will have 2 UIs - a browser-based UI developed in Wicket and an Eclipse-based rich-client app (Java). The available functionality will be a little different in each but with a good bit of overlap. There must be common authentication - a user might use either UI or both at any given time. We'll likely be using JAX-WS for communicating between the rich client and server. The server will be Tomcat. We obviously need to keep very good separation between the business logic and presentation layers, since there will be 2 presentation layers : 1) We need to have an application object/singleton to hold things like online/offline mode - so we can, for example, bring the application down for maintenance and give the user an intelligent response. In Wicket, I think that would be the Application object? I assume we'll need to make that reference a MyApplication object - how do I expose that to both Wicket and the WS APIs? JNDI? 2) We'll want our database connection pools to also be shared...one of the databases is an odd-ball - Filemaker (groan) - and I'm not sure how to pool connections for it and share the pool between the Wicket app and the WS APIs? When I've used connection pools in the past, it has always been something common, like MySQL, so the Tomcat configuration was pretty well-documented. I'm not sure where to start with this one? 3) Any other architecture issues I should be thinking about? Pointers? Good articles that might address some of these issues? Thanks in advance! Chris -- - Chris Merrill | Web Performance, Inc. ch...@webperformance.com| http://webperformance.com 919-433-1762| 919-845-7601 Website Load Testing and Stress Testing Software Services - - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: singletons, pools, wicket, web services and architecture
Might be a dumb question, but why not make your wicket front end use the JAX-WS services as well? Martijn On Thu, May 28, 2009 at 10:01 PM, Christopher L Merrill ch...@webperformance.com wrote: I've got a few questions that are somewhat general to web development, but since we've chosen Wicket as one of our front-end frameworks, I thought I would ask here first for pointers...especially where there may be a wicket way of doing things that we need to be aware of. The system we're developing will have 2 UIs - a browser-based UI developed in Wicket and an Eclipse-based rich-client app (Java). The available functionality will be a little different in each but with a good bit of overlap. There must be common authentication - a user might use either UI or both at any given time. We'll likely be using JAX-WS for communicating between the rich client and server. The server will be Tomcat. We obviously need to keep very good separation between the business logic and presentation layers, since there will be 2 presentation layers : 1) We need to have an application object/singleton to hold things like online/offline mode - so we can, for example, bring the application down for maintenance and give the user an intelligent response. In Wicket, I think that would be the Application object? I assume we'll need to make that reference a MyApplication object - how do I expose that to both Wicket and the WS APIs? JNDI? 2) We'll want our database connection pools to also be shared...one of the databases is an odd-ball - Filemaker (groan) - and I'm not sure how to pool connections for it and share the pool between the Wicket app and the WS APIs? When I've used connection pools in the past, it has always been something common, like MySQL, so the Tomcat configuration was pretty well-documented. I'm not sure where to start with this one? 3) Any other architecture issues I should be thinking about? Pointers? Good articles that might address some of these issues? Thanks in advance! Chris -- - Chris Merrill | Web Performance, Inc. ch...@webperformance.com | http://webperformance.com 919-433-1762 | 919-845-7601 Website Load Testing and Stress Testing Software Services - - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.5 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Tomcat Context problem
Your context.xml file needs to be like this ?xml version=1.0 encoding=UTF-8? Context path=/ You probably have this: ?xml version=1.0 encoding=UTF-8? Context path=/WicketApp/ Hope this helps! Jamie Anton Veretennikov wrote: Hello, all wicket users! I'm new to this list but like to be for a long time being a user and fan of wicket for several months. I worked with Struts, JSP and every time felt that simple servlets where much more clear. Wicket's plainless astound and stormed me. Well, now the problem I can't solve by my own. Tomcat 6.0.18, several Wicket apps running on it on somejava.net One test app with only one PageLink added as (new PageLink(homeLink, Index.class)) It is deployed on WicketApp and works well with http://somejava.net/WicketApp Now http://somedomain.somejava.net pointed directly to this http://somejava.net/WicketApp http://somedomain.somejava.net shows WicketApp Index page - OK Being on http://somedomain.somejava.net and clicking on homeLink - Tomcat error The requested resource (/WicketApp/WicketApp) is not available. http://somedomain.com is also pointed directly to this http://somejava.net/WicketApp http://somedomain.com shows WicketApp Index page - OK. Being on http://somedomain.com and clicking on homeLink - Tomcat error The requested resource (/WicketApp/WicketApp) is not available. How to ask wicket not to append this WicketApp string in theese cases? Best regards, Tony. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://www.nabble.com/Tomcat-Context-problem-tp20512308p23770124.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: OutOfMemory on certain combinations of controls
The sample I posted only has the single page with a link to the ModalWindow. The modal window keeps a reference to the ModalWindow param passed in to the constructor. That's only used to close the window when the AjaxRequestTarget is passed from the AjaxLink. When the OnChangeAjaxBehavior#onUpdate fires, it's rebuilding the repeating view and adding the WebMarkupContainer wrapper to the AjaxRequestTarget. So it's not keeping any references that I see. igor.vaynberg wrote: make sure you dont keep page references across pages. that may be it. -igor -- View this message in context: http://www.nabble.com/OutOfMemory-on-certain-combinations-of-controls-tp23750424p23770219.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: OutOfMemory on certain combinations of controls
there is too much going on in the sample you posted. if you want you can create a quickstart with the minimal amount of code necessary to reproduce this and i will take a look. -igor On Thu, May 28, 2009 at 2:12 PM, Flavius flav...@silverlion.com wrote: The sample I posted only has the single page with a link to the ModalWindow. The modal window keeps a reference to the ModalWindow param passed in to the constructor. That's only used to close the window when the AjaxRequestTarget is passed from the AjaxLink. When the OnChangeAjaxBehavior#onUpdate fires, it's rebuilding the repeating view and adding the WebMarkupContainer wrapper to the AjaxRequestTarget. So it's not keeping any references that I see. igor.vaynberg wrote: make sure you dont keep page references across pages. that may be it. -igor -- View this message in context: http://www.nabble.com/OutOfMemory-on-certain-combinations-of-controls-tp23750424p23770219.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: CompoundPropertyModel and Combobox
Thanx for the tip. It work on some cases. I found a pattern. For instance, if
a component (be it a textfield or a DropDownChoice) has it self a Model, for
instance a PropertyModel, the instance variables of the class that is used
on the form model (CompoundPropertyModel) are not filled.
EXAMPLE
the form:
public class ImovelHabitacionalForm extends Form {
nbsp;nbsp;nbsp;nbsp;private final ImovelHabitacionalInput
imovelHabitacionalInput = new ImovelHabitacionalInput();
nbsp;nbsp;nbsp;nbsp;...
nbsp;nbsp;nbsp;nbsp;public ImovelHabitacionalForm() {
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;super(ID);
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;setModel(new
CompoundPropertyModel(imovelHabitacionalInput));
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;buildForm();
nbsp;nbsp;nbsp;nbsp;}
nbsp;nbsp;nbsp;nbsp;/*The components creations */
nbsp;nbsp;nbsp;nbsp;private void buildForm() {
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;/*TRANSACTION TYPES*/
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;List transactionTypes =
TipoTransaccaoFacade.getTipoTransaccoes();
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;transactionType = new
DropDownChoice(transactionType, transactionTypes);
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;/*DISTRICTS*/
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;DistritosModel
distritosModel = new DistritosModel();
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;selectedDistrito = new
SelectedChoice(); /*class with a instance variable selectedChoice and
getter and setter*/
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;distritosDDC = new
DropDownChoice(distritos, new PropertyModel(selectedDistrito,
selectedChoice), distritosModel);
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;/*PRICE*/
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;priceTextField = new
TextField(price);
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;/*AREA*/
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;/*Class with a variable name
area and a getter and a setter*/
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;private TextFieldAreaModel
areaModel = new TextFieldAreaModel();
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;areaTextField = new
TextField(area, new PropertyModel(areaModel, area));
nbsp;nbsp;nbsp;nbsp;}
}
/*Part of the user input class used on the form model*/
private class ImovelHabitacionalInput implements IClusterable {
nbsp;nbsp;nbsp;nbsp;private String district= ;
nbsp;nbsp;nbsp;nbsp;private String transactionType= ;
nbsp;nbsp;nbsp;nbsp;private String price= ;
nbsp;nbsp;nbsp;nbsp;private String area = ;
nbsp;nbsp;nbsp;nbsp;/*GETTERS AND SETTERS*/
}
When the form is submited happens that the transactionType and the price
variables on the class ImovelHabitacionalInput are filled with the values
inserted by the user, but the district and the area dont. the diferences
between the textfields and the dropdownchoices is that the transactionType
and the price doesn't have a model itself.
Does any one knows why if a model is supllyed to a form model, the
respective instance variables are not filled, even more, those getters and
setters are not called (in debug mode i noticed that too).
Thanks a lot everyone
MARCO SANTOS
Marcin Palka wrote:
The code below works just fine for me. Instead of using complex type as a
model object for a drop down I use an instance of IChoiceRenderer to
control what's used for an id and what's displayed as a value.
User user = ;
setModel(new CompoundPropertyModel(user));
add(new DropDownChoice(usrRole, SystemRole.asStringList(),
new IChoiceRenderer() {
@Override
public String getDisplayValue(Object object) {
return Enum.valueOf(SystemRole.class,
object.toString()).getRoleName();
}
@Override
public String getIdValue(Object object, int index) {
if (index == -1) {
return SystemRole.SALESMAN.toString();
}
return SystemRole.asStringList().get(index);
}
}).setRequired(true));
The combo items are populated from Enum values:
public enum SystemRole {
SYS_ADMIN(Administrator systemu),
SERVICEMAN(Serwisant),
NETWORK_ADMIN(Administrator sieci),
SALESMAN(Pracownik punktu),
ANY(Bez roli);
private final String roleName;
SystemRole(String roleName) {
this.roleName = roleName;
}
public String getRoleName() {
return roleName;
}
private static List stringList;
public static List asStringList() {
if (stringList == null) {
stringList = new ArrayList();
for (SystemRole sr : values()) {
stringList.add(sr.toString());
}
}
return stringList;
}
}
And this is how model object looks like:
public class User {
private Integer usrId;
private String usrLogin;
Use of base tag in head seems to break AJAX
We have a site with lots of wicket AJAX working fine but we needed to add a base href=http://www.mysite.com/; / because the site uses a Rich Text editor that wants to convert all absolute links to links relative to www.mysite.com/ Adding this base tag seems to have broken all AJAX on the site - no AJAX method handlers get triggered anymore. When clicking on the buttons that used to work the browser shows: http://www.mysite.com/# whereas before they used to show http://www.mysite.com/param1/value1# Is there a work around for this problem? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model?
Another extremely light weight IoC with ORM wrapping (JDO and Hibernate) is exPOJO at http://www.expojo.com No need for old fashioned DAOs etc., just POJOs being persisted transparently the way they should be. In terms of serialization: Is that for the purpose of scaling in a cluster environment? I vote for 'session affinity' every time - it's almost necessary when you have anything more sophisticated than an anemic domain model. Do you really want to be shifting complex object models from server to server via serialization? If it's not for a cluster environment but for a single server to allow stale sessions to be swapped out then let the garbage collection clean out the ORM's object cache instead. -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, 29 May 2009 3:38 AM To: users@wicket.apache.org Subject: Re: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model? On Thu, May 28, 2009 at 10:09 AM, Kent Larsson kent.lars...@gmail.com wrote: Nice! I think Salve looks great! And it solves more than this problem, I like the design by contract module too as it allows me to validate parameters in a bit more declarative way. Do you think Salve is ready to be used in production? I'm a bit concerned by Although already usable, Salve is still in its infancy. Not all features have been implemented and not all problems worked out.. I only see one open issue and it doesn't seem too major for me to pick it up. we have been using it in production for a while without any problems. i just need to find the time to update the website text :) If I'm not mistaken Salve may be used (for lots of things, but one is) to solve serialization issues with Spring beans in Wicket components? But isn't that the same issue that the Wicket IOC and it's @SpringBean annotation solves? wicket ioc can only take it so far. because it has to generate a proxy there are limitations to what classes can be proxies - eg no final methods, default constructor, etc. salve doesnt use a proxy so it doesnt have any problems. although small, wicket ioc does have an overhead of having to serialize the proxy with the componnet. since salve removes the field it has no such overhead, this is more important when you are returning large resultsets of entities that use dependencies. If that's the case: Could I use Spring to inject my entities with DAO's for now, and use the @SpringBean annotation on those as well in my Wicket components (In those cases I have entities as class vars)? And the @SpringBean will solve the serialization issue? you can use whatever works for you. salve is an alternative :) By just looking at Salve a bit it seems I could migrate to Salve in two steps that way. And it might be a pretty smooth path to take? It would mean that I inject 1000 entities for no good reason. But if I see a performance problem in doing so I could just migrate to Salve? By smooth path I mean that I would have access to my DAO's in my entities and would essentially only change the dependency annotations and setup Salve. as long as you do not use spring-specific injection rules you should be fine. salve uses lookup by type primarily, but also does have @SpringBeanId that can be used as a qualifier. Of course, if Salve is production ready. Then could I throw out Wicket IOC and the @SpringBean annotation and use Salve instead to solve serialization issues? In this case I would use Salve for my presentation/Wicket -layer as well as dependency injection in my entities and Spring as I already do for my service/business -layer and my persistence/DTO -layer. Or would it be nicer to have Salve handle dependencies in the last two layers as well? we use salve to inject across all layers. it gives you a consistent approach to use and mock in unit tests. we have a spring context that contains true services - eg session factory, mail sender, credit card processor, etc. all of our domain model then uses salve to inject these wherever needed. -igor A lot of questions and text. Thanks for reading this far! :-) Best regards, Kent On Thu, May 28, 2009 at 5:36 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: this is why i built salve.googlecode.com you can easily hook it into spring and have all your objects (doman objects or wicket components) injected via @Dependency without worrying about serialization issues or eager injection - eg if you load a result set of 1000 hibernate entities that need injection you dont want all those injected for no reason. -igor On Thu, May 28, 2009 at 6:38 AM, Kent Larsson kent.lars...@gmail.com wrote: Hi, Our current architecture: --- We're currently using a 3-tier architecture (presentation, service/business and persistence) consisting of Wicket (+ a little Spring), Spring and
Re: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model?
serialization in the context when you need to serialize the object - eg wicket serializes its pages for offline storage, etc. -igor On Thu, May 28, 2009 at 5:51 PM, Chris Colman chr...@stepaheadsoftware.com wrote: Another extremely light weight IoC with ORM wrapping (JDO and Hibernate) is exPOJO at http://www.expojo.com No need for old fashioned DAOs etc., just POJOs being persisted transparently the way they should be. In terms of serialization: Is that for the purpose of scaling in a cluster environment? I vote for 'session affinity' every time - it's almost necessary when you have anything more sophisticated than an anemic domain model. Do you really want to be shifting complex object models from server to server via serialization? If it's not for a cluster environment but for a single server to allow stale sessions to be swapped out then let the garbage collection clean out the ORM's object cache instead. -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, 29 May 2009 3:38 AM To: users@wicket.apache.org Subject: Re: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model? On Thu, May 28, 2009 at 10:09 AM, Kent Larsson kent.lars...@gmail.com wrote: Nice! I think Salve looks great! And it solves more than this problem, I like the design by contract module too as it allows me to validate parameters in a bit more declarative way. Do you think Salve is ready to be used in production? I'm a bit concerned by Although already usable, Salve is still in its infancy. Not all features have been implemented and not all problems worked out.. I only see one open issue and it doesn't seem too major for me to pick it up. we have been using it in production for a while without any problems. i just need to find the time to update the website text :) If I'm not mistaken Salve may be used (for lots of things, but one is) to solve serialization issues with Spring beans in Wicket components? But isn't that the same issue that the Wicket IOC and it's @SpringBean annotation solves? wicket ioc can only take it so far. because it has to generate a proxy there are limitations to what classes can be proxies - eg no final methods, default constructor, etc. salve doesnt use a proxy so it doesnt have any problems. although small, wicket ioc does have an overhead of having to serialize the proxy with the componnet. since salve removes the field it has no such overhead, this is more important when you are returning large resultsets of entities that use dependencies. If that's the case: Could I use Spring to inject my entities with DAO's for now, and use the @SpringBean annotation on those as well in my Wicket components (In those cases I have entities as class vars)? And the @SpringBean will solve the serialization issue? you can use whatever works for you. salve is an alternative :) By just looking at Salve a bit it seems I could migrate to Salve in two steps that way. And it might be a pretty smooth path to take? It would mean that I inject 1000 entities for no good reason. But if I see a performance problem in doing so I could just migrate to Salve? By smooth path I mean that I would have access to my DAO's in my entities and would essentially only change the dependency annotations and setup Salve. as long as you do not use spring-specific injection rules you should be fine. salve uses lookup by type primarily, but also does have @SpringBeanId that can be used as a qualifier. Of course, if Salve is production ready. Then could I throw out Wicket IOC and the @SpringBean annotation and use Salve instead to solve serialization issues? In this case I would use Salve for my presentation/Wicket -layer as well as dependency injection in my entities and Spring as I already do for my service/business -layer and my persistence/DTO -layer. Or would it be nicer to have Salve handle dependencies in the last two layers as well? we use salve to inject across all layers. it gives you a consistent approach to use and mock in unit tests. we have a spring context that contains true services - eg session factory, mail sender, credit card processor, etc. all of our domain model then uses salve to inject these wherever needed. -igor A lot of questions and text. Thanks for reading this far! :-) Best regards, Kent On Thu, May 28, 2009 at 5:36 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: this is why i built salve.googlecode.com you can easily hook it into spring and have all your objects (doman objects or wicket components) injected via @Dependency without worrying about serialization issues or eager injection - eg if you load a result set of 1000 hibernate entities that need injection you dont want all those injected for no reason. -igor On Thu, May 28, 2009 at 6:38 AM, Kent Larsson
RE: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model?
Is that controllable? What if I have complex object models referenced from wicket UI components that I don't want (can't reasonably with Java's non optimal serialization) serialized? If we're serializing for offline storage aren't we going to require the underlying model objects to get serialized as well? -Original Message- serialization in the context when you need to serialize the object - eg wicket serializes its pages for offline storage, etc. -igor On Thu, May 28, 2009 at 5:51 PM, Chris Colman chr...@stepaheadsoftware.com wrote: Another extremely light weight IoC with ORM wrapping (JDO and Hibernate) is exPOJO at http://www.expojo.com No need for old fashioned DAOs etc., just POJOs being persisted transparently the way they should be. In terms of serialization: Is that for the purpose of scaling in a cluster environment? I vote for 'session affinity' every time - it's almost necessary when you have anything more sophisticated than an anemic domain model. Do you really want to be shifting complex object models from server to server via serialization? If it's not for a cluster environment but for a single server to allow stale sessions to be swapped out then let the garbage collection clean out the ORM's object cache instead. -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, 29 May 2009 3:38 AM To: users@wicket.apache.org Subject: Re: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model? On Thu, May 28, 2009 at 10:09 AM, Kent Larsson kent.lars...@gmail.com wrote: Nice! I think Salve looks great! And it solves more than this problem, I like the design by contract module too as it allows me to validate parameters in a bit more declarative way. Do you think Salve is ready to be used in production? I'm a bit concerned by Although already usable, Salve is still in its infancy. Not all features have been implemented and not all problems worked out.. I only see one open issue and it doesn't seem too major for me to pick it up. we have been using it in production for a while without any problems. i just need to find the time to update the website text :) If I'm not mistaken Salve may be used (for lots of things, but one is) to solve serialization issues with Spring beans in Wicket components? But isn't that the same issue that the Wicket IOC and it's @SpringBean annotation solves? wicket ioc can only take it so far. because it has to generate a proxy there are limitations to what classes can be proxies - eg no final methods, default constructor, etc. salve doesnt use a proxy so it doesnt have any problems. although small, wicket ioc does have an overhead of having to serialize the proxy with the componnet. since salve removes the field it has no such overhead, this is more important when you are returning large resultsets of entities that use dependencies. If that's the case: Could I use Spring to inject my entities with DAO's for now, and use the @SpringBean annotation on those as well in my Wicket components (In those cases I have entities as class vars)? And the @SpringBean will solve the serialization issue? you can use whatever works for you. salve is an alternative :) By just looking at Salve a bit it seems I could migrate to Salve in two steps that way. And it might be a pretty smooth path to take? It would mean that I inject 1000 entities for no good reason. But if I see a performance problem in doing so I could just migrate to Salve? By smooth path I mean that I would have access to my DAO's in my entities and would essentially only change the dependency annotations and setup Salve. as long as you do not use spring-specific injection rules you should be fine. salve uses lookup by type primarily, but also does have @SpringBeanId that can be used as a qualifier. Of course, if Salve is production ready. Then could I throw out Wicket IOC and the @SpringBean annotation and use Salve instead to solve serialization issues? In this case I would use Salve for my presentation/Wicket -layer as well as dependency injection in my entities and Spring as I already do for my service/business -layer and my persistence/DTO -layer. Or would it be nicer to have Salve handle dependencies in the last two layers as well? we use salve to inject across all layers. it gives you a consistent approach to use and mock in unit tests. we have a spring context that contains true services - eg session factory, mail sender, credit card processor, etc. all of our domain model then uses salve to inject these wherever needed. -igor A lot of questions and text. Thanks for reading this far! :-) Best regards, Kent On Thu, May 28, 2009 at 5:36 PM, Igor Vaynberg
Re: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model?
well, this is why salve removes the dependency field to at least help with those. other then that you can use a loadabledetachablemodel to release the reference when the page is not used. -igor On Thu, May 28, 2009 at 6:40 PM, Chris Colman chr...@stepaheadsoftware.com wrote: Is that controllable? What if I have complex object models referenced from wicket UI components that I don't want (can't reasonably with Java's non optimal serialization) serialized? If we're serializing for offline storage aren't we going to require the underlying model objects to get serialized as well? -Original Message- serialization in the context when you need to serialize the object - eg wicket serializes its pages for offline storage, etc. -igor On Thu, May 28, 2009 at 5:51 PM, Chris Colman chr...@stepaheadsoftware.com wrote: Another extremely light weight IoC with ORM wrapping (JDO and Hibernate) is exPOJO at http://www.expojo.com No need for old fashioned DAOs etc., just POJOs being persisted transparently the way they should be. In terms of serialization: Is that for the purpose of scaling in a cluster environment? I vote for 'session affinity' every time - it's almost necessary when you have anything more sophisticated than an anemic domain model. Do you really want to be shifting complex object models from server to server via serialization? If it's not for a cluster environment but for a single server to allow stale sessions to be swapped out then let the garbage collection clean out the ORM's object cache instead. -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, 29 May 2009 3:38 AM To: users@wicket.apache.org Subject: Re: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model? On Thu, May 28, 2009 at 10:09 AM, Kent Larsson kent.lars...@gmail.com wrote: Nice! I think Salve looks great! And it solves more than this problem, I like the design by contract module too as it allows me to validate parameters in a bit more declarative way. Do you think Salve is ready to be used in production? I'm a bit concerned by Although already usable, Salve is still in its infancy. Not all features have been implemented and not all problems worked out.. I only see one open issue and it doesn't seem too major for me to pick it up. we have been using it in production for a while without any problems. i just need to find the time to update the website text :) If I'm not mistaken Salve may be used (for lots of things, but one is) to solve serialization issues with Spring beans in Wicket components? But isn't that the same issue that the Wicket IOC and it's @SpringBean annotation solves? wicket ioc can only take it so far. because it has to generate a proxy there are limitations to what classes can be proxies - eg no final methods, default constructor, etc. salve doesnt use a proxy so it doesnt have any problems. although small, wicket ioc does have an overhead of having to serialize the proxy with the componnet. since salve removes the field it has no such overhead, this is more important when you are returning large resultsets of entities that use dependencies. If that's the case: Could I use Spring to inject my entities with DAO's for now, and use the @SpringBean annotation on those as well in my Wicket components (In those cases I have entities as class vars)? And the @SpringBean will solve the serialization issue? you can use whatever works for you. salve is an alternative :) By just looking at Salve a bit it seems I could migrate to Salve in two steps that way. And it might be a pretty smooth path to take? It would mean that I inject 1000 entities for no good reason. But if I see a performance problem in doing so I could just migrate to Salve? By smooth path I mean that I would have access to my DAO's in my entities and would essentially only change the dependency annotations and setup Salve. as long as you do not use spring-specific injection rules you should be fine. salve uses lookup by type primarily, but also does have @SpringBeanId that can be used as a qualifier. Of course, if Salve is production ready. Then could I throw out Wicket IOC and the @SpringBean annotation and use Salve instead to solve serialization issues? In this case I would use Salve for my presentation/Wicket -layer as well as dependency injection in my entities and Spring as I already do for my service/business -layer and my persistence/DTO -layer. Or would it be nicer to have Salve handle dependencies in the last two layers as well? we use salve to inject across all layers. it gives you a consistent approach to use and mock in unit tests. we have a spring context that contains true
RE: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model?
When you say offline storage do you mean that the user has chosen to save pages for future offline reference or do you mean a more 'automated' process that wicket performs when system memory becomes too low? Chris -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, 29 May 2009 11:43 AM To: users@wicket.apache.org Subject: Re: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model? well, this is why salve removes the dependency field to at least help with those. other then that you can use a loadabledetachablemodel to release the reference when the page is not used. -igor On Thu, May 28, 2009 at 6:40 PM, Chris Colman chr...@stepaheadsoftware.com wrote: Is that controllable? What if I have complex object models referenced from wicket UI components that I don't want (can't reasonably with Java's non optimal serialization) serialized? If we're serializing for offline storage aren't we going to require the underlying model objects to get serialized as well? -Original Message- serialization in the context when you need to serialize the object - eg wicket serializes its pages for offline storage, etc. -igor On Thu, May 28, 2009 at 5:51 PM, Chris Colman chr...@stepaheadsoftware.com wrote: Another extremely light weight IoC with ORM wrapping (JDO and Hibernate) is exPOJO at http://www.expojo.com No need for old fashioned DAOs etc., just POJOs being persisted transparently the way they should be. In terms of serialization: Is that for the purpose of scaling in a cluster environment? I vote for 'session affinity' every time - it's almost necessary when you have anything more sophisticated than an anemic domain model. Do you really want to be shifting complex object models from server to server via serialization? If it's not for a cluster environment but for a single server to allow stale sessions to be swapped out then let the garbage collection clean out the ORM's object cache instead. -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, 29 May 2009 3:38 AM To: users@wicket.apache.org Subject: Re: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model? On Thu, May 28, 2009 at 10:09 AM, Kent Larsson kent.lars...@gmail.com wrote: Nice! I think Salve looks great! And it solves more than this problem, I like the design by contract module too as it allows me to validate parameters in a bit more declarative way. Do you think Salve is ready to be used in production? I'm a bit concerned by Although already usable, Salve is still in its infancy. Not all features have been implemented and not all problems worked out.. I only see one open issue and it doesn't seem too major for me to pick it up. we have been using it in production for a while without any problems. i just need to find the time to update the website text :) If I'm not mistaken Salve may be used (for lots of things, but one is) to solve serialization issues with Spring beans in Wicket components? But isn't that the same issue that the Wicket IOC and it's @SpringBean annotation solves? wicket ioc can only take it so far. because it has to generate a proxy there are limitations to what classes can be proxies - eg no final methods, default constructor, etc. salve doesnt use a proxy so it doesnt have any problems. although small, wicket ioc does have an overhead of having to serialize the proxy with the componnet. since salve removes the field it has no such overhead, this is more important when you are returning large resultsets of entities that use dependencies. If that's the case: Could I use Spring to inject my entities with DAO's for now, and use the @SpringBean annotation on those as well in my Wicket components (In those cases I have entities as class vars)? And the @SpringBean will solve the serialization issue? you can use whatever works for you. salve is an alternative :) By just looking at Salve a bit it seems I could migrate to Salve in two steps that way. And it might be a pretty smooth path to take? It would mean that I inject 1000 entities for no good reason. But if I see a performance problem in doing so I could just migrate to Salve? By smooth path I mean that I would have access to my DAO's in my entities and would essentially only change the dependency annotations and setup Salve. as long as you do not use spring-specific injection rules you should be fine. salve uses lookup by type primarily, but also does have @SpringBeanId that can be used as a qualifier. Of course,
IResourceStreamWriter
Has anybody tried to use a an impl of IResourceStreamWriter? I created one and I have a link that set this to the RequestCyle in an on click. When I click the link, nothing happens in the browser, but I can use a debugger and see the impl get called and my code is writting to the OutputStream. I am probably missing something obvious... Douglas - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: IResourceStreamWriter
I just discovered the issue. It is a because I was using an AjaxFallbackLink, I switch it to a regular Link and now it works. However, as a side effect of clicking this link, I'd like make some changes to the screen, i.e. I need an AjaxRequestTarget. Is it possible to trigger a download using an AjaxFallbackLink? Douglas Douglas Ferguson wrote: Has anybody tried to use a an impl of IResourceStreamWriter? I created one and I have a link that set this to the RequestCyle in an on click. When I click the link, nothing happens in the browser, but I can use a debugger and see the impl get called and my code is writting to the OutputStream. I am probably missing something obvious... Douglas - 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: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model?
to keep memory overhread low only the last visisted page is stored in http session. the rest of the pages are spooled to disk for long-term storage in case the user uses the back button, and are cleaned up on session expiration. -igor On Thu, May 28, 2009 at 6:54 PM, Chris Colman chr...@stepaheadsoftware.com wrote: When you say offline storage do you mean that the user has chosen to save pages for future offline reference or do you mean a more 'automated' process that wicket performs when system memory becomes too low? Chris -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, 29 May 2009 11:43 AM To: users@wicket.apache.org Subject: Re: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model? well, this is why salve removes the dependency field to at least help with those. other then that you can use a loadabledetachablemodel to release the reference when the page is not used. -igor On Thu, May 28, 2009 at 6:40 PM, Chris Colman chr...@stepaheadsoftware.com wrote: Is that controllable? What if I have complex object models referenced from wicket UI components that I don't want (can't reasonably with Java's non optimal serialization) serialized? If we're serializing for offline storage aren't we going to require the underlying model objects to get serialized as well? -Original Message- serialization in the context when you need to serialize the object - eg wicket serializes its pages for offline storage, etc. -igor On Thu, May 28, 2009 at 5:51 PM, Chris Colman chr...@stepaheadsoftware.com wrote: Another extremely light weight IoC with ORM wrapping (JDO and Hibernate) is exPOJO at http://www.expojo.com No need for old fashioned DAOs etc., just POJOs being persisted transparently the way they should be. In terms of serialization: Is that for the purpose of scaling in a cluster environment? I vote for 'session affinity' every time - it's almost necessary when you have anything more sophisticated than an anemic domain model. Do you really want to be shifting complex object models from server to server via serialization? If it's not for a cluster environment but for a single server to allow stale sessions to be swapped out then let the garbage collection clean out the ORM's object cache instead. -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, 29 May 2009 3:38 AM To: users@wicket.apache.org Subject: Re: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model? On Thu, May 28, 2009 at 10:09 AM, Kent Larsson kent.lars...@gmail.com wrote: Nice! I think Salve looks great! And it solves more than this problem, I like the design by contract module too as it allows me to validate parameters in a bit more declarative way. Do you think Salve is ready to be used in production? I'm a bit concerned by Although already usable, Salve is still in its infancy. Not all features have been implemented and not all problems worked out.. I only see one open issue and it doesn't seem too major for me to pick it up. we have been using it in production for a while without any problems. i just need to find the time to update the website text :) If I'm not mistaken Salve may be used (for lots of things, but one is) to solve serialization issues with Spring beans in Wicket components? But isn't that the same issue that the Wicket IOC and it's @SpringBean annotation solves? wicket ioc can only take it so far. because it has to generate a proxy there are limitations to what classes can be proxies - eg no final methods, default constructor, etc. salve doesnt use a proxy so it doesnt have any problems. although small, wicket ioc does have an overhead of having to serialize the proxy with the componnet. since salve removes the field it has no such overhead, this is more important when you are returning large resultsets of entities that use dependencies. If that's the case: Could I use Spring to inject my entities with DAO's for now, and use the @SpringBean annotation on those as well in my Wicket components (In those cases I have entities as class vars)? And the @SpringBean will solve the serialization issue? you can use whatever works for you. salve is an alternative :) By just looking at Salve a bit it seems I could migrate to Salve in two steps that way. And it might be a pretty smooth path to take? It would mean that I inject 1000 entities for no good reason. But if I see a performance problem in doing so I could just migrate to Salve? By smooth path I mean that I would have
RE: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model?
Is that a relatively new feature because we're still on 1.4m2 (2008/05/24) and haven't had any trouble with non serializeable model objects when going back to pages that have been spooled to disk. Maybe if it's a newer feature and we upgrade to the latest wicket we might start seeing some problems due to the lack of serializability of our model objects hmmm Chris to keep memory overhread low only the last visisted page is stored in http session. the rest of the pages are spooled to disk for long-term storage in case the user uses the back button, and are cleaned up on session expiration. -igor On Thu, May 28, 2009 at 6:54 PM, Chris Colman chr...@stepaheadsoftware.com wrote: When you say offline storage do you mean that the user has chosen to save pages for future offline reference or do you mean a more 'automated' process that wicket performs when system memory becomes too low? Chris -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, 29 May 2009 11:43 AM To: users@wicket.apache.org Subject: Re: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model? well, this is why salve removes the dependency field to at least help with those. other then that you can use a loadabledetachablemodel to release the reference when the page is not used. -igor On Thu, May 28, 2009 at 6:40 PM, Chris Colman chr...@stepaheadsoftware.com wrote: Is that controllable? What if I have complex object models referenced from wicket UI components that I don't want (can't reasonably with Java's non optimal serialization) serialized? If we're serializing for offline storage aren't we going to require the underlying model objects to get serialized as well? -Original Message- serialization in the context when you need to serialize the object - eg wicket serializes its pages for offline storage, etc. -igor On Thu, May 28, 2009 at 5:51 PM, Chris Colman chr...@stepaheadsoftware.com wrote: Another extremely light weight IoC with ORM wrapping (JDO and Hibernate) is exPOJO at http://www.expojo.com No need for old fashioned DAOs etc., just POJOs being persisted transparently the way they should be. In terms of serialization: Is that for the purpose of scaling in a cluster environment? I vote for 'session affinity' every time - it's almost necessary when you have anything more sophisticated than an anemic domain model. Do you really want to be shifting complex object models from server to server via serialization? If it's not for a cluster environment but for a single server to allow stale sessions to be swapped out then let the garbage collection clean out the ORM's object cache instead. -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, 29 May 2009 3:38 AM To: users@wicket.apache.org Subject: Re: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model? On Thu, May 28, 2009 at 10:09 AM, Kent Larsson kent.lars...@gmail.com wrote: Nice! I think Salve looks great! And it solves more than this problem, I like the design by contract module too as it allows me to validate parameters in a bit more declarative way. Do you think Salve is ready to be used in production? I'm a bit concerned by Although already usable, Salve is still in its infancy. Not all features have been implemented and not all problems worked out.. I only see one open issue and it doesn't seem too major for me to pick it up. we have been using it in production for a while without any problems. i just need to find the time to update the website text :) If I'm not mistaken Salve may be used (for lots of things, but one is) to solve serialization issues with Spring beans in Wicket components? But isn't that the same issue that the Wicket IOC and it's @SpringBean annotation solves? wicket ioc can only take it so far. because it has to generate a proxy there are limitations to what classes can be proxies - eg no final methods, default constructor, etc. salve doesnt use a proxy so it doesnt have any problems. although small, wicket ioc does have an overhead of having to serialize the proxy with the componnet. since salve removes the field it has no such overhead, this is more important when you are returning large resultsets of entities that use dependencies. If that's the case: Could I use Spring to inject my entities with DAO's for now, and use the @SpringBean annotation on those as well in my Wicket components (In those
Re: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model?
noep, there since 1.3.6 and enabled by default. if you use httpsessionstore the problem will only appear when clustering or when servlet container spools sessions to disk. -igor On Thu, May 28, 2009 at 7:26 PM, Chris Colman chr...@stepaheadsoftware.com wrote: Is that a relatively new feature because we're still on 1.4m2 (2008/05/24) and haven't had any trouble with non serializeable model objects when going back to pages that have been spooled to disk. Maybe if it's a newer feature and we upgrade to the latest wicket we might start seeing some problems due to the lack of serializability of our model objects hmmm Chris to keep memory overhread low only the last visisted page is stored in http session. the rest of the pages are spooled to disk for long-term storage in case the user uses the back button, and are cleaned up on session expiration. -igor On Thu, May 28, 2009 at 6:54 PM, Chris Colman chr...@stepaheadsoftware.com wrote: When you say offline storage do you mean that the user has chosen to save pages for future offline reference or do you mean a more 'automated' process that wicket performs when system memory becomes too low? Chris -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, 29 May 2009 11:43 AM To: users@wicket.apache.org Subject: Re: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model? well, this is why salve removes the dependency field to at least help with those. other then that you can use a loadabledetachablemodel to release the reference when the page is not used. -igor On Thu, May 28, 2009 at 6:40 PM, Chris Colman chr...@stepaheadsoftware.com wrote: Is that controllable? What if I have complex object models referenced from wicket UI components that I don't want (can't reasonably with Java's non optimal serialization) serialized? If we're serializing for offline storage aren't we going to require the underlying model objects to get serialized as well? -Original Message- serialization in the context when you need to serialize the object - eg wicket serializes its pages for offline storage, etc. -igor On Thu, May 28, 2009 at 5:51 PM, Chris Colman chr...@stepaheadsoftware.com wrote: Another extremely light weight IoC with ORM wrapping (JDO and Hibernate) is exPOJO at http://www.expojo.com No need for old fashioned DAOs etc., just POJOs being persisted transparently the way they should be. In terms of serialization: Is that for the purpose of scaling in a cluster environment? I vote for 'session affinity' every time - it's almost necessary when you have anything more sophisticated than an anemic domain model. Do you really want to be shifting complex object models from server to server via serialization? If it's not for a cluster environment but for a single server to allow stale sessions to be swapped out then let the garbage collection clean out the ORM's object cache instead. -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, 29 May 2009 3:38 AM To: users@wicket.apache.org Subject: Re: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model? On Thu, May 28, 2009 at 10:09 AM, Kent Larsson kent.lars...@gmail.com wrote: Nice! I think Salve looks great! And it solves more than this problem, I like the design by contract module too as it allows me to validate parameters in a bit more declarative way. Do you think Salve is ready to be used in production? I'm a bit concerned by Although already usable, Salve is still in its infancy. Not all features have been implemented and not all problems worked out.. I only see one open issue and it doesn't seem too major for me to pick it up. we have been using it in production for a while without any problems. i just need to find the time to update the website text :) If I'm not mistaken Salve may be used (for lots of things, but one is) to solve serialization issues with Spring beans in Wicket components? But isn't that the same issue that the Wicket IOC and it's @SpringBean annotation solves? wicket ioc can only take it so far. because it has to generate a proxy there are limitations to what classes can be proxies - eg no final methods, default constructor, etc. salve doesnt use a proxy so it doesnt have any problems. although small, wicket ioc does have an overhead of having to serialize the proxy with the componnet. since salve removes the field it has no such overhead, this is more
Re: unit test of AjaxLazyLoadPanel and ModalWindow
And boom! Thanks for the inspiration Frank!
final WicketTester wc = constructBasicPanel();
wc.debugComponentTrees();
wc.dumpPage();
// delicious is the constructed panel, which contains a AjaxLazyLoadPanel...
// visit it's children, looking for the AjaxLazyLoadPanel
delicious.visitChildren( AjaxLazyLoadPanel.class, new
IVisitorAjaxLazyLoadPanel(){
@Override
public Object component(AjaxLazyLoadPanel component) {
// get the AbstractAjaxBehaviour which is responsible for getting the
contents of the lazy panel
ListIBehavior behaviors = component.getBehaviors();
final AbstractAjaxBehavior b;
b = (AbstractAjaxBehavior) behaviors.get( 0 );
// tell wicket tester to execute it :)
wc.executeBehavior( b );
// continue with visitation rights, or not, i don't care
return null;
}} );
wc.debugComponentTrees();
wc.dumpPage();
// and volah, your lazy panel is now replaced with the contents :)
wc.assertComponent(
panel:lazy:content:repeaterContainer:bookmarks:1, Item.class );
wc.assertInvisible( panel:lazy:content:noBookmarks );
Let me know what you think or if you have any improvements!
Antony Stubbs wrote:
Thanks for the info Frank. Any tips on how to do so?
Frank Bille wrote:
On Thu, Apr 24, 2008 at 8:10 PM, qk wuhanqiangk...@gmail.com wrote:
1. after the page was rendered using WicketTester.startPage(), the
real
content (the one that returned by getLazyLoadComponent()) was not
loaded by
default. I always got an empty panel. Is there a way that I can have
the
real content rendered?
Wicket tester doesn't parse javascript, so it can't execute the ajax
callback. You have to do that yourself.
Frank
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
___
http://stubbisms.wordpress.com http://stubbisms.wordpress.com
--
View this message in context:
http://www.nabble.com/unit-test-of-AjaxLazyLoadPanel-and-ModalWindow-tp16851306p23773322.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: unit test of AjaxLazyLoadPanel and ModalWindow
And here's a nicer version to add to your library:
/**
* Triggers an {...@link AjaxLazyLoadPanel} to fetch it's contents.
*
* @param wc the {...@link WicketTester} to execute the behaviour (
{...@link
WicketTester#executeBehavior} ).
* @param container contains the {...@link AjaxLazyLoadPanel} to trigger
*/
private void executeAjaxLazyLoadPanel(final WicketTester wc, Panel
container) {
container.visitChildren( AjaxLazyLoadPanel.class, new
IVisitorAjaxLazyLoadPanel() {
@Override
public Object component(AjaxLazyLoadPanel component) {
ListIBehavior behaviors = component.getBehaviors();
// get the AbstractAjaxBehaviour which is responsible for
// getting the contents of the lazy panel
AbstractAjaxBehavior b = (AbstractAjaxBehavior)
behaviors.get( 0 );
// tell wicket tester to execute it :)
wc.executeBehavior( b );
// continue with visitation rights, or not, i don't care
return CONTINUE_TRAVERSAL;
}
} );
}
Antony Stubbs wrote:
And boom! Thanks for the inspiration Frank!
final WicketTester wc = constructBasicPanel();
wc.debugComponentTrees();
wc.dumpPage();
// delicious is the constructed panel, which contains a
AjaxLazyLoadPanel...
// visit it's children, looking for the AjaxLazyLoadPanel
delicious.visitChildren( AjaxLazyLoadPanel.class, new
IVisitorAjaxLazyLoadPanel(){
@Override
public Object component(AjaxLazyLoadPanel component) {
// get the AbstractAjaxBehaviour which is responsible for getting the
contents of the lazy panel
ListIBehavior behaviors = component.getBehaviors();
final AbstractAjaxBehavior b;
b = (AbstractAjaxBehavior) behaviors.get( 0 );
// tell wicket tester to execute it :)
wc.executeBehavior( b );
// continue with visitation rights, or not, i don't care
return null;
}} );
wc.debugComponentTrees();
wc.dumpPage();
// and volah, your lazy panel is now replaced with the contents :)
wc.assertComponent(
panel:lazy:content:repeaterContainer:bookmarks:1, Item.class );
wc.assertInvisible( panel:lazy:content:noBookmarks );
Let me know what you think or if you have any improvements!
Antony Stubbs wrote:
Thanks for the info Frank. Any tips on how to do so?
Frank Bille wrote:
On Thu, Apr 24, 2008 at 8:10 PM, qk wuhanqiangk...@gmail.com wrote:
1. after the page was rendered using WicketTester.startPage(), the
real
content (the one that returned by getLazyLoadComponent()) was not
loaded by
default. I always got an empty panel. Is there a way that I can have
the
real content rendered?
Wicket tester doesn't parse javascript, so it can't execute the ajax
callback. You have to do that yourself.
Frank
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
___
http://stubbisms.wordpress.com http://stubbisms.wordpress.com
--
View this message in context:
http://www.nabble.com/unit-test-of-AjaxLazyLoadPanel-and-ModalWindow-tp16851306p23773356.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: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model?
Yep, we use HttpSessionStore in a non clustered environment. We also turn off session persistence in Tomcat in context.xml with Manager pathname= / So we there should be no session spooling to disk by the servlet container. Cool, I can relax now =] noep, there since 1.3.6 and enabled by default. if you use httpsessionstore the problem will only appear when clustering or when servlet container spools sessions to disk. -igor On Thu, May 28, 2009 at 7:26 PM, Chris Colman chr...@stepaheadsoftware.com wrote: Is that a relatively new feature because we're still on 1.4m2 (2008/05/24) and haven't had any trouble with non serializeable model objects when going back to pages that have been spooled to disk. Maybe if it's a newer feature and we upgrade to the latest wicket we might start seeing some problems due to the lack of serializability of our model objects hmmm Chris to keep memory overhread low only the last visisted page is stored in http session. the rest of the pages are spooled to disk for long-term storage in case the user uses the back button, and are cleaned up on session expiration. -igor On Thu, May 28, 2009 at 6:54 PM, Chris Colman chr...@stepaheadsoftware.com wrote: When you say offline storage do you mean that the user has chosen to save pages for future offline reference or do you mean a more 'automated' process that wicket performs when system memory becomes too low? Chris -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, 29 May 2009 11:43 AM To: users@wicket.apache.org Subject: Re: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model? well, this is why salve removes the dependency field to at least help with those. other then that you can use a loadabledetachablemodel to release the reference when the page is not used. -igor On Thu, May 28, 2009 at 6:40 PM, Chris Colman chr...@stepaheadsoftware.com wrote: Is that controllable? What if I have complex object models referenced from wicket UI components that I don't want (can't reasonably with Java's non optimal serialization) serialized? If we're serializing for offline storage aren't we going to require the underlying model objects to get serialized as well? -Original Message- serialization in the context when you need to serialize the object - eg wicket serializes its pages for offline storage, etc. -igor On Thu, May 28, 2009 at 5:51 PM, Chris Colman chr...@stepaheadsoftware.com wrote: Another extremely light weight IoC with ORM wrapping (JDO and Hibernate) is exPOJO at http://www.expojo.com No need for old fashioned DAOs etc., just POJOs being persisted transparently the way they should be. In terms of serialization: Is that for the purpose of scaling in a cluster environment? I vote for 'session affinity' every time - it's almost necessary when you have anything more sophisticated than an anemic domain model. Do you really want to be shifting complex object models from server to server via serialization? If it's not for a cluster environment but for a single server to allow stale sessions to be swapped out then let the garbage collection clean out the ORM's object cache instead. -Original Message- From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] Sent: Friday, 29 May 2009 3:38 AM To: users@wicket.apache.org Subject: Re: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model? On Thu, May 28, 2009 at 10:09 AM, Kent Larsson kent.lars...@gmail.com wrote: Nice! I think Salve looks great! And it solves more than this problem, I like the design by contract module too as it allows me to validate parameters in a bit more declarative way. Do you think Salve is ready to be used in production? I'm a bit concerned by Although already usable, Salve is still in its infancy. Not all features have been implemented and not all problems worked out.. I only see one open issue and it doesn't seem too major for me to pick it up. we have been using it in production for a while without any problems. i just need to find the time to update the website text :) If I'm not mistaken Salve may be used (for lots of things, but one is) to solve serialization issues with Spring beans in Wicket components? But isn't that the same issue that the Wicket IOC and it's @SpringBean annotation solves? wicket ioc can only take it
Re: Expired sign in link after signing out
Same error in 1.3.6. Worked in 1.4-rc4. Thanks for the suggestion.
Tim
Jeremy Thomerson-5 wrote:
If you're on 1.3.2 can you try upgrading to at least the latest 1.3.X
release (or even better, 1.4-rc4) to see if that doesn't fix it?
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, May 27, 2009 at 7:34 AM, Tim Moose hungl...@gmail.com wrote:
add(new BookmarkablePageLink(signin, SigninPage.class));
That is one thing I tried, but it didn't work for me. I am using
org.apache.wicket.authentication.panel.SignInPanel and with the above
bookmarkable link, I get the following exception in onSignInSucceeded:
java.lang.IllegalArgumentException: wrong number of arguments
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at
org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:149)
at
org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:88)
at org.apache.wicket.authentication.panel.SignInPanel
onSignInSucceeded(SignInPage.java:65)
I'm not able to spot the problem from the 1.3.2 source code:
protected void onSignInSucceeded()
{
// If login has been called because the user was not yet
// logged in, than continue to the original destination,
// otherwise to the Home page
if (!continueToOriginalDestination())
{
setResponsePage(getApplication().getSessionSettings().getPageFactory().newPage(
getApplication().getHomePage(),
(PageParameters)null));
}
}
I did verify that getHomePage() is correctly returning my home page class
and my home page constructors look like this:
public Index() {
this(null);
}
public Index(final PageParameters parameters) {
super(parameters);
}
Any idea what I'm doing wrong?
Thanks,
Tim
--
View this message in context:
http://www.nabble.com/Expired-sign-in-link-after-signing-out-tp23732685p23741603.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
--
View this message in context:
http://www.nabble.com/Expired-sign-in-link-after-signing-out-tp23732685p23773978.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: Anemic domain model and are @SpringBean's compatible with the solution in Spring 2.0 vs. the Anemic Domain Model?
On Thu, May 28, 2009 at 11:36 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: this is why i built salve.googlecode.com you can easily hook it into spring and have all your objects (doman objects or wicket components) injected via @Dependency without worrying about serialization issues or eager injection - eg if you load a result set of 1000 hibernate entities that need injection you dont want all those injected for no reason. I try not to design my domain models in such a way, but sometimes it just fits if you want to be domain-driven and salve definitely is a good alternative to the @Configurable/@Autowire support in Spring. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: nested loop view
Can you please share the solution?
I am doing something similar and I get java.lang.IllegalArgumentException: A
child with id 'reoirtItems' already exists
/*java*/
add(new ListView(reportList, reportVector) {
public void populateItem(final ListItem listItem) {
VectorReportItem reportItems = ((ReportDAO)
listItem
.getModelObject()).getReportItems();
add(new ListView(reportItems, reportItems) {
protected void populateItem(final
ListItem reportItem) {
ReportItem item = (ReportItem)
reportItem
.getModelObject();
int copyId = item.getCopyID();
String image =
item.getItemImage();
String itemClass =
item.getItemClass();
String itemSubClass =
item.getItemSubClass();
String itemLocation =
item.getItemLocation();
String actionDate =
item.getActionDate();
String status = item.getState();
String userID =
item.getUserID();
reportItem.add(new
Label(image,
(image == null)
? Unavailable : image));
reportItem
.add(new Label(
itemClass,
(itemClass.equals(NA) || itemClass == null) ? Unavailable
: itemClass));
reportItem.add(new
Label(itemSubClass,
(itemSubClass
== null) ? Unavailable
: itemSubClass));
reportItem.add(new
Label(itemLocation,
(itemLocation
== null) ? Unavailable
: itemLocation));
reportItem
.add(new
Label(actionDate,
actionDate == null ? Unavailable
: actionDate));
reportItem.add(new
Label(status,
status == null
? Unavailable : status));
reportItem.add(new Label(user,
userID == null
? Unavailable : userID));
}
});
}
});
/*HTML*/
table wicket:id=reportList
table wicket:id=reportItems
tr
-
/tr
td wicket:id=image[image path]/td
td
table
tr
td class=labelTitle:/td
td wicket:id=title[Item's Title]/td
/tr
tr
td class=labelClass:/td
td wicket:id=itemClass[class]/td
/tr
tr
td class=labelSub-Class:/td
td wicket:id=itemSubClass[subclass]/td
/tr
tr
td class=labelLocation:/td
td wicket:id=itemLocation[location]/td
/tr
tr
td class=labelDate:/td
td wicket:id=actionDate[Action Date]/td
/tr
tr
td class=labelStatus:/td
td wicket:id=itemStatus[item state]/td
Re: [announce] Wicket 1.4-rc4 released
Is it just me, or is there no rc4 tag in svn? I only see rc3. Regards, Antony Stubbs, NZ http://friendfeed.com/astubbs On 12/05/2009, at 6:13 AM, Jeremy Thomerson wrote: The Apache Wicket team is proud to announce the availability of the fourth release candidate for the newest version of Wicket - 1.4. A lot of bugs have been squashed and several improvements implemented. If you are already using earlier versions of 1.4, it is recommended you update to Wicket 1.4-rc4 at your earliest convenience. Eager people click here to download the distribution, others can read further: http://www.apache.org/dyn/closer.cgi/wicket/1.4-rc4 We thank you for your patience and support. - The Wicket Team Apache Wicket Apache Wicket is a component oriented Java web application framework. With proper mark-up/logic separation, a POJO data model, and a refreshing lack of XML, Apache Wicket makes developing web-apps simple and enjoyable again. Swap the boilerplate, complex debugging and brittle code for powerful, reusable components written with plain Java and HTML. You can find out more about Apache Wicket on our website: http://wicket.apache.org This release This release is the fourth release candidate for the Wicket 1.4 product. This release fixes several bugs and adds some minor improvements. You can find out about the changes at the bottom of this announcement. Migrating from 1.2 If you are coming from Wicket 1.3, you really want to read our migration guide, found on the wiki: http://cwiki.apache.org/WICKET/migrate-14.html Downloading the release: You can download the release from the official Apache mirror system, and you can find it through the following link: http://www.apache.org/dyn/closer.cgi/wicket/1.4-rc4/ For the Maven and Ivy fans out there: update your pom's to the following, and everything will be downloaded automatically: dependency groupIdorg.apache.wicket/groupId artifactIdwicket/artifactId version1.4-rc4/version /dependency Substitute the artifact ID with the projects of your liking to get the other projects. Please note that we don't prescribe a Logging implementation for SLF4J. You need to specify yourself which one you prefer. Read more about SLF4J here: http://slf4j.org Validating the release The release has been signed by Jeremy Thomerson, your release manager for today. The public key can be found in the KEYS file in the download area. Download the KEYS file only from the Apache website. http://www.apache.org/dist/wicket/1.4-rc4/KEYS Instructions on how to validate the release can be found here: http://www.apache.org/dev/release-signing.html#check-integrity Reporting bugs In case you do encounter a bug, we would appreciate a report in our JIRA: http://issues.apache.org/jira/browse/WICKET The distribution In the distribution you will find a README. The README contains instructions on how to build from source yourself. You also find a CHANEGELOG-1.4 which contains a list of all things that have been fixed, added and/or removed since the 1.4 branch was created. Release Notes - Wicket - Version 1.4-RC4 ** Bug * [WICKET-1960] - AutoCompleteTextField - gives a type mismatch error on IE - version wicket-1.4-rc1 * [WICKET-2241] - Guice integration doesn't honour optional bindings * [WICKET-2250] - IOptionRenderer getModel(Object value) should change to getModel(T value) * [WICKET-2251] - LoadableDeatachableModel onDetach() invoked after nulling the model ** New Feature * [WICKET-2255] - Simple changes for datepicker/datefield Release Notes - Wicket - Version 1.4-RC3 ** Bug * [WICKET-1673] - Toggling visibility on nested Borders breaks page markup * [WICKET-1861] - Inevitable UnknownSizeException with HTTPS * [WICKET-2000] - AjaxRequestTarget escapes ] to ]^ * [WICKET-2005] - pb to access to this on event onchange on the AutoCompleteTextField * [WICKET-2015] - Empty File Upload field breaks validation of other fields in WicketTester. * [WICKET-2022] - wicket fails on WebLogic 9.2 clustered * [WICKET-2024] - AutoComplete ShowListOnFocusGain not working * [WICKET-2049] - beforeRender not called for behaviour added to ComponentTag * [WICKET-2060] - Invalid javascript when setStripJavascriptCommentsAndWhitespace is enabled * [WICKET-2061] - interceptContinuationURL with umlauts not encoded * [WICKET-2071] - Wicket-Examples Nested example fails with a NPE * [WICKET-2077] - SerializationChecker issue * [WICKET-2079] - Component Use Check always fails for visible components inside an invisible border body * [WICKET-2083] - NPE when clearing DateTimeField * [WICKET-2086] - setOutputMarkupContainerClassName() ... and wrong render mode in IE7 * [WICKET-2087] - typo in SpringBeanLocator.java * [WICKET-2088] - ApacheLicenceHeaderTests fail after projects' metadata created by Eclipse * [WICKET-2091] - Error feedback is hidden by lower level messages * [WICKET-2092] - SignInPanel IllegalArgumentException exception
