Is there an estimated time frame for when we might expect a “for reals” 4.2
release that would be ready for production use? Exciting stuff!
Rebecca M. Fountain
Applications Developer
Tacoma Community College
Information Systems
Ph: 253.566.5106
From: bounce-38940926-96632...@lists.wisc.edu
[ma
Hi,
So I think we really want these two worlds to collide in some way. I
absolutely agree that uPortal should be a client side app that ajaxies
back to the uPortal server.
Having special portlet modes/window states that allow portlets to
contribute plugins to the portal's client side app see
?I'm currently attempting to cut a release of the bookmarks portlet. I'm
getting these errors:
[INFO] Missing header in:
/home/vertein/git/BookmarksPortlet/src/main/java/edu/wisc/my/portlets/bookmarks/domain/Folder.java
[INFO] Missing header in:
/home/vertein/git/BookmarksPortlet/src/main/
Anthony,
All that's fair.
I'm coming at it a bit sideways in that I'm thinking about how to add
server-generated dynamic content to
https://github.com/UW-Madison-DoIT/angularjs-portal , of course.
Currently when our Beta users dive into a portlet, they bop over to our
forked-from-Respondr theme
Hi,
A few years ago this sounded like a possible good way forward. These
days I'm less convinced by this. These days I like to develop Portlet
UIs in much the same way I develop servlet app UIs; I deliver the client
side application which calls back to its portlet origin for data via
ajax. In
uPortal developers,
Has anyone given thought to what it would look like to, at the framework
layer, make all the portlet markup render down to the browser
asynchronously?
Individual portlets have been developed to asynchronously render their
content, first rendering a loading... experience and th
I suggest making this about two things.
One thing is the API between portal and portlets.
Thing 2 is how the portal implements fulfilling that API.
I think what's going on here is uPortal exposed an API whereby portlets
could get the theme name
request.getProperty(themeNameProperty);
and that u
We would want the desktop view if they were on a desktop. However, since
respondr is also used for mobile, if on a mobile phone/tablet we would want
them to see the mobile view of that portlet.
The best solution would be to have a portlet that is responsive like the
framework, but just trying