I was afraid of that ... maybe there will be a standardized mechanism in the
next Portlet specification. I wanted to change renderers based on user
privilege, but will have to look at another mechanism.
Thanks for the help Roy!
View the original post :
http://www.jboss.com/index.html?module=b
I started fighting with this problem last evening and (wouldn't you know it)
found the answer as soon as I posted.
You can control header-content injection in the JBoss specific portlet
descriptor (though I hadn't found it because I've been developing portable
portlets).
Is there some way to a
There is a comment in the generic layout reading:
|
|
This implies that you can add content between the and tags from within a
portlet (or more than one). Some of my portlets require extra JavaScript or
Style Sheet files and I need to be able to add them to the head element.
Unfortun
I read the two sticky topics above ("How to properly create JIRA issues" and
"READ ME BEFORE POSTING!", but was wondering whether you preferred to receive
new bug reports via a forum post (creating a bug if the problem is confirmed)
or directly with a bug ticket (which may be rejected if it's no
In a corporate environment, it would be more likely that you'd authenticate
against an LDAP server and remove the capability to "join" the Portal.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3939398#3939398
Reply to the post :
http://www.jboss.com/index.ht
That's the beauty of open-source software ... you can find the error and fix it
yourself.
In this case, the problem is in the
org.jboss.portal.core.portlet.management.actions.AddWindowAction file's
validateWindowName(FacesContext, UIComponent, Object) method. This method
checks for empty stri
I'm also just starting with JSF based portlets but can say that I'm not having
this problem. The Portal takes care of rendering everything with the correct
WindowState before your Portlet is actually called. If you click the
"maximize" control, the Portal rerenders the page with the appropriat
DISCLAIMER - I HAVE NOT TRIED THIS YET!
I have a similar requirement and have been considering ways to force the
Portlet to use the emptyRenderer for certain requests ... is this a sane way to
accomplish what jkancianic has asked?
View the original post :
http://www.jboss.com/index.html?module
Oooops, that should be "thanks for YOUR help:)". I also should have noted that
I'm using the bundled AS4.0.3/JBP2.2 package.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3937958#3937958
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posti
I searched around but couldn't find a direct answer to how the deployment
process differs when an EAR is exploded vs. unexploded. I have my first
portlet project patterned after the HelloWorldPortlet which behaves differently
depending on how it is deployed.
If I deploy it as an "Enterprise Ar
Within the .ear file, it will need to reside within the .war file. Web browsers look
for the file "/favicon.ico". Note the leading slash as this is the root context. If
you are using a /nukes context (as it is out of the box), I'm not sure this will work.
View the original post :
http://www.
11 matches
Mail list logo