Hi Wolfgang, I have been following your thread with interest. I think that many users who are implementing "portal-like" functionality with magnolia will face your problem. I don't think I can give you a solution, but I would like to share some thoughts:
1. Generally we have found that using very "generic" webservice interfaces tends to cause problems. If the job of rendering a page requires many SOAP (or REST) calls, performance suffers, as you have noticed. So if the "generic" webservice requires you to make multiple calls like (hypothetically) getList() followed by getRecordById() followed by getDetailById() then the calls always need to be chained, and the latencies add up to impact performance noticeably. We changed our backend services to provide "application-specific" interfaces, so that each page can be rendered after only a single SOAP-call. So for example getDataForOverviewPage() would get all the data (list, record and detail) needed for that page-rendering. Usually it isn't much work to provide these application-specific interfaces since they can normally be composed out of the existing generic methods on the server side. 2. For a portal that speaks to different back-end services for the same page-rendition, #1 is not really a practical solution. Here we tend to prefer AJAX. I know you mentioned that you would prefer to avoid AJAX, but I am wondering why? We have found that going the AJAX route generally results in an improved user experience: the "frame" of the page arrives quickly, meaning the user gets immediate feedback, and you can provide "spinners" to show where more data is being loaded via AJAX. Users are more willing to wait for the data if "something happens" in the meantime. As a "recipe" for creating these kinds of pages we have found the following useful: - for the components that contain the portal data, create 2 variants of the component-template: the "normal" variant and the "ajax" variant. - the normal variant simply renders the frame, a spinner and the javascript for the AJAX call - the ajax call then uses "direct paragraph access" to request only the component node (not the whole page), and it requests the ajax variant of the template. So if the page is "/mysite/mypage.html" the URL for the ajax call might look something like this: "/mysite/mypage/myarea/mycoolajaxcomponent.ajax" - the ajax variant of the template then does the work of calling the backend service, rendering the data to a html-snippet, and returning this snippet to the client. In this way you get the multi-threading you need "for free", based on the fact that each component is called in its own request by the client browser, and you get a better user experience, as the basic page frame loads quickly. Of course there may be reasons why you cannot go the AJAX way. In that case I fear you have a more difficult road ahead of you. Converting the rendering to multi-threaded rendering will not be so easy, I fear. The places to start looking are in the module "magnolia-rendering", in particular the classes "AbstractRenderingEngine" and "ModelExecutionFilter", I think. I think the basic problem you will run into is that the rendering of areas is triggered by the rendering of the surrounding page, and the rendering of the components is triggered by rendering the areas. In other words, it is rendering of the template scripts themselves that trigger the rendering of the parts contained in those scripts. To parallelize this you would have to change the way this works: - either you would have to do 2 passes over the content, first to parse the scripts without actually rendering, but just finding all the model classes that will be called. Then execute the model-classes (in parallel), and then run the scripts again but actually render, using the pre-executed models. - or you would have to in some way spawn threads each time you hit an execute method, and then insert the content into the output stream at a later time. You might be able to do that with a kind of filter that does the following: before rendering, create a wrapper around the response output stream. When you hit an model execute method, spawn a thread to call the backend service, and render a "placeholder" into the output. In a filter that acts after the whole rendering process, collect the data from all the asynchronous calls, and then render that data into the output replacing the placeholders you created before. An expert from Magnolia Inc might have more pointers for you on this. In any case, I would be very interested to find out which solution you decide to go for, and what your experiences with that will be. Regards from Vienna, Richard -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Im Auftrag von Wolfgang Wachsmuth (via Magnolia Forums) Gesendet: Mittwoch, 05. September 2012 09:59 An: Magnolia User List Betreff: [magnolia-user] Re: Request order per component Hi, I still really would love to put the rendering process of a template into a thread. Can someone give me a hint where to start best? I am using Blossom maybe that helps. According to the graphics shown here http://documentation.magnolia-cms.com/technical-guide/request-processing-and-filters.html there should be something like an master aggregator calling each renderer of a template. Thanks for your advice Wolfgang -- Context is everything: http://forum.magnolia-cms.com/forum/thread.html?threadId=af619dda-0a01-4700-81d0-a93562ed49c2 ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]> ---------------------------------------------------------------- ---------------------------------------------------------------- For list details, see http://www.magnolia-cms.com/community/mailing-lists.html Alternatively, use our forums: http://forum.magnolia-cms.com/ To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
