Re: Portlets on Tapestry 4.1
You don't need the @Script processing things to include scripts. (Esp with the AjaxShellDelegate I pointed out.) The default configuration for using this delegate is currently encapsulated in http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/java/org/apache/tapestry/html/Shell.jwc?view=markup The gist of it is that it's a simple IAsset resource. If this is going to cross boundaries into the portlet world I should probably go a bit farther by doing a composition of components, possibly providing a small generic @IncludeScript sort of component that will allow IAsset style context path statements. (Since you will already have dojo/tapestry in your classpath this would be the preferred method). I probably need to think about this some more to be sure I don't screw it up. As far as including/not including scripts in the head, I think it will work fine in either scenerio. (Not sure if caching is handled the same in either though?) Either way it's not very hard to include js packages in the document head (portlet specs be damned! no just kidding of course...), take a look at the tapestry.loadScriptFromUrl function here: http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/js/tapestry/core.js?view=markup A combination of setting the assets up like Shell.jwc does in the first url I gave you + using AjaxShellDelegate should temporarily solve your problem until a more permanent solution is found/designed. (I would probably create a very simple component to wrap the ShellDelegate, sort of like @Shell, only you won't need to output any actual html content. ) On 8/2/06, Epstein, Ezra <[EMAIL PROTECTED]> Still, for those odd cases where we control the entire page, how can I link in the .js and other stuff. I don't mind, for example, having it part of all our portal pages. I.e., is there a way to statically link to the relevant .js files as-is that would work, or must parts be processed by the Script-processing tools provided by Tapestry? Thanks, Ezra Epstein -Original Message- From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 02, 2006 6:24 PM To: Tapestry users Subject: Re: Portlets on Tapestry 4.1 Ok, I think I'm a little out of my element here. I can't honestly say I understand the day to day sort of development patterns that people use with Tapestry portlets. Is there an equivalent idea to something containing each page? (ie something that handles stylesheets/ etc ?) Rather than trying to pull what I think is the right way out of my arse, can the community help me out a little here? ;) I do have one specific IRender "bean" sort of class that the @Shell component delegates the work of rendering the tapestry/dojo/browser debug configuration includes to. It can be found here: http://tapestry.apache.org/tapestry4.1/tapestry-framework/apidocs/org/apache/tapestry/dojo/AjaxShellDelegate.html . If the functionality this provides sounds somewhat palatable I can try refactoring the naming a little bit to eliminate the verbage of "Shell". (I'd like to remove AJAX as well...) On 8/2/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > Hmm...Good question. I will answer with a documentation page. > > > On 8/2/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote: > > > > We want to move to 4.1 for our portlets. Reading up I find: > > > > "By default, the Shell component will include the core dojo > > javascript object dojo.js, as well as the new core Tapestry > > javascript object - core.js. This means that you don't have to worry > > about how to include dojo or Tapestry javascript on any of your > > pages, they will already be available." > > > > Of course, that's not the case for portlets. > > > > Is there a simple step-by-step how-to for those of us who don't > > (can't) use the Shell component. > > > > Thanks, > > > > Ezra Epstein > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Jesse Kuhnert > Tacos/Tapestry, team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
RE: Portlets on Tapestry 4.1
I need to go double-check the portlet spec, but my current understanding is that the portlet spec does not provide any way for portlets to contribute to the head content of a page! (Does this sound like a common occurrence in JCP "standards"?) The Appendix E of the spec http://www.jcp.org/en/jsr/detail?id=168 is relevant here: Features Deferred to Future Releases The following are some of the features that would be considered in future versions of the Portlet Specification. The technical details of these features would be resolved by the 5 Expert Group of the corresponding JSR. * Portlet filters * Inter-portlet, event style, communication * Allow portlets to produce and influence markup outside of the portlet fragment Notice the very last one there. That kinda sums it up. (Some would say that, as a result, Portlet's a la this spec, suck.) Here are other relevant parts of the spec: Portlets do not have access to the following functionality provided by servlets: * Setting the character set encoding of the response * Setting HTTP headers on the response * The URL of the client request to the portal Portlets generating HTML fragments must not use the following tags: base, body, iframe, frame, frameset, head, html and title. Portlets generating XHTML and XHTML-Basic fragments must not use the following tags: base, body, iframe, head, html and title. Within their content, portlets may include elements that must be unique within the whole portal page. JavaScript functions and variables are an example of this The getNamespace method must provide the portlet with a mechanism that ensures the uniqueness of the returned string in the whole portal page. For example, the getNamespace method would return a unique string that could be prefixed to a JavaScript variable name within the content generated by the portlet, ensuring its uniqueness in the whole page. The getNamespace method must return the same value if invoked multiple times within a render request. Still, for those odd cases where we control the entire page, how can I link in the .js and other stuff. I don't mind, for example, having it part of all our portal pages. I.e., is there a way to statically link to the relevant .js files as-is that would work, or must parts be processed by the Script-processing tools provided by Tapestry? Thanks, Ezra Epstein -Original Message- From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 02, 2006 6:24 PM To: Tapestry users Subject: Re: Portlets on Tapestry 4.1 Ok, I think I'm a little out of my element here. I can't honestly say I understand the day to day sort of development patterns that people use with Tapestry portlets. Is there an equivalent idea to something containing each page? (ie something that handles stylesheets/ etc ?) Rather than trying to pull what I think is the right way out of my arse, can the community help me out a little here? ;) I do have one specific IRender "bean" sort of class that the @Shell component delegates the work of rendering the tapestry/dojo/browser debug configuration includes to. It can be found here: http://tapestry.apache.org/tapestry4.1/tapestry-framework/apidocs/org/apache/tapestry/dojo/AjaxShellDelegate.html . If the functionality this provides sounds somewhat palatable I can try refactoring the naming a little bit to eliminate the verbage of "Shell". (I'd like to remove AJAX as well...) On 8/2/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > Hmm...Good question. I will answer with a documentation page. > > > On 8/2/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote: > > > > We want to move to 4.1 for our portlets. Reading up I find: > > > > "By default, the Shell component will include the core dojo > > javascript object dojo.js, as well as the new core Tapestry > > javascript object - core.js. This means that you don't have to worry > > about how to include dojo or Tapestry javascript on any of your > > pages, they will already be available." > > > > Of course, that's not the case for portlets. > > > > Is there a simple step-by-step how-to for those of us who don't > > (can't) use the Shell component. > > > > Thanks, > > > > Ezra Epstein > > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Jesse Kuhnert > Tacos/Tapestry, team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Portlets on Tapestry 4.1
More importantly than that, we'd have a potential "situation" wrt ~other~ portlets also including javascript. It seems like something that you'd think would come up more often. I'd be interested in knowing if things like css/script includes have been addressed by anyone else in the portlet community? For example, the current delegate might optionally have to include a Compatibility checking sort of script to ensure that no other dojo or tapestry script librariers were already being included in the browser. If they were included we might then have to check versions and do "something" if they are found to be incompatible. (both dojo and tapestry include release version meta information in the js runtime, so we can write logic to check it fairly easily.) Thoughts ? On 8/2/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: Ok, I think I'm a little out of my element here. I can't honestly say I understand the day to day sort of development patterns that people use with Tapestry portlets. Is there an equivalent idea to something containing each page? (ie something that handles stylesheets/ etc ?) Rather than trying to pull what I think is the right way out of my arse, can the community help me out a little here? ;) I do have one specific IRender "bean" sort of class that the @Shell component delegates the work of rendering the tapestry/dojo/browser debug configuration includes to. It can be found here: http://tapestry.apache.org/tapestry4.1/tapestry-framework/apidocs/org/apache/tapestry/dojo/AjaxShellDelegate.html . If the functionality this provides sounds somewhat palatable I can try refactoring the naming a little bit to eliminate the verbage of "Shell". (I'd like to remove AJAX as well...) On 8/2/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > Hmm...Good question. I will answer with a documentation page. > > > On 8/2/06, Epstein, Ezra < [EMAIL PROTECTED]> wrote: > > > > We want to move to 4.1 for our portlets. Reading up I find: > > > > "By default, the Shell component will include the core dojo javascript > > object dojo.js, as well as the new core Tapestry javascript object - > > core.js. This means that you don't have to worry about how to include > > dojo or Tapestry javascript on any of your pages, they will already be > > available." > > > > Of course, that's not the case for portlets. > > > > Is there a simple step-by-step how-to for those of us who don't > > (can't) use the Shell component. > > > > Thanks, > > > > Ezra Epstein > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Jesse Kuhnert > Tacos/Tapestry, team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: Portlets on Tapestry 4.1
Ok, I think I'm a little out of my element here. I can't honestly say I understand the day to day sort of development patterns that people use with Tapestry portlets. Is there an equivalent idea to something containing each page? (ie something that handles stylesheets/ etc ?) Rather than trying to pull what I think is the right way out of my arse, can the community help me out a little here? ;) I do have one specific IRender "bean" sort of class that the @Shell component delegates the work of rendering the tapestry/dojo/browser debug configuration includes to. It can be found here: http://tapestry.apache.org/tapestry4.1/tapestry-framework/apidocs/org/apache/tapestry/dojo/AjaxShellDelegate.html . If the functionality this provides sounds somewhat palatable I can try refactoring the naming a little bit to eliminate the verbage of "Shell". (I'd like to remove AJAX as well...) On 8/2/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: Hmm...Good question. I will answer with a documentation page. On 8/2/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote: > > We want to move to 4.1 for our portlets. Reading up I find: > > "By default, the Shell component will include the core dojo javascript > object dojo.js, as well as the new core Tapestry javascript object - > core.js. This means that you don't have to worry about how to include > dojo or Tapestry javascript on any of your pages, they will already be > available." > > Of course, that's not the case for portlets. > > Is there a simple step-by-step how-to for those of us who don't (can't) > use the Shell component. > > Thanks, > > Ezra Epstein > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Re: Portlets on Tapestry 4.1
Hmm...Good question. I will answer with a documentation page. On 8/2/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote: We want to move to 4.1 for our portlets. Reading up I find: "By default, the Shell component will include the core dojo javascript object dojo.js, as well as the new core Tapestry javascript object - core.js. This means that you don't have to worry about how to include dojo or Tapestry javascript on any of your pages, they will already be available." Of course, that's not the case for portlets. Is there a simple step-by-step how-to for those of us who don't (can't) use the Shell component. Thanks, Ezra Epstein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
Portlets on Tapestry 4.1
We want to move to 4.1 for our portlets. Reading up I find: "By default, the Shell component will include the core dojo javascript object dojo.js, as well as the new core Tapestry javascript object - core.js. This means that you don't have to worry about how to include dojo or Tapestry javascript on any of your pages, they will already be available." Of course, that's not the case for portlets. Is there a simple step-by-step how-to for those of us who don't (can't) use the Shell component. Thanks, Ezra Epstein - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
