[jira] Commented: (WICKET-1312) Generic inter-component event mechanism
[ https://issues.apache.org/jira/browse/WICKET-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570139#action_12570139 ] Edward Yakop commented on WICKET-1312: -- This is a great patch. This would enable a more elegant way to handle AjaxRequestTarget#addComponent. If possible, please make this feature available for the next wicket 1.3.2 release. Generic inter-component event mechanism --- Key: WICKET-1312 URL: https://issues.apache.org/jira/browse/WICKET-1312 Project: Wicket Issue Type: New Feature Components: wicket-extensions Affects Versions: 1.3.0-final Reporter: Timo Rantalaiho Fix For: 1.4-M1 Attachments: Generic_EventBroadcaster.patch, Generic_EventBroadcaster_glued_in_Component.patch The attached patch provides a generic mechanism for transmitting inter-component events within a page. This has grown primarily from the need to repaint all relevant ajax components after an event, but can be used also in non-ajax environments such as after normal form submits. The basic idea is to fire an IVisitor on the page of the component sending an event, giving as an argument an event-specific listener interface that must be implemented by the components willing to receive the events. They can then do whatever they need such as add themselves to the AjaxRequestTarget that can be supplied in the event. Sometimes the basic Wicket mechanisms such as sharing a model are not enough; particularly repainting all relevant components in Ajax events gets tedious if the components are far away from each other in a complex DOM tree. The benefits of this approach are - loose coupling between the sending and receiving end - however, because of strong static typing it's easy enough to find with an IDE from where the events are broadcasted and where they are received - good testability (EventBroadcaster can be mocked on the sending end, and event handlers tested directly on the receiving end, possibly with mock events) - no need the keep references to Component instances or their paths (which could have been problematic on repeaters) (This is not a real observer or listener pattern implementation because the components cannot register and unregister themselves dynamically, but registering is handled statically on a class basis by implementing the relevant event receiver interface.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[CONF] Apache Wicket: Wasp-Swarm (Security) (page created)
Page Created : WICKET : Wasp-Swarm (Security) Wasp-Swarm (Security) has been created by Will Hoover (Feb 19, 2008). Content: Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request Unsubscribe or edit your notifications preferences
[jira] Commented: (WICKET-1243) the DatePicker show the same week title in china.
[ https://issues.apache.org/jira/browse/WICKET-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570362#action_12570362 ] Gerolf Seitz commented on WICKET-1243: -- can you provide a patch for TAIWAN and TRADITIONAL_CHINESE? that would be great. the DatePicker show the same week title in china. --- Key: WICKET-1243 URL: https://issues.apache.org/jira/browse/WICKET-1243 Project: Wicket Issue Type: Bug Components: wicket-datetime Affects Versions: 1.3.0-beta4, 1.3.0-rc1, 1.3.0-rc2 Environment: in chinese(zh_CN) language Reporter: Julian Ding Assignee: Gerolf Seitz Priority: Minor Fix For: 1.3.1 Attachments: screenshot-1.jpg, screenshot-2.jpg the DatePicker show the same week title in china. you can see it here in the first pic. if DatePicker can show as the last pic is the best: i have correct this on my own version. i will submit the solution tomorrow -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[CONF] Apache Wicket: Spring (page edited)
Page Edited :
WICKET :
Spring
Spring
has been edited by Rob Guest
(Feb 19, 2008).
Change summary:
added "org.apache." to Wicket class names in web.xml listing
(View changes)
Content:
Bookmarkable link
Table of contents
The Issues
Wicket is an unmanaged framework
Wicket components and models are often serialized
Solutions
Application Object Approach
Proxy-based Approach
Annotation-based Approach
Unit Testing the Proxy Approach
Beyond Spring
wicket-spring project is in the subversion alongside wicket
also look at wicket-spring-examples, wicket-spring-annot, and wicket-spring-annot-examples projects.
Some knowledge of spring is required
In wicket the Page class is a subclass of Component, so from here on the word component can represent either a component or a page.
This is only the first pass at the documentation so its far from perfect
Feel free to add new content and fix any mistakes you find.
The Issues
Most problems with injecting dependencies from an IOC container come from the following
wicket is an unmanaged framework
wicket components and models are often serialized
Wicket is an unmanaged framework
Wicket does not manage the lifecycle of its components. This means that a page or a component can be created anywhere in the code by simply using the new operator. This makes it difficult to inject dependencies because it is difficult to intercept the creation of the component. A possible solution can be to use a singleton factory to create the components and subsequently inject them with dependencies. However, this approach is not very flexible because it is often more convinient to have specific constructors in components rather then the default empty constructor. ie
class EditUserPage extends WebPage {
public EditUserPage(long userId) {...}
}
...
setResponsePage(new EditUserPage(userId));
is far more convenient than
class EditUserPage extends WebPage {
public EditUserPage() {...}
void setUserId(long userId) {...}
}
...
PageFactory factory=getPageFactory();
EditUserPage page=(EditUserPage)factory.createPage(EditUserPage.class);
page.setUserId(userId);
setResponsePage(page);
Wicket components and models are often serialized
Wicket keeps its tree of components in the session. In a clustered environment, session data needs to be replicated across the cluster. This is done by serializing objects in a cluster-node's session and deserializing them on another cluster-node's session. This presents a problem for dependency injection because it is not desirable to serialize the dependency. Dependencies often have references to other dependencies in the container, and so if one is serialized it will probably serialize a few others and can possibly cascade to serializing the entire container. To say the least, this is undesirable. Even if the cascading is not a problem and the dependency is serialized, when it deserializes it will no longer be part of the conainer - it will be a stand alone clone. This is also undesirable.
Solutions
Application Object Approach
Wicket applications have a global application object which is a subclass of Application. This global application object is only created once per application and is never serialized (since it contains no user-specific data and thus remains the same across all nodes in the cluster). These qualities make it a good candidate to act as a service locator for the rest of the application. Wicket allows you to provide a custom factory for creating this object, the wicket-contrib-spring project provides such a factory (SpringWebApplicationFactory) that, instead of creating an instance, pulls it out of the spring application context. Wicket keeps the instance of the application object in a threadlocal variable and provides various helper methods in components to get to it, so it is easy to retrieve dependencies in wicket components.
Example:
web.xml:
...
servlet
servlet-namewicket/servlet-name
servlet-classorg.apache.wicket.protocol.http.WicketServlet/servlet-class
init-param
param-nameapplicationFactoryClassName/param-name
param-valueorg.apache.wicket.spring.SpringWebApplicationFactory/param-value
/init-param
load-on-startup1/load-on-startup
/servlet
...
!-- The SpringWebApplicationFactory will need access to a Spring Application context, configured like this... --
context-param
param-namecontextConfigLocation/param-name
param-value/WEB-INF/applicationContext.xml/param-value
/context-param
listener
listener-classorg.springframework.web.context.ContextLoaderListener/listener-class
/listener
...
applicationContext.xml:
...
!-- setup wicket application --
bean id="wicketApplication" class="project.MyApplication"
property name="contactDao" ref="contactDao"/
/bean
[CONF] Apache Wicket: Using GWT Widgets as Wicket Components (Tutorial) (comment added)
Comment Added : WICKET : Re: Using GWT Widgets as Wicket Components (Tutorial) Using GWT Widgets as Wicket Components (Tutorial) commented on by Kevin Murphy (Feb 19, 2008). Comment: No tutorial here, harrumph. Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request Unsubscribe or edit your notifications preferences
[jira] Commented: (WICKET-1332) AjaxFormChoiceComponentUpdatingBehavior just updates the group grandchildren
[
https://issues.apache.org/jira/browse/WICKET-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570459#action_12570459
]
Carlos Pita commented on WICKET-1332:
-
Here is a shorter, safer and faster version that uses getElementsByTagName
instead of a recursive descent. It also checks for the type of input fields in
order to attach handlers just to radios and checkboxes.
asb.append(function attachChoiceHandlers(markupId, callbackScript)
{\n);
asb.append( var inputNodes =
wicketGet(markupId).getElementsByTagName('input');\n);
asb.append( for (var i = 0 ; i inputNodes.length ; i ++) {\n);
asb.append(var inputNode = inputNodes[i];\n);
asb.append(if (!inputNode.type) continue;\n);
asb.append(var inputType = inputNode.type.toLowerCase();\n);
asb.append(if (inputType == 'check' || inputType == 'radio') {\n);
asb.append( Wicket.Event.add(inputNode, 'click',
callbackScript);\n);
asb.append(}\n);
asb.append( }\n);
asb.append(}\n);
AjaxFormChoiceComponentUpdatingBehavior just updates the group grandchildren
--
Key: WICKET-1332
URL: https://issues.apache.org/jira/browse/WICKET-1332
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.1
Reporter: Carlos Pita
Assignee: Matej Knopp
Up to 1.3.0, there was a bug in that AjaxFormChoiceComponentUpdatingBehavior
updated just the group's direct children. Now it generates the header script
quoted below, that iterates over the direct children and then over the
children of these, triggering the event for the input grandchildren only. So
the situation is even worse. I think that attachChoiceHandlers should descend
recursively and search for input elements along all the group descendants,
not just one arbitrarily chosen level.
function attachChoiceHandlers(markupid, callbackscript) {
var choiceElementGroup = document.getElementById(markupid);
for( var x = 0; x choiceElementGroup.childNodes.length; x++ ) {
var choiceElementList = choiceElementGroup.childNodes[x]; for( var y =
0; y choiceElementList.childNodes.length; y++ ) {
if (choiceElementList.childNodes[y]
choiceElementList.childNodes[y].tagName) {
var tag = choiceElementList.childNodes[y].tagName.toLowerCase();
if (tag == 'input') {
Wicket.Event.add(choiceElementList.childNodes[y],'click',
callbackscript); }
}
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1358) Make Application Class More Bean-ish
[ https://issues.apache.org/jira/browse/WICKET-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-1358: - Attachment: WICKET-1358.patch Here's what I have in mind. So far, I've only implemented ApplicationSettings, DebugSettings, and ExceptionSettings, but you'll get the idea of what I'm wanting to do. I don't want to the rest if you guys don't like the idea in the first place (it takes a bit of time to do this). If you like the idea, let me know and I'll finish it up and attach a patch. Thanks. Make Application Class More Bean-ish Key: WICKET-1358 URL: https://issues.apache.org/jira/browse/WICKET-1358 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.1 Reporter: James Carman Attachments: WICKET-1358.patch The Application class has getters for properties like applicationSettings and securitySettings. Couldn't we make those properties writable also? I realize that the internal implementation might have to change a bit. Currently, the Settings class implements all of those interfaces and it uses a single instance of Settings by default. The reason that I want this is so that I can set up my Application object in Spring and access it via wicket-spring. The current implementation of Application doesn't facilitate the set up part very well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1358) Make Application Class More Bean-ish
[ https://issues.apache.org/jira/browse/WICKET-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-1358: - Attachment: WICKET-1358.patch Here's the full patch. All test cases pass with this. I had to modify the existing test case for application settings so that it tested against the new Default* flavors of the different interfaces. I hope you guys like it. I think it makes it a bit cleaner (and it allows me to do what I want ;). Make Application Class More Bean-ish Key: WICKET-1358 URL: https://issues.apache.org/jira/browse/WICKET-1358 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.1 Reporter: James Carman Attachments: WICKET-1358.patch The Application class has getters for properties like applicationSettings and securitySettings. Couldn't we make those properties writable also? I realize that the internal implementation might have to change a bit. Currently, the Settings class implements all of those interfaces and it uses a single instance of Settings by default. The reason that I want this is so that I can set up my Application object in Spring and access it via wicket-spring. The current implementation of Application doesn't facilitate the set up part very well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1358) Make Application Class More Bean-ish
[ https://issues.apache.org/jira/browse/WICKET-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Carman updated WICKET-1358: - Attachment: (was: WICKET-1358.patch) Make Application Class More Bean-ish Key: WICKET-1358 URL: https://issues.apache.org/jira/browse/WICKET-1358 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.1 Reporter: James Carman Attachments: WICKET-1358.patch The Application class has getters for properties like applicationSettings and securitySettings. Couldn't we make those properties writable also? I realize that the internal implementation might have to change a bit. Currently, the Settings class implements all of those interfaces and it uses a single instance of Settings by default. The reason that I want this is so that I can set up my Application object in Spring and access it via wicket-spring. The current implementation of Application doesn't facilitate the set up part very well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1358) Make Application Class More Bean-ish
[ https://issues.apache.org/jira/browse/WICKET-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570538#action_12570538 ] James Carman commented on WICKET-1358: -- Wait, you guys can't all go on vacation at the same time! What happens if there's some freak accident!?!? Who's going to maintain Wicket!?!?! ;) Have fun! This will be waiting when you get back. No rush. Make Application Class More Bean-ish Key: WICKET-1358 URL: https://issues.apache.org/jira/browse/WICKET-1358 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.1 Reporter: James Carman Attachments: WICKET-1358.patch The Application class has getters for properties like applicationSettings and securitySettings. Couldn't we make those properties writable also? I realize that the internal implementation might have to change a bit. Currently, the Settings class implements all of those interfaces and it uses a single instance of Settings by default. The reason that I want this is so that I can set up my Application object in Spring and access it via wicket-spring. The current implementation of Application doesn't facilitate the set up part very well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1360) Wrong path separator in reloading classloader patterns
Wrong path separator in reloading classloader patterns
--
Key: WICKET-1360
URL: https://issues.apache.org/jira/browse/WICKET-1360
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.1
Reporter: Carlos Pita
public class WildcardMatcherHelper
{
[]
/** Default path separator: / */
public static final char PATHSEP = '/'; should be '.'
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
