[jira] Created: (WICKET-2000) AjaxRequestTarget escapes ] to ]^
AjaxRequestTarget escapes ] to ]^ - Key: WICKET-2000 URL: https://issues.apache.org/jira/browse/WICKET-2000 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-RC1 Reporter: Jan Kriesten Fix For: 1.4-RC2 Current 1.4 trunk 'messes' with escaping ']' to ']^' on AjaxRequestTarget.appendJavascript which leeds to non-functional Javascript when using array indices on variables. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1997) TextFilteredPropertyColumn needs different generic for FilterModel
TextFilteredPropertyColumn needs different generic for FilterModel -- Key: WICKET-1997 URL: https://issues.apache.org/jira/browse/WICKET-1997 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.4-RC1 Reporter: Jan Kriesten Like ChoiceFilteredPropertyColumn: TextFilteredPropertyColumn needs separate generic for the FilterModel -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1965) Remove final from MarkupCache#clear()
Remove final from MarkupCache#clear() - Key: WICKET-1965 URL: https://issues.apache.org/jira/browse/WICKET-1965 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-RC1 Reporter: Jan Kriesten Priority: Minor Fix For: 1.3.6 When extending MarkupCache to hook inother MarkupLoader for certain components, I'd like to be able to delegate a call to clearing the cache to this other markup loader. To be able to do so, I need to have the final removed from MarkupCache. Use case: http://www.footprint.de/fcc/2008/11/some-wicket-scala/ (To delegate the clear to FreeMarker/Velocity e.g.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1965) Remove final from MarkupCache#clear()
[ https://issues.apache.org/jira/browse/WICKET-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12652146#action_12652146 ] Jan Kriesten commented on WICKET-1965: -- Timo, ouch - you're right! I think I was just blind on that eye. :-) Best regards, --- Jan. Remove final from MarkupCache#clear() - Key: WICKET-1965 URL: https://issues.apache.org/jira/browse/WICKET-1965 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-RC1 Reporter: Jan Kriesten Priority: Minor Fix For: 1.3.6 When extending MarkupCache to hook inother MarkupLoader for certain components, I'd like to be able to delegate a call to clearing the cache to this other markup loader. To be able to do so, I need to have the final removed from MarkupCache. Use case: http://www.footprint.de/fcc/2008/11/some-wicket-scala/ (To delegate the clear to FreeMarker/Velocity e.g.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1965) Remove final from MarkupCache#clear()
[ https://issues.apache.org/jira/browse/WICKET-1965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kriesten closed WICKET-1965. Resolution: Invalid Remove final from MarkupCache#clear() - Key: WICKET-1965 URL: https://issues.apache.org/jira/browse/WICKET-1965 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.4-RC1 Reporter: Jan Kriesten Priority: Minor Fix For: 1.3.6 When extending MarkupCache to hook inother MarkupLoader for certain components, I'd like to be able to delegate a call to clearing the cache to this other markup loader. To be able to do so, I need to have the final removed from MarkupCache. Use case: http://www.footprint.de/fcc/2008/11/some-wicket-scala/ (To delegate the clear to FreeMarker/Velocity e.g.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1839) IAjaxIndicatorAware/WicketAjaxIndicatorAppender with AutoCompleteTextField doesn't work
IAjaxIndicatorAware/WicketAjaxIndicatorAppender with AutoCompleteTextField doesn't work --- Key: WICKET-1839 URL: https://issues.apache.org/jira/browse/WICKET-1839 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.4 Environment: Any Reporter: Jan Kriesten Fix For: 1.3.5 When adding IAjaxIndicatorAware/WicketAjaxIndicatorAppender to an AutoCompleteTextField to indicate loading of remote data, the Indicator isn't activated. On a side note: AbstractAutoCompleteBehavior#onBind adds another AbstractDefaultAjaxBehavior which is unnecessary since AbstractAutoCompleteBehavior extends that already. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1839) IAjaxIndicatorAware/WicketAjaxIndicatorAppender with AutoCompleteTextField doesn't work
[ https://issues.apache.org/jira/browse/WICKET-1839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kriesten updated WICKET-1839: - Attachment: indicator-test.tar.gz Test case. IAjaxIndicatorAware/WicketAjaxIndicatorAppender with AutoCompleteTextField doesn't work --- Key: WICKET-1839 URL: https://issues.apache.org/jira/browse/WICKET-1839 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.4 Environment: Any Reporter: Jan Kriesten Fix For: 1.3.5 Attachments: indicator-test.tar.gz When adding IAjaxIndicatorAware/WicketAjaxIndicatorAppender to an AutoCompleteTextField to indicate loading of remote data, the Indicator isn't activated. On a side note: AbstractAutoCompleteBehavior#onBind adds another AbstractDefaultAjaxBehavior which is unnecessary since AbstractAutoCompleteBehavior extends that already. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1773) DiskPageStore-FileNotFoundException
[
https://issues.apache.org/jira/browse/WICKET-1773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12628333#action_12628333
]
Jan Kriesten commented on WICKET-1773:
--
Behavior is reproducable when sessions are invalidated not within wicket but
e.g. Spring Security.
It turns out that DiskPageStore#unbind calls flushPagesToSaveList() which again
tries to write to the no longer existing SessionStore.
Just clearing the list of pages instead of trying to write them solves the
problem:
---8---
public void unbind(String sessionId)
{
SessionEntry entry =
(SessionEntry)sessionIdToEntryMap.remove(sessionId);
if (entry != null)
{
if (isSynchronous())
{
entry.unbind();
}
else
{
List pages = getPagesToSaveList(sessionId);
if( pages!=null )
pages.clear();
entry.unbind();
pagesToSaveAll.remove(sessionId);
}
}
}
---8---
DiskPageStore-FileNotFoundException
---
Key: WICKET-1773
URL: https://issues.apache.org/jira/browse/WICKET-1773
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.4
Reporter: Jan Kriesten
Assignee: Matej Knopp
Fix For: 1.3.5
With the current 1.3-Snapshot, I encounter problems with DiskPageStore:
---8---
09:30:43.151 ERROR [.wicket.protocol.http.pagestore.DiskPageStore] - Error
flushing page
java.lang.RuntimeException: java.io.FileNotFoundException:
/usr/local/www/services/local.silberlicht.de/html/WEB-INF/tmp/Silberlicht-filestore/abcgm_hyTIaiqgnqDNmUr/pm-null
(No such file or directory)
at
org.apache.wicket.protocol.http.pagestore.FileChannelPool.newFileChannel(FileChannelPool.java:104)
at
org.apache.wicket.protocol.http.pagestore.FileChannelPool.getFileChannel(FileChannelPool.java:171)
at
org.apache.wicket.protocol.http.pagestore.DiskPageStore$SessionEntry.savePage(DiskPageStore.java:241)
at
org.apache.wicket.protocol.http.pagestore.DiskPageStore.flushPagesToSaveList(DiskPageStore.java:891)
at
org.apache.wicket.protocol.http.pagestore.DiskPageStore$PageSavingThread.run(DiskPageStore.java:961)
at java.lang.Thread.run(Thread.java:613)
Caused by: java.io.FileNotFoundException:
/usr/local/www/services/local.silberlicht.de/html/WEB-INF/tmp/Silberlicht-filestore/abcgm_hyTIaiqgnqDNmUr/pm-null
(No such file or directory)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.init(RandomAccessFile.java:212)
at
org.apache.wicket.protocol.http.pagestore.FileChannelPool.newFileChannel(FileChannelPool.java:99)
... 5 common frames omitted
---8---
The path
/usr/local/www/services/local.silberlicht.de/html/WEB-INF/tmp/Silberlicht-filestore/
actually exists and has the proper rights - so creation of temporary
directories/files should be possible (actually, the directory was created by
the wicket app).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1560) MarkupFragmentFinder fails on transparent resolvers within Repeaters
[
https://issues.apache.org/jira/browse/WICKET-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12610121#action_12610121
]
Jan Kriesten commented on WICKET-1560:
--
If you don't extend AbstractRepeater, in which way does this affect you at all?
MarkupFragmentFinder fails on transparent resolvers within Repeaters
Key: WICKET-1560
URL: https://issues.apache.org/jira/browse/WICKET-1560
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.3, 1.4-M1
Environment: Any
Reporter: Jan Kriesten
Assignee: Gerolf Seitz
Priority: Critical
Fix For: 1.3.4, 1.4-M2
I extended the AjaxDataTable to be able to add Rows to certain states of the
rows. However, MarkupFragmentFinder fails to resolve the code under this
condition since it compares with the wrong components in this case:
Markup:
wicket:container wicket:id=rows
tr wicket:id=rowtd wicket:id=cellsspan
wicket:id=cell[cell]/span/td/tr
tr wicket:id=action-row class=actionRow/tr
/wicket:container
'row' is the transparent resolver in this case to maintain the hierarchy
needed by the DataTable. MarkupFragmentFinder fails in the case of adding a
cell to an AjaxRequestTarget.
Fix:
Everything works as expected, when MarkupFragmentFinder checks for the parent
being an AbstractRepeater and in the case compares the parent.id with the
supplied id (code provided by Gerolf):
if (elem instanceof ComponentTag)
{
ComponentTag tag = (ComponentTag)elem;
String id = tag.getId();
if ((id != null) id.equals(component.getId()))
{
// Ok, found it
return markupStream;
}
else
{
Component parent = component.getParent();
if (parent instanceof AbstractRepeater id != null
id.equals(parent.getId()))
{
return markupStream;
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1564) filter-restore script-tag isn't xhtml-valid
filter-restore script-tag isn't xhtml-valid --- Key: WICKET-1564 URL: https://issues.apache.org/jira/browse/WICKET-1564 Project: Wicket Issue Type: Improvement Components: wicket-extensions Affects Versions: 1.3.3 Reporter: Jan Kriesten Priority: Trivial The script-tag needs to be modified from script.../script to script type=text/javascript.../script -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1564) filter-restore script-tag isn't xhtml-valid
[ https://issues.apache.org/jira/browse/WICKET-1564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kriesten updated WICKET-1564: - Description: The script-tag needs to be modified from script.../script to script type=text/javascript.../script File: org/apache/wicket/extensions/markup/html/repeater/data/table/filter/FilterForm.java was: The script-tag needs to be modified from script.../script to script type=text/javascript.../script filter-restore script-tag isn't xhtml-valid --- Key: WICKET-1564 URL: https://issues.apache.org/jira/browse/WICKET-1564 Project: Wicket Issue Type: Improvement Components: wicket-extensions Affects Versions: 1.3.3 Reporter: Jan Kriesten Priority: Trivial The script-tag needs to be modified from script.../script to script type=text/javascript.../script File: org/apache/wicket/extensions/markup/html/repeater/data/table/filter/FilterForm.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1560) MarkupFragmentFinder fails on transparent resolvers within Repeaters
MarkupFragmentFinder fails on transparent resolvers within Repeaters
Key: WICKET-1560
URL: https://issues.apache.org/jira/browse/WICKET-1560
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.3
Environment: Any
Reporter: Jan Kriesten
Priority: Critical
Fix For: 1.3.4
I extended the AjaxDataTable to be able to add Rows to certain states of the
rows. However, MarkupFragmentFinder fails to resolve the code under this
condition since it compares with the wrong components in this case:
Markup:
wicket:container wicket:id=rows
tr wicket:id=rowtd wicket:id=cellsspan
wicket:id=cell[cell]/span/td/tr
tr wicket:id=action-row class=actionRow/tr
/wicket:container
'row' is the transparent resolver in this case to maintain the hierarchy needed
by the DataTable. MarkupFragmentFinder fails in the case of adding a cell to an
AjaxRequestTarget.
Fix:
Everything works as expected, when MarkupFragmentFinder checks for the parent
being an AbstractRepeater and in the case compares the parent.id with the
supplied id (code provided by Gerolf):
if (elem instanceof ComponentTag)
{
ComponentTag tag = (ComponentTag)elem;
String id = tag.getId();
if ((id != null) id.equals(component.getId()))
{
// Ok, found it
return markupStream;
}
else
{
Component parent = component.getParent();
if (parent instanceof AbstractRepeater id != null
id.equals(parent.getId()))
{
return markupStream;
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1560) MarkupFragmentFinder fails on transparent resolvers within Repeaters
[
https://issues.apache.org/jira/browse/WICKET-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12591580#action_12591580
]
Jan Kriesten commented on WICKET-1560:
--
Just realized:
Maybe it doesn't has to do anything with transparent resolvers at all but only
with nested repeaters and adding cells from the innermost.
MarkupFragmentFinder fails on transparent resolvers within Repeaters
Key: WICKET-1560
URL: https://issues.apache.org/jira/browse/WICKET-1560
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.3.3
Environment: Any
Reporter: Jan Kriesten
Priority: Critical
Fix For: 1.3.4
I extended the AjaxDataTable to be able to add Rows to certain states of the
rows. However, MarkupFragmentFinder fails to resolve the code under this
condition since it compares with the wrong components in this case:
Markup:
wicket:container wicket:id=rows
tr wicket:id=rowtd wicket:id=cellsspan
wicket:id=cell[cell]/span/td/tr
tr wicket:id=action-row class=actionRow/tr
/wicket:container
'row' is the transparent resolver in this case to maintain the hierarchy
needed by the DataTable. MarkupFragmentFinder fails in the case of adding a
cell to an AjaxRequestTarget.
Fix:
Everything works as expected, when MarkupFragmentFinder checks for the parent
being an AbstractRepeater and in the case compares the parent.id with the
supplied id (code provided by Gerolf):
if (elem instanceof ComponentTag)
{
ComponentTag tag = (ComponentTag)elem;
String id = tag.getId();
if ((id != null) id.equals(component.getId()))
{
// Ok, found it
return markupStream;
}
else
{
Component parent = component.getParent();
if (parent instanceof AbstractRepeater id != null
id.equals(parent.getId()))
{
return markupStream;
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1542) Transparent Resolvers as targets for Ajax requests
Transparent Resolvers as targets for Ajax requests -- Key: WICKET-1542 URL: https://issues.apache.org/jira/browse/WICKET-1542 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.3 Environment: Any Reporter: Jan Kriesten As it is now, using Componants which are transparent resolvers as targets for Ajax requests don't lead to actually rerender their Markup-children. Now I have an urgent implementation issue with this where I want to have two table rows with a DataTable for certain rows, so I have to change the Markup hierarchy. To not break the functionality of the contained DataGrid, I have to use a transparent resolver: wicket:container wicket:id=rows tr wicket:id=rowtd wicket:id=cellsspan wicket:id=cell[cell]/span/td/tr tr wicket:id=action-rowtd wicket:id=action-cellsspan wicket:id=action-cell[cell]/span/td/tr /wicket:container 'row' would be the transparent resolver in this case - and also a target for Ajax requests. This doesn't work at the moment, since the 'cells' aren't re-rendered on Ajax requests. Is there another solution to this problem I didn't think of? Or is there another solution to have the cells rerendered? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1519) wicket:component : header-contributions don't work atm
wicket:component : header-contributions don't work atm -- Key: WICKET-1519 URL: https://issues.apache.org/jira/browse/WICKET-1519 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.3 Reporter: Jan Kriesten Currently, components embedded thru templates using the wicket:component-tag seem to be ignored when it comes to header contributions. E.g. AjaxTimerBehavior don't work. It would be nice if wicket:component could be enhanced in that respect. Best regards, --- Jan. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1501) MarkupCache.putIntoCache doesn't behave correctly!!
MarkupCache.putIntoCache doesn't behave correctly!! --- Key: WICKET-1501 URL: https://issues.apache.org/jira/browse/WICKET-1501 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3 Reporter: Jan Kriesten Priority: Critical 'putIntoCache' checks for the locationString not to be null instead of the cacheKey! This way you always get old markup returned instead of the freshly supplied markup which shouldn't be cached at all. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1501) MarkupCache.putIntoCache doesn't behave correctly!!
[ https://issues.apache.org/jira/browse/WICKET-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587093#action_12587093 ] Jan Kriesten commented on WICKET-1501: -- I don't actually understand why the markup is loaded from the markupCache in putIntoCache at all - it's already provided as a method argument... MarkupCache.putIntoCache doesn't behave correctly!! --- Key: WICKET-1501 URL: https://issues.apache.org/jira/browse/WICKET-1501 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3 Reporter: Jan Kriesten Priority: Critical 'putIntoCache' checks for the locationString not to be null instead of the cacheKey! This way you always get old markup returned instead of the freshly supplied markup which shouldn't be cached at all. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1501) MarkupCache.putIntoCache doesn't behave correctly!!
[ https://issues.apache.org/jira/browse/WICKET-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587155#action_12587155 ] Jan Kriesten commented on WICKET-1501: -- Johan - I return 'null' for the cacheKey of my template. That's fine. The Markup isn't cached _under_this_ key. The problem arises because wicket caches the Markup in putIntoCache also under the locationString - which has nothing to do with the cacheKey. So, markup is cached under two keys by wicket, which leads to the problem. Regards, --- Jan. MarkupCache.putIntoCache doesn't behave correctly!! --- Key: WICKET-1501 URL: https://issues.apache.org/jira/browse/WICKET-1501 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3 Reporter: Jan Kriesten Assignee: Juergen Donnerstag Priority: Critical 'putIntoCache' checks for the locationString not to be null instead of the cacheKey! This way you always get old markup returned instead of the freshly supplied markup which shouldn't be cached at all. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1501) MarkupCache.putIntoCache doesn't behave correctly!!
[ https://issues.apache.org/jira/browse/WICKET-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587163#action_12587163 ] Jan Kriesten commented on WICKET-1501: -- hi johan, huh?? i have no cache key for the template - it just shall not be handled by wicket's cache system (it's already cached by freemarker and changes every request) so - not having a cache key means i can't lookup the locationString in the first map, right? regards, --- jan. MarkupCache.putIntoCache doesn't behave correctly!! --- Key: WICKET-1501 URL: https://issues.apache.org/jira/browse/WICKET-1501 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3 Reporter: Jan Kriesten Assignee: Juergen Donnerstag Priority: Critical 'putIntoCache' checks for the locationString not to be null instead of the cacheKey! This way you always get old markup returned instead of the freshly supplied markup which shouldn't be cached at all. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1501) MarkupCache.putIntoCache doesn't behave correctly!!
[ https://issues.apache.org/jira/browse/WICKET-1501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587179#action_12587179 ] Jan Kriesten commented on WICKET-1501: -- That's what I was trying to say: Even though cacheKey is 'null' - the markup is still cached under locationString. Since the resulting Markup is always returned from 'putIntoCache' - the originally updated markup in the parameter to 'putIntoCache' is thrown away and replaced by the old cached one... Regards, --- Jan. MarkupCache.putIntoCache doesn't behave correctly!! --- Key: WICKET-1501 URL: https://issues.apache.org/jira/browse/WICKET-1501 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3 Reporter: Jan Kriesten Assignee: Juergen Donnerstag Priority: Critical 'putIntoCache' checks for the locationString not to be null instead of the cacheKey! This way you always get old markup returned instead of the freshly supplied markup which shouldn't be cached at all. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1495) Ajax, MulitlineLabel, AjaxEditableMultiLineLabel
[ https://issues.apache.org/jira/browse/WICKET-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kriesten updated WICKET-1495: - Attachment: tmp.txt Wicket-Debug for MultiLineLabel + Label Ajax, MulitlineLabel, AjaxEditableMultiLineLabel Key: WICKET-1495 URL: https://issues.apache.org/jira/browse/WICKET-1495 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3 Reporter: Jan Kriesten Attachments: tmp.txt I encountered the following problems when using AjaxEditableMultiLineLabel: a) MultiLineLabels aren't rendered with Internet Explorer 7 when content contains something like pre?xml... but give a runtime error. The same code works fine when using a 'normal' label, though! I'll attach a file showing the Wicket-Debug for both cases. b) AEML doesn't show anything on empty string models -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1495) Ajax, MulitlineLabel, AjaxEditableMultiLineLabel
[ https://issues.apache.org/jira/browse/WICKET-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586773#action_12586773 ] Jan Kriesten commented on WICKET-1495: -- Wicket-Debug had a bug displaying entities as etc. Matej resolved this. IE seems to have a problem rendering br/ within pre /pre on Ajax-Requests. Resolved this issue using Label instead of MultiLineLabel in this case. Ajax, MulitlineLabel, AjaxEditableMultiLineLabel Key: WICKET-1495 URL: https://issues.apache.org/jira/browse/WICKET-1495 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.3 Reporter: Jan Kriesten Attachments: tmp.txt I encountered the following problems when using AjaxEditableMultiLineLabel: a) MultiLineLabels aren't rendered with Internet Explorer 7 when content contains something like pre?xml... but give a runtime error. The same code works fine when using a 'normal' label, though! I'll attach a file showing the Wicket-Debug for both cases. b) AEML doesn't show anything on empty string models -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1499) AjaxEditableMultiLineLabel + race condition /
AjaxEditableMultiLineLabel + race condition /
--
Key: WICKET-1499
URL: https://issues.apache.org/jira/browse/WICKET-1499
Project: Wicket
Issue Type: Bug
Components: wicket-extensions
Affects Versions: 1.3.3
Reporter: Jan Kriesten
There are two issues concerning AjaxEditableMultiLineLabel:
a) Race condition cancel editing
Using 'Esc' to cancel editing might lead to two events to be fired: first
onKeypress is executed - which leads to bluring the component in Opera. This
results in the onblur-event firing and the input is submitted!
Changing the code in onComponentTag to
protected void onComponentTag(ComponentTag tag)
{
super.onComponentTag(tag);
final String saveCall = {wicketAjaxGet(' +
getCallbackUrl() +
save=true'+this.name+'='+wicketEncode(this.value)); return false;};
final String cancelCall = {wicketAjaxGet(' +
getCallbackUrl() +
save=false'); this.onblur=''; return
false;};
final String keypress = var
kc=wicketKeyCode(event); if (kc==27) + cancelCall +
; ;
tag.put(onblur, saveCall);
tag.put(onkeypress, keypress);
}
stops onblur being fired.
This might also apply for AjaxEditableLabel - though I haven't seen this
happening there yet.
b) Displaying defaultNullLabel on empty String Model:
Should behave like AjaxEditableLabel, i.e.:
protected void onComponentTagBody(MarkupStream markupStream,
ComponentTag openTag)
{
Object modelObject = getModelObject();
if (modelObject == null || .equals(modelObject))
{
replaceComponentTagBody(markupStream, openTag,
defaultNullLabel());
}
else
{
super.onComponentTagBody(markupStream, openTag);
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1469) New Wicket tag 'wicket:for'
New Wicket tag 'wicket:for' --- Key: WICKET-1469 URL: https://issues.apache.org/jira/browse/WICKET-1469 Project: Wicket Issue Type: New Feature Components: wicket Affects Versions: 1.3.2 Reporter: Jan Kriesten Priority: Minor This often happens during my daily work: You create a form with labels and corresponding input fields. As it is now, you have to bind all those Labels and FormComponents together with some boilerplate code within Java. I'd like to suggest the following enhancement Wicket tag: label wicket:for=username wicket:messge=keydefault message/label where wicket:for contains the referenced wicket:id -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1175) IDataProvider-Overflow with size()
[ https://issues.apache.org/jira/browse/WICKET-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544422 ] Jan Kriesten commented on WICKET-1175: -- hi johan, i don't think it's a question of sense, but to be able to handle such situations. as stated elsewhere - jpa also delivers longs, so currently you strip those down to int, too, which is not a nice thing at all imho. regards, --- jan. IDataProvider-Overflow with size() -- Key: WICKET-1175 URL: https://issues.apache.org/jira/browse/WICKET-1175 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.0-rc1 Environment: any Reporter: Jan Kriesten Assignee: Igor Vaynberg Hi, I get an Integer-overflow with my Dataprovider (yeah, there are a couple of entries in the database). Is there a reason why size() and iterator( first, count ) are limited to Integer? Regards, --- Jan. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1098) AjaxEditableLabel: add method to override edit-event
[ https://issues.apache.org/jira/browse/WICKET-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Kriesten updated WICKET-1098: - Attachment: ael.patch Hi Johan, thanks for looking into it. I attached a small patch which should be sufficient. Best regards, --- Jan. AjaxEditableLabel: add method to override edit-event Key: WICKET-1098 URL: https://issues.apache.org/jira/browse/WICKET-1098 Project: Wicket Issue Type: Improvement Components: wicket-extensions Affects Versions: 1.3.0-beta4 Environment: any Reporter: Jan Kriesten Assignee: Johan Compagner Priority: Minor Fix For: 1.3.0-rc2 Attachments: ael.patch Currently, as event 'onclick' is hardcoded in AjaxEditableLabel. To change this behavior, a bunch of logic has to be copied. It would be nice, if there was a method newLabelAjaxBehavior(String event) which could be easily overriden. Might apply to other AjaxEdit-Components as 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-1131) AjaxEditableLabel: defaultNullLabel() should really be a defaultNullorEmptyLabel()
AjaxEditableLabel: defaultNullLabel() should really be a defaultNullorEmptyLabel() -- Key: WICKET-1131 URL: https://issues.apache.org/jira/browse/WICKET-1131 Project: Wicket Issue Type: Bug Affects Versions: 1.3.0-beta4 Environment: any Reporter: Jan Kriesten Fix For: 1.3.0-rc1 defaultNullLabel() only inserts '...' when the model is NULL, not when the model contains an empty String. So right now it's impossible to get empty Strings edited with this component. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1097) AjaxEditableLabel: Model change events not propagated from Editor
AjaxEditableLabel: Model change events not propagated from Editor
-
Key: WICKET-1097
URL: https://issues.apache.org/jira/browse/WICKET-1097
Project: Wicket
Issue Type: Improvement
Components: wicket-extensions
Affects Versions: 1.3.0-beta4
Environment: any
Reporter: Jan Kriesten
Model changes are not propagated from the Editor to the AjaxEditableLabel, so
overriding onModelChanging/onModelChanged doesn't work as one might expect. The
implementation should be changed to something like this (code sample by Gerolf):
---
protected FormComponent newEditor(MarkupContainer parent, String componentId,
IModel model)
{
TextField editor = new TextField(componentId, model)
{
private static final long serialVersionUID = 1L;
protected void onModelChanging()
{
super.onModelChanging();
AjaxEditableLabel.this.onModelChanging();
}
protected void onModelChanged()
{
super.onModelChanged();
AjaxEditableLabel.this.onModelChanged();
}
};
editor.setOutputMarkupId(true);
editor.setVisible(false);
editor.add(new EditorAjaxBehavior());
return editor;
}
---
The same issue might apply to the other inline-editors.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1080) StringResourceModel.toString() misbehavior
StringResourceModel.toString() misbehavior -- Key: WICKET-1080 URL: https://issues.apache.org/jira/browse/WICKET-1080 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta4 Environment: any Reporter: Jan Kriesten StringResourceModel.toString() doesn't behave like the API documentation states any more. It returns a lot of debug information instead of the the getString()-result as stated in the docs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1069) RFE: DataTable colgroup
RFE: DataTable colgroup
--
Key: WICKET-1069
URL: https://issues.apache.org/jira/browse/WICKET-1069
Project: Wicket
Issue Type: Improvement
Components: wicket-extensions
Environment: any
Reporter: Jan Kriesten
Hi!
I want to suggest an enhancement for the DataTable extension.
Right now it's only possible to style columns (width, alignment, color etc.)
via stylesheets. This has some not so nice implications IMHO:
- You have to extend the IStyledColumn to return the proper CSS class.
- You have to add a bunch of CSS classes to get the proper styles.
- You have redundancy in HTML output - which isn't necessary.
This is actually what colgroupcol/colgroup is meant to solve.
My suggestion:
Adding a 'addColGroup( ColGroup cg )'-feature, which actually lets you add x
ColGroups with n Cols on which you can use AttributeModifiers to have your
styles/classes/width-Attributes added.
A quick implementation would be this:
---[ColGroup.java]--
import java.util.List;
import org.apache.wicket.behavior.IBehavior;
import
org.apache.wicket.extensions.markup.html.repeater.data.table.AbstractToolbar;
import org.apache.wicket.extensions.markup.html.repeater.data.table.DataTable;
import org.apache.wicket.markup.html.WebMarkupContainer;
import org.apache.wicket.markup.repeater.RepeatingView;
public class ColGroup
extends AbstractToolbar
{
private static final long serialVersionUID = 1L;
private int numCols;
private Col[] cols;
public ColGroup( DataTable datatable, int numCols )
{
super( datatable );
this.numCols = numCols;
}
public void onBeforeRender()
{
if( !hasBeenRendered() )
{
WebMarkupContainer colgroup = new WebMarkupContainer( colgroup );
for( IBehavior b : (ListIBehavior) getBehaviors() )
colgroup.add( b );
setRenderBodyOnly( true );
removeAll();
add( colgroup );
RepeatingView colgroupCols = new RepeatingView( elements );
colgroup.add( colgroupCols );
for( Col column : getCols() )
{
WebMarkupContainer item = new WebMarkupContainer(
colgroupCols.newChildId() );
colgroupCols.add( item );
item.add( column );
}
}
super.onBeforeRender();
}
public final Col[] getCols( )
{
if( cols == null )
{
cols = new Col[numCols];
for( int i = 0; i numCols; i++ )
cols[i] = new Col();
}
return(cols);
}
public final class Col
extends WebMarkupContainer
{
private static final long serialVersionUID = 1L;
private Col()
{
super( col );
}
}
}
---[/ColGroup.java]--
---[ColGroup.html]--
wicket:panel
colgroup wicket:id=colgroup
wicket:container wicket:id=elementscol
wicket:id=col//wicket:container
/colgroup
/wicket:panel
---[/ColGroup.html]--
Usage:
ColGroup colgroup = new ColGroup( datatable, 4 );
colgroup.add( new SimpleAttributeModifier( style, border: solid 1px green;
) );
Col[] cols = colgroup.getCols();
cols[0].add( new SimpleAttributeModifier( width, 10% ) );
cols[1].add( new SimpleAttributeModifier( width, 35% ) );
cols[2].add( new SimpleAttributeModifier( width, 45% ) );
cols[3].add( new SimpleAttributeModifier( width, 10% ) );
datatable.addColGroup( colgroup );
Any thoughts?
Regards, --- Jan.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1006) Mount vs setPageExpiredErrorPage
Mount vs setPageExpiredErrorPage Key: WICKET-1006 URL: https://issues.apache.org/jira/browse/WICKET-1006 Project: Wicket Issue Type: Improvement Components: wicket Affects Versions: 1.3.0-beta3 Environment: n/a Reporter: Jan Kriesten Priority: Minor I have the following simple scenario: app.mount( new IndexedParamUrlCodingStrategy( login, LoginPage.class ) ); app.getApplicationSettings().setPageExpiredErrorPage( LoginPage.class ); If I call the application, I get directed to the url http://appurl/login fine. When the Session times out, I get redirected to the LoginPage again, but this time not to the above url but to http://appurl/?wicket:interface=:2 Couldn't the PageExpiredErrorPage be checked for Mounts? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-930) Wrap Guice-Injector with proxying for Objects
Wrap Guice-Injector with proxying for Objects - Key: WICKET-930 URL: https://issues.apache.org/jira/browse/WICKET-930 Project: Wicket Issue Type: New Feature Components: wicket-guice Reporter: Jan Kriesten Priority: Minor Since the GuiceComponentInjector already has proxying support build in, I'd like to use this to inject other Objects besides from Components. A function like guiceComponentInjector.inject( Object xy ) would be great! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-842) html wicket:id=html is broken again...
[ https://issues.apache.org/jira/browse/WICKET-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519616 ] Jan Kriesten commented on WICKET-842: - IMHO the problem is, that you don't always know what the parent defines. So when you extend a page class, you should always be able to add components without knowing what structure has been defined yet. html (and maybe head and body, too) are special tags in that matter. They are taken as given when not specifically defined with a wicket:id. You automatically add to them - and they're generated for you if not defined. No other tags are generated by wicket, so in that respect they're outstanding anyway. html wicket:id=html is broken again... -- Key: WICKET-842 URL: https://issues.apache.org/jira/browse/WICKET-842 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta3 Environment: JDK 1.6 / OpenSuSE 10.2 Reporter: Jan Kriesten Attachments: test.tar.gz hi, some changes in latest trunk broke adding a wicket:id to html again! :-( actually, the wicket:id in html works. but extending such a basepage and then adding a component to it doesn't work any more! the component hierarchy doesn't seem to be resolved correctly. test case is attached. regards, --- jan. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-842) html wicket:id=html is broken again...
[ https://issues.apache.org/jira/browse/WICKET-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519867 ] Jan Kriesten commented on WICKET-842: - Igor, your example is very different from this case. You explicitely build a hierarchy with the div - the html would live without it, too. But you always have to have a html and a body, so these are entry points for headers and markup and so are created by wicket if not defined! And as these are defined as a container by default (else you couldn't add a header or elements to the page at all), there is actually not really a change in the hierarchy if you add an id to html. But at last, it's your decision, how wicket's to behave. :-) Case closed. html wicket:id=html is broken again... -- Key: WICKET-842 URL: https://issues.apache.org/jira/browse/WICKET-842 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta3 Environment: JDK 1.6 / OpenSuSE 10.2 Reporter: Jan Kriesten Attachments: test.tar.gz hi, some changes in latest trunk broke adding a wicket:id to html again! :-( actually, the wicket:id in html works. but extending such a basepage and then adding a component to it doesn't work any more! the component hierarchy doesn't seem to be resolved correctly. test case is attached. regards, --- jan. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-842) html wicket:id=html is broken again...
[ https://issues.apache.org/jira/browse/WICKET-842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519593 ] Jan Kriesten commented on WICKET-842: - Having html behaving like any other tag is IMHO fine. But I think it a problem that one has to know what component hierarchy has been set up in base Page classes (and which has been completely handled by these). If I change the base Page class to html wicket:id or remove that again, the whole application based on that class shouldn't break. Shouldn't html be a transparent resolver by default? Also, can html wicket:id=xy be overwritten by child pages? What happens, if the child page has an html wicket:id=yz? Regards, --- Jan. html wicket:id=html is broken again... -- Key: WICKET-842 URL: https://issues.apache.org/jira/browse/WICKET-842 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.3.0-beta3 Environment: JDK 1.6 / OpenSuSE 10.2 Reporter: Jan Kriesten Attachments: test.tar.gz hi, some changes in latest trunk broke adding a wicket:id to html again! :-( actually, the wicket:id in html works. but extending such a basepage and then adding a component to it doesn't work any more! the component hierarchy doesn't seem to be resolved correctly. test case is attached. regards, --- jan. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
