Re: [uportal-dev] Resource Server as its own 1st-class project

[Eric Dalquist]

Gary,

It is a separate project: https://www.ja-sig.org/svn/sandbox/resource-server/

-Eric

Gary Weaver wrote:

It has been submitted for incubation as its own project. There are release artifacts in the Jasig maven repository tagged 1.0.0-RC2. The area it needs help with right now is documentation, examples of the Maven dependency configuration for using the taglib and where to find the WAR file. Also some documentation on how to request new resources be added to the project.

Does anyone else think that it would be a good idea to move to split off the uPortal 3.1 resource server as a separate project and download from uPortal hosted by JASIG?

http://www.ja-sig.org/wiki/display/UPC/Resource+Server







Thanks,
Gary

-------- Original Message --------

Date:     Tue, 28 Apr 2009 10:04:12 -0400
From:     Gary Weaver <gary.wea...@duke.edu>
Reply-To:     jasig...@lists.ja-sig.org
To:     jasig...@lists.ja-sig.org








Gary


Eric Dalquist wrote:

It seems like it would be a good idea if people would start using it for web development (especially for JSR-168/JSR-286 portlet development) in such a way that they could have multiple webapps or portlets rely on the same versioned resource bundle for similar functionality. For example, javascript bugs (like browser incompatibilities that may have been missed in testing) could be fixed in one place and not require alteration of many custom portlets that use similar functionality. So if I were writing a portlet or any other webapp, you could just say in the documentation to configure that portlet/webapp to point at the resource server (webapp) wherever it is hosted, and deploy the X and Y packages to the server that the portlet/webapp depends on. It would probably take some work to get it there, but I think that more widespread adoption might be key to its success and use. If you think this is a bad idea, then how do you propose that the issue of duplicated javascript be solved? (and note that having portlets, etc. poms depend on the same dependencies that bundle resources means having to debuild and redeploy a number of portlets, which is more disruptive and difficult than just deploying resource bundles separate from portlets.) Subject: Re: [jasig-ue] recommended way of sharing javascript between portlets References: <49f1f167.6050...@duke.edu> <2b938a27bb91494ea4223733c3da13fc2d53caa...@arborexch01.utorarbor.utorad.utoronto.ca> <28648_1240604099_zzg0t38drjkgn.00_49f21d9d.2050...@duke.edu> <49f63429.2080...@doit.wisc.edu> <8860_1240925657_zzg0t7q252qu4.00_49f705c9.3040...@duke.edu> <49f70928.9000...@doit.wisc.edu> Could it be offered as a separate download on its own project site in JASIG? That would be the best, because then those writing JSR168/JSR286 portlets could just include in the install documentation that the portlet by default expects to be using the resource server. That those using other portals besides uPortal could use it also, but more importantly, people would be more likely to use it since they wouldn't be as tied to uPortal (since they would need download uPortal to get the resource server webapp out of it). Also, if the resource server was useful to others outside of just portlet development, they could use it also. Oops- I totally misunderstood about the references in that page to web.xml meaning the resource server webapp's web.xml. BTW- is there a portlet archetype hosted by JASIG or anyone else? (I know that is off-topic, but while on the subject...)

It is a stand-alone webapp, all you need to do is deploy the WAR along side whatever webapp you want to use it with.

-Eric

Gary Weaver wrote:

More examples would be great, usage in a static page would simply reference the ResourceServer file explicitly in the page, ex: */ResourceServingWebapp/rs/jquery/1.3.1/jquery-1.3.1.js* With the catch that you're dependent on the ResourceServingWebapp being available then. This isn't something that is used as an archtype for a project, perhaps we need to document that a bit better. You deploy the ResourceServingWebapp webapp in your container and then there is a JAR you include in your webapp to allow you to use the tag library. Thats all, nothing else special about your webapp is needed. uPortal 3.1 doesn't even bother with the tag library. It just references files under /ResourceServingWebapp explicitly and it is a required webapp to be deployed alongside uPortal.

Eric,

That's perfect! :) !!!

It would be even better if it were available as a standalone resource server that could be used for older versions of uPortal and other portal servers (maybe make it a separate product, but include it with uPortal 3.1 and up). And the documentation is great! If you could add some more copy/pasteable example code to use for config of portlets, etc. in http://www.ja-sig.org/wiki/display/UPC/Using+the+Resource+Server that would help people get started even faster. (And maybe add that a Maven 2 archetype so that portlet developers could easily use it in new uPortal portlets, with some docs on how to do that in a portlet development section of the jasig wiki.)

It would also be awesome to provide a description of how it might be used in static/non-JSP pages (if possible) (on http://www.ja-sig.org/wiki/display/UPC/Using+the+Resource+Server ). For example, it might be used in static pages, templates, or if someone were to write a uPortal bridge and ActiveRecord model for Rails Portlet ( http://rails-portlet.rubyforge.org/overview.html ) then possibly even Rails portlets would be supported, which might open up uPortal portlet development for Ruby developers, like some of those on our team at Duke. (I would really like to help with the bridge/model, but it might be a while considering I'm already way behind in my obligation to some portlets in sandbox, we haven't upgraded to 3.1 yet, and we're cross training (pair programming) on our other apps now so that developers can swarm development on different apps.)

:)

Gary


Eric Dalquist wrote:

Thanks again so much for sharing that! 3.1 seems to be quite the release!

Perhaps the Resource Server included with uPortal 3.1 can fill this role? Take a look here for more info: http://www.ja-sig.org/wiki/display/UPC/Resource+Server

