Re: DateTimeField or html5 date
Thanks Martin for this quick answer! Martin Grigorov mgrigo...@apache.org , 18-12-2013 8:51: Hi, Wicket just generates the final page markup. So the decision what to use depends on: what user experience you want to provide ? By using HTML5's date, datetime, ... types some browsers will show datepicker-like widget, and other browsers won't show anything (older versions of IE). So your users will have different experience if they use different browsers. Martin Grigorov Wicket Training and Consulting On Wed, Dec 18, 2013 at 9:45 AM, gerritqf gerrit.wass...@qfactors.nlwrote: Hello, I am using Wicket now for a couple of weeks. In my form i have some datefields. Now is my question: considering my not so experienced knowledge about Wicket, is it better to use the html5 input type=date or should i implement a DateTimeField (like the example in Wicket in Action, page 208)? Thanks! Greetings Gerrit -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/DateTimeField-or-html5-date-tp4663100.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
Wicket 6.12 and wicket-native-websocket-javax
Is there a 6.X branch I can use which contains native javax websockets? My git kung fu is letting me down. (Still only a white belt) Thanks Peter.
Re: Wicket 6.12 and wicket-native-websocket-javax
Hi, https://twitter.com/mtgrigorov/status/364323832490110976 The main problem is that JSR 356 API and all impls are build with JDK7, and Wicket 6.x uses JDK 1.6 ... But it seems this is not a problem for the -jetty9 module. The build works (somehow) without problems. If there are no objections from others then I can port the module to wicket-6.x branch. But why do you prefer the -javax impl ? The Wicket Native WebSocket APIs for Jetty and Tomcat are the same, the only difference is the WicketFilter impl you should use. Martin Grigorov Wicket Training and Consulting On Wed, Dec 18, 2013 at 1:09 PM, Peter Henderson peter.hender...@starjar.com wrote: Is there a 6.X branch I can use which contains native javax websockets? My git kung fu is letting me down. (Still only a white belt) Thanks Peter.
Re: Wicket 6.12 and wicket-native-websocket-javax
Hi Martin, Tomcat 7.0.47 back ported javax websockets from 8. Which means wicket-native-websocket-tomcat no longer works (well I couldn't get it working but I didn't try too hard) Wicket 7 sounds lovely. Many thanks Peter. On 18 December 2013 11:23, Martin Grigorov mgrigo...@apache.org wrote: Hi, https://twitter.com/mtgrigorov/status/364323832490110976 The main problem is that JSR 356 API and all impls are build with JDK7, and Wicket 6.x uses JDK 1.6 ... But it seems this is not a problem for the -jetty9 module. The build works (somehow) without problems. If there are no objections from others then I can port the module to wicket-6.x branch. But why do you prefer the -javax impl ? The Wicket Native WebSocket APIs for Jetty and Tomcat are the same, the only difference is the WicketFilter impl you should use. Martin Grigorov Wicket Training and Consulting On Wed, Dec 18, 2013 at 1:09 PM, Peter Henderson peter.hender...@starjar.com wrote: Is there a 6.X branch I can use which contains native javax websockets? My git kung fu is letting me down. (Still only a white belt) Thanks Peter.
Re: Wicket 6.12 and wicket-native-websocket-javax
I think the old impl is deprecated but still there in 7.0.47. I'll test it soon. Martin Grigorov Wicket Training and Consulting On Wed, Dec 18, 2013 at 2:05 PM, Peter Henderson peter.hender...@starjar.com wrote: Hi Martin, Tomcat 7.0.47 back ported javax websockets from 8. Which means wicket-native-websocket-tomcat no longer works (well I couldn't get it working but I didn't try too hard) Wicket 7 sounds lovely. Many thanks Peter. On 18 December 2013 11:23, Martin Grigorov mgrigo...@apache.org wrote: Hi, https://twitter.com/mtgrigorov/status/364323832490110976 The main problem is that JSR 356 API and all impls are build with JDK7, and Wicket 6.x uses JDK 1.6 ... But it seems this is not a problem for the -jetty9 module. The build works (somehow) without problems. If there are no objections from others then I can port the module to wicket-6.x branch. But why do you prefer the -javax impl ? The Wicket Native WebSocket APIs for Jetty and Tomcat are the same, the only difference is the WicketFilter impl you should use. Martin Grigorov Wicket Training and Consulting On Wed, Dec 18, 2013 at 1:09 PM, Peter Henderson peter.hender...@starjar.com wrote: Is there a 6.X branch I can use which contains native javax websockets? My git kung fu is letting me down. (Still only a white belt) Thanks Peter.
Re: Example for presenting pdf in modal window
Hey, The Java code runs without any errors, but the InlineFrame sametimes loads the wrong pdf files. When i open the page the first time it always loads a File i deleted 13 days ago. I can’t even find it on my pc anymore... The code is the standard code from git and the Folder contains only the right pdf. myInlineFrame = new DocumentInlineFrame(mypdf, new FileResourceStream( D:\\test\\mypdf.pdf)); theForm.add(myInlineFrame) The second Problem is that the InlineFrame is in the front. So when i add a DateField with a calender oder the InlineFrame the Calender opens behind the InlineFrame and is not visible. how can i change that? Sry for all these questions but I am a beginner and do not know anybody else to ask. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Example-for-presenting-pdf-in-modal-window-tp1879547p4663108.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
Re: Example for presenting pdf in modal window
On Wed, Dec 18, 2013 at 3:20 PM, MyScheme katerc...@web.de wrote: Hey, The Java code runs without any errors, but the InlineFrame sametimes loads the wrong pdf files. When i open the page the first time it always loads a File i deleted 13 days ago. I can’t even find it on my pc anymore... The Sounds like a caching issue. Clear the caches in your browser. Also add: webResponse.disableCaching() in the code that delivers the PDF to prevent the same problem in the future code is the standard code from git and the Folder contains only the right pdf. myInlineFrame = new DocumentInlineFrame(mypdf, new FileResourceStream( D:\\test\\mypdf.pdf)); theForm.add(myInlineFrame) The second Problem is that the InlineFrame is in the front. So when i add a DateField with a calender oder the InlineFrame the Calender opens behind the InlineFrame and is not visible. how can i change that? Google: CSS z-index Sry for all these questions but I am a beginner and do not know anybody else to ask. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Example-for-presenting-pdf-in-modal-window-tp1879547p4663108.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
Re: Example for presenting pdf in modal window
Hey, Cleared the Cache but the document is still shown on the web side. Maybe the Adobe Reader saves the file somewhere? CSS z-index are not working. The calendar which opens on click is still in the background of the DocumentInlineFrame. Thanks for your help, Patrick -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Example-for-presenting-pdf-in-modal-window-tp1879547p4663111.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
Extending TextField to display Joda's LocalTime in HH:mm format
Dear Forum, I am trying to have an input field in which user inserts a time of the day in HH:mm format. In some cases, the field could be already populated. I thought of extending TextFieldLocalTime and pass a LocalTime object to the form field. The problem is that when if the local time variable already has a value, the LocalTime field will be populated in HH:mm:ss.SSS format. How can I properly extend TextField so that when populating the field it will do it in *HH:mm* format, please? I would be grateful if someone could point me in the right direction? I am trying to extend text field but I don't know which function I should override. My simple example is as follow: HomePage class: HomePage HTML: And the maven import for joda time: Thanks in advance, Lucas -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Extending-TextField-to-display-Joda-s-LocalTime-in-HH-mm-format-tp4663112.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
Re: Extending TextField to display Joda's LocalTime in HH:mm format
Use a converter: http://wicket.apache.org/guide/guide/chapter11.html#chapter11_3 Regards Sven On 12/18/2013 04:40 PM, lucast wrote: Dear Forum, I am trying to have an input field in which user inserts a time of the day in HH:mm format. In some cases, the field could be already populated. I thought of extending TextFieldLocalTime and pass a LocalTime object to the form field. The problem is that when if the local time variable already has a value, the LocalTime field will be populated in HH:mm:ss.SSS format. How can I properly extend TextField so that when populating the field it will do it in *HH:mm* format, please? I would be grateful if someone could point me in the right direction? I am trying to extend text field but I don't know which function I should override. My simple example is as follow: HomePage class: HomePage HTML: And the maven import for joda time: Thanks in advance, Lucas -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Extending-TextField-to-display-Joda-s-LocalTime-in-HH-mm-format-tp4663112.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.4.7 app form does not submit on server when panel is not visible.
This is in one of our Wicket 1.4.7 apps that we have not converted yet. The
problem does not happen in localhost test environments, but does happen on
the server. Moreover, the problem only happens when a data condition causes
a particular panel to be visible.
When this panel is visible (and I pick that because it is the only major
difference between it working and failing), the page does not submit. I hit
the submit button, and rather than advancing to the next page, the current
page redisplays with no validation errors displayed.
Loig statements at the top of every event do not fire. Log statements at
the top of the validate methods of the three validators applied to the form
do not fire.
The panel itself seems fairly nondescript:
private void buildEDocPanel() {
WebMarkupContainer wmc = new WebMarkupContainer(eDocsWrapper);
DocTypeSelect docTypes = new DocTypeSelect(eDocTypes,
model.geteDocTypes()) {
private static final long serialVersionUID = 1L;
@Override
public ListFilterValue loadDocumentTypes() {
return
lookupService.fetchFilterValuesByFilterName(Document Type);
//Document Type
}
};
form.add(wmc);
wmc.add(docTypes);
wmc.setVisible(model.getApplicationCode().equals(UMCConstants.APPL_EDOCS));
}
DocTypeSelect is a custom panel that implements a wizard-y control where one
side has a master list and you pick which ones to add to the right side's
list with add/remove buttons in the middle. The code for this panel is
below. Based on the log, the onAddSelected method and onSelectionChange
method fire, but both of those are BEFORE the page submit.
The HTML for the submit button is:
input type=submit class=submit btnsubmit wicket:id=nextBtn
onclick=document.ignoreDirty=true;return true; value=Step 3: Review
gt;
The onclick is for a are you sure you want to leave since you have made
changes kind of warning in javascript. It doesn't interfere in localhost
or if the panel is not visible, and when it prevent departure, the page
wouldn't reload, so i am mostly sure that isn't the problem, but I present
that it is an input type submit since that has sometimes made a difference
during my experience with wicket.
public abstract class DocTypeSelect extends Panel {
private static final long serialVersionUID = 1L;
private static Logger log = Logger.getLogger(DocTypeSelect.class);
private ListFilterValue selected;
private ListMultipleChoiceFilterValue ddAvailable;
private ListMultipleChoiceFilterValue ddSelected;
public DocTypeSelect(String id, ListFilterValue selectedDocTypes) {
super(id);
selected = selectedDocTypes;
init();
}
private void init() {
buildLeftSide();
buildCenter();
buildRightSide();
}
public abstract ListFilterValue loadDocumentTypes();
public void onSelectionChange(AjaxRequestTarget target,
ListFilterValue
selected) {
log.debug(onSelectionChange());
}
@SuppressWarnings({ unchecked, rawtypes })
private void buildLeftSide() {
ListFilterValue docTypes = loadDocumentTypes();
ddAvailable = new
ListMultipleChoiceFilterValue(docTypesAvailable,
new Model(new ArrayListFilterValue()),
docTypes,
new IChoiceRendererFilterValue() {
private static final long
serialVersionUID = 1L;
@Override
public Object
getDisplayValue(FilterValue arg0) {
return
arg0.getFilterValueDecode();
}
@Override
public String getIdValue(FilterValue
arg0, int arg1) {
return arg0.getFilterValue();
}
});
add(ddAvailable);
}
private void buildCenter() {
add(new AjaxButton(addSelected) {
private static final long serialVersionUID = 1L;
@SuppressWarnings({ rawtypes })
@Override
protected void onSubmit(AjaxRequestTarget target, Form
form) {
onAddSelected(target);
}
}.setDefaultFormProcessing(false));
add(new AjaxButton(addAll) {
wicket-el - is this a safe way to hook into wicket?
A few weeks back I made a post about the first version of universal expression language for wicket. Since then it's come quite a way. The initial version hooked into by implementing IMarkupResourceStreamProvider for markup owning MarkupContainers (Panel, Page etc...) and by regenerating markup fragments for markup receiving MarkupContainers (ListView). Unfortunately due to the fact that the EL expressions need to be evaluated on every request this meant a huge performance hit (about 75% less than standard wicket) due to forcing wicket to constantly parse markup on every request cycle. The current evolution of wicket-el hooks in very differently. My first preference was to create a dynamic version of Markup and MarkupFragment that replaces MarkupElements that contain EL expressions with a dynamic version. Unfortuantely this was impossible because I need to subclass Markup (wicket uses a few case of 'instanceof Markup') and Markup has many final methods. And simply wrapping all the MarkupElements isn't possible because RawMarkup is a final class and is also reference inside wicket with 'instanceof'. So the only way I could think of to do it (which I've done and it works) is to create a subclass of Markup (ModifiableMarkup) that takes the original wicket-parsed markup, and adds all it's elements. Then during the onRender phase EL enabled components call ModifiableMarkup.resolve(ExpressionResolver, ELParseMatchList) which internally replaces RawMarkup elements belonging to that compenent with an EL resolved version. This is done just before calling super.onRender(). Sounds ugly but it works and performance is now equal to standard wicket (in some cases can even be a little faster due to not needing PropertyModels). Because the Markup instances are now mutable I can't use wicket's markup cache as it's one per class and ModifiableMarkup.resolve method could easily be called by many threads at once. So I've had to implement caching per thread/class combination. i.e. ELPanel will have a cached instance of Markup for every thread. My question is twofold: 1/ As I have no choice but to leave ModifiableMarkup mutable, what is the purpose of making Markup immutable? From what I can see from browsing wicket source all it achieves is a bit of safety and releasing some resources from the backing XmlTags in the MarkupElements. Is there any other purpose to it? i.e. can you forsee any problems with using a mutable instance of Markup for rendering? 2/ Is the per thread/class caching strategy really safe? The only way I could think it could be broken is if it was possible for the server to suspend a thread mid-render cycle and give another request use of that thread. If that happened the new request would overwrite the markup expressions and the when the old resumed and expressions already resolved would have values from the the request that interrupted it. As far as I'm aware with the work I've done with Jetty and NIO connectors before this will only happen if you ask Jetty to do it while processing the request. Is this a possibility with wicket or can I rely on a complete render cycle to happen uninterrupted before the thread is reused for another request?
