Re: pivot table for wicket
Great! Always a very useful component! Tom On 7-8-2012 9:46, Decebal Suiu wrote: Hi I implemented a simple pivot table for wicket that can be found at https://github.com/decebals/wicket-pivot Best regards, Decebal -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/pivot-table-for-wicket-tp4651031.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: logout
Ok. The actual problem I have is that wicket auth keeps logging in automatically. This is a side effect of a.o. BASIC authentication (not sure if that is used in this case, but the behavior is similar) which sends the login credentials with every request, even if you have logged out in the mean time. To enforce a new login via the login page, one usually places some marker in the session telling the authenticator class that it should not accept the current credentials until a valid login page submit was done. But since Wicket keeps doing things to the session, I'm not able to get this marker to work. Are there any people using auth and that are able to fully log out? Tom On 2012-06-25 13:29, Martin Grigorov wrote: Hi Tom, I agree with your vision. But since Wicket is a framework around the Servlet API we call HttpSession.invalidate(). This triggers some web container internal workings and at some point Wicket is called back (see javax.servlet.http.HttpSessionListener/HttpSessionBindingListener) and Wicket clears everything that it added to this session. What happens with this session later is not our business. It may be teared down or recycled, we really don't care. Next time we need to store something in the http session we just call: httpRequest.getSession(true) and use it. I know you use recent version of Wicket (6.x ?) and there are no pagemaps since Wicket 1.5.0 but if you find that anything leaks then it is a bug and it should be fixed. On Sat, Jun 23, 2012 at 11:31 AM, Tom Eugelink t...@tbee.org wrote: Which means that upon logout, these values should be removed / cleared. A session does not represent a user, it is a construct to bind request, no more no less. All other usages are bolted on and should be bolted off. You don't tear down the house, just because you are moving. Tom On 2012-06-23 10:18, Bert wrote: But Wicket also stores the page map in the session to support back button functionality. If you only change the status, than the user could possibly (depending on how you construct your page) go back after the logout and see the last pages. This could be a problem on public computers. You could also see a session as representing a user, not a browser. Than, invalidating the session on logout makes perfect sense to me. regards - 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: logout
Ok. I also have a logout page, call signout in the before-render, and then use the exception thing to immediately forward to another page. Maybe actually showing the logout page is the trick (better a page and autologin all the time). What do you do on the logout page to force the logout? Tom On 2012-06-25 13:58, Stefan Moises wrote: Hi Tom, we are using wicket auth and we can only logout if we use a dedicated Signout page (with template) - if we only logout (and e.g. try to forward right to the homepage with setResponsePage()) it doesn't work and the user always stays logged in as you describe it. We'd love to get rid of the additional Signout page though (because it only says Good bye and is rather annoying for regular users I think ...) :) Stefan Am 25.06.2012 13:38, schrieb Tom Eugelink: Ok. The actual problem I have is that wicket auth keeps logging in automatically. This is a side effect of a.o. BASIC authentication (not sure if that is used in this case, but the behavior is similar) which sends the login credentials with every request, even if you have logged out in the mean time. To enforce a new login via the login page, one usually places some marker in the session telling the authenticator class that it should not accept the current credentials until a valid login page submit was done. But since Wicket keeps doing things to the session, I'm not able to get this marker to work. Are there any people using auth and that are able to fully log out? Tom On 2012-06-25 13:29, Martin Grigorov wrote: Hi Tom, I agree with your vision. But since Wicket is a framework around the Servlet API we call HttpSession.invalidate(). This triggers some web container internal workings and at some point Wicket is called back (see javax.servlet.http.HttpSessionListener/HttpSessionBindingListener) and Wicket clears everything that it added to this session. What happens with this session later is not our business. It may be teared down or recycled, we really don't care. Next time we need to store something in the http session we just call: httpRequest.getSession(true) and use it. I know you use recent version of Wicket (6.x ?) and there are no pagemaps since Wicket 1.5.0 but if you find that anything leaks then it is a bug and it should be fixed. On Sat, Jun 23, 2012 at 11:31 AM, Tom Eugelink t...@tbee.org wrote: Which means that upon logout, these values should be removed / cleared. A session does not represent a user, it is a construct to bind request, no more no less. All other usages are bolted on and should be bolted off. You don't tear down the house, just because you are moving. Tom On 2012-06-23 10:18, Bert wrote: But Wicket also stores the page map in the session to support back button functionality. If you only change the status, than the user could possibly (depending on how you construct your page) go back after the logout and see the last pages. This could be a problem on public computers. You could also see a session as representing a user, not a browser. Than, invalidating the session on logout makes perfect sense to me. regards - 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 - 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: logout
On 2012-06-22 16:57, Tom Eugelink wrote: Anyhow, I've added Wicket Auth/Roles (http://wicket.apache.org/learn/projects/authroles.html) as the security framework and it is working fine except one thing; logging out. I've found that the login / logout logic is invalidating the session. During an attempt to setup security in a webapp years back, I found that Tomcat also does this and I never understood why. The session is a technical construct that binds requests from the same browser and allows the website to become coherent over multiple request. It has nothing to do with an authentication state. Naturally it can be used as a means to administer if a user is logged in, but there is no reason to trash the session when a user is logging out; after all, it's still the same brower sending requests. The session has not changed, the user's status has. The security filter I've implemented years back as a result of this discovery simply changes the logged in state in the current session. If any attributes need to be cleared when a user logs out, this is easily done by removing them from the current session (may even by using a special map store as an attribute in the session). This will prevent the automatic login I'm experiencing now. I will roll my security filter in to my wicket app. Tom - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: logout
Which means that upon logout, these values should be removed / cleared. A session does not represent a user, it is a construct to bind request, no more no less. All other usages are bolted on and should be bolted off. You don't tear down the house, just because you are moving. Tom On 2012-06-23 10:18, Bert wrote: But Wicket also stores the page map in the session to support back button functionality. If you only change the status, than the user could possibly (depending on how you construct your page) go back after the logout and see the last pages. This could be a problem on public computers. You could also see a session as representing a user, not a browser. Than, invalidating the session on logout makes perfect sense to me. regards - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
logout
I've started a new project and decided to use Wicket for the web component again. Still intrigued enough to be curious how it will work out. Anyhow, I've added Wicket Auth/Roles (http://wicket.apache.org/learn/projects/authroles.html) as the security framework and it is working fine except one thing; logging out. I am invalidating the session but the next time I want to log in, the credentials of the previous login are picked up automatically. Maybe sometime during testing I had the remember me checkbox selected, I don't know but I don't believe so, but this now causing me problems. 1. How can I stop this cross-session autologin? 2. How can I do a full log out? Tom - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JPA: iplease/i a simple way to go
On 16-5-2012 11:29, Martin Grigorov wrote: On Wed, May 16, 2012 at 11:18 AM, hfriederichsh.friederi...@ohra.nl wrote: Just an afterthought - I can't figure out the English word for the Dutch 'nabrander'. As it happens, my afterthought has to do with another (non-existing) Dutch word: /hoevaakheid/. Translated to English you would also get an non-existing word: /howoftenness/. Maybe that's funny, maybe not. But apart from that, I think howoftenness is a very important and often neglected concept. And your example is a perfect application of good use of howoftenness. How many 'layers of decoupling' have been written that turned out to be useless... Had one only thought of howoftenness... If you create an app with 2 pages then these layers look useless indeed, but if you create a bigger app then you will see how all this becomes useful. You'll configure the layers once (it will take you a day or two) but after that you will just inject the EntityManager and use it in PageN, and this will return your initial investment. Apart of that, doing manual transaction management is just silly. Better let the layers to do this for you instead of spreading such kind of logic all over your code. In my opinion both are correct. Some layers need to be in from the start, because putting them in afterwards is a tremendous effort (e.g. separation of concern). Some layers should only be put in if the requirements actually requires them or it is reasonable to expect it to become a requirement (e.g. internationalization), or when the abstraction actually would be saving effort (spreading of code). For example: the need to type Name in the html and in the setLabel does IMHO not justify in the resource files abstraction. I'd also need to keep the ID for fetching the label in two locations in sync, which is the same effort. Or I would also need to add an additional abstraction by using a central list of java string constants. Fetching an EM should happen only in one place, because that is most definitely a separate concern. But how complex that must be can evolve from a simple setup to quantum logic. I currently have a fetch EM logic in a Swing application that evolved to being based on open JFrames and active focus. Topm - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JPA: iplease/i a simple way to go
On 16-5-2012 11:52, Martin Grigorov wrote: Using a resource bundle for i18n has this big benefit for me: all my translations are in *one* place. But if the app does not have translations as a requirement? But this is your app... Ignore me. That would be unfriendly :-) Tom - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JPA: iplease/i a simple way to go
Chiming in; As it happens I'm currently working on a NoSQL (Cassandra) project and found a JPA implementation for Cassandra (http://code.google.com/p/kundera/). Currently JPA is the most used persistency API in Java, allowing for binding with RDBMS, XML, NoSQL. I decided not to use it, BTW, but that is because of other considerations. To also have an quick opinion on the rest of the thread (as I understand it). Java projects have a tendency to over complicate and bloat. For example, wicket convention dictates that all labels should be put in property files. I decided not to do that. I fully understand the advantages, but for this project I'm simply not going to add an additional label component and a property file just to get Name on the screen. Yes, if it must be internationalized I have to rework my code, but as it stands the application probably won't have to be, and I would have added the abstraction for nothing. Same goes for the 6 line JPA example a few posts back. If it works, great, just use it as is. Why make it more complex from the start? Refactor if you need to, not overarchitecture in advance. I found that this pragmatic style (mind you; it's all a balance, you can't skip every corner), usually delivers results PHP style fast, but still has Java quality architecture in the overall setup. And even with all refactoring counted in, it stays well within budget; I'm currently aiming to complete my project in 75% of the Java architecture estimate. ;-) Coming full circle; one of the corners you can't cut is clear separation of concern. So extracting the model (JPA) from the presentation (wicket) is very important. My 2 euro cents. And thanks for a well though through framework, I'm warming up to it. Tom On 2012-05-13 09:51, dhar...@yahoo.com wrote: Has your company heard of NOSQL? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JPA: iplease/i a simple way to go
On 2012-05-13 13:49, James Carman wrote: If your application is that simple, check out Wicketopia. Always interesting, but the information (http://wicketopia.sourceforge.net/) is, ah, lacking? :-) Tom - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and JPA: iplease/i a simple way to go
Where? I get almost empty pages. About Wicketopia Example Application A Rapid Application Development (RAD) library for the Apache Wicket framework On 2012-05-13 18:44, James Carman wrote: There is a sample application by the way. It'll give you a good idea of the capabilities. On May 13, 2012 12:18 PM, James Carmanjcar...@carmanconsulting.com wrote: Patches and contributions are welcome. On May 13, 2012 10:55 AM, Tom Eugelinkt...@tbee.org wrote: On 2012-05-13 13:49, James Carman wrote: If your application is that simple, check out Wicketopia. Always interesting, but the information (http://wicketopia.** sourceforge.net/http://wicketopia.sourceforge.net/) is, ah, lacking? :-) Tom --**--**- To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.orgusers-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket 6.0
I'm back on my Wicket project tomorrow, so I'll give it spin. Dank je. Tom On 2012-05-09 10:31, Hielke Hoeve wrote: Hi Tom, We now have a working WiQuery 6. I will release a new snapshot tonight, but you can clone it from github already. Hielke -Original Message- From: Tom Eugelink [mailto:t...@tbee.org] Sent: vrijdag 13 april 2012 14:44 To: users@wicket.apache.org Subject: Re: wicket 6.0 On 2012-04-13 14:24, Martin Grigorov wrote: How many of you tried beta1 ? I started off with 6, but was afraid things like wiquery would conflict in the usage of jquery, so I returned to safety using 1.5.5. Should that be a problem? Otherwise I'll upgrade back to 6. Tom - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Status of wicketstuff jquery integration
As a fairly newbie to Wicket I also found the JQuery integration most confusing (and have abandoned it for now). Too many projects trying to do the same, with only half a documentation and half of the components. IMHO, with Wicket 6 ready using jquery for its Ajax (as I understand it), it could be very wise to more formally adopt JQuery, similar to wicket extentions or DateTime. Tom - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
generics
I would like to suggest an API improvement in the fluent interface, which
should not break backwards compatibility. Currently if you create, say, a
mandatory FileUploadField, you cannot do this.
/FileUploadField lFileUploadField = new FileUploadField(fileInput,
...).setRequired(true);
/
Because setRequired is actually implemented in FormComponent and returns a
FormComponent. By adding the component type to the generics of FormComponent
and casting the return value, this could be resolved.
/public abstract class FormComponentT, C/
/{
public C setRequired(boolean required)
{
...
return (C)this;
}
}
/
/public class FileUploadField extends FormComponentListFileUpload,
FileUploadField/
/{
...
}
/Now the setRequired method in FormComponent knows exactly what type to return.
The casting naturally does not earn a style award, but the improvement in the
API does, and in my opinion is worth the trade-off.
Tom
constant strings
The Wicket application I'm developing is an internal app which will only be available in English. In order to not unnecessarily bloat the code and the project, I'm often use hardcoded labels. I know this is not convention, but there is no reason for me to introduce a resource file and use the ResourceModel. So my code has a number of lines like: .setLabel(new Model(Valid from)) All these models result are being stored in the state, I presume, while there is no reason because the value is hardcoded. Wouldn't it be practical to have a model that never stores anything in the state, for example a ConstantModelT? Being a newbie to Wicket I have problems envisioning if and how this would work. Tom - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: constant strings
On 2-5-2012 17:07, Eric Jablow wrote: Actually, there are reasons to use resource files. If you use a label on more than one page, or even more than once on a single page, and if your application is changing as you develop it, you may want to change the text for a label, and you probably will want to change all the labels at once. So, you can do a multi-file search/replace, or you may change just one properties file. And, there's a value in consistency too. Some people go to the extreme of never including any plain text in an html file at all. I know. I use resources file often, but the scenario that I'm in now lets me lean towards not using them; Java applications are always bloated and arguments like that. Here the additional layer of a resource file it is not really needed. Conceptual discussion aside, the question of not storing constant values in the state seems valid to me. Tom - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: constant strings
On 2012-05-02 17:16, Igor Vaynberg wrote: if it doesnt store anything then where would it get the value from when the second request needs to be processed? wicket components live across many requests. Don't know. That exactly was my question. Is it possible to not store constant values in the state? Maybe because they are recreated when the post reexecutes the java code setting up the components? The answer can very well be no. Tom - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: constant strings
AH! Ok. Makes sense! Thanks. Tom On 2012-05-02 17:23, Igor Vaynberg wrote: no. if you do not want to store the string then instead of a new Model use new AbstratReadOnlyModel(). -igor - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
property converting model
I've got a form bound to a CompoundPropertyModel. One of the properties
contains a XML document. In order to edit that property, I've added a TextArea
to the form (with the CodeMirror javascript XML editor bound to it), but I need
to convert the XML document property to string and back again. I've implemented
this by creating an anonymous model, like this:
lForm.add(new TextArea(services, new IModelString()
{
@Override
public void detach()
{
}
@Override
public String getObject()
{
return
JAXBUtil.extractAndSerializeServicesElement(lLicenseJAXB);
}
@Override
public void setObject(String s)
{
try
{
JAXBUtil.parseAndSpliceServicesElement(lLicenseJAXB, s);
}
catch (Exception e)
{
lErrorOccurredAtomicBoolean.set(true);
slf4j.error(Error during submit, e);
error(e.getLocalizedMessage());
}
}
}).setOutputMarkupId(true).setMarkupId(codemirror));
There are a few question I have:
1. Is this the right way to add such a conversion?
2. Will this model be persisted to the session as well? I of course do not want
that, it just needs to convert.
3. If there is an exception in setObject, I use an AtomicBoolean to register
that, so that the Form.onSubmit knows that something is amiss. Otherwise I get
a big fat exception on the screen or the ssubmit just continues. Is there a
better way?
4. If there is an error, I would like getObject to return the value that was
submitted by the form, so that the user can correct his mistake. Now it always
returns the value before the edit. How to do that?
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: property converting model
The converter correctly converts, but if there is an error in the converter, I'm getting a exception dump on screen. Root cause: org.xml.sax.SAXParseException; lineNumber: 4; columnNumber: 3; The element type notificationx must be terminated by the matching end-tag /notificationx. at org.apache.xerces.parsers.DOMParser.parse(Unknown Source) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source) at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:121) at com.service2media.licenseframework.service.license.jaxb.JAXBUtil.parseServicesElement(JAXBUtil.java:256) at com.service2media.licenseframework.wicket.MasterLicenseEdit$13$1.convertToObject(MasterLicenseEdit.java:395) at org.apache.wicket.markup.html.form.FormComponent.convertInput(FormComponent.java:1141) at org.apache.wicket.markup.html.form.AbstractTextComponent.convertInput(AbstractTextComponent.java:129) at org.apache.wicket.markup.html.form.FormComponent.validate(FormComponent.java:1083) at org.apache.wicket.markup.html.form.Form$16.validate(Form.java:1759) at org.apache.wicket.markup.html.form.Form$ValidationVisitor.component(Form.java:170) at org.apache.wicket.markup.html.form.Form$ValidationVisitor.component(Form.java:154) at org.apache.wicket.util.visit.Visits.visitPostOrderHelper(Visits.java:273) at org.apache.wicket.util.visit.Visits.visitPostOrderHelper(Visits.java:261) at org.apache.wicket.util.visit.Visits.visitPostOrder(Visits.java:244) at org.apache.wicket.markup.html.form.FormComponent.visitFormComponentsPostOrder(FormComponent.java:349) at org.apache.wicket.markup.html.form.Form.visitFormComponentsPostOrder(Form.java:998) at org.apache.wicket.markup.html.form.Form.validateComponents(Form.java:1751) at org.apache.wicket.markup.html.form.Form.validate(Form.java:1716) at org.apache.wicket.markup.html.form.Form.process(Form.java:803) at org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:762) at org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:692) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.wicket.RequestListenerInterface.internalInvoke(RequestListenerInterface.java:260) at org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:216) at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:248) at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:234) at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:781) at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:255) at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:212) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:283) at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:185) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:241) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:217) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279) at org.apache.catalina.core.StandardContextValve.__invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java) at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:161) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:331) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:231) at com.sun.enterprise.v3.services.impl.ContainerMapper$AdapterCallable.call(ContainerMapper.java:317) at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195) at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849) at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746) at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045) at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
Re: property converting model
You are right. I'm sorry. On 25-4-2012 14:56, Martin Grigorov wrote: ... and if it fails with org.apache.wicket.util.convert.ConversionException ... try/catch your code and wrap the original exception in ConversionException and rethrow - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: focus locked in place
This is very sad; I had a label tag (that was copied with the initial HTML) wrapping the whole table. On 2012-04-19 14:11, Tom Eugelink wrote: Ok, I've opened wicket's ajax debugger and there is NO ajax call. I hope this helps you find out what causes the jumps in the focused elements. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: reloading of HTML and classes
Aha! This is very interesting. I have the same problems and wrote my own resource finder, which works ok now. But this would explain what the original problem is! Should be a fairly easy problem to fix, though. Tom On 2012-04-20 18:24, Andrew Geery wrote: An issue I ran into with having Wicket reload the html files in development mode is that it doesn't seem to work if the path to the html files has spaces in it. For example, running under Eclipse with the workspace in c:\Documents and Settings\... html reloading did not work. Taking the exact same configuration but putting the workspace directly on the c:\ drive (e.g., c:\workspace), the htm reloading works perfectly. Hope that helps. Andrew - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: two interlinked ajax textfields
Switched back to simple onchange. All is well now. On 2012-04-19 16:50, Martin Grigorov wrote: OnChangeAjaxBehavior uses oninput/onpaste/oncut behind the scenes for text form components, that's why it reacts on each key press onchange fires only when you leave the input field - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
two interlinked ajax textfields
Again a situation where I'm missing the background because of my newbie status. I have two textfields, one for the buildingnr, the second for the roomnr within that building. Both have a label to the right with a description. All four components (2x TextField, 2x Label) are within a single WebMarkupContainer and the two textfields each have a AjaxFormComponentUpdatingBehavior associated. This basic setup works. The next step is that once the buildnr number is changed, I may want to change the roomnr (clear it if it doesn't exist) or the room label as well. So the ajax event on the buildingnr textfield also influences the roomnr fields. This does not work as expected: I cannot set the value of the second TextField. What would be the best way to do this? Tom - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: focus locked in place
Ok, I've opened wicket's ajax debugger and there is NO ajax call. What I see is
this:
INFO: focus set on
INFO: focus removed from
INFO: focus set on
INFO: focus removed from
So it seems to me the fields do not have names. However in the HTML I do see a
name.
input type=text wicket:id=runtimeOs style=width:100px; value=ios
name=runtimesPanel:runtimes:1:runtimeOs
However, there are more of these inputs with the same wicket:id; it's a make
shift table build using a RefreshingView
input type=text wicket:id=runtimeOs style=width:100px; value=bada
name=runtimesPanel:runtimes:2:runtimeOs
input type=text wicket:id=runtimeOs style=width:100px; value=bada
name=runtimesPanel:runtimes:3:runtimeOs
...
I believe I'm doing something wrong in building that make shift table.
// the panel taking care of the ajax
final MarkupContainer lRuntimesPanel = new
WebMarkupContainer(runtimesPanel);
lRuntimesPanel.setOutputMarkupId(true);
lForm.add(lRuntimesPanel);
// the list of runtimes
final
RefreshingViewcom.service2media.licenseframework.service.license.jaxb.Runtime
lRuntimeListView = new
RefreshingViewcom.service2media.licenseframework.service.license.jaxb.Runtime(runtimes)
//LicenseModel.RUNTIMES_PROPERTY)
{
@Override
protected
IteratorIModelcom.service2media.licenseframework.service.license.jaxb.Runtime
getItemModels()
{
return new
ModelIteratorAdapter(lLicenseJAXB.getRuntimes().getRuntime().iterator())
{
@Override
protected final IModel model(final Object object)
{
return new
CompoundPropertyModel((com.service2media.licenseframework.service.license.jaxb.Runtime)
object);
}
};
}
@Override
protected void populateItem(final
Itemcom.service2media.licenseframework.service.license.jaxb.Runtime item)
{
item.add( new DropDownChoiceString(runtimeType, new
PropertyModelString(item.getDefaultModel(), type), License.RUNTIME_TYPES));
item.add( new TextFieldString(runtimeOs, new
PropertyModelString(item.getDefaultModel(), os)));
item.add( new TextFieldString(runtimeOsVersion, new
PropertyModelString(item.getDefaultModel(), osversion)));
item.add( new TextFieldString(runtimePoolId, new
PropertyModelString(item.getDefaultModel(), poolid)));
item.add( new TextFieldBigInteger(runtimePoolSize, new
PropertyModelBigInteger(item.getDefaultModel(), poolsize)));
// remove button
AjaxSubmitLink lRemoveRuntime = new
AjaxSubmitLink(removeRuntime, lForm)
{
@Override
protected void onError(AjaxRequestTarget target,
Form? form)
{
}
@Override
protected void onSubmit(AjaxRequestTarget target,
Form? form)
{
Listcom.service2media.licenseframework.service.license.jaxb.Runtime lRuntimes
= lLicenseJAXB.getRuntimes().getRuntime();
lRuntimes.remove(item.getModelObject());
if (target != null) target.add(lRuntimesPanel);
// ajax update
}
@Override
protected IAjaxCallDecorator getAjaxCallDecorator()
{
return new JavascriptConfirmDecorator(Remove the
runtime?);
}
};
lRemoveRuntime.setDefaultFormProcessing(false);
item.add(lRemoveRuntime);
}
};
lRuntimesPanel.add(lRuntimeListView);
On 16-4-2012 8:54, Martin Grigorov wrote:
Hi Tom,
Wicket keeps track of the last focused element only for Ajax requests.
I.e. Wicket sends a header in the ajax requests with the id of the
focused element when the Ajax call starter and later when the Ajax
response is processed it re-focuses this element.
Additionally there is AjaxRequestTarget#focusComponent(Component)
method which may be used to focus another element.
If you replace the focused element in the Ajax response then
lastFocusedId will be obsolete and Wicket wont be able to find the old
component.
I hope this helps you find out what causes the jumps in the focused elements.
On Fri, Apr 13, 2012 at 5:49 PM, Tom Eugelinkt...@tbee.org wrote:
On 2012-04-13 11:58, Tom Eugelink wrote:
The cursor can be placed in the date fields, but not in any of the
textfield in the listview.
To add some additional information
Re: two interlinked ajax textfields
Thank you!
The problem apparently was that I had the ajax bound to onblur and not to
onchange. Copied that from some example on the web.
Tom
On 19-4-2012 14:12, Martin Grigorov wrote:
field1.add(new AjaxFormComponentUpdatingBehavior(onchange) {
onUpdate(target) {
buildingNr = getComponent.getModelObject();
if (buildingNr == ...) {
field2.setModelObject(newValue)
target.add(field2)
}
}
})
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: two interlinked ajax textfields
Hm. Using onchange either directly or via OnChangeAjaxBehavior, I'm not able to type more that one character in the textbox. As soon as I've typed one, the ajax call triggers and does a select-all of the textbox (in Chrome), the next keystroke when overwrites the contents. Onblur does not have this behavior, but does not update the second textfield. Naturally this behavior is related to the browser; FF and IE do not do a select-all, but they place the cursor at the beginning of the text (which is not helping either). Tom On 19-4-2012 14:39, Martin Grigorov wrote: Check OnChangeAjaxBehavior too. It is bit smarter than AjaxFormComponentUpdatingBehavior and you wont need to leave the text input field with it. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: two interlinked ajax textfields
Hm. So I type something in field #1, tab to the field #2, start typing,
then the 1 second delay on field #1 triggers the ajax call, it refreshes the
label associated with #1 AND a select all on field #2 happens. This is not an
acceptable user interface experience.
I've upgraded to Wicket 6 beta 1 to see if the problem was in the javascript
being used, and even though there is no onchange attribute on the element
anymore (it's put there by jquery), the behavior is identical.
What confuses me is that if I do a simple onchange=javascript:alert('test');
on any textfield, it does not trigger until the cursor leaves the textfield.
On 19-4-2012 15:53, Martin Grigorov wrote:
see org.apache.wicket.ajax.AjaxEventBehavior#setThrottleDelay
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: two interlinked ajax textfields
To take it one level further, if I add
onchange=javascript:alert('test');
to an input without and with an OnChangeAjaxBehavior:
div class=clearfix
labelRenewal delay:
div class=input
input type=text size=10 wicket:id=renewalDelay
onchange=javascript:alert('test');/
/div
/label
/div
div class=clearfix wicket:id=contextPanel
labelClient:
div class=input
input type=text size=5 wicket:id=context.owner.id
onchange=javascript:alert('test');/
/div
/label
/div
The last alert is displayed on every key press, the first after leaving the
field. The behavior of the event is different.
Tom
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: two interlinked ajax textfields
Removing the OnChangeAjaxBehavior does not help, this behavior comes from the MarkupContainer; it changes the behavior of the onchange to a per-keypress event. Tom On 19-4-2012 16:40, Tom Eugelink wrote: The last alert is displayed on every key press, the first after leaving the field. The behavior of the event is different. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
getconverter is final
Is there any particular reason why getConverter has been made final. I really would like to roll in my own converter in DateTextField to handle Joda time. Tom - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: getconverter is final
https://issues.apache.org/jira/browse/WICKET-4503 By now I have created my own JodaDateTextField and a JodaDateConverter. The only thing that doesn't work yet is the DatePicker popup; it doesn't format the time. Tom On 2012-04-17 16:21, Martin Grigorov wrote: I see no reason why to keep the final at org.apache.wicket.datetime.markup.html.form.DateTextField#getConverter() There are several other places where #getConverter() is overridden and it is not final there. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: focus locked in place
Thanks for the feedback. So to check if this is the cause, I could simply remove the ajax code. Tom On 2012-04-16 08:54, Martin Grigorov wrote: Hi Tom, Wicket keeps track of the last focused element only for Ajax requests. I.e. Wicket sends a header in the ajax requests with the id of the focused element when the Ajax call starter and later when the Ajax response is processed it re-focuses this element. Additionally there is AjaxRequestTarget#focusComponent(Component) method which may be used to focus another element. If you replace the focused element in the Ajax response then lastFocusedId will be obsolete and Wicket wont be able to find the old component. I hope this helps you find out what causes the jumps in the focused elements. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: reload model each time
Just keep in mind that you can't use an EntityModel if the entity has already been persisted and if you want to change it with multiple ajax requests/multistep forms. It will lose any changes on every request. Simply serialize the entity again for that use case. Stealing the thread back ;-) Have't had time to work with this model (weekend and all) but I am visualizing it. The question I had is: if I have a from in a web browser that modifies several points in the backing model, and an AJAX requests comes in, will the full change set that is in the browser's form be applied to the model? Tom - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
reload model each time
Another newbie question; it is now the case that each model is serialized between requests and (I presume) stored in the session. I would really prefer if a identifier (primary key + lazy locking versionnr) could be remembered and that each time when Wicket needs the model, it is loaded from the database. Is this possible? Is there something like a ReloadingModel? Tom - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: reload model each time
Thanks! This looks very promising! On 2012-04-14 14:03, Christoph Leiter wrote: Here's a good article about EntityModel, which does what you want: http://wicketinaction.com/2008/09/building-a-smart-entitymodel/ Christoph - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
focus locked in place
I'm slowly getting some ground under my Wicket feet, but now I have a strange
problem. I've got a form with two TextFields and a RefreshingView inside a
MarkupContainer, building rows containing a DropDownChoice, TextField and a
AjaxSubmitLink. The stripped version of the Java code looks like this:
final FormMasterLicenseModel lForm = new
FormMasterLicenseModel(form, new CompoundPropertyModel(masterLicenseModel)) ;
add(lForm);
DatePickerDate lValidFromDateTextField = new
DatePickerDate(LicenseModel.VALIDFROM_PROPERTY)
lForm.add(lValidFromDateTextField);
DatePicker lValidUntilDateTextField = new
DatePicker(LicenseModel.VALIDUNTIL_PROPERTY);
lForm.add(lValidUntilDateTextField);
final MarkupContainer lRuntimesPanel = new
WebMarkupContainer(runtimesPanel);
lRuntimesPanel.setOutputMarkupId(true);
lForm.add(lRuntimesPanel);
final RefreshingViewLicense.Runtime lRuntimeListView = new
RefreshingViewLicense.Runtime(LicenseModel.RUNTIMES_PROPERTY)
{
@Override
protected void populateItem(final ItemRuntime item)
{
item.add( new DropDownChoiceString(runtimeType, new
PropertyModelString(item.getDefaultModel(), type), License.RUNTIME_TYPES));
item.add( new TextFieldString(runtimeOs, new
PropertyModelString(item.getDefaultModel(), os)));
AjaxSubmitLink lRemoveRuntime = new
AjaxSubmitLink(removeRuntime, lForm)
lRemoveRuntime.setDefaultFormProcessing(false);
item.add(lRemoveRuntime);
}
};
lRuntimesPanel.add(lRuntimeListView);
AjaxSubmitLink lAddRuntime = new AjaxSubmitLink(addRuntime, lForm)
{
};
lAddRuntime.setDefaultFormProcessing(false);
lRuntimesPanel.add(lAddRuntime);
The cursor can be placed in the date fields, but not in any of the textfield in the
listview. Focus then immediately jumps to the DropDownChoice in the first row. I've
tried removing the MarkupContainer Ajax part, reverting back to a regular
ListView. In the HTML I use a table for the listview, but a bunch of divs instead
do not make a difference.
I also see no events on the HTML text element in the listview either.
input type=text wicket:id=runtimeOs style=width:100px; value=ios
name=runtimesPanel:runtimes:19:runtimeOs
Any ideas why the focus jumps?
Tom
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket 6.0
On 2012-04-13 14:24, Martin Grigorov wrote: How many of you tried beta1 ? I started off with 6, but was afraid things like wiquery would conflict in the usage of jquery, so I returned to safety using 1.5.5. Should that be a problem? Otherwise I'll upgrade back to 6. Tom - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: focus locked in place
On 2012-04-13 11:58, Tom Eugelink wrote: The cursor can be placed in the date fields, but not in any of the textfield in the listview. To add some additional information; the cursor can be placed in the textfields by using the TAB key. A mouse click will always jump to the first field. So it seems to be a RefreshingView in combination with a mouse click problem. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket and Menu support
Is there any documentation on this jquery support in wicket 6? I'm setting up a new project ARM and instead of including all kinds of side kick projects, core support is preferable. Tom On 2012-04-08 19:55, msalman wrote: Thanks to every one for all of your comments and suggestions. Great to know that wicket core will include jquery. Alle, I would appreciate very much if you can please share your code for using jquery tree. It would give me a good start. Thanks. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-and-Menu-support-tp4540516p4541287.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: reloading of HTML and classes
Eclipse in debug mode indeed allows for some limited reloading of classes, but JRebel does a good job and my explicit HTML code seems to work as well. I still need to test it thoroughly. But none of Wicket's regular tools seem to work and that amazes me. Tom - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
reloading of HTML and classes
I've been fighting this for the past two days, but I'm not succeeding. I'm
using Wicket 1.5.5 on GlassFish 3.1.2 and that runs without a problem. I have
configured
filter-classorg.apache.wicket.protocol.http.ReloadingWicketFilter/filter-class
to reload the classes, but that is not working. The only way to reload the
class file is by using JRebel.
Also Wicket reports that it runs in DEVELOPMENT mode, but it is not reloading
the HTML files. In an attempting to resolve that I explicitely configured
getResourceSettings().setDefaultCacheDuration(Duration.ONE_SECOND);
but that does not make a difference. The only way I can get it to work
somewhat, is to add my own ResourceFinder directly on the src folder:
getResourceSettings().setResourceFinder(new IResourceFinder()
{
@Override
public IResourceStream find(Class? clazz, String pathname)
{
File f = new File(C:/Documents and Settings/User/My
Documents/s2m/sources/components/service/src/main/java/ + pathname);
if (f.exists())
{
return new FileResourceStream( f );
}
return null;
}
});
getResourceSettings().setUseDefaultOnMissingResource(true);
But still the source are not reloaded reliably. I figure if the cache expires,
a new call to the resource finder should be done, correct?
Is there any debugging of these autoreload features, so I can see what Wicket
is doing?
Tom
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
