voyent
Messages posted by: edykory  XML
Profile for edykory -> Messages posted by edykory [319] Go to Page: 1, 2, 3  ...  20, 21, 22 Next 
Author Message
Well, first of all, don't deploy it as a portlet application.

So don't put in in the portal's deploy folder, but in the tomcat's webapps folder.

Eduard Korenschi
most probably the path in "value" is not correct. I don't know the project structure you are using, but after generating the war, check the path to the image in the war, not in your source project. And use that path.

if you have proejct.war
/images
/css
/WEB-INF


then you need value="/images/BBBSLogo.png", even if in your project source you have that src folder. But, if the project is a classic eclipse project, then you are putting the images in the wrong place. They should be in /WebContent/images, not /src/images (Check if the images end up in the generated war in /WEB-INF/classes/images -> then you found your mistake and move the images folder to the WebContent folder of you eclipse project).

Cheers,
Eduard Korenschi
Yes, I've seen the same problem with ui:repeat and dataTable.
Try to replace ui:repeat with <ice:panelSeries>. They have both value and var attributes, but panelSeries is a jsf component, whereas ui:repeat is a facelets tag, and i think it causes some wrong var resolving in this particular combination as a consequence of being handled by the facelets view handler.

Eduard Korenschi
So, when you navigate to pagee 2, you have 2 possibilities:
1. Simple navigation (no redirect) and then you can just put the values as request attributes and get them back in the second bean
2. Navigation with redirect (this is a real browser redirect) so if the beans have some "request" scope, the second bean will always be recreated. There is nothing in between but the session (If you're using icefaces 2.0 you should be able to use the "flash" scope, but you didn't mention the version). So you would have to put the parameters on the session, and remove them in the second bean.
3. Basically it's best to keep your controller beans uncoupled as much as possible so don't inject one into another. One bean should put some parameters on the session and signal redirect, then the second bean (whichever it may be) should get the parameters from the session (and remove them) and deal with them.

Cheers,

Eduard Korenschi
Ok, so in order to upset you:
1. Study some English
2. Study some JSF
3. Here is a little piece of info:

Although you could create JSF components programatically (in Java), it's not the usual way to do it.
Basically, to solve your problem, you would need to add an "action" or an "actionListener" method to your button, and switch on a flag on you controller.

Then, the panel that you want to appear dinamically needs a "rendered" attribute which depends on that flag on the controller. Finally, the "close" button needs an "action" or actionListener that switches off the "visible" flag.


So, to make it short:
Code:
<ice:form>
 bla bla bla
 
 <ice:commandButton value="Show panel" actionListener="#{myBean.showPanel}" disabled="#{myBean.panelVisible}" />
 
 </ice:form>
 
 <ice:panelGroup rendered="#{myBean.panelVisible}">
 <ice:form>
 bla bla bla bla
 <ice:commandButton value="Close" actionListener="#{myBean.hidePanel}" />
 /ice:form>
 </ice:panelGroup>




and your MyBean should have a field
Code:
private boolean panelVisible;
 

with getter and setter and the methods
Code:
public void showPanel(ActionEvent event) { 
     panelVisible = true;
 }
 
 public void hidePanel(ActionEvent event) {
     panelvisible = false;
 }
 


