Lets see if I can answer some of these questions. For 'better URLs':- The requirement behind this is actually a search-engine friendly guest view in uPortal. This will require the current tab and some window state information to be tracked via the URL instead of in a server-side object. This is possible just using layout ids to some extent but it would be nice if we could avoid synthetic IDs in the URLs as much as possible as they may change. - To get this nicer IDs I was planning on building on the work that was done to allow named access to tabs via a fname like attribute. This protects the URL from having to deal with full tab names which may contain multi-byte characters and may not be unique for a user. - Your point about tabs/columns/channels versus simply folders in the raw layout is a good one. With the added URL processing and generation steps in uP3 changing the URL format to accommodate a different structure XSL should only require modifying a few (two?) classes that handle the generation and parsing of the base portal URL - Restricting both tab and channel fnames to valid URI characters seems like a reasonable restriction as these are meant to be human-readable unique identifiers for portal objects to allow for direct access like this without exposing the actual synthetic id.
For the DETACHED WindowState:- The use-case here is a portlet that pops open search results in new windows. These results would be able to be further refined by the user via controls in the pop-up window while the user can still interact with the original portlet on the tab. - The portlet object model does support the idea of multiple PortletWindows into one subscribed PortletEntity, this scopes the request parameters, WindowState and PortletMode from each instance the user interacts with while the session and preferences are still shared.
I hope that helps clarify a bit. I'll update the jira issues later today. -Eric Dustin S. wrote:
I like the idea of the URL's. I think "User Friendly URL's" would provide for a much cleaner look if anything. They may help with the analytics of things too... I'm not sure I understand the second JIRA, what would be the uses for it? On Wed, May 7, 2008 at 3:05 PM, Cris J Holdorph <[EMAIL PROTECTED]> wrote:What's the motivation behind the 'human readable' part? Do you expect, (as a student) I can read the URL, that at some point in the future, I'll simply type in http://myportal.myuniv.edu/supercooltab/someportlet in my address bar, because I remember I have a "supercool" tab and I put "some" portlet on that tab? Or is the motivation instead, something different? I'm not sure what human readable URL means if it's not the above use case. I think the first half of the JIRA makes sense, but wouldn't describe that as "human readable" url. The aspect of being able to control which tab/portlet is being displayed and what the portlet window state was with altering the URL, I think is interesting. But what part of those features requires it to be 'human readable'. Also, your second half of the jira, which Mark is commenting on, about tab/page/column doesn't seem to match up with what you described in the first half. ---- Cris J H Mark Boyd wrote:Eric, Recall that uportal infrastructure sees layouts as folders and channel nottabs and columns. So if anyone ever does decide to put together a non tab/column layout this approach (like the paging that Susan B. started looking at a couple years ago) wouldn't make sense for these enhanced layouts.Secondly, keep in mind that tab labels can be internationalized. (Or couldbe if we ever roll the Luminis approach from the sandbox into baseline.) So you may well have mult-byte characters in those tab names. Perhaps we need to add a new friendly URL name to folders before such a folder (tab) is made available via such URLs. Or it can be mandatory with the caveat that its content must only consist of characters support by the URI spec. Ditto for channels.Food for thought. Mark On Wed, May 7, 2008 at 1:55 PM, Eric Dalquist <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote:We have a portlet project coming through the pipes here that is going to require some new uPortal functionality. In an attempt to do this "the right way" I've described both features in uPortal Jira issues and plan on trying to implement them in uPortal directly then merge the features into our local version. I'd like to get other developers feedback on that approach and on ideas around these features. The first is human-readable / search engine friendly URLs: http://www.ja-sig.org/issues/browse/UP-2045 The second is a detached WindowState for portlets: http://www.ja-sig.org/issues/browse/UP-2046 -Eric -- You are currently subscribed to [email protected] as:[EMAIL PROTECTED]To unsubscribe, change settings or access archives, seehttp://www.ja-sig.org/wiki/display/JSG/uportal-dev--You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
smime.p7s
Description: S/MIME Cryptographic Signature
