Re: wicket-bootstrap and another webjars components
Hello all I recreated my project with maven quickstart, it works fine. So I replaced the dependencies in my broken application with maven quickstart, and it works! Table below shows the dependencies of two applications. +--- Broken application Fine application +--- wicket-webjars-0.3.2.jar +wicket-webjars-0.2.0.jar +--- webjars-locator-0.6.jar +webjars-locator-0.1.jar +--- - We do this not because it is easy. We do this because it is hard. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket-bootstrap-and-another-webjars-components-tp4662572p4662606.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Using Wicket and Hibernate
Here's an example of wicket spring and hibernate all working together, with an h2 database: https://github.com/dalvizu/wicket-spring-hibernate-template -Dan On Thu, Nov 21, 2013 at 8:30 AM, Gerrit Wassink wrote: > Hello, > I am reading "Wicket in Action" the part over wicket, spring and > hibernate.Since i am new to concepts like wicket, spring and hibernate i > want to learn about them.But also learning three new tools together is a > bit much. > Is it therefore a good idea to forget about Spring and make the mvc > working with only Wicket and Hibernate? > Maybe you can give me a startup voor working together wicket and hibernate? > Thanks a lot! > Greetings Gerrit
WicketTester - asserting on HTML
Is it possible to to make assertions on the rendered HTML of a Wicket page? Im trying to make assertions on element attributes (class contents specifically). Is this possible with WicketTester? N
Sign to Google with Java Wicket
Hi, Does someone know how to open a Google account in Java (Wicket) and how to close it again? I read several pages about it on the internet, but I cannot figure it out. I accomplished to open a connection to GoogleMail, after which a mail is being sent via the SMTP server of Google. Now, I only want an automatic login in Java. When I have finished it has to log out again. Can someone help me? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Sign-to-Google-with-Java-Wicket-tp4662591.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
Using Wicket and Hibernate
Hello, I am reading "Wicket in Action" the part over wicket, spring and hibernate.Since i am new to concepts like wicket, spring and hibernate i want to learn about them.But also learning three new tools together is a bit much. Is it therefore a good idea to forget about Spring and make the mvc working with only Wicket and Hibernate? Maybe you can give me a startup voor working together wicket and hibernate? Thanks a lot! Greetings Gerrit
Re: WicketTester - asserting on HTML
You could use the TagTester for that.
Example:
// hello
world
TagTester tester = wicketTester.getTagByWicketId("myLabel");
assertTrue(tester.getAttributeContains("class", "one-class"));
assertTrue(tester.getAttributeContains("class", "another-class"));
assertFalse(tester.getAttributeContains("class", "not-this-class"));
Best regards / Met vriendelijke groet,
Kees van Dieren
Squins IT Solutions BV
Oranjestraat 30
2983 HS Ridderkerk
The Netherlands
Mobile: +31 (0)6 30413841
www.squins.com
Chamber of commerce Rotterdam: 24435103
2013/11/21 Martin Makundi
> assertContains
>
>
> 2013/11/21 Nick Pratt
>
> > Is it possible to to make assertions on the rendered HTML of a Wicket
> page?
> >
> > Im trying to make assertions on element attributes (class contents
> > specifically). Is this possible with WicketTester?
> >
> > N
> >
>
Re: Using Wicket and Hibernate
Thanks! Dan Alvizu , 21-11-2013 14:59: Here's an example of wicket spring and hibernate all working together, with an h2 database: https://github.com/dalvizu/wicket-spring-hibernate-template -Dan On Thu, Nov 21, 2013 at 8:30 AM, Gerrit Wassink wrote: > Hello, > I am reading "Wicket in Action" the part over wicket, spring and > hibernate.Since i am new to concepts like wicket, spring and hibernate i > want to learn about them.But also learning three new tools together is a > bit much. > Is it therefore a good idea to forget about Spring and make the mvc > working with only Wicket and Hibernate? > Maybe you can give me a startup voor working together wicket and hibernate? > Thanks a lot! > Greetings Gerrit
Re: WicketTester - asserting on HTML
assertContains 2013/11/21 Nick Pratt > Is it possible to to make assertions on the rendered HTML of a Wicket page? > > Im trying to make assertions on element attributes (class contents > specifically). Is this possible with WicketTester? > > N >
Re: Java EL for Wicket
Hi Steve,
Thanks for sharing!
As longtime wicket users we are doing something similar.
We have the notion of a "page context" to which components can
contribute data (it's a simple map) by implementing an
interface (PageContextContributor).
A component can then either:
- add an InlineContextLabel, which will replace expressions in it's body
using the page context, or
- add an InlineContextMarkupContainer, which can serve as a parent to
wicket:message tags, so they can resolve properties in the page context
The reason we have started using this in more recent projects is that we
didn't like the split you get once you have pages (or components) which
have localized html files, but also contain some "dynamic" content:
labels with property replacement.
Before using our above solution, we would have some of the content in
properties files, and some in the localized html files. Now we can have
a lot more of the localized stuff directly in the html files.
I'll have a look at your code.
Met vriendelijke groet,
Kind regards,
Bas Gooren
schreef Steve op 21-11-2013 12:05:
This will probably horrify some of the wicket dev team. It's probably
not the 'wicket way'. But I've been using wicket for years and there's
plenty of thing you can do in many different ways but a few things that
you just can't.
An incidental but very useful part of this package in a Renderer class.
It's an extension of wicket's ComponentRenderer that allows you to
Render components without having to create a wicket application. If you
do happen to be inside a wicket application when you invoke it no
problem. But with the wicket version you have no choice. So for a
quick and dirty HTML output it lets you go with 2 lines of code:
Renderer.init();
String html = Renderer.renderComponent(myPanel).toString();
The main part of the package is an integration of JUEL with wicket
allowing you to put Java Expression Language into your markup which will
be evaluated just before the wicket rendering cycle. It might seem odd
but I've wished this was part of wicket for years. There's many times
when I just want to populate a html element with a bean property and it
gets a bit tedious having to add it in both markup and code. It also
makes dynamic markup generation a lot easier given that your generator
only needs to spit out HTML for many purposes and doesn't need to
generate java code as well.
The wicket version would be something like this:
markup:
code:
add(new Label("label1", bean.getFirstName())
.add(AttributeModifier.replace("color", new Model("green") {
public String getObject() {
bean.getColor();
}
}));
add(new Label("label2", bean.getLastName());
The EL version would be simply:more
${bean.firstName}
${bean.lastName}
No code needed at all if 'bean' is a property of the Component.
Otherwise you can just add a single line:
setELBaseObject(bean);
then the above html becomes even simpler:
${firstName} ${lastName}
All the magic of wicket is retained. But with a much neater way of
adding simple values to markup.
The code is model aware. If any part of an expression evaluates to a
wicket model it will be unwrapped before the rest of the expression is
evaluated. So all the model magic is also retained and models can be
used to achieve anything particularly fancy needed for an evaluation.
Currently the code is split into two behaviours. The first part enables
modifiable markup. If you want a simple way to interfere with markup
before wicket gets to it you can use this behaviour on it's own by
overriding a single method: String modifyMarkup(String). The second
part is the EL implementation (which uses the JUEL library). Both are
implemented using the behaviour pattern because there's no common parent
class to inject this behaviour into the Component class heirarchy.
Currently there's implementations for Panel, ListView and Page but
looking at those an example should give you an idea how to add the
behaviour to other component types.
Be warned the code is very fresh so is likely got a few bugs and I have
fairly hefty TODO list. But I intend using it for a couple of projects
I'm working on so it should be getting plenty of developer love in the
near future. I'm the first to admit it's a bit hacky in the way it
hooks into the wicket lifecycle. Wicket really doesn't make it easy to
intercept markup. With luck the dev team won't hate this idea too much
and might provide some neater hooks in future versions of the API.
You can find it here: https://bitbucket.org/shadders/wicket-el
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Rendering a component into a String
I think the fix for 6.13 will be something similar. The page should report that it is stateless no matter what components/behaviors it renders. On Thu, Nov 21, 2013 at 1:33 PM, Mateusz Mieszkowski < mmieszkow...@objectivity.co.uk> wrote: > Just a quick update for those with the same problem: > Option 1 did not work as the page is not bookmarkable. > I used option 2 and override isBookmarkable() method in RenderPage to > return true. Page is set to stateless on its own. > > It's not too clean but in my case should be enough. Martin, please let me > know if you see any danger in such solution. > > Mateusz > > > -Original Message- > From: Martin Grigorov [mailto:mgrigo...@apache.org] > Sent: Thursday, November 21, 2013 10:56 AM > To: users@wicket.apache.org > Subject: Re: Rendering a component into a String > > Option 1) Override your component's onInitialize/onConfigure and call > page.setStatelessHint(true) > Option 2) Copy/paste ComponentRenderer.java locally and do something > similar directly in RenderPage > > > On Thu, Nov 21, 2013 at 11:29 AM, Mateusz Mieszkowski < > mmieszkow...@objectivity.co.uk> wrote: > > > Martin, > > > > Ticket created: https://issues.apache.org/jira/browse/WICKET-5422 > > Can you advise a workaround for now? > > > > Cheers, > > Mateusz > > > > > > -Original Message- > > From: Martin Grigorov [mailto:mgrigo...@apache.org] > > Sent: Thursday, November 21, 2013 9:49 AM > > To: users@wicket.apache.org > > Cc: Martin Dietze > > Subject: Re: Rendering a component into a String > > > > Please create a ticket. > > The page should be marked as stateless to avoid storing it. > > > > > > On Thu, Nov 21, 2013 at 10:40 AM, Mateusz Mieszkowski < > > mmieszkow...@objectivity.co.uk> wrote: > > > > > Hi guys, > > > > > > I noticed a problem with ComponentRenderer.renderComponent(). It is > > > possible that I'm missing something but this is what I get for now: > > > I'm using ComponenetRenderer withing CustomTooltipBehavior > > > (wicket-jquery-ui) to generate tooltip content. I add this to about > > > 50 rows in my table so I run renderComponent() method as many times. > > > All worked fine but there was a problem with performance when I used > > > Fragment component with markup attached to the WebPage. I did some > > > digging and finally checked > > > http://localhost:8080/context/wicket/internal/debug/diskDataStore > > > and it appeared that for one request, Wicket stores 51 pages in it. > > > All of the size of the whole page (about 300kB) and all of them > > > named org.apache.wicket.core.util.string.ComponentRenderer$RenderPage. > > > > > > I changed implementation from Fragment to Panel componenet and the > > > size was reduced to (1kB) but still all of these items were stored > > > in the DataStore. > > > > > > It seems that this method is creating a dummy page in order to > > > create the markup, but how can I avoid storing these pages? > > > > > > Best regards, > > > Mateusz > > > > > > -Original Message- > > > From: Martin Grigorov [mailto:mgrigo...@apache.org] > > > Sent: Wednesday, November 13, 2013 2:09 PM > > > To: users@wicket.apache.org; Martin Dietze > > > Subject: Re: Rendering a component into a String > > > > > > Hi, > > > > > > See the source of > > > http://www.wicket-library.com/wicket-examples-6.0.x/mailtemplate/?2e > > > xa > > > mple > > > > > > > > > On Wed, Nov 13, 2013 at 3:04 PM, Martin Dietze wrote: > > > > > > > In a legacy project I've inherited I've got a piece of code that > > > > no longer works since the project was upgraded from Wicket 1.4 to > > > > Wicket 6. > > > > > > > > It's about rendering a component (a Wicket panel) into a string in > > > > order to return it wrapped into a webservice reply. > > > > > > > > The webservice is based on Wicket, too. The webservice is based on > > > > a Javascript handshake - the client calls the service using a > > > > token connecting the user to his current session he has on the > > > > application, the service replies are rendered into an iframe and > > > > deliver their data through postMessage. > > > > > > > > Thus, when rendering a reply, I am basically rendering a Wicket > > > > page within the context of my session. > > > > > > > > Now one of my API's calls requires me to render a Wicket panel > > > > into a String, which is then wrapped into JSON as part of the > > > > respective call's reply. > > > > > > > > The legacy code used to do this roughly like this (changes for > > > > using the Wicket 6 API were applied, but this nevertheless never > > > > worked): > > > > > > > > - create a mock RequestCycle by creating a MockHttpSession, a > > > > MockHttpServletRequest and a MockHttpServletResponse, glue > > > > this all together to obtain a ServletWebRequest and a > > > > BufferedWebResponse and finaly use use > > Application.createRequestCycle() > > > > to create the RequestCycle object > > > > > > > > - the component wrapped into a ComponentRenderingRequestHandler > > > >
RE: Rendering a component into a String
Just a quick update for those with the same problem:
Option 1 did not work as the page is not bookmarkable.
I used option 2 and override isBookmarkable() method in RenderPage to return
true. Page is set to stateless on its own.
It's not too clean but in my case should be enough. Martin, please let me know
if you see any danger in such solution.
Mateusz
-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Thursday, November 21, 2013 10:56 AM
To: users@wicket.apache.org
Subject: Re: Rendering a component into a String
Option 1) Override your component's onInitialize/onConfigure and call
page.setStatelessHint(true)
Option 2) Copy/paste ComponentRenderer.java locally and do something similar
directly in RenderPage
On Thu, Nov 21, 2013 at 11:29 AM, Mateusz Mieszkowski <
mmieszkow...@objectivity.co.uk> wrote:
> Martin,
>
> Ticket created: https://issues.apache.org/jira/browse/WICKET-5422
> Can you advise a workaround for now?
>
> Cheers,
> Mateusz
>
>
> -Original Message-
> From: Martin Grigorov [mailto:mgrigo...@apache.org]
> Sent: Thursday, November 21, 2013 9:49 AM
> To: users@wicket.apache.org
> Cc: Martin Dietze
> Subject: Re: Rendering a component into a String
>
> Please create a ticket.
> The page should be marked as stateless to avoid storing it.
>
>
> On Thu, Nov 21, 2013 at 10:40 AM, Mateusz Mieszkowski <
> mmieszkow...@objectivity.co.uk> wrote:
>
> > Hi guys,
> >
> > I noticed a problem with ComponentRenderer.renderComponent(). It is
> > possible that I'm missing something but this is what I get for now:
> > I'm using ComponenetRenderer withing CustomTooltipBehavior
> > (wicket-jquery-ui) to generate tooltip content. I add this to about
> > 50 rows in my table so I run renderComponent() method as many times.
> > All worked fine but there was a problem with performance when I used
> > Fragment component with markup attached to the WebPage. I did some
> > digging and finally checked
> > http://localhost:8080/context/wicket/internal/debug/diskDataStore
> > and it appeared that for one request, Wicket stores 51 pages in it.
> > All of the size of the whole page (about 300kB) and all of them
> > named org.apache.wicket.core.util.string.ComponentRenderer$RenderPage.
> >
> > I changed implementation from Fragment to Panel componenet and the
> > size was reduced to (1kB) but still all of these items were stored
> > in the DataStore.
> >
> > It seems that this method is creating a dummy page in order to
> > create the markup, but how can I avoid storing these pages?
> >
> > Best regards,
> > Mateusz
> >
> > -Original Message-
> > From: Martin Grigorov [mailto:mgrigo...@apache.org]
> > Sent: Wednesday, November 13, 2013 2:09 PM
> > To: users@wicket.apache.org; Martin Dietze
> > Subject: Re: Rendering a component into a String
> >
> > Hi,
> >
> > See the source of
> > http://www.wicket-library.com/wicket-examples-6.0.x/mailtemplate/?2e
> > xa
> > mple
> >
> >
> > On Wed, Nov 13, 2013 at 3:04 PM, Martin Dietze wrote:
> >
> > > In a legacy project I've inherited I've got a piece of code that
> > > no longer works since the project was upgraded from Wicket 1.4 to
> > > Wicket 6.
> > >
> > > It's about rendering a component (a Wicket panel) into a string in
> > > order to return it wrapped into a webservice reply.
> > >
> > > The webservice is based on Wicket, too. The webservice is based on
> > > a Javascript handshake - the client calls the service using a
> > > token connecting the user to his current session he has on the
> > > application, the service replies are rendered into an iframe and
> > > deliver their data through postMessage.
> > >
> > > Thus, when rendering a reply, I am basically rendering a Wicket
> > > page within the context of my session.
> > >
> > > Now one of my API's calls requires me to render a Wicket panel
> > > into a String, which is then wrapped into JSON as part of the
> > > respective call's reply.
> > >
> > > The legacy code used to do this roughly like this (changes for
> > > using the Wicket 6 API were applied, but this nevertheless never
> > > worked):
> > >
> > > - create a mock RequestCycle by creating a MockHttpSession, a
> > > MockHttpServletRequest and a MockHttpServletResponse, glue
> > > this all together to obtain a ServletWebRequest and a
> > > BufferedWebResponse and finaly use use
> Application.createRequestCycle()
> > > to create the RequestCycle object
> > >
> > > - the component wrapped into a ComponentRenderingRequestHandler
> > >
> > > - then this code is executed:
> > >
> > > |try {
> > > |
> requestCycle.scheduleRequestHandlerAfterCurrent(requestHandler);
> > > |try {
> > > |if ( !requestCycle.processRequestAndDetach() ) {
> > > |
> > > | requestCycle.scheduleRequestHandlerAfterCurrent(new
> > > ErrorCodeRequestHandler((HttpServletResponse.SC_NOT_FOUND));
> > > | }
> > > |} finally {
> > > |request
Java EL for Wicket
This will probably horrify some of the wicket dev team. It's probably
not the 'wicket way'. But I've been using wicket for years and there's
plenty of thing you can do in many different ways but a few things that
you just can't.
An incidental but very useful part of this package in a Renderer class.
It's an extension of wicket's ComponentRenderer that allows you to
Render components without having to create a wicket application. If you
do happen to be inside a wicket application when you invoke it no
problem. But with the wicket version you have no choice. So for a
quick and dirty HTML output it lets you go with 2 lines of code:
Renderer.init();
String html = Renderer.renderComponent(myPanel).toString();
The main part of the package is an integration of JUEL with wicket
allowing you to put Java Expression Language into your markup which will
be evaluated just before the wicket rendering cycle. It might seem odd
but I've wished this was part of wicket for years. There's many times
when I just want to populate a html element with a bean property and it
gets a bit tedious having to add it in both markup and code. It also
makes dynamic markup generation a lot easier given that your generator
only needs to spit out HTML for many purposes and doesn't need to
generate java code as well.
The wicket version would be something like this:
markup:
code:
add(new Label("label1", bean.getFirstName())
.add(AttributeModifier.replace("color", new Model("green") {
public String getObject() {
bean.getColor();
}
}));
add(new Label("label2", bean.getLastName());
The EL version would be simply:more
${bean.firstName}
${bean.lastName}
No code needed at all if 'bean' is a property of the Component.
Otherwise you can just add a single line:
setELBaseObject(bean);
then the above html becomes even simpler:
${firstName} ${lastName}
All the magic of wicket is retained. But with a much neater way of
adding simple values to markup.
The code is model aware. If any part of an expression evaluates to a
wicket model it will be unwrapped before the rest of the expression is
evaluated. So all the model magic is also retained and models can be
used to achieve anything particularly fancy needed for an evaluation.
Currently the code is split into two behaviours. The first part enables
modifiable markup. If you want a simple way to interfere with markup
before wicket gets to it you can use this behaviour on it's own by
overriding a single method: String modifyMarkup(String). The second
part is the EL implementation (which uses the JUEL library). Both are
implemented using the behaviour pattern because there's no common parent
class to inject this behaviour into the Component class heirarchy.
Currently there's implementations for Panel, ListView and Page but
looking at those an example should give you an idea how to add the
behaviour to other component types.
Be warned the code is very fresh so is likely got a few bugs and I have
fairly hefty TODO list. But I intend using it for a couple of projects
I'm working on so it should be getting plenty of developer love in the
near future. I'm the first to admit it's a bit hacky in the way it
hooks into the wicket lifecycle. Wicket really doesn't make it easy to
intercept markup. With luck the dev team won't hate this idea too much
and might provide some neater hooks in future versions of the API.
You can find it here: https://bitbucket.org/shadders/wicket-el
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Visural wicket, input text hint is considered as input value.
Hello,
I don't know if here is the right place to ask this question, but visural
wicket group seems to not be active anymore.
I used visural wicket library to display hint into a text field. When
submitting the form by an ajax button, the component is properly handled.
But when I use a AjaxFormComponentUpdatingBehavior("onblur"), when the
component is validated, the hint is considered input text.
Example, for a text field for age, teh text 'Please enter your age' is
considered as input text. After rendering, the text is not styled as a hit
anymore.
I could not figure out what is different between the two ajax request
(submit button and ajaxformcomponentupdatingbehavior)
Thanks.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Visural-wicket-input-text-hint-is-considered-as-input-value-tp4662584.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Rendering a component into a String
Option 1) Override your component's onInitialize/onConfigure and call
page.setStatelessHint(true)
Option 2) Copy/paste ComponentRenderer.java locally and do something
similar directly in RenderPage
On Thu, Nov 21, 2013 at 11:29 AM, Mateusz Mieszkowski <
mmieszkow...@objectivity.co.uk> wrote:
> Martin,
>
> Ticket created: https://issues.apache.org/jira/browse/WICKET-5422
> Can you advise a workaround for now?
>
> Cheers,
> Mateusz
>
>
> -Original Message-
> From: Martin Grigorov [mailto:mgrigo...@apache.org]
> Sent: Thursday, November 21, 2013 9:49 AM
> To: users@wicket.apache.org
> Cc: Martin Dietze
> Subject: Re: Rendering a component into a String
>
> Please create a ticket.
> The page should be marked as stateless to avoid storing it.
>
>
> On Thu, Nov 21, 2013 at 10:40 AM, Mateusz Mieszkowski <
> mmieszkow...@objectivity.co.uk> wrote:
>
> > Hi guys,
> >
> > I noticed a problem with ComponentRenderer.renderComponent(). It is
> > possible that I'm missing something but this is what I get for now:
> > I'm using ComponenetRenderer withing CustomTooltipBehavior
> > (wicket-jquery-ui) to generate tooltip content. I add this to about 50
> > rows in my table so I run renderComponent() method as many times.
> > All worked fine but there was a problem with performance when I used
> > Fragment component with markup attached to the WebPage. I did some
> > digging and finally checked
> > http://localhost:8080/context/wicket/internal/debug/diskDataStore and
> > it appeared that for one request, Wicket stores 51 pages in it. All of
> > the size of the whole page (about 300kB) and all of them named
> > org.apache.wicket.core.util.string.ComponentRenderer$RenderPage.
> >
> > I changed implementation from Fragment to Panel componenet and the
> > size was reduced to (1kB) but still all of these items were stored in
> > the DataStore.
> >
> > It seems that this method is creating a dummy page in order to create
> > the markup, but how can I avoid storing these pages?
> >
> > Best regards,
> > Mateusz
> >
> > -Original Message-
> > From: Martin Grigorov [mailto:mgrigo...@apache.org]
> > Sent: Wednesday, November 13, 2013 2:09 PM
> > To: users@wicket.apache.org; Martin Dietze
> > Subject: Re: Rendering a component into a String
> >
> > Hi,
> >
> > See the source of
> > http://www.wicket-library.com/wicket-examples-6.0.x/mailtemplate/?2exa
> > mple
> >
> >
> > On Wed, Nov 13, 2013 at 3:04 PM, Martin Dietze wrote:
> >
> > > In a legacy project I've inherited I've got a piece of code that no
> > > longer works since the project was upgraded from Wicket 1.4 to
> > > Wicket 6.
> > >
> > > It's about rendering a component (a Wicket panel) into a string in
> > > order to return it wrapped into a webservice reply.
> > >
> > > The webservice is based on Wicket, too. The webservice is based on a
> > > Javascript handshake - the client calls the service using a token
> > > connecting the user to his current session he has on the
> > > application, the service replies are rendered into an iframe and
> > > deliver their data through postMessage.
> > >
> > > Thus, when rendering a reply, I am basically rendering a Wicket page
> > > within the context of my session.
> > >
> > > Now one of my API's calls requires me to render a Wicket panel into
> > > a String, which is then wrapped into JSON as part of the respective
> > > call's reply.
> > >
> > > The legacy code used to do this roughly like this (changes for using
> > > the Wicket 6 API were applied, but this nevertheless never
> > > worked):
> > >
> > > - create a mock RequestCycle by creating a MockHttpSession, a
> > > MockHttpServletRequest and a MockHttpServletResponse, glue
> > > this all together to obtain a ServletWebRequest and a
> > > BufferedWebResponse and finaly use use
> Application.createRequestCycle()
> > > to create the RequestCycle object
> > >
> > > - the component wrapped into a ComponentRenderingRequestHandler
> > >
> > > - then this code is executed:
> > >
> > > |try {
> > > |
> requestCycle.scheduleRequestHandlerAfterCurrent(requestHandler);
> > > |try {
> > > |if ( !requestCycle.processRequestAndDetach() ) {
> > > |requestCycle.scheduleRequestHandlerAfterCurrent(new
> > > ErrorCodeRequestHandler((HttpServletResponse.SC_NOT_FOUND));
> > > | }
> > > |} finally {
> > > |requestCycle.getResponse().close();
> > > |}
> > > |return requestCycle.getResponse().toString();
> > > |} finally {
> > > |requestCycle.detach();
> > > |}
> > >
> > > I must admit I could not have written this myself :)
> > >
> > > Now when running this code, I run into two different
> > > exceptions:
> > >
> > > org.apache.wicket.WicketRuntimeException: Exception in rendering
> > > component: [Profile [Component id = profile]]
> > > at
> > > org.apache.wicket.Component.internalRenderComponent(Component.java:2
> > > 57
> > > 6)
> > > [wicket-core-6.9.1.jar:6.9.1
RE: Rendering a component into a String
Martin,
Ticket created: https://issues.apache.org/jira/browse/WICKET-5422
Can you advise a workaround for now?
Cheers,
Mateusz
-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Thursday, November 21, 2013 9:49 AM
To: users@wicket.apache.org
Cc: Martin Dietze
Subject: Re: Rendering a component into a String
Please create a ticket.
The page should be marked as stateless to avoid storing it.
On Thu, Nov 21, 2013 at 10:40 AM, Mateusz Mieszkowski <
mmieszkow...@objectivity.co.uk> wrote:
> Hi guys,
>
> I noticed a problem with ComponentRenderer.renderComponent(). It is
> possible that I'm missing something but this is what I get for now:
> I'm using ComponenetRenderer withing CustomTooltipBehavior
> (wicket-jquery-ui) to generate tooltip content. I add this to about 50
> rows in my table so I run renderComponent() method as many times.
> All worked fine but there was a problem with performance when I used
> Fragment component with markup attached to the WebPage. I did some
> digging and finally checked
> http://localhost:8080/context/wicket/internal/debug/diskDataStore and
> it appeared that for one request, Wicket stores 51 pages in it. All of
> the size of the whole page (about 300kB) and all of them named
> org.apache.wicket.core.util.string.ComponentRenderer$RenderPage.
>
> I changed implementation from Fragment to Panel componenet and the
> size was reduced to (1kB) but still all of these items were stored in
> the DataStore.
>
> It seems that this method is creating a dummy page in order to create
> the markup, but how can I avoid storing these pages?
>
> Best regards,
> Mateusz
>
> -Original Message-
> From: Martin Grigorov [mailto:mgrigo...@apache.org]
> Sent: Wednesday, November 13, 2013 2:09 PM
> To: users@wicket.apache.org; Martin Dietze
> Subject: Re: Rendering a component into a String
>
> Hi,
>
> See the source of
> http://www.wicket-library.com/wicket-examples-6.0.x/mailtemplate/?2exa
> mple
>
>
> On Wed, Nov 13, 2013 at 3:04 PM, Martin Dietze wrote:
>
> > In a legacy project I've inherited I've got a piece of code that no
> > longer works since the project was upgraded from Wicket 1.4 to
> > Wicket 6.
> >
> > It's about rendering a component (a Wicket panel) into a string in
> > order to return it wrapped into a webservice reply.
> >
> > The webservice is based on Wicket, too. The webservice is based on a
> > Javascript handshake - the client calls the service using a token
> > connecting the user to his current session he has on the
> > application, the service replies are rendered into an iframe and
> > deliver their data through postMessage.
> >
> > Thus, when rendering a reply, I am basically rendering a Wicket page
> > within the context of my session.
> >
> > Now one of my API's calls requires me to render a Wicket panel into
> > a String, which is then wrapped into JSON as part of the respective
> > call's reply.
> >
> > The legacy code used to do this roughly like this (changes for using
> > the Wicket 6 API were applied, but this nevertheless never
> > worked):
> >
> > - create a mock RequestCycle by creating a MockHttpSession, a
> > MockHttpServletRequest and a MockHttpServletResponse, glue
> > this all together to obtain a ServletWebRequest and a
> > BufferedWebResponse and finaly use use Application.createRequestCycle()
> > to create the RequestCycle object
> >
> > - the component wrapped into a ComponentRenderingRequestHandler
> >
> > - then this code is executed:
> >
> > |try {
> > |requestCycle.scheduleRequestHandlerAfterCurrent(requestHandler);
> > |try {
> > |if ( !requestCycle.processRequestAndDetach() ) {
> > |requestCycle.scheduleRequestHandlerAfterCurrent(new
> > ErrorCodeRequestHandler((HttpServletResponse.SC_NOT_FOUND));
> > | }
> > |} finally {
> > |requestCycle.getResponse().close();
> > |}
> > |return requestCycle.getResponse().toString();
> > |} finally {
> > |requestCycle.detach();
> > |}
> >
> > I must admit I could not have written this myself :)
> >
> > Now when running this code, I run into two different
> > exceptions:
> >
> > org.apache.wicket.WicketRuntimeException: Exception in rendering
> > component: [Profile [Component id = profile]]
> > at
> > org.apache.wicket.Component.internalRenderComponent(Component.java:2
> > 57
> > 6)
> > [wicket-core-6.9.1.jar:6.9.1]
> > at
> > org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1493
> > )
> > ~[wicket-core-6.9.1.jar:6.9.1]
> > at
> > org.apache.wicket.Component.internalRender(Component.java:2379)
> > [wicket-core-6.9.1.jar:6.9.1]
> > at org.apache.wicket.Component.render(Component.java:2307)
> > [wicket-core-6.9.1.jar:6.9.1]
> > [...]
> > Caused by: java.lang.NullPointerException: null
> > at
> > org.apache.wicket.markup.html.internal.Enclosure.isVisible(Enclosure
> > .j
Re: Rendering a component into a String
Please create a ticket.
The page should be marked as stateless to avoid storing it.
On Thu, Nov 21, 2013 at 10:40 AM, Mateusz Mieszkowski <
mmieszkow...@objectivity.co.uk> wrote:
> Hi guys,
>
> I noticed a problem with ComponentRenderer.renderComponent(). It is
> possible that I'm missing something but this is what I get for now:
> I'm using ComponenetRenderer withing CustomTooltipBehavior
> (wicket-jquery-ui) to generate tooltip content. I add this to about 50 rows
> in my table so I run renderComponent() method as many times.
> All worked fine but there was a problem with performance when I used
> Fragment component with markup attached to the WebPage. I did some digging
> and finally checked
> http://localhost:8080/context/wicket/internal/debug/diskDataStore and it
> appeared that for one request, Wicket stores 51 pages in it. All of the
> size of the whole page (about 300kB) and all of them named
> org.apache.wicket.core.util.string.ComponentRenderer$RenderPage.
>
> I changed implementation from Fragment to Panel componenet and the size
> was reduced to (1kB) but still all of these items were stored in the
> DataStore.
>
> It seems that this method is creating a dummy page in order to create the
> markup, but how can I avoid storing these pages?
>
> Best regards,
> Mateusz
>
> -Original Message-
> From: Martin Grigorov [mailto:mgrigo...@apache.org]
> Sent: Wednesday, November 13, 2013 2:09 PM
> To: users@wicket.apache.org; Martin Dietze
> Subject: Re: Rendering a component into a String
>
> Hi,
>
> See the source of
> http://www.wicket-library.com/wicket-examples-6.0.x/mailtemplate/?2example
>
>
> On Wed, Nov 13, 2013 at 3:04 PM, Martin Dietze wrote:
>
> > In a legacy project I've inherited I've got a piece of code that no
> > longer works since the project was upgraded from Wicket 1.4 to Wicket
> > 6.
> >
> > It's about rendering a component (a Wicket panel) into a string in
> > order to return it wrapped into a webservice reply.
> >
> > The webservice is based on Wicket, too. The webservice is based on a
> > Javascript handshake - the client calls the service using a token
> > connecting the user to his current session he has on the application,
> > the service replies are rendered into an iframe and deliver their data
> > through postMessage.
> >
> > Thus, when rendering a reply, I am basically rendering a Wicket page
> > within the context of my session.
> >
> > Now one of my API's calls requires me to render a Wicket panel into a
> > String, which is then wrapped into JSON as part of the respective
> > call's reply.
> >
> > The legacy code used to do this roughly like this (changes for using
> > the Wicket 6 API were applied, but this nevertheless never
> > worked):
> >
> > - create a mock RequestCycle by creating a MockHttpSession, a
> > MockHttpServletRequest and a MockHttpServletResponse, glue
> > this all together to obtain a ServletWebRequest and a
> > BufferedWebResponse and finaly use use Application.createRequestCycle()
> > to create the RequestCycle object
> >
> > - the component wrapped into a ComponentRenderingRequestHandler
> >
> > - then this code is executed:
> >
> > |try {
> > |requestCycle.scheduleRequestHandlerAfterCurrent(requestHandler);
> > |try {
> > |if ( !requestCycle.processRequestAndDetach() ) {
> > |requestCycle.scheduleRequestHandlerAfterCurrent(new
> > ErrorCodeRequestHandler((HttpServletResponse.SC_NOT_FOUND));
> > | }
> > |} finally {
> > |requestCycle.getResponse().close();
> > |}
> > |return requestCycle.getResponse().toString();
> > |} finally {
> > |requestCycle.detach();
> > |}
> >
> > I must admit I could not have written this myself :)
> >
> > Now when running this code, I run into two different
> > exceptions:
> >
> > org.apache.wicket.WicketRuntimeException: Exception in rendering
> > component: [Profile [Component id = profile]]
> > at
> > org.apache.wicket.Component.internalRenderComponent(Component.java:257
> > 6)
> > [wicket-core-6.9.1.jar:6.9.1]
> > at
> > org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1493)
> > ~[wicket-core-6.9.1.jar:6.9.1]
> > at
> > org.apache.wicket.Component.internalRender(Component.java:2379)
> > [wicket-core-6.9.1.jar:6.9.1]
> > at org.apache.wicket.Component.render(Component.java:2307)
> > [wicket-core-6.9.1.jar:6.9.1]
> > [...]
> > Caused by: java.lang.NullPointerException: null
> > at
> > org.apache.wicket.markup.html.internal.Enclosure.isVisible(Enclosure.j
> > ava:143)
> > ~[wicket-core-6.9.1.jar:6.9.1]
> > at
> > org.apache.wicket.Component.determineVisibility(Component.java:4363)
> > [wicket-core-6.9.1.jar:6.9.1]
> > at
> > org.apache.wicket.Component.internalBeforeRender(Component.java:916)
> > [wicket-core-6.9.1.jar:6.9.1]
> > at
> > org.apache.wicket.Component.beforeRender(Component.java:991)
> > [wicket-core-6
RE: Rendering a component into a String
Hi guys,
I noticed a problem with ComponentRenderer.renderComponent(). It is possible
that I'm missing something but this is what I get for now:
I'm using ComponenetRenderer withing CustomTooltipBehavior (wicket-jquery-ui)
to generate tooltip content. I add this to about 50 rows in my table so I run
renderComponent() method as many times.
All worked fine but there was a problem with performance when I used Fragment
component with markup attached to the WebPage. I did some digging and finally
checked http://localhost:8080/context/wicket/internal/debug/diskDataStore and
it appeared that for one request, Wicket stores 51 pages in it. All of the size
of the whole page (about 300kB) and all of them named
org.apache.wicket.core.util.string.ComponentRenderer$RenderPage.
I changed implementation from Fragment to Panel componenet and the size was
reduced to (1kB) but still all of these items were stored in the DataStore.
It seems that this method is creating a dummy page in order to create the
markup, but how can I avoid storing these pages?
Best regards,
Mateusz
-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Wednesday, November 13, 2013 2:09 PM
To: users@wicket.apache.org; Martin Dietze
Subject: Re: Rendering a component into a String
Hi,
See the source of
http://www.wicket-library.com/wicket-examples-6.0.x/mailtemplate/?2 example
On Wed, Nov 13, 2013 at 3:04 PM, Martin Dietze wrote:
> In a legacy project I've inherited I've got a piece of code that no
> longer works since the project was upgraded from Wicket 1.4 to Wicket
> 6.
>
> It's about rendering a component (a Wicket panel) into a string in
> order to return it wrapped into a webservice reply.
>
> The webservice is based on Wicket, too. The webservice is based on a
> Javascript handshake - the client calls the service using a token
> connecting the user to his current session he has on the application,
> the service replies are rendered into an iframe and deliver their data
> through postMessage.
>
> Thus, when rendering a reply, I am basically rendering a Wicket page
> within the context of my session.
>
> Now one of my API's calls requires me to render a Wicket panel into a
> String, which is then wrapped into JSON as part of the respective
> call's reply.
>
> The legacy code used to do this roughly like this (changes for using
> the Wicket 6 API were applied, but this nevertheless never
> worked):
>
> - create a mock RequestCycle by creating a MockHttpSession, a
> MockHttpServletRequest and a MockHttpServletResponse, glue
> this all together to obtain a ServletWebRequest and a
> BufferedWebResponse and finaly use use Application.createRequestCycle()
> to create the RequestCycle object
>
> - the component wrapped into a ComponentRenderingRequestHandler
>
> - then this code is executed:
>
> |try {
> |requestCycle.scheduleRequestHandlerAfterCurrent(requestHandler);
> |try {
> |if ( !requestCycle.processRequestAndDetach() ) {
> |requestCycle.scheduleRequestHandlerAfterCurrent(new
> ErrorCodeRequestHandler((HttpServletResponse.SC_NOT_FOUND));
> | }
> |} finally {
> |requestCycle.getResponse().close();
> |}
> |return requestCycle.getResponse().toString();
> |} finally {
> |requestCycle.detach();
> |}
>
> I must admit I could not have written this myself :)
>
> Now when running this code, I run into two different
> exceptions:
>
> org.apache.wicket.WicketRuntimeException: Exception in rendering
> component: [Profile [Component id = profile]]
> at
> org.apache.wicket.Component.internalRenderComponent(Component.java:257
> 6)
> [wicket-core-6.9.1.jar:6.9.1]
> at
> org.apache.wicket.MarkupContainer.onRender(MarkupContainer.java:1493)
> ~[wicket-core-6.9.1.jar:6.9.1]
> at
> org.apache.wicket.Component.internalRender(Component.java:2379)
> [wicket-core-6.9.1.jar:6.9.1]
> at org.apache.wicket.Component.render(Component.java:2307)
> [wicket-core-6.9.1.jar:6.9.1]
> [...]
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.wicket.markup.html.internal.Enclosure.isVisible(Enclosure.j
> ava:143)
> ~[wicket-core-6.9.1.jar:6.9.1]
> at
> org.apache.wicket.Component.determineVisibility(Component.java:4363)
> [wicket-core-6.9.1.jar:6.9.1]
> at
> org.apache.wicket.Component.internalBeforeRender(Component.java:916)
> [wicket-core-6.9.1.jar:6.9.1]
> at
> org.apache.wicket.Component.beforeRender(Component.java:991)
> [wicket-core-6.9.1.jar:6.9.1]
> at
> org.apache.wicket.Component.internalPrepareForRender(Component.java:22
> 14)
> [wicket-core-6.9.1.jar:6.9.1]
> at org.apache.wicket.Component.render(Component.java:2303)
> [wicket-core-6.9.1.jar:6.9.1]
> at
> org.apache.wicket.MarkupContainer.renderNext(MarkupContainer.java:1390
> )
> ~[wicket-core-6.9.1.jar:6.9.1]
> at
> org.apache.w
Re: wicket-bootstrap and another webjars components
i use 0.3.2 On 2013/11/21 下午 03:51, Martin Grigorov wrote: which version of wicket-webjars do you use ? there was a fix recently that may be related. Please provide a quickstart (github project) as Michael requested in the ticket and we will check it. On Thu, Nov 21, 2013 at 9:46 AM, Shengche Hsiao wrote: Hello Martin Sorry, I typed wrong version, actually i used the version you figured. If i implement the web application just using wicket 6.11.0 and webjars (wicket-webjars, codemirror, ace), it works fine. Once i added wicket-bootstrap 0.8.4 in it , every js reference broken but bootstrap related js. On 2013/11/21 下午 03:40, Martin Grigorov wrote: Hi, It looks like you use wrong version of webjars-ace. I found 07.31.2013 On Thu, Nov 21, 2013 at 6:55 AM, Shengche Hsiao wrote: Hi all I successfully implemented two projects, one project used apache wicket 6.11.0 with wicket-bootstrap 0.8.4 another used apache wicket 6.11.0 with webjars component - ace 2017.07.31! But, when I create a new project with apache wicket 6.11.0 with wicket-bootstrap and ace, the ace js reference cannot locate correctly (ie. ). Does anybody meet this issue previous? - We do this not because it is easy. We do this because it is hard. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/wicket- bootstrap-and-another-webjars-components-tp4662572.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 -- ---> We do this not because it is easy. We do this because it is hard. ---> ShengChe Hsiao ---> front...@gmail.com front...@tc.edu.tw ---> VoIP : 070-910-2450 ---> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- ---> We do this not because it is easy. We do this because it is hard. ---> ShengChe Hsiao ---> front...@gmail.com front...@tc.edu.tw ---> VoIP : 070-910-2450 ---> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