now, if all you need in the showPanel / hidePanel is to switch the flag (that is you don't need to populate some other fields, do some other business logic), then you can get rid of the methods and you buttons change into
Code:
<ice:commandButton value="Show panel">
     <f:setPropertyActionListener value="#{true}" target="#{myBean.panelVisible}" />
 </ice:commandButton>


If all you do is very "readonly" (you don't have other fields needing/failing validation) you can enclose all the code in just one form.

Good luck and study hard!

Eduard Korenschi



Hi there, did you ever find any explanation for this behavior? I'm seeing this exception thrown in my logs, but haven't received any complains from users, so I don't know if it's critical.

Cheers,

Eduard Korenschi
In fact it has. It's controlled by the concurrentDomViews parameter. But it's mainly for supporting multiple conversation threads if you like ... not multiple users (if that's what you need). Servlet specification (and icefaces) have things called "isUserInRole" and other stuff like that, and these depend on one user being logged in. So if you just need to support multiple browser windows without each other stepping on their toes, then concurrentDomViews is perfect, but not for user authentication.

Secondly, if you activate concurrentDomViews and you also have asynchrounous enabled (as it is by default) you might see some "Network Connection interrupted" if you don't properly configure icepush. This is because they keep a connection open in the back, and browsers, by default, don't allow more than 2 connection per server simultaneously.

That's all,

Cheers
Well, actually you're a little bit wrong here. The session map you get in the FacesContext.getCurrentInstance().getExternalContext().getSessionMap() is the real "servlet" session. This is usually implemented by using a cookie or through url (the jsessionid). So if you have two different browsers (like IE and Firefox) they will never share the same session. If what you're saying is that two different browser windows are sharing the same session ... well ... that's the way it is supposed to work. If you want to have more than one user logged in during the same session ... well it's a little bit nonstandard. (Even the jaas doesn't accept something like this). But you could implement it by passing through the url (or some hidden input field) a "conversation_id" param. This could be some sort of integer which is incremented automatically and used as a key inside the real session. So the key would be this "cid" and the value would be a Map<String,Object>.

|--------------------session --------------------------------|
|--cid=1---|---cid=2----| ............................|--cid=n--|

But I repeat, this is something nonstandard, and shouldn't be normally used for users. And you'll have to manage the cleanup yourself.

Eduard Korenschi


I didn't read the tutorial thoroughly, but at a first read, it's a little bit messy.
To make it short, you can develop JSF app using JSP or Facelets as a page description technology.

By default, JSF expects JSP (it's not recommended nowadays, and JSF2 even eliminated it), but then, the files should have a jsp extension.

If you use facelets, then you can write xhtml files (best in my opinion) or jspx files (sort of jsps with xml-correct syntax), and in these cases you need:
1. a definition like this in your web.xml
Code:
 	<context-param>
 		<param-name>javax.faces.DEFAULT_SUFFIX</param-name>
 		<param-value>.xhtml</param-value>
 	</context-param>
 

or .jspx in your case
2. a definition like this in you faces-config.xml
Code:
	<application>
 		<view-handler>com.icesoft.faces.facelets.D2DFaceletViewHandler</view-handler>
 	</application>
 


I don't know why the write of that tutorial chose to remove these.
Give it a try and see what you get.
And even better, read the icefaces tutorials (http://www.icefaces.org/main/resources/tutorials.iface). They are better written ;)

Cheers,
Eduard

PS. If you're deploying to JBoss, don't forget to remove the jsf-api and jsf-impl from you libs, as they might conflict with the ones provided by the big boss.
It's not a tutorial, but you can get a sample jsf 1.1/1.2 with jsp/facelets and icefaces sample portlet in the liferay plugins repository. Download the war and take a look.

Alternatively, you could take a look at the svn version http://svn.liferay.com/repos/public/plugins/trunk/portlets (user guest / no password).

Better yet, do a
Code:
and you'll be able to even build them ;)


Cheers,
Eduard
You have a small problem here. I hope I didn't get it wrong, but:
1. You need some js code in the window.onload to be executed in order for the Ajax bridge to function.
2. You can't have 1 if you don't reload the page ;)

Considering these, I think in general adding / removing portlets should be an administrative thing, you don't do it all the time and when you do it, you definitely don't mind lose some fields you entered in a form. If adding/removing portlets is something users do all the time, maybe it could make more sense to change that instead.

PS. Taking into account the number of posts you have, I would guess you're new to icefaces development. In case I'm right, keep in mind that while the ajax model icefaces employed has some advantages (submits are a lot faster, ajax, partial submits, etc), you will faces some challenges you might not know by now: all post submits don't have access the the portal objects (unless you save them), inter-portlet communication is kinda difficult to do, command buttons and links don't do full page portal submits, etc. This is not bad in itself, but you have to work your way around these. Please check PortletFaces too, a project which helps with some of these problems, but only on Liferay.


Cheers,
Eduard
I think the problem is related to you specifying the imageDir="./xmlhttp/xxxxxxxx" in the ice:tree. Just omit it and the right images will be automatically loaded from the current theme.

Eduard Korenschi
I think you have a problem in correctly configuring your web.xml.

In case you're using facelets (which I recommend a lot) please make sure you have the
Code:
 	<context-param>
 		<param-name>javax.faces.DEFAULT_SUFFIX</param-name>
 		<param-value>.xhtml (or .jspx if you use jspx files)</param-value>
 	</context-param>
 

setting
also, make sure you have these servlets registered:
Code:
 	<servlet>
 		<servlet-name>Faces Servlet</servlet-name>
 		<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
 		<load-on-startup>1</load-on-startup>
 	</servlet>
 	<servlet>
 		<servlet-name>Persistent Faces Servlet</servlet-name>
 		<servlet-class>com.icesoft.faces.webapp.xmlhttp.PersistentFacesServlet</servlet-class>
 		<load-on-startup>1</load-on-startup>
 	</servlet>
 	<servlet>
 		<servlet-name>Blocking Servlet</servlet-name>
 		<servlet-class>com.icesoft.faces.webapp.xmlhttp.BlockingServlet</servlet-class>
 		<load-on-startup>1</load-on-startup>
 	</servlet>
 

and their mappings:
Code:
 	<servlet-mapping>
 		<servlet-name>Persistent Faces Servlet</servlet-name>
 		<url-pattern>/xmlhttp/*</url-pattern>
 	</servlet-mapping>
 	<servlet-mapping>
 		<servlet-name>Persistent Faces Servlet</servlet-name>
 		<url-pattern>*.iface</url-pattern>
 	</servlet-mapping>
 	<servlet-mapping>
 		<servlet-name>Blocking Servlet</servlet-name>
 		<url-pattern>/block/*</url-pattern>
 	</servlet-mapping>
 


In this case, when you request a page (written as xxx.xhtml or xxx.jspx) you do it like this http://blabla/xxx.iface

Good luck
Please wait until Monday. My internet connection here sucks. On monday I'll post a blank project to start up your on. It will be based on IceFaces 1.8, JSF 1.2, and all things necessary for JBoss 4.2 (that's what I'm using now).

Eduard Korenschi
@ext920
The problem doesn't manifest anymore in IceFaces 1.8.0 RC1 (I didn't check with the DR releases). In JIRA it looks like it was a problem in the Bridge when applying the diff to the current page .

http://jira.icefaces.org/browse/ICE-3945 (read Mark Collette's posts)

Eduard
 
Profile for edykory -> Messages posted by edykory [319] Go to Page: 1, 2, 3  ...  20, 21, 22 Next 
Go to:   
Powered by JForum 2.1.7ice © JForum Team