Re: Single page app as custom resource?
Interesting! Thank you Andrea! fre 18 nov. 2016 kl. 12:41 skrev Andrea Del Bene <an.delb...@gmail.com>: > Hi, > > I haven't directly tried this approach but there is an Apache project, > Syncope, that recently has gone in this direction. The following is the > link to their enduser module which is built with Angular for the > frontend and uses Wicket resources for the REST API: > > https://github.com/apache/syncope/tree/master/client/enduser > > On 16/11/2016 12:56, Lars Törner wrote: > > Ok, thanks Martin! > > > > It would be really interesting to hear the opinion of someone that tried > > the approach. > > > > 2016-11-16 12:43 GMT+01:00 Martin Grigorov <martin.grigo...@gmail.com>: > > > >> Hi Lars, > >> > >> AFAIK some people use this approach in their applications. > >> > >> You can use Wicket resources as endpoints or any other, e.g. Spring MVC, > >> just make sure you "wrap" them in WicketSessionFilter so you have > access to > >> Application.get() and Session.get() inside them. > >> > >> On Nov 16, 2016 7:41 AM, "Lars Törner" <lars.tor...@gmail.com> wrote: > >> > >>> Ok, now I found wicketstuff-rest-annotations... so, can I create a > >> wicket > >>> page, load resources for a java scriptframework and then use > >>> wicket-rest-requests with ajax to integrate a SPA in my > >>> wicket-web-application? > >>> > >>> tisdag 15 november 2016 skrev Lars Törner <lars.tor...@gmail.com>: > >>> > >>>> Hi, > >>>> > >>>> we're developing a webbapplication to our legacy product and we're > >> doing > >>>> it in wicket. > >>>> > >>>> We have a few pages which are using a lot of ajax, and therefore each > >> one > >>>> of them could be seen as kind of a SPA. (Does that make sense?) > >>>> > >>>> Now we might have a case when a client (or we our selves) would like > to > >>>> extend the wicket webbapplication with a page/spa written in > javascript > >>>> (angular/react etc). From the users point of view, there should be no > >>>> difference. It should be the same session etc. > >>>> > >>>> Can this be done with a dynamic resource? Or in some other way? Is it > a > >>>> bad idea or just another way to do things? > >>>> > >>>> Cheers > >>>> Lars > >>>> > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Single page app as custom resource?
Ok, thanks Martin! It would be really interesting to hear the opinion of someone that tried the approach. 2016-11-16 12:43 GMT+01:00 Martin Grigorov <martin.grigo...@gmail.com>: > Hi Lars, > > AFAIK some people use this approach in their applications. > > You can use Wicket resources as endpoints or any other, e.g. Spring MVC, > just make sure you "wrap" them in WicketSessionFilter so you have access to > Application.get() and Session.get() inside them. > > On Nov 16, 2016 7:41 AM, "Lars Törner" <lars.tor...@gmail.com> wrote: > > > Ok, now I found wicketstuff-rest-annotations... so, can I create a > wicket > > page, load resources for a java scriptframework and then use > > wicket-rest-requests with ajax to integrate a SPA in my > > wicket-web-application? > > > > tisdag 15 november 2016 skrev Lars Törner <lars.tor...@gmail.com>: > > > > > Hi, > > > > > > we're developing a webbapplication to our legacy product and we're > doing > > > it in wicket. > > > > > > We have a few pages which are using a lot of ajax, and therefore each > one > > > of them could be seen as kind of a SPA. (Does that make sense?) > > > > > > Now we might have a case when a client (or we our selves) would like to > > > extend the wicket webbapplication with a page/spa written in javascript > > > (angular/react etc). From the users point of view, there should be no > > > difference. It should be the same session etc. > > > > > > Can this be done with a dynamic resource? Or in some other way? Is it a > > > bad idea or just another way to do things? > > > > > > Cheers > > > Lars > > > > > >
Re: Single page app as custom resource?
Ok, now I found wicketstuff-rest-annotations... so, can I create a wicket page, load resources for a java scriptframework and then use wicket-rest-requests with ajax to integrate a SPA in my wicket-web-application? tisdag 15 november 2016 skrev Lars Törner <lars.tor...@gmail.com>: > Hi, > > we're developing a webbapplication to our legacy product and we're doing > it in wicket. > > We have a few pages which are using a lot of ajax, and therefore each one > of them could be seen as kind of a SPA. (Does that make sense?) > > Now we might have a case when a client (or we our selves) would like to > extend the wicket webbapplication with a page/spa written in javascript > (angular/react etc). From the users point of view, there should be no > difference. It should be the same session etc. > > Can this be done with a dynamic resource? Or in some other way? Is it a > bad idea or just another way to do things? > > Cheers > Lars >
Single page app as custom resource?
Hi, we're developing a webbapplication to our legacy product and we're doing it in wicket. We have a few pages which are using a lot of ajax, and therefore each one of them could be seen as kind of a SPA. (Does that make sense?) Now we might have a case when a client (or we our selves) would like to extend the wicket webbapplication with a page/spa written in javascript (angular/react etc). From the users point of view, there should be no difference. It should be the same session etc. Can this be done with a dynamic resource? Or in some other way? Is it a bad idea or just another way to do things? Cheers Lars
Re: Bookmarkable link doesn't become a https link
Hi Martin and thanks for your answer!
I think that what you say is that the documentation I found is correct.
"It is extremely important that when setting the rootRequestMapper it
is done AFTER you have added any bookmarkable links otherwise they will not
be switched over to Secure mode".
I also understand why it's implemented like this. What I don't understand
is why it's now working in our code when we're mounting the bookmarkable
page after setting the requestmapper. I guess we have to take a deeper look
into it.
Once again, thank you for your effort!
Lars
lördag 15 oktober 2016 skrev Martin Grigorov <mgrigo...@apache.org>:
> Hi Lars,
>
>
> mountPage("page2", Page2.class);
> setRootRequestMapper(new HttpsMapper(getRootRequestMapper(), new
> HttpsConfig(8080, 8443)));
> mountPage("page3", Page3.class);
>
> Now if I am at Page1 (http://localhost:8080/page1) and there I have
> add(new BookmarkablePageLink("page2", Page2.class));
> then the generated url is https://localhost:8443/page2 because the
> HttpsMapper wraps the old root mapper that knows about Page2.
>
> HttpsMapper doesn't
> implement org.apache.wicket.request.mapper.ICompoundRequestMapper so when
> mountPage(page3) is called Wicket creates a
> new org.apache.wicket.request.mapper.CompoundRequestMapper that adds the
> current root mapper (HttpsMapper) at position 1 and a MountedMapper for
> Page3 at position 2. So requests to Page3 are not handled by HttpsMapper
> and the generated urls are HTTP, not HTTPS.
>
> HttpsMapper intentionally doesn't implement ICompoundRequestMapper exactly
> for this reason - to make it possible to configure pages which should never
> be secured.
>
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Fri, Oct 14, 2016 at 2:48 PM, Lars Törner <lars.tor...@gmail.com
> <javascript:;>> wrote:
>
> > Hi,
> >
> > we had a problem where a bookmarkable link didn't become a https link.
> >
> > I found this:
> > https://cwiki.apache.org/confluence/display/WICKET/How+
> > to+switch+to+SSL+mode
> >
> > Which, with a warning, states:
> >
> > "It is extemtely important that when setting the rootRequestMapper it is
> > done AFTER you have added any bookmarkable links otherwise they will not
> be
> > switched over to Secure mode."
> >
> > I found that we in our Application.init() did the opposite, i.e. set the
> > rootRequestMapper before the page mounting. Problem solved, I thought.
> >
> > Instead the problem was that the page wasn't mounted at all, and the only
> > thing that worked was to mount the page and keep the order we had, which,
> > according to the link and the warning above is bound to fail.
> >
> > Please, can anyone tell me what I'm missing here?
> >
> > Wicket version: 6.22.
> >
> > Cheers
> > Lars
> >
>
Bookmarkable link doesn't become a https link
Hi, we had a problem where a bookmarkable link didn't become a https link. I found this: https://cwiki.apache.org/confluence/display/WICKET/How+to+switch+to+SSL+mode Which, with a warning, states: "It is extemtely important that when setting the rootRequestMapper it is done AFTER you have added any bookmarkable links otherwise they will not be switched over to Secure mode." I found that we in our Application.init() did the opposite, i.e. set the rootRequestMapper before the page mounting. Problem solved, I thought. Instead the problem was that the page wasn't mounted at all, and the only thing that worked was to mount the page and keep the order we had, which, according to the link and the warning above is bound to fail. Please, can anyone tell me what I'm missing here? Wicket version: 6.22. Cheers Lars
Re: Busy indicator delay with IAjaxIndicatorAware?
Thanks, I'll take a look at your suggestions! Lasse 2016-10-06 11:02 GMT+02:00 Martin Grigorov <mgrigo...@apache.org>: > Hi Lars, > > At Apache Isis we use the custom solution for this: > https://github.com/apache/isis/blob/master/core/viewer- > wicket-ui/src/main/java/org/apache/isis/viewer/wicket/ui/ > pages/jquery.isis.wicket.viewer.js#L88-L96 > At my current project I've used the same approach but directly with jQuery > APIs (#ajaxStart() & #ajaxComplete()) so it covers also non-Wicket Ajax > calls. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Thu, Oct 6, 2016 at 10:58 AM, Lars Törner <lars.tor...@gmail.com> > wrote: > > > Hi everyone! > > > > Is there a best practice in wicket for adding a busy indicator with a > delay > > for an ajax request? > > > > Or should it be done with a before handler that executes a javascript > that > > shows the busy indicator after a configured time, and abort this > > "busy-indicator-script" with an after-handler when the request returns? > > > > Example: > > 1. User clicks an ajax-link. > > 2. A busy indicator is displayed only if the call takes more than a > second > > to complete. > > > > Cheers > > Lasse > > >
Busy indicator delay with IAjaxIndicatorAware?
Hi everyone! Is there a best practice in wicket for adding a busy indicator with a delay for an ajax request? Or should it be done with a before handler that executes a javascript that shows the busy indicator after a configured time, and abort this "busy-indicator-script" with an after-handler when the request returns? Example: 1. User clicks an ajax-link. 2. A busy indicator is displayed only if the call takes more than a second to complete. Cheers Lasse
Re: Rendering performance
Ok, that might have something to do with it! :-D Thanks! 2016-06-16 16:21 GMT+02:00 Martin Grigorov <mgrigo...@apache.org>: > The models and data providers are asked for their data at render time. > Once the final data is available Wicket starts populating the HTML markup > with it. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Thu, Jun 16, 2016 at 4:17 PM, Lars Törner <lars.tor...@gmail.com> > wrote: > > > Hi Martin, > > > > we use wicket 6.22. > > > > Doesn't the rendering take place when everything else is done? I.e the > > wicket components are already created and populated with data when the > > rendering phase starts. I guess I have to dig a bit deeper... anyway, > > thanks for your quick answers! > > > > Lasse > > > > 2016-06-16 15:47 GMT+02:00 Martin Grigorov <mgrigo...@apache.org>: > > > > > Also it could be similar to > > > https://issues.apache.org/jira/browse/WICKET-6177. > > > There the user also has a lot of components in the tree and this takes > > time > > > at page serialization time. > > > > > > Martin Grigorov > > > Wicket Training and Consulting > > > https://twitter.com/mtgrigorov > > > > > > On Thu, Jun 16, 2016 at 3:46 PM, Martin Grigorov <mgrigo...@apache.org > > > > > wrote: > > > > > > > Hi Lasse, > > > > > > > > Which version of Wicket do you use ? > > > > > > > > I think you will have to use a profiler to see where the times is > > spent. > > > > It could be Wicket, but also it could be the application spending a > lot > > > of > > > > time while loading the data which should be rendered. > > > > > > > > > > > > Martin Grigorov > > > > Wicket Training and Consulting > > > > https://twitter.com/mtgrigorov > > > > > > > > On Thu, Jun 16, 2016 at 3:37 PM, Lars Törner <lars.tor...@gmail.com> > > > > wrote: > > > > > > > >> Hi, > > > >> > > > >> we have an issue with rendering performance and I wonder if there > are > > > any > > > >> common misusages of wicket when it comes to this. > > > >> > > > >> When rendering a fully expanded tree with 160 top level nodes and > > mostly > > > >> no > > > >> subtrees (an expanded node is a forms with a bunch of labels and > > > >> attributes) it takes about 20 seconds for the page to load (actually > > > it's > > > >> an Ajax request) and it seems that most of this time is spent when > > > wicket > > > >> renders the components. > > > >> > > > >> For one ot these 160 nodes, which has some sub nodes and forms, > > > rendering > > > >> takes about half a second. > > > >> > > > >> I'm using the RenderPerformanceListener from wicket-devutils to do > the > > > >> measuring and gets, for the entire expanded tree, over 22 000 > > > >> "afterRender" > > > >> rows in the log from the RenderPerformanceListener. > > > >> This is in my opinion a huge number! > > > >> > > > >> - is it expected that rendering of so many components takes this > > amount > > > of > > > >> time? > > > >> - is this amount a sign of that we are using wicket in the wrong > way? > > > >> > > > >> > > > >> Don't know if this makes any sense to anyone but this is the last > > lines > > > of > > > >> the log output for one of the top level nodes: > > > >> > > > >> > > > >> > > > > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeEditLabel' > > > >> for 0ms > > > >> > > > >> > > > > > > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplayLabel' > > > >> for 0ms > > > >> > > > >> > > &
Re: Rendering performance
Hi Martin, we use wicket 6.22. Doesn't the rendering take place when everything else is done? I.e the wicket components are already created and populated with data when the rendering phase starts. I guess I have to dig a bit deeper... anyway, thanks for your quick answers! Lasse 2016-06-16 15:47 GMT+02:00 Martin Grigorov <mgrigo...@apache.org>: > Also it could be similar to > https://issues.apache.org/jira/browse/WICKET-6177. > There the user also has a lot of components in the tree and this takes time > at page serialization time. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Thu, Jun 16, 2016 at 3:46 PM, Martin Grigorov <mgrigo...@apache.org> > wrote: > > > Hi Lasse, > > > > Which version of Wicket do you use ? > > > > I think you will have to use a profiler to see where the times is spent. > > It could be Wicket, but also it could be the application spending a lot > of > > time while loading the data which should be rendered. > > > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Thu, Jun 16, 2016 at 3:37 PM, Lars Törner <lars.tor...@gmail.com> > > wrote: > > > >> Hi, > >> > >> we have an issue with rendering performance and I wonder if there are > any > >> common misusages of wicket when it comes to this. > >> > >> When rendering a fully expanded tree with 160 top level nodes and mostly > >> no > >> subtrees (an expanded node is a forms with a bunch of labels and > >> attributes) it takes about 20 seconds for the page to load (actually > it's > >> an Ajax request) and it seems that most of this time is spent when > wicket > >> renders the components. > >> > >> For one ot these 160 nodes, which has some sub nodes and forms, > rendering > >> takes about half a second. > >> > >> I'm using the RenderPerformanceListener from wicket-devutils to do the > >> measuring and gets, for the entire expanded tree, over 22 000 > >> "afterRender" > >> rows in the log from the RenderPerformanceListener. > >> This is in my opinion a huge number! > >> > >> - is it expected that rendering of so many components takes this amount > of > >> time? > >> - is this amount a sign of that we are using wicket in the wrong way? > >> > >> > >> Don't know if this makes any sense to anyone but this is the last lines > of > >> the log output for one of the top level nodes: > >> > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeEditLabel' > >> for 0ms > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplayLabel' > >> for 0ms > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplay' > >> for 0ms > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeFeedback' > >> for 1ms > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell' > >> for 2ms > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12' > >> for 2ms > >> > >> > 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeR
Rendering performance
Hi, we have an issue with rendering performance and I wonder if there are any common misusages of wicket when it comes to this. When rendering a fully expanded tree with 160 top level nodes and mostly no subtrees (an expanded node is a forms with a bunch of labels and attributes) it takes about 20 seconds for the page to load (actually it's an Ajax request) and it seems that most of this time is spent when wicket renders the components. For one ot these 160 nodes, which has some sub nodes and forms, rendering takes about half a second. I'm using the RenderPerformanceListener from wicket-devutils to do the measuring and gets, for the entire expanded tree, over 22 000 "afterRender" rows in the log from the RenderPerformanceListener. This is in my opinion a huge number! - is it expected that rendering of so many components takes this amount of time? - is this amount a sign of that we are using wicket in the wrong way? Don't know if this makes any sense to anyone but this is the last lines of the log output for one of the top level nodes: 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeEditLabel' for 0ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplayLabel' for 0ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeDisplay' for 0ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell:attributeFeedback' for 1ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12:cell' for 2ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol:12' for 2ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow:attributeRowCol' for 26ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent:attributeRow' for 27ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1:objectSectionContent' for 27ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection:1' for 27ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm:objectSection' for 28ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component:objectViewerForm' for 29ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content:component' for 29ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node:content' for 36ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:node' for 36ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:subtree:branches' for 0ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8:subtree' for 1ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches:8' for 37ms 'mainContent:detailViewer:detailAndSidebarContainer:detailContainer:bodyContainer:subtree:subtree:branches:158:subtree:branches' for 340ms
Re: Generate css from less for package resources at runtime.
Hi Martin, many thanks for your efforts! Unfortunately this isn't a priority for our team at the moment. I'll get back to you if/when we dig deeper into this matter. Cheers Lasse 2016-06-08 22:04 GMT+02:00 Martin Grigorov <mgrigo...@apache.org>: > HI Lasse, > > I've checked again Wicket Bootstrap code and I see that it works only with > LessSource$URLSource class which have lastModifiedDate. > I'll need more info (or a demo app) how exactly you use StringSource so I > can think for improvement. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Mon, May 30, 2016 at 4:38 PM, Martin Grigorov <mgrigo...@apache.org> > wrote: > > > Hi Lasse, > > > > > > > https://github.com/SomMeri/less4j/blob/master/src/main/java/com/github/sommeri/less4j/LessSource.java#L365 > > > > StringSource doesn't have get/set lastModifiedDate. > > I can add a specialization of this class in Wicket Bootstrap Less project > > and make use of it while calculating the last modified for a LessSource > and > > all its imports. > > Then the application should use my version instead of the Less4j one. > > If you think this is a good solution then please open an issue at > > https://github.com/l0rdn1kk0n/wicket-bootstrap/ > > A Pull Request will be awesome! > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Wed, May 25, 2016 at 3:54 PM, Lars Törner <lars.tor...@gmail.com> > > wrote: > > > >> Hi Martin, Bas and others! > >> > >> Unfortunately I got one crucial thing wrong when I described our > scenario. > >> > >> "A less-variable (put in a separate file) gets a new value." > >> > >> This is not the case, the variable is changed in code and not in a file. > >> This means that even though we have changed a less variable and > >> regenerated > >> the css, the less files themselves has not changed (no new modification > >> time), and therefore the problem we have arises. > >> > >> To touch the css-file might be a work around, but it seems kind of a > >> strange way to handle things. > >> > >> Cheers > >> Lasse > >> > >> 2016-05-25 12:35 GMT+02:00 Bas Gooren <b...@iswd.nl>: > >> > >> > Lars, Martin, > >> > > >> > > >> > Sorry for hijacking this thread (sort of). > >> > > >> > > >> > Hmmm, I am 100% sure it was not working for us in a web app we > currently > >> > have running. > >> > > >> > I just checked which version of wicket-bootstrap-less it uses (version > >> > 0.9.11), and that version already has the recursive check on the > >> > last-modified time of imported sources. > >> > > >> > > >> > I’ll try to do some debugging to see if it really is not working, and > if > >> > that’s the case: why it’s not working. > >> > > >> > Met vriendelijke groet, > >> > Kind regards, > >> > > >> > Bas Gooren > >> > > >> > Op 24 mei 2016 bij 20:25:52, Lars Törner (lars.tor...@gmail.com) > >> schreef: > >> > > >> > Thanks Martin, I'll take a look at it! > >> > > >> > tisdag 24 maj 2016 skrev Martin Grigorov <mgrigo...@apache.org>: > >> > > >> > > Hi, > >> > > > >> > > I checked the code last night and I believe this use case should be > >> > covered > >> > > by > >> > > > >> > > > >> > > >> > https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/a64af20bcd65f365dbd487c7480db441fd6b6489/bootstrap-less/src/main/java/de/agilecoders/wicket/less/LessCacheManager.java#L156 > >> > > It uses Less4j's APIs to get all imported resources recursively and > >> > > extracts the latest modification time. > >> > > > >> > > > >> > > Martin Grigorov > >> > > Wicket Training and Consulting > >> > > https://twitter.com/mtgrigorov > >> > > > >> > > On Wed, May 18, 2016 at 3:17 PM, Lars Törner <lars.tor...@gmail.com > >> > > <javascript:;>> wrote: > >> > > > >> > > > Thanks, we'll try this! > >> > > > > >> > > > Cheers > >> > > > Lasse > >> > > > > >&
Re: Generate css from less for package resources at runtime.
Hi Martin, Bas and others! Unfortunately I got one crucial thing wrong when I described our scenario. "A less-variable (put in a separate file) gets a new value." This is not the case, the variable is changed in code and not in a file. This means that even though we have changed a less variable and regenerated the css, the less files themselves has not changed (no new modification time), and therefore the problem we have arises. To touch the css-file might be a work around, but it seems kind of a strange way to handle things. Cheers Lasse 2016-05-25 12:35 GMT+02:00 Bas Gooren <b...@iswd.nl>: > Lars, Martin, > > > Sorry for hijacking this thread (sort of). > > > Hmmm, I am 100% sure it was not working for us in a web app we currently > have running. > > I just checked which version of wicket-bootstrap-less it uses (version > 0.9.11), and that version already has the recursive check on the > last-modified time of imported sources. > > > I’ll try to do some debugging to see if it really is not working, and if > that’s the case: why it’s not working. > > Met vriendelijke groet, > Kind regards, > > Bas Gooren > > Op 24 mei 2016 bij 20:25:52, Lars Törner (lars.tor...@gmail.com) schreef: > > Thanks Martin, I'll take a look at it! > > tisdag 24 maj 2016 skrev Martin Grigorov <mgrigo...@apache.org>: > > > Hi, > > > > I checked the code last night and I believe this use case should be > covered > > by > > > > > https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/a64af20bcd65f365dbd487c7480db441fd6b6489/bootstrap-less/src/main/java/de/agilecoders/wicket/less/LessCacheManager.java#L156 > > It uses Less4j's APIs to get all imported resources recursively and > > extracts the latest modification time. > > > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Wed, May 18, 2016 at 3:17 PM, Lars Törner <lars.tor...@gmail.com > > <javascript:;>> wrote: > > > > > Thanks, we'll try this! > > > > > > Cheers > > > Lasse > > > > > > 2016-05-18 13:21 GMT+02:00 Bas Gooren <b...@iswd.nl <javascript:;>>: > > > > > > > Hi all, > > > > > > > > We’ve encountered this issue, too; Simple fix is to touch the less > > file, > > > > even when a secondary file was the only change. > > > > > > > > The root cause is simple: wicket is not aware of any includes in the > > less > > > > file, and as such only looks at the “parent” less file to see if it > was > > > > changed. A potential way to fix this is to make it more intelligent, > > > > assuming the less compiler can expose such details (referenced > files, > > > > last-modified time of those files). > > > > > > > > Met vriendelijke groet, > > > > Kind regards, > > > > > > > > Bas Gooren > > > > > > > > Op 18 mei 2016 bij 13:06:59, Martin Grigorov (mgrigo...@apache.org > > <javascript:;>) > > > > schreef: > > > > > > > > Hi Lasse, > > > > > > > > I'll take a look in the coming days! > > > > > > > > Martin Grigorov > > > > Wicket Training and Consulting > > > > https://twitter.com/mtgrigorov > > > > > > > > On Wed, May 18, 2016 at 11:43 AM, Lars Törner <lars.tor...@gmail.com > > <javascript:;>> > > > > wrote: > > > > > > > > > Hi Martin! > > > > > > > > > > We have now implemented this solution and we're using > bootstrap-less > > - > > > > > thanks for that! > > > > > > > > > > But we have a little problem... > > > > > The browser does not recognize when the css has changed, the cause > > > seems > > > > to > > > > > be that the newly generated css is placed in a file with the same > > name > > > as > > > > > before. The name has a hashsum in the name that is generated from > the > > > > > less-file and the less file has not changed. > > > > > > > > > > What happens is: > > > > > A less-variable (put in a separate file) gets a new value. > > > > > This triggers the less compiler to re-generate css > > > > > The name of the file with generated css has the same name as > before > > so > > > > the > > > > > browser decides to use its c
Re: Generate css from less for package resources at runtime.
Thanks Martin, I'll take a look at it! tisdag 24 maj 2016 skrev Martin Grigorov <mgrigo...@apache.org>: > Hi, > > I checked the code last night and I believe this use case should be covered > by > > https://github.com/l0rdn1kk0n/wicket-bootstrap/blob/a64af20bcd65f365dbd487c7480db441fd6b6489/bootstrap-less/src/main/java/de/agilecoders/wicket/less/LessCacheManager.java#L156 > It uses Less4j's APIs to get all imported resources recursively and > extracts the latest modification time. > > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Wed, May 18, 2016 at 3:17 PM, Lars Törner <lars.tor...@gmail.com > <javascript:;>> wrote: > > > Thanks, we'll try this! > > > > Cheers > > Lasse > > > > 2016-05-18 13:21 GMT+02:00 Bas Gooren <b...@iswd.nl <javascript:;>>: > > > > > Hi all, > > > > > > We’ve encountered this issue, too; Simple fix is to touch the less > file, > > > even when a secondary file was the only change. > > > > > > The root cause is simple: wicket is not aware of any includes in the > less > > > file, and as such only looks at the “parent” less file to see if it was > > > changed. A potential way to fix this is to make it more intelligent, > > > assuming the less compiler can expose such details (referenced files, > > > last-modified time of those files). > > > > > > Met vriendelijke groet, > > > Kind regards, > > > > > > Bas Gooren > > > > > > Op 18 mei 2016 bij 13:06:59, Martin Grigorov (mgrigo...@apache.org > <javascript:;>) > > > schreef: > > > > > > Hi Lasse, > > > > > > I'll take a look in the coming days! > > > > > > Martin Grigorov > > > Wicket Training and Consulting > > > https://twitter.com/mtgrigorov > > > > > > On Wed, May 18, 2016 at 11:43 AM, Lars Törner <lars.tor...@gmail.com > <javascript:;>> > > > wrote: > > > > > > > Hi Martin! > > > > > > > > We have now implemented this solution and we're using bootstrap-less > - > > > > thanks for that! > > > > > > > > But we have a little problem... > > > > The browser does not recognize when the css has changed, the cause > > seems > > > to > > > > be that the newly generated css is placed in a file with the same > name > > as > > > > before. The name has a hashsum in the name that is generated from the > > > > less-file and the less file has not changed. > > > > > > > > What happens is: > > > > A less-variable (put in a separate file) gets a new value. > > > > This triggers the less compiler to re-generate css > > > > The name of the file with generated css has the same name as before > so > > > the > > > > browser decides to use its cached version instead. > > > > > > > > (I'm not the developer of this issue, but hopefully I got it > right...) > > > > > > > > Any suggestions? > > > > > > > > Cheers > > > > Lasse > > > > > > > > > > > > > > > > 2016-03-01 13:02 GMT+01:00 Lars Törner <lars.tor...@gmail.com > <javascript:;>>: > > > > > > > > > Thanks for your quick answer Martin! We will look into your > > suggestions > > > > > and get back to you if we have more questions! > > > > > > > > > > 2016-03-01 11:49 GMT+01:00 Martin Grigorov <mgrigo...@apache.org > <javascript:;>>: > > > > > > > > > >> Hi Lasse, > > > > >> > > > > >> I think the easiest would be to save the generated CSS in memory, > > e.g. > > > > in > > > > >> YourApplication. > > > > >> Once you receive an update from the other system you should just > > > delete > > > > >> the > > > > >> cache (entry). I guess you will have to use read lock when serving > > the > > > > >> response and write lock when updating it. > > > > >> Wicket uses AbstractResource#dataNeedsToBeWritten() > > > > >> < > > > > >> > > > > > > > > > > https://github.com/apache/wicket/blob/ffa34c6bfbd2ccd8340e23ff1601edd3e0e941d6/wicket-core/src/main/java/org/apache/wicket/request/resource/AbstractResourc
Re: Generate css from less for package resources at runtime.
Thanks, we'll try this! Cheers Lasse 2016-05-18 13:21 GMT+02:00 Bas Gooren <b...@iswd.nl>: > Hi all, > > We’ve encountered this issue, too; Simple fix is to touch the less file, > even when a secondary file was the only change. > > The root cause is simple: wicket is not aware of any includes in the less > file, and as such only looks at the “parent” less file to see if it was > changed. A potential way to fix this is to make it more intelligent, > assuming the less compiler can expose such details (referenced files, > last-modified time of those files). > > Met vriendelijke groet, > Kind regards, > > Bas Gooren > > Op 18 mei 2016 bij 13:06:59, Martin Grigorov (mgrigo...@apache.org) > schreef: > > Hi Lasse, > > I'll take a look in the coming days! > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Wed, May 18, 2016 at 11:43 AM, Lars Törner <lars.tor...@gmail.com> > wrote: > > > Hi Martin! > > > > We have now implemented this solution and we're using bootstrap-less - > > thanks for that! > > > > But we have a little problem... > > The browser does not recognize when the css has changed, the cause seems > to > > be that the newly generated css is placed in a file with the same name as > > before. The name has a hashsum in the name that is generated from the > > less-file and the less file has not changed. > > > > What happens is: > > A less-variable (put in a separate file) gets a new value. > > This triggers the less compiler to re-generate css > > The name of the file with generated css has the same name as before so > the > > browser decides to use its cached version instead. > > > > (I'm not the developer of this issue, but hopefully I got it right...) > > > > Any suggestions? > > > > Cheers > > Lasse > > > > > > > > 2016-03-01 13:02 GMT+01:00 Lars Törner <lars.tor...@gmail.com>: > > > > > Thanks for your quick answer Martin! We will look into your suggestions > > > and get back to you if we have more questions! > > > > > > 2016-03-01 11:49 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>: > > > > > >> Hi Lasse, > > >> > > >> I think the easiest would be to save the generated CSS in memory, e.g. > > in > > >> YourApplication. > > >> Once you receive an update from the other system you should just > delete > > >> the > > >> cache (entry). I guess you will have to use read lock when serving the > > >> response and write lock when updating it. > > >> Wicket uses AbstractResource#dataNeedsToBeWritten() > > >> < > > >> > > > https://github.com/apache/wicket/blob/ffa34c6bfbd2ccd8340e23ff1601edd3e0e941d6/wicket-core/src/main/java/org/apache/wicket/request/resource/AbstractResource.java#L433 > > >> > > > >> method to decide whether the client/browser has the latest version. > I.e. > > >> when the browser makes a request for the CSS you should first check > > >> whether > > >> there is a cached entry for this CSS file. If there is no such then > > >> generate it, save it in the cache and serve it back. If there is such > > >> cache > > >> entry then let Wicket check its last modification time against the > > request > > >> header value for 'If-Modified-Since'. > > >> > > >> Additionally you may want to pre-build the CSS resources at > application > > >> start time, or even preserve the current build-time solution, so it is > > >> faster for the first users of the application before any changes in > the > > >> variables. > > >> I've had an issue with similar setup in the past - we were using CDN > > >> (Akamai) and their request timed out while waiting for the Less > > >> compilation. For requests from normal browsers this shouldn't be a > > problem > > >> though. > > >> > > >> You may also check Wicket Bootstrap Less > > >> < > > >> > > > https://github.com/l0rdn1kk0n/wicket-bootstrap/tree/master/bootstrap-less > > >> >. > > >> It is a module of Wicket-Bootstrap project but could be used without > the > > >> other modules. > > >> It provides most of the features you need. You just need to see how to > > >> plug > > >> the update of the variables. > > >> > > >> Martin Grigorov > > >>
Re: Generate css from less for package resources at runtime.
Hi Martin! We have now implemented this solution and we're using bootstrap-less - thanks for that! But we have a little problem... The browser does not recognize when the css has changed, the cause seems to be that the newly generated css is placed in a file with the same name as before. The name has a hashsum in the name that is generated from the less-file and the less file has not changed. What happens is: A less-variable (put in a separate file) gets a new value. This triggers the less compiler to re-generate css The name of the file with generated css has the same name as before so the browser decides to use its cached version instead. (I'm not the developer of this issue, but hopefully I got it right...) Any suggestions? Cheers Lasse 2016-03-01 13:02 GMT+01:00 Lars Törner <lars.tor...@gmail.com>: > Thanks for your quick answer Martin! We will look into your suggestions > and get back to you if we have more questions! > > 2016-03-01 11:49 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>: > >> Hi Lasse, >> >> I think the easiest would be to save the generated CSS in memory, e.g. in >> YourApplication. >> Once you receive an update from the other system you should just delete >> the >> cache (entry). I guess you will have to use read lock when serving the >> response and write lock when updating it. >> Wicket uses AbstractResource#dataNeedsToBeWritten() >> < >> https://github.com/apache/wicket/blob/ffa34c6bfbd2ccd8340e23ff1601edd3e0e941d6/wicket-core/src/main/java/org/apache/wicket/request/resource/AbstractResource.java#L433 >> > >> method to decide whether the client/browser has the latest version. I.e. >> when the browser makes a request for the CSS you should first check >> whether >> there is a cached entry for this CSS file. If there is no such then >> generate it, save it in the cache and serve it back. If there is such >> cache >> entry then let Wicket check its last modification time against the request >> header value for 'If-Modified-Since'. >> >> Additionally you may want to pre-build the CSS resources at application >> start time, or even preserve the current build-time solution, so it is >> faster for the first users of the application before any changes in the >> variables. >> I've had an issue with similar setup in the past - we were using CDN >> (Akamai) and their request timed out while waiting for the Less >> compilation. For requests from normal browsers this shouldn't be a problem >> though. >> >> You may also check Wicket Bootstrap Less >> < >> https://github.com/l0rdn1kk0n/wicket-bootstrap/tree/master/bootstrap-less >> >. >> It is a module of Wicket-Bootstrap project but could be used without the >> other modules. >> It provides most of the features you need. You just need to see how to >> plug >> the update of the variables. >> >> Martin Grigorov >> Wicket Training and Consulting >> https://twitter.com/mtgrigorov >> >> On Tue, Mar 1, 2016 at 10:45 AM, Lars Törner <lars.tor...@gmail.com> >> wrote: >> >> > Hi! >> > >> > We would like to be able to set new colors in our gui at runtime, i.e. >> > change the theme. >> > We use less on component basis. To day we compile the less files to css >> at >> > buildtime and these becom packacke resources. >> > >> > Now we would like to change the colors by altering the appropriate >> > less-variables. We want to set the colors (just values as - themeColor = >> > #00) in our legacy application. Our web app lives in another >> > servletcontainer than the legacy applicaton, so one apporach is to fetch >> > the new colors by REST (for example check for new colors once a minute) >> and >> > get them as json in our wicket-web-app. >> > >> > Now we're thinking of using dynamic resources. i.e. do not compile the >> > less-files at build-time, instead generate css-files fom the less files >> > (hooking in a less-preprocessor) per component at runtime when >> requested. >> > >> > We don't want to generate the css-resource and send it to the client if >> > it's already cached in browser and not updated on server. >> > We don't want to generate the css if it has already been done for the >> > component and new colors hasn't been set, i.e once a dynamic resource is >> > generated, a cached version should be given as response for all clients >> > that request the component. >> > >> > Now the question is if the right way to do this is by implementing a >> > dynamic resource by extending AbstractResource and to cache the css >> (output >> > a css-file on disk?, cache in application?) when once generated? >> > >> > Any drawbacks? Performance issues? Is there a better way to do it? >> > >> > Cheers >> > Lasse >> > >> > >
Re: Exception Handling (ajax)
Hi Sven and thanks for your answer!
Ok I see! That's a better solution. I guess it means that I don't have to
set:
getExceptionSettings().setAjaxErrorHandlingStrategy(
AjaxErrorStrategy.INVOKE_FAILURE_HANDLER);
Because we'll never get to the DefaultExceptionMapper (in the case of an
expected unexpected exception).
Cheers
Lars
2016-03-09 10:56 GMT+01:00 Sven Meier <s...@meiers.net>:
> Hi Lars,
>
> > if this is a good or bad way to handle exceptions during ajax requests
>
> I'd keep your IRequestCycleListener and just return new
> ErrorCodeRequestHandler(500, message) from there.
> No need to fiddle with IExceptionMapper and/or DefaultExceptionMapper.
>
> Have fun
> Sven
>
>
>
>
> On 09.03.2016 09:33, Lars Törner wrote:
>
>> About exception handling
>>
>> I would like a fallback for unexcpected exceptions that are thrown during
>> ajax-calls.
>>
>> I don't want to redirect to a new page so in my application#init I do:
>>
>>
>> getExceptionSettings().setAjaxErrorHandlingStrategy(AjaxErrorStrategy.INVOKE_FAILURE_HANDLER);
>>
>> For the moment I have a request cycle listener for exceptions (added also
>> in application#init). Which implements #onException but for now does
>> nothing if an ajax-request is running:
>> !((WebRequest) requestCycle.getRequest()).isAjax()) -> return null
>>
>> AjaxErrorStrategy.INVOKE_FAILURE_HANDLER leads to
>> org.apache.wicket.DefaultExceptionMapper.internalMap(Exception) returns
>> ErrorCodeRequestHandler(500)
>>
>> What I would like is to register a global failure handler that via java
>> script shows a nice toaster with a user friendly message:
>>
>> Wicket.Event.subscribe('/ajax/call/failure',
>> function (jqEvent, attributes, jqXHR, errorThrown, textStatus)
>> {
>>//TODO Show a fancy toaster with a nice localized user error message
>> });
>>
>> ErrorCodeRequestHandler above has also a constructor that takes a message:
>> ErrorCodeRequestHandler(final int errorCode, final String message)
>>
>> I guess this can be used to get the nice message to the browser?
>>
>> So when I write this an do some more thinking my conclusion is that I must
>> implement my own IExceptionMapper (extending DefaultExceptionMapper?).
>>
>> I will then create my new ExceptionMapper in MyApplication#init and
>> override Application#getExceptionMapperProvider() to return it. In my
>> exception mapper I can check all types of unexpected exeptions my
>> application might throw and get the corresponding user message to supply
>> it
>> to ErrorCodeRequestHandler(final int errorCode, final String message) and
>> then let failure handler show it in the toaster.
>>
>> Ok, so now I guess it would be easier to just test this, but the mail is
>> written so I hope I don´t waste to much of your time by asking if this is
>> a
>> good or bad way to handle exceptions during ajax requests.
>>
>> Cheers
>> Lasse
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Exception Handling (ajax)
About exception handling
I would like a fallback for unexcpected exceptions that are thrown during
ajax-calls.
I don't want to redirect to a new page so in my application#init I do:
getExceptionSettings().setAjaxErrorHandlingStrategy(AjaxErrorStrategy.INVOKE_FAILURE_HANDLER);
For the moment I have a request cycle listener for exceptions (added also
in application#init). Which implements #onException but for now does
nothing if an ajax-request is running:
!((WebRequest) requestCycle.getRequest()).isAjax()) -> return null
AjaxErrorStrategy.INVOKE_FAILURE_HANDLER leads to
org.apache.wicket.DefaultExceptionMapper.internalMap(Exception) returns
ErrorCodeRequestHandler(500)
What I would like is to register a global failure handler that via java
script shows a nice toaster with a user friendly message:
Wicket.Event.subscribe('/ajax/call/failure',
function (jqEvent, attributes, jqXHR, errorThrown, textStatus)
{
//TODO Show a fancy toaster with a nice localized user error message
});
ErrorCodeRequestHandler above has also a constructor that takes a message:
ErrorCodeRequestHandler(final int errorCode, final String message)
I guess this can be used to get the nice message to the browser?
So when I write this an do some more thinking my conclusion is that I must
implement my own IExceptionMapper (extending DefaultExceptionMapper?).
I will then create my new ExceptionMapper in MyApplication#init and
override Application#getExceptionMapperProvider() to return it. In my
exception mapper I can check all types of unexpected exeptions my
application might throw and get the corresponding user message to supply it
to ErrorCodeRequestHandler(final int errorCode, final String message) and
then let failure handler show it in the toaster.
Ok, so now I guess it would be easier to just test this, but the mail is
written so I hope I don´t waste to much of your time by asking if this is a
good or bad way to handle exceptions during ajax requests.
Cheers
Lasse
Re: http/2
Ok, thanks! I hope to find the time to test it in the near future. :-) 2016-03-02 17:30 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>: > That's correct! > > Honestly I haven't checked the network traffic to verify that all or at > least several resources are served in the same connection but I have > verified that both Google Chrome and Firefox report that the site is HTTP/2 > enabled. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Wed, Mar 2, 2016 at 5:16 PM, Lars Törner <lars.tor...@gmail.com> wrote: > > > Hi Martin, > > > > that sounds interesting! > > > > So what you´re saying is that if the server where the wicket-applictation > > is deployed supports http/2 then wicket itself doesn't need any > > wicket-specific-extension to work. And that, for example, all components > > css/javascript-resources of a page will be fetched over one multiplexed > > connection. > > > > Cheers > > Lasse > > > > > > > > 2016-03-02 16:40 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>: > > > > > Hi Lasse, > > > > > > I have successfully tested a Wicket application (my WebSockets demo > app) > > on > > > Tomcat 9.0.0.M1/M2/M3 ( > > > https://twitter.com/mtgrigorov/status/665916977957982208) with HTTP/2. > > > Currently there is a discussion at Tomcat dev@ mailing list about > > porting > > > back the changes to Tomcat 8.5.0. 8.5 will be what 9.0 is now without > the > > > Servlet 4.x APIs because Servlet 4.x release date is far in the future. > > > > > > I have also was able to run Wicket app with Jetty SPDY impl in the > past. > > > > > > I haven't tested with WildFly 10 but I don't expect any problems from > > > Wicket side. > > > Please let us know if you face any issues and we will investigate them! > > > > > > Thanks! > > > > > > > > > Martin Grigorov > > > Wicket Training and Consulting > > > https://twitter.com/mtgrigorov > > > > > > On Wed, Mar 2, 2016 at 4:31 PM, Lars Törner <lars.tor...@gmail.com> > > wrote: > > > > > > > Hi, > > > > > > > > I have some (naive?) questions: > > > > > > > > - Isn't it time to think about wicket and http/2? > > > > - Must we wait for javaee8/servlet 4.0 and then wait for a new > version > > of > > > > wicket that supports it? > > > > - Is it possible to implement an extension to support http/2 in > wicket? > > > > - Is it a huge effort to make this happen? > > > > > > > > I think (most of?) the latest versions of the major browsers support > > > > http/2, Wildfly supports http/2 server side with undertow... etc. > > > > Known implementations of HTTP/2: > > > > https://github.com/http2/http2-spec/wiki/Implementations > > > > > > > > I have read Martin G:s comment from a year back about this (see > below), > > > but > > > > not found anything else... maybe there already is an ongoing > discussion > > > > about this? > > > > > > > > Cheers > > > > Lasse > > > > > > > > Martins reflections about http/2 and servlet 4.0 > > > > I'm afraid it is too early for this. We can make sure Wicket works > fine > > > in > > > > a container supporting those but it is too early to require that. > > Servlet > > > > 4.0 is still in design process. Apache Tomcat didn't started > > implementing > > > > any features from it. I am not sure about the status in Jetty. I know > > > that > > > > Undertow (the web container for JBoss Wildfly) supports HTTP 2.0 but > I > > > > haven't heard of any Servlet 4.0 features. It will take us some time > to > > > > release 8.0.0 but I think it will be too > > > > early to require Servlet 4.0 even then. > > > > > > > > > >
Re: http/2
Hi Martin, that sounds interesting! So what you´re saying is that if the server where the wicket-applictation is deployed supports http/2 then wicket itself doesn't need any wicket-specific-extension to work. And that, for example, all components css/javascript-resources of a page will be fetched over one multiplexed connection. Cheers Lasse 2016-03-02 16:40 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>: > Hi Lasse, > > I have successfully tested a Wicket application (my WebSockets demo app) on > Tomcat 9.0.0.M1/M2/M3 ( > https://twitter.com/mtgrigorov/status/665916977957982208) with HTTP/2. > Currently there is a discussion at Tomcat dev@ mailing list about porting > back the changes to Tomcat 8.5.0. 8.5 will be what 9.0 is now without the > Servlet 4.x APIs because Servlet 4.x release date is far in the future. > > I have also was able to run Wicket app with Jetty SPDY impl in the past. > > I haven't tested with WildFly 10 but I don't expect any problems from > Wicket side. > Please let us know if you face any issues and we will investigate them! > > Thanks! > > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Wed, Mar 2, 2016 at 4:31 PM, Lars Törner <lars.tor...@gmail.com> wrote: > > > Hi, > > > > I have some (naive?) questions: > > > > - Isn't it time to think about wicket and http/2? > > - Must we wait for javaee8/servlet 4.0 and then wait for a new version of > > wicket that supports it? > > - Is it possible to implement an extension to support http/2 in wicket? > > - Is it a huge effort to make this happen? > > > > I think (most of?) the latest versions of the major browsers support > > http/2, Wildfly supports http/2 server side with undertow... etc. > > Known implementations of HTTP/2: > > https://github.com/http2/http2-spec/wiki/Implementations > > > > I have read Martin G:s comment from a year back about this (see below), > but > > not found anything else... maybe there already is an ongoing discussion > > about this? > > > > Cheers > > Lasse > > > > Martins reflections about http/2 and servlet 4.0 > > I'm afraid it is too early for this. We can make sure Wicket works fine > in > > a container supporting those but it is too early to require that. Servlet > > 4.0 is still in design process. Apache Tomcat didn't started implementing > > any features from it. I am not sure about the status in Jetty. I know > that > > Undertow (the web container for JBoss Wildfly) supports HTTP 2.0 but I > > haven't heard of any Servlet 4.0 features. It will take us some time to > > release 8.0.0 but I think it will be too > > early to require Servlet 4.0 even then. > > >
http/2
Hi, I have some (naive?) questions: - Isn't it time to think about wicket and http/2? - Must we wait for javaee8/servlet 4.0 and then wait for a new version of wicket that supports it? - Is it possible to implement an extension to support http/2 in wicket? - Is it a huge effort to make this happen? I think (most of?) the latest versions of the major browsers support http/2, Wildfly supports http/2 server side with undertow... etc. Known implementations of HTTP/2: https://github.com/http2/http2-spec/wiki/Implementations I have read Martin G:s comment from a year back about this (see below), but not found anything else... maybe there already is an ongoing discussion about this? Cheers Lasse Martins reflections about http/2 and servlet 4.0 I'm afraid it is too early for this. We can make sure Wicket works fine in a container supporting those but it is too early to require that. Servlet 4.0 is still in design process. Apache Tomcat didn't started implementing any features from it. I am not sure about the status in Jetty. I know that Undertow (the web container for JBoss Wildfly) supports HTTP 2.0 but I haven't heard of any Servlet 4.0 features. It will take us some time to release 8.0.0 but I think it will be too early to require Servlet 4.0 even then.
Re: Generate css from less for package resources at runtime.
Thanks for your quick answer Martin! We will look into your suggestions and get back to you if we have more questions! 2016-03-01 11:49 GMT+01:00 Martin Grigorov <mgrigo...@apache.org>: > Hi Lasse, > > I think the easiest would be to save the generated CSS in memory, e.g. in > YourApplication. > Once you receive an update from the other system you should just delete the > cache (entry). I guess you will have to use read lock when serving the > response and write lock when updating it. > Wicket uses AbstractResource#dataNeedsToBeWritten() > < > https://github.com/apache/wicket/blob/ffa34c6bfbd2ccd8340e23ff1601edd3e0e941d6/wicket-core/src/main/java/org/apache/wicket/request/resource/AbstractResource.java#L433 > > > method to decide whether the client/browser has the latest version. I.e. > when the browser makes a request for the CSS you should first check whether > there is a cached entry for this CSS file. If there is no such then > generate it, save it in the cache and serve it back. If there is such cache > entry then let Wicket check its last modification time against the request > header value for 'If-Modified-Since'. > > Additionally you may want to pre-build the CSS resources at application > start time, or even preserve the current build-time solution, so it is > faster for the first users of the application before any changes in the > variables. > I've had an issue with similar setup in the past - we were using CDN > (Akamai) and their request timed out while waiting for the Less > compilation. For requests from normal browsers this shouldn't be a problem > though. > > You may also check Wicket Bootstrap Less > <https://github.com/l0rdn1kk0n/wicket-bootstrap/tree/master/bootstrap-less > >. > It is a module of Wicket-Bootstrap project but could be used without the > other modules. > It provides most of the features you need. You just need to see how to plug > the update of the variables. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Tue, Mar 1, 2016 at 10:45 AM, Lars Törner <lars.tor...@gmail.com> > wrote: > > > Hi! > > > > We would like to be able to set new colors in our gui at runtime, i.e. > > change the theme. > > We use less on component basis. To day we compile the less files to css > at > > buildtime and these becom packacke resources. > > > > Now we would like to change the colors by altering the appropriate > > less-variables. We want to set the colors (just values as - themeColor = > > #00) in our legacy application. Our web app lives in another > > servletcontainer than the legacy applicaton, so one apporach is to fetch > > the new colors by REST (for example check for new colors once a minute) > and > > get them as json in our wicket-web-app. > > > > Now we're thinking of using dynamic resources. i.e. do not compile the > > less-files at build-time, instead generate css-files fom the less files > > (hooking in a less-preprocessor) per component at runtime when requested. > > > > We don't want to generate the css-resource and send it to the client if > > it's already cached in browser and not updated on server. > > We don't want to generate the css if it has already been done for the > > component and new colors hasn't been set, i.e once a dynamic resource is > > generated, a cached version should be given as response for all clients > > that request the component. > > > > Now the question is if the right way to do this is by implementing a > > dynamic resource by extending AbstractResource and to cache the css > (output > > a css-file on disk?, cache in application?) when once generated? > > > > Any drawbacks? Performance issues? Is there a better way to do it? > > > > Cheers > > Lasse > > >
Generate css from less for package resources at runtime.
Hi! We would like to be able to set new colors in our gui at runtime, i.e. change the theme. We use less on component basis. To day we compile the less files to css at buildtime and these becom packacke resources. Now we would like to change the colors by altering the appropriate less-variables. We want to set the colors (just values as - themeColor = #00) in our legacy application. Our web app lives in another servletcontainer than the legacy applicaton, so one apporach is to fetch the new colors by REST (for example check for new colors once a minute) and get them as json in our wicket-web-app. Now we're thinking of using dynamic resources. i.e. do not compile the less-files at build-time, instead generate css-files fom the less files (hooking in a less-preprocessor) per component at runtime when requested. We don't want to generate the css-resource and send it to the client if it's already cached in browser and not updated on server. We don't want to generate the css if it has already been done for the component and new colors hasn't been set, i.e once a dynamic resource is generated, a cached version should be given as response for all clients that request the component. Now the question is if the right way to do this is by implementing a dynamic resource by extending AbstractResource and to cache the css (output a css-file on disk?, cache in application?) when once generated? Any drawbacks? Performance issues? Is there a better way to do it? Cheers Lasse
