AutocompleteTextField
Hello! I have a question that I hope someone can help me with. Lets say I have two classes like the ones here: http://papernapkin.org/pastebin/view/1760/ . Lets say I want a page with a AutoCompleteTextField where I can search students by entering their name in the search field. Because there can be several students with the same name I want to be able to separate one from the other when I choose one of them from the list of choices. So, what I want to happen is that when I for example enter Ad into the search field, I want the search field to show A list with all students whos name is Adam, when I select one of them I want the ID for that specific adam to be stored in the Model associated with the search field. How do I do that? Anyone that has an idea? -- View this message in context: http://www.nabble.com/AutocompleteTextField-tp18523765p18523765.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AutocompleteTextField
This is a common question, search the mailing list and you will find a few different ways of doing this. On Fri, Jul 18, 2008 at 3:09 AM, ulrik [EMAIL PROTECTED] wrote: Hello! I have a question that I hope someone can help me with. Lets say I have two classes like the ones here: http://papernapkin.org/pastebin/view/1760/ . Lets say I want a page with a AutoCompleteTextField where I can search students by entering their name in the search field. Because there can be several students with the same name I want to be able to separate one from the other when I choose one of them from the list of choices. So, what I want to happen is that when I for example enter Ad into the search field, I want the search field to show A list with all students whos name is Adam, when I select one of them I want the ID for that specific adam to be stored in the Model associated with the search field. How do I do that? Anyone that has an idea? -- View this message in context: http://www.nabble.com/AutocompleteTextField-tp18523765p18523765.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ryan Gravener http://twitter.com/ryangravener
Re: why are we coding Web apps?
Yes, you can have EJBs calls over HTTP. Google for HTTPInvoker. It's a component from JBoss. That's what makes the Genesis framework so interesting: http://genesis.dev.java.net See ya
swarm/wasp - using guest auto login
hi all, I did some test to implement a guest auto login with swarm/wasp. I'm just not sure if I'm digging in the right direction. my scenario is the following: - all pages are implementing the interface ISecurePage - all pages are grouped in different principals (hive) - i have an admin gui for setting principals for an individual user main goal is, that we can set for each page if you need to be logged in or not, depend on the user self, means we can have certain pages public depend on the scenario. what i did so fare: - implemented 2 LoginContext, one for the guest and one for the acutal login if a user needs to be logged in! - to do the auto login, i did a login( new GuestLoginContext()) when the session is created, on that way, the webuser can access all principals which are assigned to this special user 'guest'. - additionally the GuestLoginContext has his own Subject implementation which i override isClassAuthenticated(Class class1) to check if the guest user is allowed to access the class, currently i use the following getStrategy().isClassAuthorized(class1, getActionFactory().getAction(Access.class)); I'm not sure if this is a way to go to implement such a scenario. If someone else implemented a similar scenario, I'm happy to get some more advice. thanks gab - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaScript onChange after onClick
Okay, sorry, this wasn't really a Wicket-Problem but an IE-Problem. The Button in my application is actually a div and IE has problems to focus() divs (sometimes), so that when clicking the div, the focus is not removed from the text field and no onchange-event is fired. I managed it by giving the button div a tabIndex=0 attribute on in its onclick I call this.focus(). Then it works (even in IE). cretzel wrote: Hi, I'm having a problem regarding JavaScript/Ajax and I'm not sure if it's actually related to Wicket. I've got a Button and a TextField within a Form. The TextField uses an AjaxUpdatingBehavior for validation, which is fired onchange. The Button submits the form via Ajax onclick. In my case, sometimes the onchange event occurs after the onclick event (on the clientside), which causes problems. This is only a problem in IE(6) and not in FF. In FF the onchange event always occurs before the onclick event. And even in IE in simple examples I could never get the onchange event to occur after the onclick. So my question is, if this could have something to do with wicket's ajax JavaScript. Regards -- View this message in context: http://www.nabble.com/JavaScript-onChange-after-onClick-tp18467010p18525139.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket jobs in toulouse, france?
Francisco, If you'd like to http://jweekend.com/dev/ContactUsBody/ send us a note , I'll pass your details on to our partners in Paris, who, if I remember correctly, have a couple of clients in or around Toulouse. Regards - Cemal http://www.jWeekend.com http://jWeekend.com francisco treacy-2 wrote: hi guys, i love wicket and i'm currently searching for employment. i couldn't actually find any wicket jobs near toulouse. does somebody by chance knows if there are companies looking for wicket developers near here? thanks in advance francisco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/wicket-jobs-in-toulouse%2C-france--tp18520082p18525260.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AutocompleteTextField
Hi, you might want to have a look at wicketstuff-objectautocomplete which exactly adresses this scenario. It's not released though (and there are some changes in the pipeline so that it plays a smarter role when used within a form), but should work. The code is available via http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-objectautocomplete . Look at the exampes for how to use it. ... roland ulrik wrote: Hello! I have a question that I hope someone can help me with. Lets say I have two classes like the ones here: http://papernapkin.org/pastebin/view/1760/ . Lets say I want a page with a AutoCompleteTextField where I can search students by entering their name in the search field. Because there can be several students with the same name I want to be able to separate one from the other when I choose one of them from the list of choices. So, what I want to happen is that when I for example enter Ad into the search field, I want the search field to show A list with all students whos name is Adam, when I select one of them I want the ID for that specific adam to be stored in the Model associated with the search field. How do I do that? Anyone that has an idea? -- View this message in context: http://www.nabble.com/AutocompleteTextField-tp18523765p18526927.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Mbean
Hi, Does someone has experience with using the Wicket MBean to clear the markup cache while the application is running inside Tomcat? When I use the clearMarkupCache button in jconsole nothing happens. I do not understand the problem because the mbean is visible in jconsole and all attributes are normally set. Regards, Rik
RE: AutocompleteTextField
A simple solution is to hold on to the actual choices list until you can
match the selection:
public abstract class AbstractAutoCompleteTextFieldCHOICE extends
TextField {
private static final Logger LOG =
LoggerFactory.getLogger(AbstractAutoCompleteTextField.class);
private static final long serialVersionUID = 1L;
private final AutoCompleteChoiceBehavior autoCompleteBehavior;
private transient ListCHOICE choiceList;
/**
* Constructor
*
* @param id
*the ID to set
* @param type
*the type to set
*/
public AbstractAutoCompleteTextField(final String id, final
Class? type) {
this(id, (IModel) null, type, false);
}
/**
* Constructor
*
* @param id
*the ID to set
* @param model
*the model to set
* @param type
*the type to set
* @param preselect
*the preselect to set
*/
public AbstractAutoCompleteTextField(final String id, final
IModel model, final Class? type, final boolean preselect) {
this(id, model, type,
StringAutoCompleteRenderer.INSTANCE, preselect);
}
/**
* Constructor
*
* @param id
*the ID to set
* @param model
*the model to set
* @param type
*the type to set
* @param settings
*the settings to set
*/
public AbstractAutoCompleteTextField(final String id, final
IModel model, final Class? type, final AutoCompleteSettings settings)
{
this(id, model, type,
StringAutoCompleteRenderer.INSTANCE, settings);
}
/**
* Constructor
*
* @param id
*the ID to set
* @param model
*the model to set
* @param preselect
*the preselect to set
*/
public AbstractAutoCompleteTextField(final String id, final
IModel model, final boolean preselect) {
this(id, model, (Class?) null, preselect);
}
/**
* Constructor
*
* @param id
*the ID to set
* @param model
*the model to set
* @param settings
*the settings to set
*/
public AbstractAutoCompleteTextField(final String id, final
IModel model, final AutoCompleteSettings settings) {
this(id, model, (Class?) null, settings);
}
/**
* Constructor
*
* @param id
*the ID to set
* @param model
*the model to set
*/
public AbstractAutoCompleteTextField(final String id, final
IModel model) {
this(id, model, (Class?) null, false);
}
/**
* Constructor
*
* @param id
*the ID to set
* @param preselect
*the preselect to set
*/
public AbstractAutoCompleteTextField(final String id, final
boolean preselect) {
this(id, (IModel) null, preselect);
}
/**
* Constructor
*
* @param id
*the ID to set
* @param settings
*the settings to set
*/
public AbstractAutoCompleteTextField(final String id, final
AutoCompleteSettings settings) {
this(id, (IModel) null, settings);
}
/**
* Constructor
*
* @param id
*the ID to set
*/
public AbstractAutoCompleteTextField(final String id) {
this(id, (IModel) null, false);
}
/**
* Constructor
*
* @param id
*the ID to set
* @param renderer
*the renderer to set
*/
public AbstractAutoCompleteTextField(final String id, final
IAutoCompleteRenderer renderer) {
this(id, (IModel) null, renderer);
}
/**
* Constructor
*
* @param id
*the ID to set
* @param type
*the type to set
* @param renderer
*the renderer to set
*/
public AbstractAutoCompleteTextField(final String id, final
Class? type, final IAutoCompleteRenderer renderer) {
this(id, null, type, renderer, false);
}
/**
* Constructor
*
* @param id
*the ID to set
* @param model
*the model to set
* @param renderer
*the renderer
Just switched to 1.4-M3
Hi, I've not been able to follow the discussion on generics (simply too much) but now that I've switched to 1.4-M3 I have a comment/question. Generally I think wicket is going in the right direction regarding generics... Another (great) web application framework that I've used doesn't have component at the root of the inheritance tree, but element - component extends element. The elements are the UI atoms, and components are complete or partial pages. I think elements should be generified, but not components. As it is now Component is not generified, but further down you introduce generics to some components that you feel benefit from it. I think you should do it the other way around. Have a root - Element - that is generified, and then have a Component class where you fix the type parameter to something suitable. To me the elements - the basic building blocks - are closely related to their models and converters, but complete or partial pages are not. 1) I think Label should be generified the way TextField is. (It would be if they both inherited from Element.) 2) I think think the Model and Converter of TextField should be generified with the same type parameter as TextField itself - the way it was in M2. (This could be defined in Element.) /Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Just switched to 1.4-M3
inline... On Fri, Jul 18, 2008 at 4:52 AM, Anders Peterson [EMAIL PROTECTED] wrote: Another (great) web application framework that I've used doesn't have component at the root of the inheritance tree, but element - component extends element. The elements are the UI atoms, and components are complete or partial pages. I think elements should be generified, but not components. As it is now Component is not generified, but further down you introduce generics to some components that you feel benefit from it. I think you should do it the other way around. Have a root - Element - that is generified, and then have a Component class where you fix the type parameter to something suitable. To me the elements - the basic building blocks - are closely related to their models and converters, but complete or partial pages are not. 1) I think Label should be generified the way TextField is. (It would be if they both inherited from Element.) what benefit does a generified label bring to the table? it always converts everything to a string... 2) I think think the Model and Converter of TextField should be generified with the same type parameter as TextField itself - the way it was in M2. (This could be defined in Element.) the model of the textfield is generified with the same type as textfield. as far as converter goes, it doesnt make sense to generify. iconvertert getconverter(class clazz). if your textfield is String and something calls getconverter(integer.class) on your textfield, should it still return a string converter? -igor /Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: swarm/wasp - using guest auto login
Hmm, usually there is no need to change the guest permissions on the fly.
In that case you can just implement ISecurePage on every page that
needs to be secure and not on the guest pages.
On Fri, Jul 18, 2008 at 10:14 AM, Gabriel Bucher
[EMAIL PROTECTED] wrote:
hi all,
I did some test to implement a guest auto login with swarm/wasp. I'm just
not sure if I'm digging in the right direction.
my scenario is the following:
- all pages are implementing the interface ISecurePage
- all pages are grouped in different principals (hive)
- i have an admin gui for setting principals for an individual user
main goal is, that we can set for each page if you need to be logged in or
not, depend on the user self, means we can have certain pages public depend
on the scenario.
Implementing ISecurePage means that a subject needs to be present for this page.
This is enforced by a ClassSecurityCheck which is automatically used
when checking for access permissions.
This call ultimately ends in asking the subject if the class is
authenticated. (It first passes through the LoginContainer but that is
not easily customizable (yet))
It is also possible to only do the access check for pages implementing
a custom interface, but i don't think that will help in your case
because, as i understand it, you want to change which pages are
accessible by guests on the fly.
what i did so fare:
- implemented 2 LoginContext, one for the guest and one for the acutal login
if a user needs to be logged in!
Yes, this is required because of the above mentioned restriction.
- to do the auto login, i did a login( new GuestLoginContext()) when the
session is created, on that way, the webuser can access all principals which
are assigned to this special user 'guest'.
Yes also because of the above mentioned restriction you need a
subject. on session creation is the most logical place to do that.
You might be able to put a few pages which are sure not to be changed
on the fly in an anonymous grant block.
grant
{
};
that way every user, guest or otherwise will have those permissions.
but judging from your story i doubt there will be many pages this
applies to.
- additionally the GuestLoginContext has his own Subject implementation
which i override isClassAuthenticated(Class class1) to check if the guest
user is allowed to access the class, currently i use the following
getStrategy().isClassAuthorized(class1,
getActionFactory().getAction(Access.class));
By default a subject returns true for isClassAuthenticated, so yes if
you want to customize this, then this is the place.
I am not sure i agree with you using the authorized calls to check for
authentication but that is probably nitpicking :) It certainly gets
the job done.
I'm not sure if this is a way to go to implement such a scenario. If someone
else implemented a similar scenario, I'm happy to get some more advice.
That was a lot of writing just to say, i think you are on the right track :)
Mind you that i never tried any of this myself.
Maurice
thanks gab
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: URLValidator to auto-append http://
try adding it before validation - i copy+paste my code (which works in
production)
final TextField website = new
TextField(profiles.contactProfile.website)
{
private static final long serialVersionUID = 1L;
// add http:// if missing
@Override
protected void convertInput() {
String input = getInput();
if (input != null !Strings.isEmpty(input)
!(input.startsWith(http://;) || input.startsWith(https://;))) {
setConvertedInput(http://; + input);
} else {
setConvertedInput(Strings.isEmpty(input) ? null : input);
}
}
};
Sergey Podatelev wrote:
Okay, I'm sorry, that was a bad question.
Validators shouldn't do anything but validation anyway.
But a way to allow validator to skip protocol-less strings, i.e.
google.com
instead of http://google.com;?
On Thu, Jul 17, 2008 at 11:04 AM, Sergey Podatelev
[EMAIL PROTECTED] wrote:
Is there a way to configure URLValidator to automatically append the
http://; string to provided value in case it's otherwise correct, but no
protocol notation is present?
--
sp
--
sp
-
Michael Sparer
http://talk-on-tech.blogspot.com
--
View this message in context:
http://www.nabble.com/URLValidator-to-auto-append-%22http%3A--%22-tp18502724p18533599.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Switching SecondLevelCacheSessionStore to HttpSessionStore throws ClassCastException
Hi, I encountered java.io.InvalidClassException when trying to change from default SecondLevelCacheSessionStore to HttpSessionStore. The exceptions are shown below: org.apache.wicket.protocol.http.HttpSessionStore cannot be cast to org.apache.wicket.protocol.http.SecondLevelCacheSessionStor e java.lang.ClassCastException: org.apache.wicket.protocol.http.HttpSessionStore cannot be cast to org.apache.wicket.protocol.ht tp.SecondLevelCacheSessionStore at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.getStore(SecondLevelCacheSessi onStore.java:366) at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.get(SecondLevelCacheSessionSto re.java:303) at org.apache.wicket.Session.getPage(Session.java:751) at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:448) at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1229) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1349) at org.apache.wicket.RequestCycle.request(RequestCycle.java:493) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:387) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:124) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.cayenne.conf.WebApplicationContextFilter.doFilter(WebApplicationContextFilter.java:91) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apaat org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) at java.lang.Thread.run(Thread.java:619) there was an error detaching the request from the session [EMAIL PROTECTED] java.lang.ClassCastException: org.apache.wicket.protocol.http.HttpSessionStore cannot be cast to org.apache.wicket.protocol.ht tp.SecondLevelCacheSessionStore at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.getStore(SecondLevelCacheSessi onStore.java:366) at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.put(SecondLevelCacheSessionSto re.java:332) at org.apache.wicket.Session.requestDetached(Session.java:1370) at org.apache.wicket.RequestCycle.detach(RequestCycle.java:1081) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1367) at org.apache.wicket.RequestCycle.request(RequestCycle.java:493) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:387) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:124) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.cayenne.conf.WebApplicationContextFilter.doFilter(WebApplicationContextFilter.java:91) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) .. --- The code shown below: public class AtsApplication
Wicket 1.4M3 migration
We moved to wicket 1.4M3 (current trunk) with success. It was not so hard because we already have wrappers for most of wickets core components (e.g. GenericPanel etc.). We still love the way generics were in M2 but we can live with M3. But it definitely makes sense that ConverterLocator is no longer Generic. Thank you all for your work on wicket! Maybe we can see Wicket 1.4.0 final in the near future? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RelativePathPrefixHandler and form action attributes
I am trying to rewrite an HTML form action attribute (for a non-Wicket form) inside a Wicket Panel and could use some help. While converting a large webapp to Wicket, I created a Panel to wrap a search form. The form processing is not handled by Wicket yet. So in my SearchPanel.html, I have something like this: wicket:panel form method=get action=search.do [..] /form a href=search.doAdvanced Search/a /wicket:panel The Advanced Search href is automatically prefixed with the correct number of ../ strings by RelativePathPrefixHandler, but the form action is not rewritten. Is adding a new IMarkupFilter (based on RelativePathPrefixHandler) to handle the action attribute rewriting a good option? Or is there a better way? My first attempt was using a wicket:message for the action along with getRelativePathPrefixToContextRoot() inside SearchPanel.java to set the message. That turned out to be more complicated than I expected...but mostly because I was not able to find a simple hook into the message lookup from the SearchPanel class to set the message text. (Putting the URL in SearchPanel.properties worked fine but did not allow for dynamically prefixing the action URL based on the request URL.) Any ideas on how to best handle this scenario would be much appreciated. Thanks! --Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RelativePathPrefixHandler and form action attributes
override oncomponenttag() of the form and call super followed by tag.put(action, whateverurl); -igor On Fri, Jul 18, 2008 at 12:56 PM, Brad Fritz [EMAIL PROTECTED] wrote: I am trying to rewrite an HTML form action attribute (for a non-Wicket form) inside a Wicket Panel and could use some help. While converting a large webapp to Wicket, I created a Panel to wrap a search form. The form processing is not handled by Wicket yet. So in my SearchPanel.html, I have something like this: wicket:panel form method=get action=search.do [..] /form a href=search.doAdvanced Search/a /wicket:panel The Advanced Search href is automatically prefixed with the correct number of ../ strings by RelativePathPrefixHandler, but the form action is not rewritten. Is adding a new IMarkupFilter (based on RelativePathPrefixHandler) to handle the action attribute rewriting a good option? Or is there a better way? My first attempt was using a wicket:message for the action along with getRelativePathPrefixToContextRoot() inside SearchPanel.java to set the message. That turned out to be more complicated than I expected...but mostly because I was not able to find a simple hook into the message lookup from the SearchPanel class to set the message text. (Putting the URL in SearchPanel.properties worked fine but did not allow for dynamically prefixing the action URL based on the request URL.) Any ideas on how to best handle this scenario would be much appreciated. Thanks! --Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Just switched to 1.4-M3
Sorry... I guess generics design has been discussed enough. /Anders Igor Vaynberg wrote: On Fri, Jul 18, 2008 at 4:52 AM, Anders Peterson wrote: As it is now Component is not generified, but further down you introduce generics to some components that you feel benefit from it. I think you should do it the other way around. Have a root - Element - that is generified, and then have a Component class where you fix the type parameter to something suitable. To me the elements - the basic building blocks - are closely related to their models and converters, but complete or partial pages are not. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: why are we coding Web apps?
[EMAIL PROTECTED] wrote: Yes, you can have EJBs calls over HTTP. Google for HTTPInvoker. It's a component from JBoss. Ah, you lucky EJB guys - you're on top of it already. That's what makes the Genesis framework so interesting: http://genesis.dev.java.net ...to allow people with little knowledge of the Java platform to develop robust applications fast, without requiring them to learn several new technologies and complex concepts. In just six days. And on the seventh, they rest. -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RelativePathPrefixHandler and form action attributes
I am trying to rewrite an HTML form action attribute (for a non-Wicket form) inside a Wicket Panel and could use some help. While converting a large webapp to Wicket, I created a Panel to wrap a search form. The form processing is not handled by Wicket yet. So in my SearchPanel.html, I have something like this: wicket:panel form method=get action=search.do [..] /form a href=search.doAdvanced Search/a /wicket:panel The Advanced Search href is automatically prefixed with the correct number of ../ strings by RelativePathPrefixHandler, but the form action is not rewritten. Is adding a new IMarkupFilter (based on RelativePathPrefixHandler) to handle the action attribute rewriting a good option? Or is there a better way? My first attempt was using a wicket:message for the action along with getRelativePathPrefixToContextRoot() inside SearchPanel.java to set the message. That turned out to be more complicated than I expected...but mostly because I was not able to find a simple hook into the message lookup from the SearchPanel class to set the message text. (Putting the URL in SearchPanel.properties worked fine but did not allow for dynamically prefixing the action URL based on the request URL.) Any ideas on how to best handle this scenario would be much appreciated. Thanks! --Brad - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RelativePathPrefixHandler and form action attributes
On Fri, Jul 18, 2008 at 01:14:08PM -0700, Igor Vaynberg wrote:
override oncomponenttag() of the form and call super followed by
tag.put(action, whateverurl);
Thanks for the pointer, Igor!
For the benefit of archive searchers, the onComponentTag() solution
required that I add a wicket:id to my form--even though form
submission is not handled by Wicket. I also needed to override
onComponentTagBody() to prevent the Form rendering from adding Wicket
hidden fields to my form.
Here is a code snippet to illustrate:
public class SearchPanel extends Panel {
public SearchPanel(String id) {
super(id);
add(new Form(searchForm) {
protected void onComponentTag(ComponentTag tag) {
// prefix the form action attribute with a relative path
prefix
tag.put(
action,
RequestCycle.get().getRequest().getRelativePathPrefixToContextRoot()
+ tag.getAttributes().getString(action));
}
// override the default to suppress the addition of Wicket hidden
form fields
protected void onComponentTagBody(final MarkupStream markupStream,
final ComponentTag openTag) {
renderComponentTagBody(markupStream, openTag);
}
});
}
}
--Brad
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RelativePathPrefixHandler and form action attributes
Also (just for the archives), you really could override this method on
WebMarkupContainer - it doesn't actually need to be a form instance since
you're not actually using any form functionality. You're simply creating a
container that contains markup, and that you can override attributes of the
HTML tag on.
It works either way, but thought I'd throw that in for you.
--
Jeremy Thomerson
http://www.wickettraining.com
On Fri, Jul 18, 2008 at 4:16 PM, Brad Fritz [EMAIL PROTECTED]
wrote:
On Fri, Jul 18, 2008 at 01:14:08PM -0700, Igor Vaynberg wrote:
override oncomponenttag() of the form and call super followed by
tag.put(action, whateverurl);
Thanks for the pointer, Igor!
For the benefit of archive searchers, the onComponentTag() solution
required that I add a wicket:id to my form--even though form
submission is not handled by Wicket. I also needed to override
onComponentTagBody() to prevent the Form rendering from adding Wicket
hidden fields to my form.
Here is a code snippet to illustrate:
public class SearchPanel extends Panel {
public SearchPanel(String id) {
super(id);
add(new Form(searchForm) {
protected void onComponentTag(ComponentTag tag) {
// prefix the form action attribute with a relative path
prefix
tag.put(
action,
RequestCycle.get().getRequest().getRelativePathPrefixToContextRoot()
+ tag.getAttributes().getString(action));
}
// override the default to suppress the addition of Wicket
hidden form fields
protected void onComponentTagBody(final MarkupStream
markupStream, final ComponentTag openTag) {
renderComponentTagBody(markupStream, openTag);
}
});
}
}
--Brad
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Switching SecondLevelCacheSessionStore to HttpSessionStore throws ClassCastException
Are you sure you dont read in a serializef session from tomcat when you are starting up? If you use a new browser instance so that you really have a new session do you still have this problem? On 7/18/08, Michael K [EMAIL PROTECTED] wrote: Hi, I encountered java.io.InvalidClassException when trying to change from default SecondLevelCacheSessionStore to HttpSessionStore. The exceptions are shown below: org.apache.wicket.protocol.http.HttpSessionStore cannot be cast to org.apache.wicket.protocol.http.SecondLevelCacheSessionStor e java.lang.ClassCastException: org.apache.wicket.protocol.http.HttpSessionStore cannot be cast to org.apache.wicket.protocol.ht tp.SecondLevelCacheSessionStore at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.getStore(SecondLevelCacheSessi onStore.java:366) at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.get(SecondLevelCacheSessionSto re.java:303) at org.apache.wicket.Session.getPage(Session.java:751) at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:448) at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1229) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1349) at org.apache.wicket.RequestCycle.request(RequestCycle.java:493) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:387) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:124) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.cayenne.conf.WebApplicationContextFilter.doFilter(WebApplicationContextFilter.java:91) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apaat org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) at java.lang.Thread.run(Thread.java:619) there was an error detaching the request from the session [EMAIL PROTECTED] java.lang.ClassCastException: org.apache.wicket.protocol.http.HttpSessionStore cannot be cast to org.apache.wicket.protocol.ht tp.SecondLevelCacheSessionStore at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.getStore(SecondLevelCacheSessi onStore.java:366) at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.put(SecondLevelCacheSessionSto re.java:332) at org.apache.wicket.Session.requestDetached(Session.java:1370) at org.apache.wicket.RequestCycle.detach(RequestCycle.java:1081) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1367) at org.apache.wicket.RequestCycle.request(RequestCycle.java:493) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:387) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:124) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at
Field level Authorization strategy suggestions?
I'm building a database driven application. I've constructed LoadableDetachableModel for my entities, those LDMs then being presented in a Panel via a SortableDataProvider driven DefaultDataTable. I'd like to automatically expose additional functionality or field visibility depending on the authorization level of the user (session). For example, editable fields for admin users. At which point is it most appropriate to handle that? Should I somehow construct field(column) level models and encapsulate those in a higher- level model? Has anyone done something similar or is there an example somewhere that I'm overlooking? -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RelativePathPrefixHandler and form action attributes
Jeremy,
On Fri, Jul 18, 2008 at 04:35:21PM -0500, Jeremy Thomerson wrote:
Also (just for the archives), you really could override this method on
WebMarkupContainer - it doesn't actually need to be a form instance since
you're not actually using any form functionality. You're simply creating a
container that contains markup, and that you can override attributes of the
HTML tag on.
You're right; it's definitely simpler with WebMarkupContainer:
public class SearchPanel extends Panel {
public SearchPanel(String id) {
super(id);
add(new WebMarkupContainer(searchForm) {
@Override
protected void onComponentTag(ComponentTag tag) {
// prefix the form action attribute with a relative path
prefix, e.g. ../../
tag.put(
action,
RequestCycle.get().getRequest().getRelativePathPrefixToContextRoot()
+ tag.getAttributes().getString(action));
}
});
}
}
The onComponentTagBody() override wasn't very clean so it's nice to
eliminate it.
Thanks for the tip!
--Brad
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RelativePathPrefixHandler and form action attributes
2008/7/18 Brad Fritz [EMAIL PROTECTED]: I am trying to rewrite an HTML form action attribute (for a non-Wicket form) inside a Wicket Panel and could use some help. While converting a large webapp to Wicket, I created a Panel to wrap a search form. The form processing is not handled by Wicket yet. So in my SearchPanel.html, I have something like this: wicket:panel form method=get action=search.do [..] /form a href=search.doAdvanced Search/a /wicket:panel The Advanced Search href is automatically prefixed with the correct number of ../ strings by RelativePathPrefixHandler, but the form action is not rewritten. Is adding a new IMarkupFilter (based on RelativePathPrefixHandler) to handle the action attribute rewriting a good option? Or is there a better way? You could make the form into a wicket component (use a WebMarkupContainer), and then add an AttributeModifier which does what you want from code. Any ideas on how to best handle this scenario would be much appreciated. Thanks! However, this seems like a bug to me. Obviously non-Wicket form tags should have their action attributes rewritten like everything else does. Feel free to open a JIRA issue and assign it to me and I'll get it fixed for the next 1.3.x release. Alastair - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