-Eric

Gary Weaver wrote:

Jacob,













Then in each portlet, it might specify.


...




Thanks,
Gary


Jacob Farber wrote:

As for the last thought I had below, I was just wondering whether as one option we might work with you to add functionality to the FSS (even though it is very minor, and may not be appropriate) to have: * the ability to have an arrow next to text that you'd click on to expand or hide a div with fade in/out affect. * the ability to have tabs on left side of a portlet that would change the content to the right of those tabs via show/hide divs (with fade in/out effect) with multiple layers of divs (one for each left tab). (maybe could be possible extension of .fl-tabs-* I think, although I have *no* experience with using FSS, and we're using uP 2.5.3, but am just looking at the FSS API and thinking eventually we might upgrade) However, the other approach I was thinking of would involve a way of versioned resource bundles (VRB's) seperate from the skins/themes that would contain packages of javascript, css, images, and perhaps other resources. The way I'd see it working is that the portlet would have a dependency on a certain version of the VRB (or more than one) and although it could be placed in any location chosen by the portal implementation, the portal would make these resources available in a non-portal specific way. For example, lets assume that were a few portlets that all depend on a VRB that includes functionality similar to what I described in the previous email to show/hide divs via "More/Less" text that changed along with arrow pointing down (for more) or up (for less). Let's call it "showhide" and say its version is v1.0.0. This VRB could (per jar and war tradition) be a zip compressed file called "showhide-1.0.0.vrb". It might be composed of the files excellent.js, stupendous.js, down.png, up.png, some default.css that can be overridden (using knowledge of CSS specificity? or something else?) in the skin/theme. Somehow the VRB package is deployed to some location accessible by the user's browser. Maybe the default would be for them to be hosted in a known path in uPortal webapp and deployable via ant task or similar, but it could also be deployed via other means and hosted on a separate server. <script type="text/javascript" src="<%=request.getPortalContext().getProperty('vrbPath')%>/showhide/1.0.0/js/excellent.js"></script> <script type="text/javascript" src="<%=request.getPortalContext().getProperty('vrbPath')%>/showhide/1.0.0/js/stupendous.js"></script> <style type="text/css">@import url(<%=request.getPortalContext().getProperty('vrbPath')%>/showhide/1.0.0/css/defaultstyles.css);</style> (Note: portal context may/may not be appropriate to use to store the relative or absolute URL path of the VRB. not sure what would be best, although I'd vote for something not requiring a newer version of Pluto.) and the image, font, layout, etc. of the show/hide could be specified in CSS in such a way that it would be overridable in the skin/theme, and the text for any messages would probably need to be specified in the portlet. The resources could also be used by the portal structural stylesheet and any other stylesheet, jsp, resource, etc. although you might need a different way of feeding in the relative or absolute URL path of the resources if done outside the portlets.

Hi Gary,

Thanks
Jacob
________________________________________
From: Gary Weaver [gary.wea...@duke.edu]
Sent: Friday, April 24, 2009 1:05 PM
To: jasig...@lists.ja-sig.org


Hey,

(I'm posting this in portlet-dev and jasig-ue, because I don't know
where it belongs...)


then it uses script.aculo.us/prototype to do the Effect.Appear which

and "More".


two divs that each have that appear/fade functionality.

And we have another portlet (first year checklist) that has somewhat

layers with side tabs and content area to the right of the tabs.

Recently we found an incompatibility in the javascript with some

of the portlet to something else external to the portlet, and this
javascript functionality is so integral I don't think it fits the

that behavior, it wouldn't work for skins that others had written.)

So a few questions:


the intention is to share that portlet in different environments via
JASIG, etc.) or is it acceptable/is there a standard place to keep

perhaps be overriden in skin) in uPortal itself?

* Is there is a standard way to share javascript between portlets in

standard way)."

Note that we currently have shared resources like images, yui,
prototype, ... served by the uPortal app itself, and we know that we

we did there (iirc), but I'm just curious whether there is a JASIG

that would also be fit for sharing with the uPortal community.


fluid skinning system, even though it is rather simple, although I'd
probably need help in doing that.

Thanks in advance,

Gary

--

Could you elaborate on your last thoght below- what functionality exactly are you thinking of? Some sort of asset sharing? Subject: [jasig-ue] recommended way of sharing javascript between portlets We have a few portlets that are sharing similar code to do a show/hide div, where typically there is a down arrow with "More" next to it and changes the text and icon to up arrow with "Less" and when you click on that it does an Effect.Fade and then resets to the original down arrow We also have a portlet that has different text next to the arrows and similar functionality except that it is fading and appearing multiple browsers and now are having to change it in multiple portlets. I'd like to abstract it out, however then that would tie the proper functioning concept of skin. (In other words, one of the portlets (TabbedRssPortlet) is shared in the JASIG sandbox, and if we made it rely on the skin for * Is it suggested to just keep javascript like this that is needed for proper functioning of the portlet in each portlet itself (especially if javascript and possibly related resources (like default icons that could uPortal that you might also want to give back to the JASIG community, in such a way that we could say "this portlet (shared to JASIG community) relies on X library which can be found here and installed this way (in a could put the javascript to share between our portlets in each skin as suggested way of sharing javascript and other resources between portlets Maybe such functionality would be a good candidate for inclusion in the You are currently subscribed to jasig...@lists.ja-sig.org as: jacob.far...@utoronto.ca To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/jasig-ue

smime.p7s
Description: S/MIME Cryptographic Signature