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 <[email protected]>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? >
