Hello Chris,
To make better decision about how to include js, the Portlet Bridge try to
use MARKUP_HEAD_ELEMENT_SUPPORT if the portlet container supported it.
See PortletPageResponseRendererImpl for more details
Liferay support the optionnal MARKUP_HEAD_ELEMENT so tapestry is able to
add a js file only once in a portal page.
Pluto is not supporting the MARKUP_HEAD_ELEMENT.
So we have no informations about what js is already included by another
portlet.
Two options are available,
1 ) Lets Tapestry include any js.
Dirty option that works for version < 5.4-beta4 thanks to the namespace
used by tapestry.js.
2) disable js inclusion on tapestry side and add all the js required
manually
to the portal page header (depend en portlet container)
François
2013/12/3 Chris Poulsen <mailingl...@nesluop.dk>
> Hi,
>
> I've been trying to get the tapestry5-portlet bridge up and running with
> the newest T5.4 previews, just to learn a little about the technologies.
>
> Basically each portlet corresponds to a page, so I see a lot of duplicate
> javascript in the portal pages (a set of scripts per portlet).
>
> The loading of all these duplicated javascript files does not seem to
> suffer much, as they are cached. But the ModuleManagerImpl defines a page
> variable called "require". When "require" is defined multiple times; things
> break down (looks like a race condition where the variable enters
> un-initialized state here and there).
>
> The fix I came up with to ensure that "require" is only defined once (all
> occurrences seem to have same configuration) is:
>
> diff --git
>
> a/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/javascript/ModuleManagerImpl.java
> b/tapestry-core/src/main/j
> index 26cb24c..9c540b5 100644
> ---
>
> a/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/javascript/ModuleManagerImpl.java
> +++
>
> b/tapestry-core/src/main/java/org/apache/tapestry5/internal/services/javascript/ModuleManagerImpl.java
> @@ -100,7 +100,7 @@ public class ModuleManagerImpl implements ModuleManager
> }
>
> // This part gets written out before any libraries are loaded
> (including RequireJS).
> - return String.format("var require = %s;\n",
> config.toString(compactJSON));
> + return String.format("if(typeof require == 'undefined'){var
> require = %s;}\n", config.toString(compactJSON));
> }
>
> private JSONObject buildBaseConfig(Map<String,
> JavaScriptModuleConfiguration> configuration, boolean devMode)
>
>
> Also I'm seeing multiple class to "t5/core/pageinit.js" with different
> parameters, but it does not seem to break anything obvious.
>
> I'm not too familiar with requirejs, so does anyone have some ideas on how
> to be more clever when it comes to handling the many similar js files being
> requested?
>
> Also can anyone pitch in on the page initialization script being called
> multiple times with different params, will the portlet pages initialize
> successfully in all cases?
>
> Is it a viable strategy to attack things in the js layer? Or are there some
> tricks on the portlet container side of things that can be used to help the
> portlet bridge adjust tapestry to make better decisions about things like
> js includes?
>
> All input is appreciated ;-)
>
> --
> Chris
>
