[jira] Issue Comment Edited: (WICKET-1653) Invalid argument in wicket-ajax.js (line 606) causes not loading ajax lazy load panel in IE
[ https://issues.apache.org/jira/browse/WICKET-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12651272#action_12651272 ] slonopotamus edited comment on WICKET-1653 at 11/27/08 12:13 AM: Closed too early. Nobody confirmed bug is fixed on 1.4 branch. was (Author: slonopotamus): Closed to early. Nobody confirmed bug is fixed on 1.4 branch. Invalid argument in wicket-ajax.js (line 606) causes not loading ajax lazy load panel in IE --- Key: WICKET-1653 URL: https://issues.apache.org/jira/browse/WICKET-1653 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3 Environment: IE6.0.2900.2180 on xp Reporter: Per Newgro Assignee: Matej Knopp Priority: Critical see description at http://www.nabble.com/javascript-error-in-internet-explorer-td16732896.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1784) Enhance IDataProvider to support applications using the Transfer Object J2EE pattern
[ https://issues.apache.org/jira/browse/WICKET-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12651278#action_12651278 ] Stefan Fussenegger commented on WICKET-1784: Bruno, I don't think the purpose of this ticket is to follow a pattern. It's about a *major* performance hog. If you'd be accessing Lucene through Wicket using an IDataProvider, you'd realize that you are performing every query twice (except those with an empty resultset). And hitting your search index 10 or 20 times a second is quite a difference. Did you read my comment (https://issues.apache.org/jira/browse/WICKET-1784?focusedCommentId=12650587#action_12650587) above? I suggested to only change the implementation of PagingNavigationLink to allow a custom Repeater that implements IPageable (in order to use the default Navigation component - or is it the Navigator? I always confuse them ...). As mentioned above, PagingNavigationLink.getPageNumber() checks whether the chosen page number (chosen by clicking such a link) is allowed. It does that by calculating the current number of pages (i.e. fetches the size). This check isn't needed, as any current IPageable implementation checks that special case itself (which is a Good Thing (tm)). Therefore, the change would be quite trivial and would have a tremendous effect for Lucene-based applications at the same time. Hence, +1 - or may I give more than that? ;) Btw, fetching data and total amount at the same time is possible with MySQL too (See http://dev.mysql.com/doc/refman/5.1/en/information-functions.html#function_found-rows). Enhance IDataProvider to support applications using the Transfer Object J2EE pattern Key: WICKET-1784 URL: https://issues.apache.org/jira/browse/WICKET-1784 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.3, 1.4-M3 Environment: Wicket 1.3.3 and 1.4-M3 Reporter: R. Goodwin Assignee: Igor Vaynberg Attachments: wicket-paging-experiment.zip In some environments searches are performed in 'single call' fashion, using a transfer object. E.g. two queries performed by the data services tier before returning combined results to the UI tier: i. Query for paged search results ii. Query for a 'count' value representing total possible results The contract between DataView and IDataProvider does not support a 'single call' environment as the give/take relationship between these classes is biased towards DataView. DataView expects IDataProvider to provide it's size before providing IDataProvider with its offset and count. * DataView may have good reasons for needing size before it can provide offset/count. * But IDataProvider has equally good reasons for needing offset/count before it can provide size. The circular dependency: 1. DataView calls IDataProvider.size() 2. IDataProvider cannot return size as it cannot start a query until it receives offset/count from DataView 3. These it does not receive until DataView calls IDataProvider.iterator() later on Others who experienced this problem (with CODE examples): * http://www.nabble.com/IDataProvider-and-Hibernate-Search-td15546101.html * http://www.mail-archive.com/[EMAIL PROTECTED]/msg14266.html --- The suggested solution of caching the combined search results and count value does not work if the search cannot begin until offset and count are available. And writing a custom DataView is not feasible either time wise as I understand that it cannot be done without needing to write a number of other classes too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1921) Add an extension of AutoCompleteTextField which includes default css
[ https://issues.apache.org/jira/browse/WICKET-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12651329#action_12651329 ] Antony Stubbs commented on WICKET-1921: --- No problem! Just thought it might be nice. Hey - got any links to info around your statement will not do stuff in there that you shouldn't do before the object construction is finished (that's the danger of calling overridable methods from constructors). - i'm curious. Add an extension of AutoCompleteTextField which includes default css Key: WICKET-1921 URL: https://issues.apache.org/jira/browse/WICKET-1921 Project: Wicket Issue Type: Improvement Affects Versions: 1.4-M3 Reporter: Antony Stubbs Assignee: Timo Rantalaiho Fix For: 1.3.6, 1.4-RC2 Attachments: defaultcss.patch, wicket.rar The component doesn't seem to work very well without some basic CSS. Adding this will help people get started with it / demonstrate the css. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1960) AutoCompleteTextField - gives a type mismatch error on IE - version wicket-1.4-rc1
[ https://issues.apache.org/jira/browse/WICKET-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12651316#action_12651316 ] Dipu C Seminlal commented on WICKET-1960: - In the current trunk, it's reverted back to container.style.zIndex=(Number(index)!=Number.NaN?Number(index)+1:index); and it works, but its working because some thing else is broken when the value of index ='auto'; the expression (Number(index)!=Number.NaN?Number(index)+1:index); return NaN, this looks wrong to me it should be returning 'auto' for example if you run the following line in javascript console in firebug you will get NaN var index ='auto';(Number(index)!=Number.NaN?Number(index)+1:index) if you run Number(index) it return NaN but Number(index)!=Number.NaN yields true (looks wrong to me) AutoCompleteTextField - gives a type mismatch error on IE - version wicket-1.4-rc1 -- Key: WICKET-1960 URL: https://issues.apache.org/jira/browse/WICKET-1960 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.4-RC1 Reporter: Dipu C Seminlal Fix For: 1.4-RC1 Attachments: wicket-autocomplete-patch.txt wicket-autocomplete.js function function showAutoComplete() line 291 container.style.zIndex=(!isNaN(Number(index))?Number(index)+1:index); looks like IE doesn't like big i in zIndex, IE seem to be be happy with zindex not sure if that's the correct way to resolve the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1960) AutoCompleteTextField - gives a type mismatch error on IE - version wicket-1.4-rc1
[ https://issues.apache.org/jira/browse/WICKET-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12651327#action_12651327 ] Martin Benda commented on WICKET-1960: -- Mathematically, the NaN (Not a Number) is unequal to all other numbers, +-Inf and *itself* because it just has no concrete value... The isNaN function is the correct way to test whether a value is NaN or not. So the expression Number(index)!=Number.NaN?Number(index)+1:index is in fact just Number(index)+1 Regards, Bendis AutoCompleteTextField - gives a type mismatch error on IE - version wicket-1.4-rc1 -- Key: WICKET-1960 URL: https://issues.apache.org/jira/browse/WICKET-1960 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.4-RC1 Reporter: Dipu C Seminlal Fix For: 1.4-RC1 Attachments: wicket-autocomplete-patch.txt wicket-autocomplete.js function function showAutoComplete() line 291 container.style.zIndex=(!isNaN(Number(index))?Number(index)+1:index); looks like IE doesn't like big i in zIndex, IE seem to be be happy with zindex not sure if that's the correct way to resolve the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r721245 - /wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/navigation/paging/PagingNavigationLink.java
Author: ivaynberg
Date: Thu Nov 27 09:32:23 2008
New Revision: 721245
URL: http://svn.apache.org/viewvc?rev=721245view=rev
Log:
extracted page number culling into an overridable function
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/navigation/paging/PagingNavigationLink.java
Modified:
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/navigation/paging/PagingNavigationLink.java
URL:
http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/navigation/paging/PagingNavigationLink.java?rev=721245r1=721244r2=721245view=diff
==
---
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/navigation/paging/PagingNavigationLink.java
(original)
+++
wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/navigation/paging/PagingNavigationLink.java
Thu Nov 27 09:32:23 2008
@@ -73,6 +73,18 @@
*/
public final int getPageNumber()
{
+ return cullPageNumber(pageNumber);
+ }
+
+ /**
+* Allows the link to cull the page number to the valid range before it
is retrieved from the
+* link
+*
+* @param pageNumber
+* @return culled page number
+*/
+ protected int cullPageNumber(int pageNumber)
+ {
int idx = pageNumber;
if (idx 0)
{
[jira] Resolved: (WICKET-1784) Enhance IDataProvider to support applications using the Transfer Object J2EE pattern
[ https://issues.apache.org/jira/browse/WICKET-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Vaynberg resolved WICKET-1784. --- Resolution: Fixed Fix Version/s: 1.4-RC2 see pagingnavigationlink#cullPageNumber(int x) Enhance IDataProvider to support applications using the Transfer Object J2EE pattern Key: WICKET-1784 URL: https://issues.apache.org/jira/browse/WICKET-1784 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.3, 1.4-M3 Environment: Wicket 1.3.3 and 1.4-M3 Reporter: R. Goodwin Assignee: Igor Vaynberg Fix For: 1.4-RC2 Attachments: wicket-paging-experiment.zip In some environments searches are performed in 'single call' fashion, using a transfer object. E.g. two queries performed by the data services tier before returning combined results to the UI tier: i. Query for paged search results ii. Query for a 'count' value representing total possible results The contract between DataView and IDataProvider does not support a 'single call' environment as the give/take relationship between these classes is biased towards DataView. DataView expects IDataProvider to provide it's size before providing IDataProvider with its offset and count. * DataView may have good reasons for needing size before it can provide offset/count. * But IDataProvider has equally good reasons for needing offset/count before it can provide size. The circular dependency: 1. DataView calls IDataProvider.size() 2. IDataProvider cannot return size as it cannot start a query until it receives offset/count from DataView 3. These it does not receive until DataView calls IDataProvider.iterator() later on Others who experienced this problem (with CODE examples): * http://www.nabble.com/IDataProvider-and-Hibernate-Search-td15546101.html * http://www.mail-archive.com/[EMAIL PROTECTED]/msg14266.html --- The suggested solution of caching the combined search results and count value does not work if the search cannot begin until offset and count are available. And writing a custom DataView is not feasible either time wise as I understand that it cannot be done without needing to write a number of other classes too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
svn commit: r721248 - /wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/loader/PackageStringResourceLoader.java
Author: ivaynberg Date: Thu Nov 27 09:39:28 2008 New Revision: 721248 URL: http://svn.apache.org/viewvc?rev=721248view=rev Log: javadoc Modified: wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/loader/PackageStringResourceLoader.java Modified: wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/loader/PackageStringResourceLoader.java URL: http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/loader/PackageStringResourceLoader.java?rev=721248r1=721247r2=721248view=diff == --- wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/loader/PackageStringResourceLoader.java (original) +++ wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/loader/PackageStringResourceLoader.java Thu Nov 27 09:39:28 2008 @@ -38,6 +38,7 @@ * This implementation is fully aware of both locale and style values when trying to obtain the * appropriate resources. * p + * Looks for file called codepackage.properties/code * * @author Juergen Donnerstag * @author igor.vaynberg
[CONF] Apache Wicket: Wicket 1.5 Wish List (page edited)
Page Edited :
WICKET :
Wicket 1.5 Wish List
Wicket 1.5 Wish List
has been edited by Igor Vaynberg
(Nov 27, 2008).
(View changes)
Content:
create abstraction for content types
currently, wicket has a concept of "markup type" that is actually the markup extension. in doing work on wml support for "mobile wicket", i'm discovering a need for full mime type support. if it doesn't break too many people, it would ideally be best to introduce a formal MarkupType class with a getExtension() and getContentType(), where ContentType includes mime type information. there quite a bit to think through here in terms of request/response markup type mappings, but i'd be up for working on this. this problem is definitely generic to problems outside mobile wicket. jonathan
multiply child/extend inheritance
https://issues.apache.org/jira/browse/WICKET-1134
improve ajax support of _javascript_
i still think we should be doing something more object oriented in terms of composing _javascript_ for ajax purposes. i'd like to see us adopt something like that _javascript_ class i was promoting a while back. one thing that occurs to me today is that not only could you easily compose _javascript_ this way, but there might be a whole host of reusable _javascript_ behaviors we could all leverage. for example, instead of having bits of _javascript_ code hacked into strings all over projects to accomplish deletion confirmation on link/button clicks, we could have ConfirmJavaScript extends _javascript_ and take care of the gory details in there (string resources for localization, whatever). as hunks of _javascript_ get more complex and prevalent, creating this abstraction could really serve us nicely as a community. i personally would have loved to reuse things like FadeComponentJavaScript or DisableComponentJavaScript. the subclasses will all take a lot of work to create, but let's make an abstraction for JS code so we can do this work at all. jonathan
A few advantages to making our _javascript_ more OO:
conform to Yahoo recommendations on page rendering performance by putting _javascript_ just before /body
more component oriented development through object literals (JSON)
separate _javascript_ from markup
ListView users = new ListView("users", usersModel);
users.setOutputMarkupId(true);
Event e = new ClickEvent("a[class=deleteLink]"); // DomQuery-esque selector (http://extjs.com/learn/Tutorial:DomQuery_v1.1_Basics)... selector could be turned into a Builder object instead of string
e.addHandler(new ConfirmDialog("Are you sure you want to delete?"));
users.addEvent(e); // can be shortened to new ClickEvent("...", new ConfirmDialog("..."))
serializes to:
{ element: "{usersMarkupId}:", // generated by Component
events: [
{ event: "click", [ // generated by ClickEvent
{ selector: "a[class=deleteLink]",
handlers: [
function() { // generated by ConfirmDialog
if(confirm("Are you sure you want to delete?") {
// Wicket.ajax...
}
}
]
}
]
}
]
}
Wrap the above in an 'ondomready' event and we have unobtrusive _javascript_ that should be easier to abstract going forward.
brian
New Inspectors
Add inspector to look for empty src="" attrs which cause extra requests to the server
Remove Change and possibly VersionManager
no longer needed since we serialize the entire page. Downside - makes HttpSessionStore not as space efficient
(possibly move these implementation details down into the session store package? - jonathan)
(this is already pushed to the store package i guess, version manager and pagemap are created by the httpsession store already,
the problem with removing this is that it will break all stuff that cant depend on the file based store are really need to be in mem,
the disk based store already doesn't do anything with Change and also the version manager, it only uses the version number from the vm, johan)
Cleanup component visibility
Currently we have Component.set/isVisible, Component.isRenderAllowed, Component.set/isVisibilityAllowed
The reason for Component.set/isVisible is simply - allow users to control visibility of their component
The reason for Component.isRenderAllowed is for security strategy to be able to force component to be invisible
Now if i am a user and want to test if the component will be rendered or not I need to do
boolean visible=component.isVisible()component.isRenderAllowed()
This is ugly as I have to remember both checks all the time. Because of this I have introduced Component.determineVisibility() in 1.3.3 which encapsulates all necessary checks.
Now, what if I want to write a component that controls visibility of its children or other components. It can call
[CONF] Apache Wicket: Wicket 1.5 Wish List (page edited)
Page Edited :
WICKET :
Wicket 1.5 Wish List
Wicket 1.5 Wish List
has been edited by Igor Vaynberg
(Nov 27, 2008).
(View changes)
Content:
create abstraction for content types
currently, wicket has a concept of "markup type" that is actually the markup extension. in doing work on wml support for "mobile wicket", i'm discovering a need for full mime type support. if it doesn't break too many people, it would ideally be best to introduce a formal MarkupType class with a getExtension() and getContentType(), where ContentType includes mime type information. there quite a bit to think through here in terms of request/response markup type mappings, but i'd be up for working on this. this problem is definitely generic to problems outside mobile wicket. jonathan
multiply child/extend inheritance
https://issues.apache.org/jira/browse/WICKET-1134
improve ajax support of _javascript_
i still think we should be doing something more object oriented in terms of composing _javascript_ for ajax purposes. i'd like to see us adopt something like that _javascript_ class i was promoting a while back. one thing that occurs to me today is that not only could you easily compose _javascript_ this way, but there might be a whole host of reusable _javascript_ behaviors we could all leverage. for example, instead of having bits of _javascript_ code hacked into strings all over projects to accomplish deletion confirmation on link/button clicks, we could have ConfirmJavaScript extends _javascript_ and take care of the gory details in there (string resources for localization, whatever). as hunks of _javascript_ get more complex and prevalent, creating this abstraction could really serve us nicely as a community. i personally would have loved to reuse things like FadeComponentJavaScript or DisableComponentJavaScript. the subclasses will all take a lot of work to create, but let's make an abstraction for JS code so we can do this work at all. jonathan
A few advantages to making our _javascript_ more OO:
conform to Yahoo recommendations on page rendering performance by putting _javascript_ just before /body
more component oriented development through object literals (JSON)
separate _javascript_ from markup
ListView users = new ListView("users", usersModel);
users.setOutputMarkupId(true);
Event e = new ClickEvent("a[class=deleteLink]"); // DomQuery-esque selector (http://extjs.com/learn/Tutorial:DomQuery_v1.1_Basics)... selector could be turned into a Builder object instead of string
e.addHandler(new ConfirmDialog("Are you sure you want to delete?"));
users.addEvent(e); // can be shortened to new ClickEvent("...", new ConfirmDialog("..."))
serializes to:
{ element: "{usersMarkupId}:", // generated by Component
events: [
{ event: "click", [ // generated by ClickEvent
{ selector: "a[class=deleteLink]",
handlers: [
function() { // generated by ConfirmDialog
if(confirm("Are you sure you want to delete?") {
// Wicket.ajax...
}
}
]
}
]
}
]
}
Wrap the above in an 'ondomready' event and we have unobtrusive _javascript_ that should be easier to abstract going forward.
brian
New Inspectors
Add inspector to look for empty src="" attrs which cause extra requests to the server
Remove Change and possibly VersionManager
no longer needed since we serialize the entire page. Downside - makes HttpSessionStore not as space efficient
(possibly move these implementation details down into the session store package? - jonathan)
(this is already pushed to the store package i guess, version manager and pagemap are created by the httpsession store already,
the problem with removing this is that it will break all stuff that cant depend on the file based store are really need to be in mem,
the disk based store already doesn't do anything with Change and also the version manager, it only uses the version number from the vm, johan)
Cleanup component visibility
Currently we have Component.set/isVisible, Component.isRenderAllowed, Component.set/isVisibilityAllowed
The reason for Component.set/isVisible is simply - allow users to control visibility of their component
The reason for Component.isRenderAllowed is for security strategy to be able to force component to be invisible
Now if i am a user and want to test if the component will be rendered or not I need to do
boolean visible=component.isVisible()component.isRenderAllowed()
This is ugly as I have to remember both checks all the time. Because of this I have introduced Component.determineVisibility() in 1.3.3 which encapsulates all necessary checks.
Now, what if I want to write a component that controls visibility of its children or other components. It can call
