Re: A couple of questions after playing around with T5.4 and the tapestry5-portlet bridge
Hi Francois, As I wrote option 1 isn't too bad - The thing that worries me about that approach is the page specific initialization (pageinit.js) that is triggered N times instead of 1, with different parameters. - Will that always end up like expected and can we do anything to ensure that it does? Btw. how does MARKUP_HEAD_ELEMENT support work with the new module loading, where things are placed in the bottom of the page? I don't think option 2 brings much to the table, except a lot of things to manage manually. I would prefer if it was possible somehow to make requirejs (and the few other scripts included directly) loaded in a way that ensured that only a minimum of work was performed. It seems like requirejs is reset per portlet at the moment, so it "requires" its dependencies N times instead of just one. Anyway I think I was asking if it was possible to only define the "require" variable once per page - like outlined in my first mail, ecause then it seems that T5.4 would be in a pretty good state to handle the portlet case - And if the thing with multiple requirejs loads is a trivial change to fix, then it would be even better - but I don't know enough about requirejs to determine that (but that is not a deal breaker afaict). @Lance - I think you got it backwards, the tapestry portlet bridge is about being able to create portlets using tapestry, not about using portlets in a tapestry application. Also the portlet spec v2 seems like it is a pretty good answer if you are faced with the requirement to build a portal-like application (with things like user-configurable dashboards etc). -- Chris On Wed, Dec 4, 2013 at 2:18 PM, Lance Java wrote: > I've never understood why you would want portlets in a tapestry app. Apart > from maybe integrating with legacy code. > > What can a portlet give you that a tapestry component can not? >
Re: A couple of questions after playing around with T5.4 and the tapestry5-portlet bridge
I've never understood why you would want portlets in a tapestry app. Apart from maybe integrating with legacy code. What can a portlet give you that a tapestry component can not?
Re: A couple of questions after playing around with T5.4 and the tapestry5-portlet bridge
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
> 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 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
>
A couple of questions after playing around with T5.4 and the tapestry5-portlet bridge
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 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
