[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.
[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-tabpanel&focusedCommentId=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] 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] 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] Created: (WICKET-1359) org.apache.wicket.Application's javadoc refers to getSessionFactory() which is deprecated
org.apache.wicket.Application's javadoc refers to getSessionFactory() which is deprecated - Key: WICKET-1359 URL: https://issues.apache.org/jira/browse/WICKET-1359 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.1 Reporter: Jacek Laskowski org.apache.wicket.Application's javadoc refers to getSessionFactory() which is deprecated and will soon be removed (getSessionFactory() - TODO remove after deprecation release). -- 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-tabpanel&focusedCommentId=12570533#action_12570533 ] Igor Vaynberg commented on WICKET-1358: --- a lot of core devs will be on a mini vacation in thailand for the next couple of weeks so we wont be able to get to this for a whle. just a heads up. ping the list again in a couple of weeks. > 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.
svn commit: r629303 - /wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/form/FormComponent.java
Author: ivaynberg
Date: Tue Feb 19 17:31:38 2008
New Revision: 629303
URL: http://svn.apache.org/viewvc?rev=629303&view=rev
Log:
javadoc improvement
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/form/FormComponent.java
Modified:
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/form/FormComponent.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/form/FormComponent.java?rev=629303&r1=629302&r2=629303&view=diff
==
---
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/form/FormComponent.java
(original)
+++
wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/html/form/FormComponent.java
Tue Feb 19 17:31:38 2008
@@ -35,6 +35,7 @@
import org.apache.wicket.markup.ComponentTag;
import org.apache.wicket.markup.html.border.Border;
import org.apache.wicket.model.IModel;
+import org.apache.wicket.model.IPropertyReflectionAwareModel;
import org.apache.wicket.util.convert.ConversionException;
import org.apache.wicket.util.convert.IConverter;
import org.apache.wicket.util.lang.Classes;
@@ -62,8 +63,14 @@
* component children.
*
* If this component is required and that fails, the error key that is used is
the "Required"; if
- * the type conversion fails, it will use the key "IConverter". The keys that
can be used in both
- * are:
+ * the type conversion fails, it will use the key "IConverter" if the
conversion failed in a
+ * converter, or "ConversionError" if type was explicitly specified via [EMAIL
PROTECTED] #setType(Class)} or a
+ * [EMAIL PROTECTED] IPropertyReflectionAwareModel} was used. Notice that both
"IConverter" and
+ * "ConversionError" have a more specific variant of "key.classname" where
classname is the type
+ * that we failed to convert to. Classname is not full qualified, so only the
actual name of the
+ * class is used.
+ *
+ * Property expressions that can be used in error messages are:
*
* ${input}: the input the user did give
* ${name}: the name of the component that failed
[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] 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-tabpanel&focusedCommentId=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.
[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-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-tabpanel&focusedCommentId=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:
...
wicket
org.apache.wicket.protocol.http.WicketServlet
applicationFactoryClassName
org.apache.wicket.spring.SpringWebApplicationFactory
1
...
contextConfigLocation
/WEB-INF/applicationContext.xml
org.springframework.web.context.ContextLoaderListener
...
applicationContext.xml:
...
"wicketApplication" class="project.MyApplication">
"contactDao" ref="contactDao"/>
...
code:
class MyApplication extends WebApplication {
private ContactDao dao;
public void setContactDao(ContactDao dao) { this.dao=dao; }
public ContactDao getContactDao() { return dao; }
}
class BasePage extends WebPage {
ContactDao getContactDao() {
return ((MyApplication)getApplication()).getContactDao();
}
class EditContact extends BasePage {
public EditContact(long id) {
Form form=new Form("form",...)
[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-1312) Generic inter-component event mechanism
[ https://issues.apache.org/jira/browse/WICKET-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
