Re: Custom AJAX component...
I have been looking at the example from jqgrid and as far as I can understand the resource listener is used to stream back the XML content as CDATA from the server to the browser. However, I cannot see how it would be possible to stream back XML from the browser to the server. One way I can imagine it would work is by creating a form (with CSS style display none) which has a form text field with a value). In that case, submitting the form will also submit the text field and it becomes possible to both read the XML from the custom text field and rerender other wicket components as part of the same request (and also use prepend and/or append javascript). Am I missing something?
Re: Custom AJAX component...
Hi Ernesto, The approach you suggest does fit my needs, especially if I can send XML content from the browser to the server. I am exploring possibilities and one of those is using wicketAjaxPost(). The other one is the jqgrid approach which might be more flexible. I cannot quite understand how it works. It looks like the key is the GridXMLData component and the DocumentListener but I don't see yet how you use those to get the XML data back to the server. Cheers Erik On Tue, Aug 17, 2010 at 10:42 PM, Ernesto Reinaldo Barreiro < reier...@gmail.com> wrote: > 1-use the behavior to generate a URL. > 2-use that URL on client side to call the behavior > 3-use the behavior to produce the content you want to stream (XML). > 4-do what ever you want with that contents. > > That's more or less what the jqgrid example does. Does that approach > fit your use case? > > Ernesto > > On Tue, Aug 17, 2010 at 10:07 PM, Erik Brakkee > wrote: > > Thanks to wicket's clean code I am a bit further now. It looks like it is > > possible to add custom javascript to be executed just before and after > > rendering the components. This can be done using > > AjaxRequestTarget.append/prependJavascript(). So in other words, using > this > > method it is possible to pass data (even behavior) back to the client. > > > > It is still not clear to me how it would be possible to pass additional > data > > from the web browser to the server in the AbstractDefaultAjaxBehavior and > > then read it in the respond() method of the behavior. > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Custom AJAX component...
I have found this page https://cwiki.apache.org/WICKET/calling-wicket-from-javascript.html which talks about wicketAjaxGet() and wicketAjaxPost(), but again no mention of how to access the body that is sent using wicketAjaxPost(). Only request parameters are discussed. Is accessing the body simply a matter of using the basic HttpServletRequest APIs? Cheers Erik
Re: Custom AJAX component...
Thanks to wicket's clean code I am a bit further now. It looks like it is possible to add custom javascript to be executed just before and after rendering the components. This can be done using AjaxRequestTarget.append/prependJavascript(). So in other words, using this method it is possible to pass data (even behavior) back to the client. It is still not clear to me how it would be possible to pass additional data from the web browser to the server in the AbstractDefaultAjaxBehavior and then read it in the respond() method of the behavior.
Re: Custom AJAX component...
On Tue, Aug 17, 2010 at 7:02 AM, Ernesto Reinaldo Barreiro < reier...@gmail.com> wrote: > In case of wiQuery, many behaviors wicket AJAX is used (not jquery > AJAX) so it seem natural to use AbstractDefaultAjaxBehavior. In other > cases probably you are right and it is over killing. Is that what you > are asking? Well I imagine it is nice to be able to combine a custom framework using wicket ajax as that would probably allow someone to perform the custom AJAX behavior together with rendering wicketcomponents when the behavior is triggered. I am just trying to understand how this works. Right now I understand the simple method of AbstractAjaxBehavior.] I am now just wondering how the approach using wicket ajax works. Is there documentation explaining how to hook in custom client side behavior using wicket ajax. In other words, re-rendering wicket components AND reading a custom payload from the message, and returning a custom payload to be processed by the custom javascript. Both the wicket XML request and response must carry somehow the other information transparently. In the AutocompletBehavior of wiquery they are just getting the response and writing directly to it, ignoring the request target, whereas as I understand it now the request target is the interface towards the response so bypassing it is risky.
Re: Custom AJAX component...
I have been looking around a bit more and it seems like Wicket in Action provides a solution on p.260 (the book keeps on growing on me). It looks like the idea is to extend AbstractAjaxBehavior and use RequestCycle.get().setRequestTarget(new StringRequestTarget(myString)); or more generically use ResourceStreamRequestTarget. >From the looks of it, the wicket-specific ajax library comes in through AbstractDefautAjaxBehavior. It beats me why some libraries are still extending AbstractDefaultAjaxBehavior if they are integrating a custom framework. Cheers Erik
Re: Custom AJAX component...
I have seen that wiquery for instance takes another approach in for instance
their AutoCompleteBehavior.
In that class they override respond() and get the response from the
requestcycle and start writing to it, like this:
@Override
protected void respond(AjaxRequestTarget target) {
// response: outputing the list of results as a js map
List> results = autocomplete();
Response response =
this.getComponent().getRequestCycle().getResponse();
response.write("{");
for (AutocompleteValue autocompleteValue : results) {
autocompleteValue.write(response);
}
response.write("}");
}
If this is the correct approach it would be nice because it would allow me
to have complete control over generating the response. But, is this a valid
approach? Will it not interfere with the default response? Or is everything
ok as along as no components are added to the request target?
Can anyone comment on the validity of this approach? If this is not a
recommended approach then what is the correct approach to take for getting
complete control over the response content from an ajax behavior?
Cheers
Erik
Re: Custom AJAX component...
Thanks very much for the examples, I will have a look at them. On Sun, Aug 15, 2010 at 8:09 AM, Ernesto Reinaldo Barreiro < reier...@gmail.com> wrote: > and you can see the grid at work here > > > http://wiquery-plugins-demo.appspot.com/demo/?wicket:bookmarkablePage=:com.wiquery.plugins.demo.GridPage > > Ernesto > > On Sun, Aug 15, 2010 at 8:07 AM, Ernesto Reinaldo Barreiro > wrote: > > Erik, > > > > Grid component [1] does something similar to what you are asking for: > > > > -Grid is created via JavaScript > > -Grid ask back to server for some XML containing the data to render > > and generate the grids contents. > > > > The trick I use to render XML back to the server is creating a "div" > > that will stream back the contents as XML. See classes [1] and [2] > > for details. > > > > Regards, > > > > Ernesto > > > > References. > > > > 1- > http://code.google.com/p/wiquery-plugins/source/browse/trunk/wiquery-plugins/jqgrid/src/main/java/com/wiquery/plugins/jqgrid/component/Grid.java > > 2- > http://code.google.com/p/wiquery-plugins/source/browse/trunk/wiquery-plugins/jqgrid/src/main/java/com/wiquery/plugins/jqgrid/component/DocumentResourceListener.java > > > > On Sat, Aug 14, 2010 at 10:59 PM, Erik Brakkee > wrote: > >> Hi, > >> > >> > >> I would like to write an component that will retrieve page-specific > >> information using AJAX from the javascript running in the browser and > >> interpret it itself instead of having wicket rendering the content. > >> > >> This approach is slightly different from the usual behavior as in those > >> cases a wicket component renders its own content again and the page is > >> updated with the new content of the component. In this case however, I > would > >> like to return an XML document which is interpreted by the javascript > >> directly, where the XML document is page specific. > >> > >> How can I achieve such a scenario? Any examples somewhere? Is there a > >> specific Component type or behavior I should use? > >> > >> Cheers > >> Erik > >> > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Custom AJAX component...
Hi, I would like to write an component that will retrieve page-specific information using AJAX from the javascript running in the browser and interpret it itself instead of having wicket rendering the content. This approach is slightly different from the usual behavior as in those cases a wicket component renders its own content again and the page is updated with the new content of the component. In this case however, I would like to return an XML document which is interpreted by the javascript directly, where the XML document is page specific. How can I achieve such a scenario? Any examples somewhere? Is there a specific Component type or behavior I should use? Cheers Erik
Re: Disabling serialization in wicket tester....
On Sun, Aug 1, 2010 at 5:11 AM, Kent Tong wrote > I would like very much to disable serialization in wicket tester. I > am using pages with mockito mocks that are not serializable (and why > should they in a unit test). I am using workarounds now. You can take a look at http://wicketpagetest.sourceforge.net which > allows you to inject non-serializable mocks into your pages. I have already solve the problem myself now using a SerializableProxyFactory which creates serializable proxies for a mock: http://utils.wamblee.org/support/general/apidocs/org/wamblee/general/SerializableProxyFactory.html Will also have a look at the library you are suggesting. > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Disabling serialization in wicket tester....
That my tests will not be equivalent is no big problem. In this case I am really unit testing the pages while mocking the backend. That allows me to also test anomalous behavior of the backend. In addition, I am also doing unit integration testing with rendering wicket pages with an actual JPA backend with a relatively complete environment including transactions and JPA. So, overall my unit tests cover the functionality quite well. The trick I am doing now is storing the mock in a static variable of the test class and then creating a serializable proxy using LookupProxyFactory ( http://utils.wamblee.org/support/general/apidocs/org/wamblee/general/LookupProxyFactory.html) to lookup the mock dynamically. I guess this is screaming again for another test utility on top of mockito for creating serializable mocks (if I cannot solve it in wicket). Any suggestions on how to disable serialization in wicket tester?
Disabling serialization in wicket tester....
Hi, I would like very much to disable serialization in wicket tester. I am using pages with mockito mocks that are not serializable (and why should they in a unit test). I am using workarounds now. Is there an easy way in wicket tester to disable the serializations that occur? Cheers Erik
Re: Wicket and JEE6
It appears that I ran into an existing Glassfish V3 issue. The same issue occurs with passivation of regular EJBs that have an entitymanager injected. See https://glassfish.dev.java.net/issues/show_bug.cgi?id=11356
Re: Wicket and JEE6
I have found an elegant solution to the serialization problem.
Basically, in the ComponentInstantiationListener that perform injection, I
am also attaching a new InjectionBehavior. The injection behavior has a
private transient boolean field indicating whether injections are up to
date. Upon serialization/deserialization of a component, this field is reset
to false because it is transient. As a result, I can detect in the
beforeRender() method of the behavior whether I need to do injection.
The code of the component instantiationlistener is now as follows:
@Override
public void onInstantiation(Component aComponent) {
injector.inject(aComponent);
aComponent.add(new InjectionBehavior());
}
With the InjectionBahavior defined as follows:
public class InjectionBehavior extends AbstractBehavior {
private transient boolean injectionUptodate;
public InjectionBehavior() {
injectionUptodate = true;
}
@Override
public void beforeRender(Component aComponent) {
if (!injectionUptodate) {
InjectorBuilder.getInjector().inject(aComponent);
injectionUptodate = true;
}
}
}
This solution prevents unnecessary injection. This is required because
injection is expensive. For a simple class with only one injection I
measured only 1400 injections per second (I understand the weld project is
working on improving performance at the moment).
Another part of the solution is to be able to deal with detachable models
that need to keep a reference to an entity manager. The problem is that
these detachable models are also serialized/deserialized. For this I am
using a similar trick now to create a dynamic proxy of an entity manager
that delegates to a dynamically looked up version of the entity manager. The
lookup is done by creating a dummy object with a @persistenceContet in it
and using CDI to inject/obtain the entity manager. Here similarly, the
lookup caches the entity manager as a transient reference so it knows when
to recompute the entity manager.
The object that does this lookup is in fact a managed bean with a producer
method annoted with @Produces @ApplicationDatabase and @PersistenceContext:
public class EntityManagerLookup implements Lookup {
private static class EmHolder {
@PersistenceContext
private EntityManager em;
public EntityManager getEm() {
return em;
}
}
private transient EntityManager em;
@Override
public Object lookup() throws Exception {
if (em == null) {
EmHolder holder = new EmHolder();
InjectorBuilder.getInjector().inject(holder);
em = holder.getEm();
}
return em;
}
@Produces
@ApplicationDatabase
@PersistenceContext
public EntityManager getDefaultEntityManager() {
LookupProxyFactory factory = new
LookupProxyFactory(
EntityManager.class, new EntityManagerLookup());
return factory.getProxy();
}
}
Using this method, I can inject this serialization-safe entitymanager into
any object using
@Inject @ApplicationDatabase EntityManager entityManager;
So, in fact, I have a two-part solution. First of all it is robust in the
sense that @PersistenceContext still works. Second, I can also use a custom
injection to obtain serialization safe entity managers. When the entity
manager is obtained using the custom method however, problems can still
exist with for instance application scoped objects which also appear to be
serialized (this is in fact wrong as the objects will no longer be
application scoped because several copies are created).
A consequence of this solution is that all injected dependencies should be
declared as transient because this is more efficient.
The code for this can be found at http://utils.wamblee.org (wicket/inject,
support/inject, and support/cdi).
Re: Wicket and JEE6
On Thu, Jul 29, 2010 at 10:18 PM, James Carman wrote: > The problem with using the AspectJ-injected references occurs when you > pass your reference to another class (such as a model, for instance). > That class may not be instrumented via AspectJ to handle the > serialization/deserialization properly for that reference. So, it > will fail. > > I also think it is a dodgy approach with aspect J and that it's best to avoid it. Also, because it involves additional configuration and more complexity. The simplest solution appears to be to inject using the onBeforeRender listener. The disadvantage is however that I will be doing this injection too many times (every construction and onBeforeRender).
Re: Wicket and JEE6
On Thu, Jul 29, 2010 at 9:54 PM, Erik Brakkee wrote: > Is there also a callback in wicket to listen for component serialization > and deserialization? > Googling for this it also seems possible to use an aspectj pointcut to do injection at deserialization.
Re: Wicket and JEE6
I have done a lot of experimentation at the moment and I am using CDI dependency injection now for a simple wicket project. It is based on the code at utils.wamblee.org (wicket/inject). The issue I am running into is the following. I am creating a detachable entity object which is simply a detachable model that safes the primary key in onDetach() + sets the object to null. It loads the object from persistent storage using entityManager.find(class, key) in the get() method (if not yet initialized). The detachable model is constructed using an entity manager obtained using CDI. However, in the following scenario, things go wrong: (1) edit an entity in a form, (2) click ok, (3) browser back. What happens is that I get a NullPointerException in EntityManagerWrapper on line 314 on glassfish v3. What is actually happening here is that the detachable model is being serialized but the EntityManagerWrapper (the contextual that delegates to the actual entitymanager to use) has transient fields which become null after deserialization. The EntityManagerWrapper is declared Serializable but in fact it isn't. Now, I have to do two things. First I have to report an issue on glassfish v3. I think the entity manager wrapper should be truly serializable and not just declared serializable. Second, I need to work around this problem. The solution I am thinking of is to use a simple utility that provides a truly serializable entity manager that delegates to an entity manager obtained using CDI. That would solve the problem with the detachable. However, there is one more issue which is the injection setup in the application. I still need the injection at component instantiation to allow use of injected objects in the constructor. But I still have a question whether it would be required to also use a IComponentOnBeforeRenderListener to do an additional injection in the onBeforeRender() method. The only reason I would need to do this is when pages in wicket are serialized as well. Do I need to take page serialization into account? Is there also a callback in wicket to listen for component serialization and deserialization?
Re: Expiring pages in form submit and onAfterRender...
Thinking about it some more. Perhaps the best solution is to simply use a detachable model for the entity in the view page and then send the user to an error page when the entry is no longer there. I could of course also use a detachable model for the entity on the edit page because in this page all editing is done on one page and not on multiple pages. This would provide the most userfriendly behavior.
Re: Expiring pages in form submit and onAfterRender...
I have indeed seen how to set the default expiry page in the Application class and that might come in handy. Will have a look too at the StatelessForm. Anyway, I have a working solution now with the pagemap trick. However, perhaps I need to do even more, because the flow isList of items -> view item page-> edit item page-> back -> back In that case, the first back leads to en Expired page. But, the second back button leads to the view item page showing incorrect contents of the modified item. This is probably because the edit item page has its own copy of the item (even though the edit page was constructed from the view page by passing it the item object). Possibly this happens because of serialization of individual pages. Therefore, the second time the back button is pressed I am viewing stale data. I could solve it perhaps by reloading the entity from the database in the view page's onBeforeRender() and even to check for its existence (item might have been deleted) and in the latter case forward to another page. Or am I going perhaps too far in trying to get consistent views of my application's model?
Re: Expiring pages in form submit and onAfterRender...
Made some progress. Now I am removing the page from the page map in the onDetach() and now expiry is really successful. Even so successful that the form submit fails because the page has expired. This is of course logical because the page object is still needed to process the form submit and now I am apparently removing the page too early.
Expiring pages in form submit and onAfterRender...
Hi, I am experimenting a bit with page expiry. One solution that works is to remove the page from the pagemap in the submit of a form. However, removing the page from the pagemap in the onAfterRender() of a page does not seem to work. In fact, I see the same page id and version being rendered every time. Is this the way it should be? Is there another generic callback in a wicket page in which I could remove the page from the pagemap to expire it? What makes the form's onSubmit() special? Alternatively, I am considering to use a strategy whereby I set an expired flag on form submit and then in the onBeforeRender() use setResponsePage() to delegate to a specific page providing also a specific message. That would allow total control on form submit. Would that strategy work? Cheers Erik
Re: colocating wicket with servlets...
On Mon, Jul 26, 2010 at 9:15 PM, Igor Vaynberg wrote: > see WicketSessionFilter > > -igor > > Indeed, looking at the source code of WicketFilter, it does not seem to set the session for the current thread when one of the ignored paths is used.
colocating wicket with servlets...
I would like to colocate a wicket application with a servlet. What I want is for the servlet to have access to the wicket session. Looking at the code I see that Session.get() uses thread-specific storage, so I want the wicket filter to intercept all requests. Next, I want to make sure that requests for the servlet are forwarded to the servlet and not handled by wicket. The wicket filter provides one way of doing this by specifying a number of ignored paths. But, how do I now which paths I can safely ignore? I can create mounts for all bookmarkable pages but how can I control the paths of non-bookmarkable URLs. Should I create a separate request coding strategy decorator (like CryptedUrlWebRequestCodingStrategy) or is there an easier way? Cheers Erik
how to make sure text is preselected in a form?
Hi, I want to know how to make sure that text is preselected on a form. I know there was a way but I cannot find it anymore. Cheers Erik
Re: Correct way to disable browser caching...
Solved it already. Just have to override setHeaders() in my page:
aResponse.setHeader("Pragma", "no-cache");
aResponse.setHeader("Cache-Control",
"no-cache, max-age=0, must-revalidate, no-store");
On Fri, Jul 23, 2010 at 1:39 PM, Erik Brakkee wrote:
> Hi,
>
>
> I would like to disable browser caching of certain pages. What is the
> simplest way to to do this?
> Right now I am removing the page from the pagemap after form submit, but
> the browser still goes back and only resubmission is prevented.
>
> Using the HTML expire tag is an option but it is probably better to use an
> HTTP header instead. How is this done using wicket?
>
> Cheers
> Erik
>
Correct way to disable browser caching...
Hi, I would like to disable browser caching of certain pages. What is the simplest way to to do this? Right now I am removing the page from the pagemap after form submit, but the browser still goes back and only resubmission is prevented. Using the HTML expire tag is an option but it is probably better to use an HTTP header instead. How is this done using wicket? Cheers Erik
Re: what happened to setModel()?...
On Fri, Jul 23, 2010 at 12:38 AM, Igor Vaynberg wrote: > setdefaultmodel() > > -igor > > Already tried it, ignoring the scary javadocs, and it works!
what happened to setModel()?...
HI all, I have a detachable model that I want to set as the model of a page so that it is properly detached. There used to be setModel(). But how should I do this now? I cannot use the superclass constructor because the detachable model can only be computed after construction of the page because it depends on an injected variable. Also, setDefaultModel() shows me a huge warning in the javadocs. Also, setModelImpl() cannot be accessed. What is the correct solution here? Cheers Erik
Re: Wicket and JEE6
On Mon, Apr 12, 2010 at 12:12 AM, James Carman wrote: > I would imagine that most implementations would cache their injectors > (it's part of the Bean) > > > I was triggered by the remark in the WeldCOmponentInstantiationListener which says 'TODO Cache the NonContextual' Also, the NonContextual implementation itself mentions this 'Store the injection target. The CDI spec doesn't require an implementation to cache it, so we do' Therefore, it is probably safer to do the caching ourselves hen to rely on caching by the beanmanager.
Re: Wicket and JEE6
Just have a look at https://wamblee.org/svn/public/wicket-cdi The main thing I did was to make the injection and caching stuff completely independent of wicket and I made some arrangements to still allow unit tests where you can inject different things from the defaults. In particular, I think you can incorporate the InjectorCache in your design and it would also be good to make the injection support independent of wicket. Basically, the org.wamblee.cdi package tries to provide a simple and efficient injection api (bean manager api is too general and too verbose for most purposes)
Re: Wicket and JEE6
On Mon, Apr 5, 2010 at 11:58 PM, James Carman wrote: > > What I'll do is set it up in wicketstuff. That way others can > contribute/maintain it too. I've got permission already, so I can put > it up there sometime this evening. > > Do you have a location already for the source? I still think that wicket core would be a better place since wicket-spring and wicket-guice are also already there. Meanwhile I also did some refactoring already and implemented caching Not much is left of the original code, but I think it is simpler the way I have it now. A side effect is that I also have a simple Injector class that can be used to perform injection into any class. Almost all code I have a is wicket-independent and the ComponentInstantiationListener is basically a one-liner now.
Re: Wicket and JEE6
On Mon, Apr 5, 2010 at 10:37 PM, James Carman wrote: > It's apparently down again. That's what I get for "hosting" my server > at my in-law's house. Cheaper isn't necessarily better. If you want, > I can email you the code. > > You can mail the code to me. If it's not too much code, you can also mail it to the list I guess. I think in general, the code should become part of a wicket-cdi project just like wicket-spring and wicket-guice already are. I think the wicket community is probably a better place to maintain this then the weld project. This is because the code could use internal wicket APIs which are more prone to change than the CDI APIs which is a standard. So we would catch problems in the implementation much earlier. It feels a bit like stealing but I am in any case really grateful for the work done by the weld project. This is surely going to save a lot of people some time because standard Java EE capabilities can be used in wicket.
Re: Wicket and JEE6
On Mon, Apr 5, 2010 at 9:54 PM, James Carman wrote: > Did you not look at what I put together? I've already got all the > injection stuff (and conversations) working and I've got example > applications illustrating it. > > I tried to look at it but couldn't access the subversion repo because of timeouts. Atter looking at the code of weld-wicket and seeing that it was just a small amount of code, it was relatively easy to figure out what is was doing and disable the long-lived conversations support. The URL I am trying is: http://svn.carmanconsulting.com/public/wicket-cdi/trunk Can you make sure the URL is working again? I will then have a look at it. The aim would be for an implementation that is completely independent of weld, i.e. does not use any weld core classes and only uses standard CDI APIs and wicket APIs. (to avoid the problem of having to patch the application server).
Re: Wicket and JEE6
>
> I wonder what the use would be for the request, session, and conversation
> scopes in wicket since these are already managed expiicitly in wicket. At
> least, I wouldn't see a great need for such scopemanagement by the
> container. It would be nice however if CDI could be used to inject EJBs,
> resources, and OSGI services into pages.
>
>
Sorry for the mail bombing but just got @EJB injection to work based on the
weld-wicket integration. With this setup the only thing I am missing is
probably the long-lived convesations support, but that is not essential for
me. Essential is the link to ejbs and container resources and the converged
container support in Java EE6 which will simplify a lot.
The main trick is to register only the component instantiation listener from
weld-wicket in the application class.
class WicketApplication extends WebApplication {
private NonContextual
weldComponentInstantiationListener;
/**
* Constructor
*/
public WicketApplication() {
// Empty.
}
@Override
protected void init() {
BeanManager mgr = BeanManagerLookup.getBeanManager();
System.out.println("BeanManager '" + mgr + "'");
this.weldComponentInstantiationListener = new
NonContextual(BeanManagerLookup.getBeanManager(),
WeldComponentInstantiationListener.class);
addComponentInstantiationListener(weldComponentInstantiationListener.newInstance().produce().inject().get());
}
...
}
Next is simply the use of @EJB in a regular page object.
This works without having to patch the application server.
Re: Wicket and JEE6
On Wed, Mar 31, 2010 at 5:05 AM, Iskandar Salim wrote: > > > > Olivier Bourgeois-2 wrote: > > > > ... > > everything is simple unmanaged POJOs except for your classes extending > > WebPage which are "managed" > > > > Not to be picky but a minor correction :) > everything is simple unmanaged POJOs except for your classes extending > [Component] which are "managed" > > > I wonder what the use would be for the request, session, and conversation scopes in wicket since these are already managed expiicitly in wicket. At least, I wouldn't see a great need for such scopemanagement by the container. It would be nice however if CDI could be used to inject EJBs, resources, and OSGI services into pages. -- > View this message in context: > http://old.nabble.com/Wicket-and-JEE6-tp28045129p28091022.html > Sent from the Wicket - User 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: keep on getting non-bookmarkable URL with QueryStringUrlCodingStrategy...
There is definitely something strange going on. It appears that whenever I
use a parameter that has a '/' in it I get strange behavior. I do see the
'/' being encoded properly but still these '/' characters are in the way.
Typical behavior is to see an empty page with the default URL coding
strategy and to get a non-bookmarkable page with the querystring strategy.
As a workaround I am now replacing all '/' characters in the parameter by
something else and then changing it back when using it.
This is not the whole story because even if I apply this hack, the
QueryStringURLCoder strategy still generates a non-bookmarkable page for the
page I want to use. The way out was to use mountBookmarkablePage but I
really don't want to use that.
To reproduce it you would need to mount a page using the
QueryStringURLCoder:
mount(new QueryStringUrlCodingStrategy("/gpx-from-url",
RemoteTrackMapPage.class));
make the RemoteTrackMapPage have either a default constructor or one with
PageParameters (does not matter which one) and do a
setResponsePage(RemoteTrackMapPage.class, new PageParameters()).
If I have the time I will make an example.
Cheers
Erik
keep on getting non-bookmarkable URL with QueryStringUrlCodingStrategy...
Hi, I have mounted a specific page using QueryStringUrlCodingStrategy to a specific URL. Nevertheless, when I use setResponsePage(MyPage.class, pageParams), I keep on getting a URL that has a session-specific parameter with name 'x'. Is there anything I am doing wrong. I just have one parameter in the page parameters that I want to see appearing in the URL. Cheers Erik
setting contentType on ResourceReference...
Hi, I was wondering how to set the contentType when creating a ResourceReference or PackageResource. Is this possible? Cheers Erik
