Re: tinymce textarea in a modal window not letting to type
I had similar problem and at the end it was easier to switch to ckeditor, which work fine in a modal window (so far tested only in development). There is no integration package for wicket AFAIK, but simple custom integration for a specific use case is simple. On 02/07/2014 05:45 PM, jchappelle wrote: The original issue is pretty old but tinymce in a modal window worked in 1.5 and it is not working in 6.13.0. I guess I'm going to have to redesign my pages to not use the tinymce in a modal window. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/tinymce-textarea-in-a-modal-window-not-letting-to-type-tp1886534p4664309.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: ajax file download...
The way I did it - I created a panel to be used by all reports. It uses IndicatingAjaxButton for Generate Report button which starts report generation in thread and adds AjaxSelfUpdating behaviour to the button panel. Once generation is finished, previously invisible Download Report button is enabled, which uses standard non-ajax DownloadLink to allow user to Download report. On 10/12/2012 12:19 PM, mlabs wrote: I know, but the idea of the user being able to click around the web page and possibly navigate to other areas of the app... and then minutes later the save-as dialog suddenly pops up .. seems to me to be potentially confusing... which is why I like blockUI ... it lets them know that as soon as they click the download link .. something is happening... -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/ajax-file-download-tp4652911p4652917.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: 1.5 migration and border magic
Sorry, answering my own questions ... ;)
On 2012-05-11 17:03, Girts Ziemelis wrote:
1.I assume _header is staff added to page header? Can I identify it
differently, not by string _header? instanceof HtmlHeaderContainer?
Seems that check for HtmlHeaderContainer works fine.
2. is it sufficient to just override the add?
No other problems so far.
3. Can I use page and border getAssociatedMarkup().find(wicketId) and
decide based on checking, if specified wicked id is in a base
class/border?
Yes, checking markup works fine, so I can use
if (border == null
|| getAssociatedMarkup().find(component.getId()) != null
|| component instanceof HtmlHeaderContainer) {
super.add(component);
} else {
border.add(component);
}
I also do not like the extra path border:border_body now to be added
in wicket tester asserts
I actually decided to replace border with 2 panels (header and
footer). Simpler and no need to have a border in a hierarchy any more
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: TableComponentAsXlsHandler Problem
I am using ByteArrayResource and it works great (Wicket 1.5.6). It is
not link.onClick, but may be will do?
Code:
ByteArrayResource surveyExportXlsx = new
ByteArrayResource(application/vnd.ms-excel) {
private static final long serialVersionUID = 1L;
@Override
protected byte[] getData(Attributes attributes) {
Workbook wb = generate your Workbook ...
ByteArrayOutputStream os = new ByteArrayOutputStream();
try {
wb.write(os);
return os.toByteArray();
} catch (IOException ex) {
...
}
}
@Override
protected void setResponseHeaders(ResourceResponse data,
Attributes attributes) {
SimpleDateFormat df = new SimpleDateFormat(.MM.dd_HHmm);
data.setFileName(SurveyExport_ + df.format(new Date()) +
.xlsx);
data.disableCaching();
super.setResponseHeaders(data, attributes);
}
};
add(new ResourceLink(downloadAsXlsx, surveyExportXlsx));
On 2012-05-11 10:46, khanshan wrote:
Ok, I want to ask lastly,
I dynamically generated a workbook HSSFWorkbook,
and I want client to download that file inside of onclick method of a link.
(BytearrayResource doesnt work, it makes problem, please another soulution)
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/TableComponentAsXlsHandler-Problem-tp4616754p4625745.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
1.5 migration and border magic
I was using border in 1.4 to dynamically add different borders to the page (like - for printing, popup, plain, with header/ footer etc based on page parameters and some other criteria) and really liked this method in 1.4. Seems that 1.5 makes this approach clumsy :( Now I must override the page.add method and do some magic to decide where I am adding the component, etc. I got it to work (pretty sure I am not covering all cases ) , then realized, that in WicketTester also now all the component paths must be prefixed with the border:border_body string which is rather ugly :( Is there a better way to implement this (instead of borders)? It just does not feel right - most of the changes in 1.5 made my code cleaner, but this one feels like a hack ... :( - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: 1.5 migration and border magic
It is worse, because now I need to write a code, which previously I
got for free in 1.4 :D and by clumsy I meant my attempt of
implementing this functionality ;)
Now my superclass base page add method looks like this :(
@Override
public MarkupContainer add(Component... childs) {
for (Component component : childs) {
// If border has not been created yet or component is being added
to page header call super.add
if (border == null || component.getId().startsWith(_header)) {
super.add(component);
} else {
border.add(component);
}
}
return this;
}
Obviously there are several problems with my code:
1.I assume _header is staff added to page header? Can I identify it
differently, not by string _header? instanceof HtmlHeaderContainer?
2. is it sufficient to just override the add?
3. Checking that border has been added in a base class will not always
work - I would have to come up with some generic way to decide which
component goes into border and witch in a base class. Can I use page and
border getAssociatedMarkup().find(wicketId) and decide based on
checking, if specified wicked id is in a base class/border?
Would it be better to implement IComponentResolver? I tried this first
(using modified TransparentWebMarkupContainer as an example), but it
caused problems with not found markup for many Fragments and
ModalWindows. (possibly related to
https://issues.apache.org/jira/browse/WICKET-4545 ?)
I also do not like the extra path border:border_body now to be added
in wicket tester asserts, but I can see the logic requiring this... :(
On 2012-05-11 14:30, Martin Grigorov wrote:
Hi,
It is not very clear to me what exactly is clumsy.
Can you explain in more details how it got worse. Show some code maybe.
On Fri, May 11, 2012 at 2:20 PM, Girts Ziemelis
girts.zieme...@gmail.com wrote:
I was using border in 1.4 to dynamically add different borders to the page
(like - for printing, popup, plain, with header/ footer etc based on page
parameters and some other criteria) and really liked this method in 1.4.
Seems that 1.5 makes this approach clumsy :( Now I must override the
page.add method and do some magic to decide where I am adding the component,
etc. I got it to work (pretty sure I am not covering all cases ) , then
realized, that in WicketTester also now all the component paths must be
prefixed with the border:border_body string which is rather ugly :(
Is there a better way to implement this (instead of borders)? It just does
not feel right - most of the changes in 1.5 made my code cleaner, but this
one feels like a hack ... :(
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: What real life scenario calls for page ID?
On 2012-03-19 02:46, Paolo wrote: I support you! I implemented class NoVersionMount thanks to pointbreak in my MainApplication. And It will be my template for future app. But to do it, I needed to understood the problem, check on google, read a lot of pages, without found a solution, so post the question here, and after 3 post, got a right reply for me. Why an wicket user have to do all this Why not, wicket use the NoVersionMount as default Mount? Like in wicket 1.4. And implement an VersionMount as an alternative for developer? I actually like this change so far. I can finally tell, that my page is stetefull just by looking at the link and ask myself question - if I really care so much about the clean link for this page, may be it should be stateless in a first place? And why is ?0 such a big problem? It does not cause problems sending links. Is there any real proof of google indexing problems so far? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: LocaleFirstMapper in 1.5 and statefull home page
Works great! Thank you very much ! :) On 2012-03-19 10:33, Martin Grigorov wrote: Hi, I just touched CustomHomeMapper in Wicket 6.0 to support what you need. I think this way it is more usable in real life. See http://git-wip-us.apache.org/repos/asf/wicket/repo?p=wicket.git;a=commitdiff;h=cabc1bee6a5e3e43e58c9f4c7f8b5cda401c558a The new code of this class at: http://git-wip-us.apache.org/repos/asf/wicket/repo?p=wicket.git;a=blob;f=wicket-examples/src/main/java/org/apache/wicket/examples/requestmapper/CustomHomeMapper.java Have fun! On Sun, Mar 18, 2012 at 7:55 PM, Girts Ziemelis girts.zieme...@gmail.com wrote: I am doing the conversion from 1.4 to 1.5.5 and at the same time trying to start using LocaleFirstMapper and CustomHomeMapper from wicket examples. Everything works nicely except, I have a statefull home page and seems CustomHomeMapper does not handle this case. Page renders fine, but Ajax requests do not work. I think the reason is, because CustomHomeMapper does not add the version number to the link, so the link stays /en, instead of /en?0 like in case, if CustomHomeMapper is not used (home page link is /?0). Any easy solutions to fix this, before I start debugging wicket 1.5 request handling, trying to understand how things work? BTW, nice work on 1.5 wicket team. Thanks :) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
LocaleFirstMapper in 1.5 and statefull home page
I am doing the conversion from 1.4 to 1.5.5 and at the same time trying to start using LocaleFirstMapper and CustomHomeMapper from wicket examples. Everything works nicely except, I have a statefull home page and seems CustomHomeMapper does not handle this case. Page renders fine, but Ajax requests do not work. I think the reason is, because CustomHomeMapper does not add the version number to the link, so the link stays /en, instead of /en?0 like in case, if CustomHomeMapper is not used (home page link is /?0). Any easy solutions to fix this, before I start debugging wicket 1.5 request handling, trying to understand how things work? BTW, nice work on 1.5 wicket team. Thanks :) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Apache Wicket is a Flawed Framework
On Fri, 2011-11-18 at 06:27 -0800, Eric Kizaki wrote: I was not expecting so much hate. I guess now I am infamous in the Java world now. Look, it is just my opinion. Not many people actually stopped to address many of my points. They just immediately bashed me. I did not bother to respond to the first e-mail, as there were way too many points, which from my experience were incorrect and even strange (ORM, JSP, etc). Beeing so happy with wicket during last couple years (last week finally removed last traces of Struts/Spring MVC/JSP from applications), seemed pointless to try to convince someone with so different view on things ;) I am sticking with Wicket because it is required for work. I am able to do stuff in it but it seems unnecessarily complicated. Depends on what you are doing. In Wicket I am doing things I never considered in SpringMVC, as they were too cumbersome and ugly to get working and then maintain them ,,, I own the “Wicket in Action” book and “Enjoying Web Development with Wicket Book” by Kent Ka Iok Tong. The second book is much more practical. Without these books I would not be able to do anything in Wicket. That is why I did not mention documentation. I started without any wicket books. Now I own two, but to be honest - have not red them from cover to cover. There is sufficient information in mailing lists + Javadoc + wicket examples, + WIKI, but I would agree, it could be improved. Learning curve for wicket is not small, but it is objective. It is not reasonable to pick up UI lframework as quickly as JSP or velocity. I would prefer to just be able to check out something like this http://static.springsource.org/docs/petclinic.html. This is a real working application that shows how to do things with databases etc. With Wicket, I had to string a bunch of snippets together and read two books. I am still not sure I am doing things the best way. Yeah. For the beginners it would probably be helpful. Then again - wicket examples cover most components. To people who say I am inexperienced, I have tried JSF and GWT. Wicket is better than both of those. JSF has an invasive and complicated lifecycle. When I saw the lifecycle diagram I just stopped even looking into it. Same here, After Struts, I considered JSF, but after a week and still not getting the magic of JSF lifecycle I just gave up ... In my humble opinion Spring MVC done right (no scriplets) with JSTL EL and jQuery is better than Wicket. You can also use Velocity templating. Spring MVC is nice in its simplicity. So, for simple things, I like it. Problem starts, when you need something more complicated. And page logic in templates is a nightmare, especially for maintenance. Velocity does not help very much, as IDE tool support is very basic. Here is a quote from the Restlet page (http://www.restlet.org/about/introduction): “While powerful for complex centralized models, the object-oriented paradigm isn't always the best suited for Web development. I would agree with this in pre-wicket days. With wicket this is not true any more. And this is what wicket is all about - OO in web development.
Re: Authorization through Spring Security
Do not fight the framework. Use wicket security (wichet-auth-roles + Spring security in my case) for all web tier classes. Use just spring security for service layer (annotations, etc). You can use also url spring security filter, if you need to. In normal wicket applications you do not. But if you are using Spring MVC + Wicket, for example, use filter for Spring MVC links. On Fri, 24 Dec 2010 22:41:04 -0800 Dmytro Seredenko d.serede...@gmail.com wrote: Ok, things become more complex :) Guys, here is the trivial task I'm trying to resolve: provide authentication against datasource (using custom AuthenticationProvider) + authorization based on a set of criteria (user role - one of them) + secure specific pages. I try to solve it using old-school approach with Spring + Spring Security + web framework (Wicket in this case). However looks like not so many people go this way. Can someone who has Wicket experience describe Wicket-friendly solution for that? Do you really use Wicket security for all levels of you app? Or you're using Apache Shiro every time when you choose Wicket as a web framework? P.S. There is not much information about Wicket security strategy on the site and most of it is outdated. I believe some rough design pattern for the task I described will be really useful for other people. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and Netbeans
I am not using maven with netbeans any more - at some point I configured, that
it worked more or less OK, but I did not see any benefit in using it (from
netbeans). Everything was slower and just pain to configure and run. Built in
ant for netbeans works very well. Starting Jetty from runner class (Shift-F5)
in debug mode handles many class changes without Jetty restart. F11 rebuilds
war and copies html. And restarting jetty is very fast.
Jetty7 runner class:
public class Main {
public static void main(String[] args) throws Exception {
Server server = new Server(8084);
WebAppContext webapp = new WebAppContext();
webapp.setContextPath(/example);
webapp.setWar(build/web);
server.setHandler(webapp);
server.start();
server.join();
}
}
On Tue, 24 Aug 2010 10:27:32 -0700 (PDT)
LutherBaker lutherba...@gmail.com wrote:
Per the http://wicket.apache.org/start/quickstart.html quickstart page , I
built the quickstart project ala:
c:\var\dev\netbeansmvn archetype:create
-DarchetypeGroupId=org.apache.wicket
-DarchetypeArtifactId=wicket-archetype-quickstart
-DarchetypeVersion=1.4.10 -DgroupId=foo.bar -DartifactId=foo
opened it in Netbeans, created the action jetty:run and started the
application. All is well and I can see the greeting page.
If I change the text on the html file or alter the message in the class file
- nothing happens. If I shutdown and restart jetty:run, the changes appear.
I added the scanIntervalSeconds:
plugin
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/artifactId
configuration
scanIntervalSeconds3/scanIntervalSeconds
/configuration
/plugin
to the POM file but still no change. Is there something else I must do in
Netbeans to see and publish changes I make to Wicket files or ... is there a
better way to do this so that I'm not constantly restarting the web server?
I also tried the 'Start' class - and I can see the pages - but they do not
refresh when I change anything on them or their related class files.
What is generally the best routine for the smoothest development workflow
with wicket. A different IDE?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket enclosure not finding child!?
According to the developers this was a bug in a the original enclosure implementation, which allowed NOT to add all child components (if enclosure is not shown on page). Now since version 1.4.2 it is corrected. So you have to add both object_title_classification_prefix, and object_title_classification in both cases, when enclosure IS displayed and when it is NOT. For the same reason I am still on 1.4.1, so this is only my guess ... See mailing list archives for enclosure related topics, e.g. http://old.nabble.com/Re:-enclosure-changes-in-1.4.4-p26763772.html Girts Ziemelis On 02/05/2010 12:06 AM, Chris Colman wrote: I've found the problem with any version after 1.4.2. With 1.4.2 I seem to be able to use enclosures just fine - even when the children are supplied by a component resolver - but any 1.4.3, 1.4.4 and 1.4.5 cause problems. I haven't yet tried 1.4.6 but from what you're saying it probably has the same problem. Chris Colman Step Ahead Software http://develop.stepaheadsoftware.com -Original Message- From: Roman Uhlig Maxity.de [mailto:roman.uh...@maxity.de] Sent: Friday, 5 February 2010 2:23 AM To: users@wicket.apache.org Subject: Re: wicket enclosure not finding child!? I just upgraded from 1.4.1 to 1.4.6 and now I'm getting this error too without changing anything else in my source code: 04 Feb 2010 16:01:20,352 ERROR [org.apache.wicket.RequestCycle:1521] Could not find child with id: object_title_classification_prefix in the wicket:enclosure org.apache.wicket.WicketRuntimeException: Could not find child with id: object_title_classification_prefix in the wicket:enclosure at org.apache.wicket.markup.html.internal.Enclosure.checkChildComponent(Enc losure.java:220) at org.apache.wicket.markup.html.internal.Enclosure.ensureAllChildrenPresen t(Enclosure.java:262) at org.apache.wicket.markup.html.internal.Enclosure.onComponentTagBody(Encl osure.java:169) at org.apache.wicket.Component.renderComponent(Component.java:2619) at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1512) at org.apache.wicket.Component.render(Component.java:2450) at org.apache.wicket.MarkupContainer.autoAdd(MarkupContainer.java:229) at org.apache.wicket.markup.resolver.EnclosureResolver.resolve(EnclosureRes olver.java:61) at org.apache.wicket.markup.resolver.ComponentResolvers.resolve(ComponentRe solvers.java:81) at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1418) at org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer .java:1577) at org.apache.wicket.MarkupContainer.onComponentTagBody(MarkupContainer.jav a:1501) at org.apache.wicket.Component.renderComponent(Component.java:2619) at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1512) at org.apache.wicket.Component.render(Component.java:2450) at org.apache.wicket.markup.repeater.AbstractRepeater.renderChild(AbstractR epeater.java:122) at org.apache.wicket.markup.repeater.AbstractRepeater.onRender(AbstractRepe ater.java:103) at org.apache.wicket.Component.render(Component.java:2450) at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1414) at org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer .java:1577) at org.apache.wicket.MarkupContainer.onComponentTagBody(MarkupContainer.jav a:1501) at org.apache.wicket.Component.renderComponent(Component.java:2619) at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1512) at org.apache.wicket.Component.render(Component.java:2450) at org.apache.wicket.MarkupContainer.autoAdd(MarkupContainer.java:229) at org.apache.wicket.markup.resolver.MarkupInheritanceResolver.resolve(Mark upInheritanceResolver.java:66) at org.apache.wicket.markup.resolver.ComponentResolvers.resolve(ComponentRe solvers.java:81) at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1418) at org.apache.wicket.MarkupContainer.renderComponentTagBody(MarkupContainer .java:1577) at org.apache.wicket.MarkupContainer.onComponentTagBody(MarkupContainer.jav a:1501) at org.apache.wicket.Component.renderComponent(Component.java:2619) at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1512) at org.apache.wicket.Component.render(Component.java:2450) at org.apache.wicket.MarkupContainer.autoAdd(MarkupContainer.java:229) at org.apache.wicket.markup.resolver.MarkupInheritanceResolver.resolve(Mark upInheritanceResolver.java:73
Re: wicket enclosure not finding child!?
I might have sounded a bit negative in my replay, but that is actually not the case. I kind of like, that enclosure is consistent with the rest of wicket (where you have to match hierarchies). Also I accept the extra code I have to add in Java class as a punishment for being lazy and not extracting the logic I am putting in enclosure in a separate component. Also most of the previous discussion in a list was for keeping the things as they are currently - after the change :) Reason I am not upgrading to newer version is just a lack of time - checking for missing children in enclosures is a bit time consuming ... :( On 02/05/2010 06:04 PM, Igor Vaynberg wrote: why dont you start a vote to have this changed back to pre-1.4.2 behavior. if enough people agree we would have no problem applying the change. -igor On Fri, Feb 5, 2010 at 1:13 AM, Girts Ziemelisgirts.zieme...@gmail.com wrote: According to the developers this was a bug in a the original enclosure implementation, which allowed NOT to add all child components (if enclosure is not shown on page). Now since version 1.4.2 it is corrected. So you have to add both object_title_classification_prefix, and object_title_classification in both cases, when enclosure IS displayed and when it is NOT. For the same reason I am still on 1.4.1, so this is only my guess ... See mailing list archives for enclosure related topics, e.g. http://old.nabble.com/Re:-enclosure-changes-in-1.4.4-p26763772.html Girts Ziemelis On 02/05/2010 12:06 AM, Chris Colman wrote: I've found the problem with any version after 1.4.2. With 1.4.2 I seem to be able to use enclosures just fine - even when the children are supplied by a component resolver - but any 1.4.3, 1.4.4 and 1.4.5 cause problems. I haven't yet tried 1.4.6 but from what you're saying it probably has the same problem. Chris Colman Step Ahead Software http://develop.stepaheadsoftware.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: enclosure changes in 1.4.4
I also liked the behaviour - it made the code shorter, as I did not have to mirror the component tree in both then and else branches. I guess it is not a big deal, except for the testing headaches - this breaks the code at runtime :( I now, i know - I should have test cases covering all branches in the form :( On 12/13/2009 08:14 AM, Douglas Ferguson wrote: I did find the behavior handy, but it is easy to work around. D/ On Dec 12, 2009, at 11:12 PM, Igor Vaynberg wrote: i think you guys misunderstand. i believe what we are talking about here is the requirement for presence of components *other* then the component specified by enclosure's child attribute. essentially if i do this: add(new webmarkupcontainer(container).setvisible(false)); and have this in my markup: div wicket:id=containerdiv wicket:id=foo//div wicket will not throw an error even though i never added the foo component to my component hierarchy because as soon as it determins that the container div is not visible it will skip over until the closing tag. the enclosures, however, as of 1.4.4 *will* throw an error for *any* missing child declared inside enclosure's markup *even though* the enclosure has been determined as hidden. hope this clears it up somewhat -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: enclosure error
If you are using 1.4.2, there is a known problem with enclosures, which has been fixed in 1.4 snapshot: https://issues.apache.org/jira/browse/WICKET-2506 Either upgrade to snapshot or downgrade to 1.4.1. Sam Zilverberg wrote: i'm getting the following error: WicketMessage: Could not find child with id: serial in the wicket:enclosure Root cause: org.apache.wicket.WicketRuntimeException: Could not find child with id: serial in the wicket:enclosure at org.apache.wicket.markup.html.internal.Enclosure.checkChildComponent(Enclosure.java:210) at org.apache.wicket.markup.html.internal.Enclosure.ensureAllChildrenPresent(Enclosure.java:249) at org.apache.wicket.markup.html.internal.Enclosure.onComponentTagBody(Enclosure.java:169) at org.apache.wicket.Component.renderComponent(Component.java:2626) etc etc this is the part of my html that has the wicket:enclosure in it: html xmlns:wicket wicket:extend form wicket:id=deviceForm div style=float: left; width: 30%; table cellspacing=0 cellpadding=2 wicket:enclosure child=serial tr tdwicket:message key=serialSerial/wicket:message/td tdinput type=text wicket:id=serial size=40 maxlength=32 //td /tr /wicket:enclosure etc etc... and in the java code i'm adding the component with id serial to the form deviceForm. anyone has any idea why this is happening? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Bulgarian translation (bg)
Wicket version is 4.1
Regarding encoding - I know - it is encoded in the properties file
-strings I posted are once the strings are decoded to UTF-8 -for IDE
(Netbeans, for example, does this automatically for *.properties files)
and for the web site (in UTF-8).
For example - ASCII escapes below - first letter \u00d0 is
http://www.fileformat.info/info/unicode/char/00d0/index.htm
which is not a letter from Cyrillic.
My understanding is that all cyrilic charset letters are in unicode
block \u04xx
http://czyborra.com/charsets/cyrillic.html
Are you using BG translation which works correctly?
Olivier Bourgeois wrote:
What version of Wicket are you using ?
You should have native2ascii encoded strings in the property file :
Required=\u00d0\u0178\u00d0\u00be\u00d0\u00bb\u00d0\u00b5\u00d1\u201a\u00d0\u00be
'${label}' \u00d0\u00b5
\u00d0\u00b7\u00d0\u00b0\u00d0\u00b4\u00d1\u0160\u00d0\u00bb\u00d0\u00b6\u00d0\u00b8\u00d1\u201a\u00d0\u00b5\u00d0\u00bb\u00d0\u00bd\u00d0\u00be.
2009/10/11 Girts Ziemelis girts.zieme...@gmail.com
Is anyone using wicket with bulgarian translations?
It seems, the standard wicket messages for bulgarian
Application_bg.properties are all messed up :(
Unfortunately I do not speak/write Bulgarian, but version of survey we are
running is also in BG and our Bulgarian colleagues are complaining about
standard error messages being messed up.
Site is in UTF-8 and many other non standard charset languages are working
fine (e.g. Russian, Latvian).
Strings in the wicket property file do not seem to contain proper Cyrillic
characters:
e.g: string for
Required=Полето '${label}' е задължително.
I do not believe is a proper cyrillic text.
Can anyone confirm the problem, before I submit the bug report?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket Bulgarian translation (bg)
Olivier Bourgeois wrote: I'm using BG translations for my app, but not the Wicket default ones, and I am using a mix of UTF-8 properties files and XML files. I just had a look with wicket 1.4.2 and the BG translations are broken : I think something went wrong with the native2ascii transformation. If you look at the history of the Wicket BG translation file, it used to be in UTF-8, but because Java properties does not hold UTF-8 it has been encoded in ASCII. Now that Wicket 1.4.x can work with XML properties. I think this file should be in XML, like RU file is today. Yes - our BG translations from our property files also work fine - it is just the wicket standard messages. Ok, I will try to get the old translations back and encode them properly. It seems they are wrong since may 2006 :( Or is it really preferred to store them in XML? Currently russian is the only one in XML.
Re: Wicket Bulgarian translation (bg)
Thanks - I added problem report WICKET-2518 https://issues.apache.org/jira/browse/WICKET-2518 Attached is a patch for Application_bg.properties file with properly encoded bg translations Igor Vaynberg wrote: we are fine with .properties or .properties.xml. its all good. -igor On Mon, Oct 12, 2009 at 8:25 AM, Olivier Bourgeois olivier.bourgeois@gmail.com wrote: The advantage of UTF-8 vs ASCII is that the translators can directly read/write the property files without transcoding them, so I think it's better to go with XML (and less risky). But I don't know what the Wicket dev team prefer for Wicket default property files. 2009/10/12 Girts Ziemelis girts.zieme...@gmail.com Olivier Bourgeois wrote: I'm using BG translations for my app, but not the Wicket default ones, and I am using a mix of UTF-8 properties files and XML files. I just had a look with wicket 1.4.2 and the BG translations are broken : I think something went wrong with the native2ascii transformation. If you look at the history of the Wicket BG translation file, it used to be in UTF-8, but because Java properties does not hold UTF-8 it has been encoded in ASCII. Now that Wicket 1.4.x can work with XML properties. I think this file should be in XML, like RU file is today. Yes - our BG translations from our property files also work fine - it is just the wicket standard messages. Ok, I will try to get the old translations back and encode them properly. It seems they are wrong since may 2006 :( Or is it really preferred to store them in XML? Currently russian is the only one in XML. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
1.4.2 upgrade problem
Sorry about double post - I sent it first to the dev list accidentally :( I believe there is a bug in wicket 1.4.2, which stopped me from upgrading :( I have created issue for this (quickstart added): https://issues.apache.org/jira/browse/WICKET-2519 Finally I narrowed it down to adding following to quick start, which works fine in 1.4.1 and fails in 1.4.2: 2 lines to HomePage.html wicket:enclosurebr/a wicket:id=logoutwicket:message key=logout //a/wicket:enclosure wicket:enclosurea wicket:id=loginwicket:message key=login //a/wicket:enclosure 2 lines to HomePage.java add(new BookmarkablePageLinkVoid(logout, HomePage.class)); add(new BookmarkablePageLinkVoid(login, HomePage.class)); and HomePage.properties login=Login logout=Logout I get following stack trace WicketMessage: Could not find child with id: login in the wicket:enclosure Root cause: org.apache.wicket.WicketRuntimeException: Could not find child with id: login in the wicket:enclosure at org.apache.wicket.markup.html.internal.Enclosure.checkChildComponent(Enclosure.java:210) at org.apache.wicket.markup.html.internal.Enclosure.ensureAllChildrenPresent(Enclosure.java:249) at org.apache.wicket.markup.html.internal.Enclosure.onComponentTagBody(Enclosure.java:169) at org.apache.wicket.Component.renderComponent(Component.java:2626) at org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1512) at org.apache.wicket.Component.render(Component.java:2457) at org.apache.wicket.MarkupContainer.autoAdd(MarkupContainer.java:229) at org.apache.wicket.markup.resolver.EnclosureResolver.resolve(EnclosureResolver.java:61) at org.apache.wicket.markup.resolver.ComponentResolvers.resolve(ComponentResolvers.java:81) at org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1418) at org.apache.wicket.MarkupContainer.renderAll(MarkupContainer.java:1528) at org.apache.wicket.Page.onRender(Page.java:1545) at org.apache.wicket.Component.render(Component.java:2457) at org.apache.wicket.Page.renderPage(Page.java:914) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.respond(BookmarkablePageRequestTarget.java:262) at org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:105) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1258) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428) at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:468) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:301) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:295) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:503) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:827) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:511) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:210) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:379) at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicket Bulgarian translation (bg)
Is anyone using wicket with bulgarian translations?
It seems, the standard wicket messages for bulgarian
Application_bg.properties are all messed up :(
Unfortunately I do not speak/write Bulgarian, but version of survey we
are running is also in BG and our Bulgarian colleagues are complaining
about standard error messages being messed up.
Site is in UTF-8 and many other non standard charset languages are
working fine (e.g. Russian, Latvian).
Strings in the wicket property file do not seem to contain proper
Cyrillic characters:
e.g: string for
Required=Полето '${label}' е задължително.
I do not believe is a proper cyrillic text.
Can anyone confirm the problem, before I submit the bug report?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
