voyent
Messages posted by: edykory  XML
Profile for edykory -> Messages posted by edykory [319] Go to Page: Previous  1, 2, 3 ... 19 , 20, 21, 22 Next 
Author Message
Sorry ... maybe I got it wrong, but I thought that ContextRepeater listener was required only if you need Server Push functionality ...
I use only the com.icesoft.faces.webapp.http.servlet.SessionDispatcher$Listener and it works fine for me. Am I wrong?
I know this doesn't help much ... but at least it should give you some input:
I also migrated from IceFaces 1.5.3 + Facelets to IceFaces 1.6 DRx and the only change I had to do was the new listener in web.xml introduced by the DR1
Code:
   <listener>        
     <listener-class>
       com.icesoft.faces.webapp.http.servlet.SessionDispatcher$Listener
     </listener-class>
   </listener>
 

Beyond that ... everything worked OK.
Depending on the way you're deploying ... you need to make sure the Application Server reaches the same jars your IDE is using (unless you copied them in WEB-INF/lib which makes that process automatically).
Hope that helps!
I have just downloaded 1.6 DR4 and the problem seems fixed.
Nice!
Way too nice!!!
I will tell you in a few words what I have done in my application. To code is not difficult, but also it can get non-trivial, depending on the functionality.
First of all you need the session-scoped bean philip was talking about (in my case it's called BackNavigationBean).
Second ... if all you need is just a back from that page to the previous (I mean just one back operation , not more), than things are quite simple. Just use a String field where you keep that address, and on the current page use the standard navigation to go there.

If you know the previous page for sure (for example you have a MyHomePage and a ChangePassword page) ... then nothing simpler... You can forget about session beans and stuff, just register in faces-config.xml a navigation rule from the "Change Password" page to the "MyHomePage", and in the Cancel action method just return that string (You might also want a immediate=true on that cancel button to avoid validations ... but you have to know what you're getting into).

If, on the other hand, you want a more complex navigation (for example I have a navigation bar at top, like Page1 >> Page2 >> Page3 >> Page4, or you might want a multiple step Back button), then things get a little bit more complicated.
You have to make that session bean, create a list (if you need that navigation bar) or a stack (if you just show a BACK button) and keep storing the addresses.
You can get the current address using
Code:
getExternalContext().getRequestServletPath();

and the extra query (after the ?) with
Code:
((HttpServletRequest)getExternalContext().getRequest()).getQueryString();

You also have to take into account the submits to the same page (if you have things like action listeners or partial submits) and keep only one version of the link ... and so on and so forth.
If you want to make the navigation bar you will also need a way to map links to descriptions. If this is what you want ... post a message and I'll get more into details...
Just keep in mind that all this works if you navigate from one page to another ... it will not recover state if you do partial submits ... or things like that.

I heard the IceFaces guys have in mind to design a more complex Back functionality in some future release .... but that might take some time ...
Good luck!!!
Hi there !
I'm using Ice Faces 1.6 DR3 and JBoss 4.0.5
I was working on an application and after some discussions on this forum I turn the ConcurrentDOMViews on.
After this the call getExternalContext().getRequestParameterMap() started returning empty Maps when using ?param=value stuff. I could retrieve the parameter only through
Code:
 req = (HttpServletRequest)getExternalContext().getRequest();
 req.getAttribute("param").

(which, for some reasons, returns an array of objects instead of the object itself, but that's another story).
I wanted to ask if this two things (turning ConcurrentDOMViews on and the disappearance of parametterMap) are somehow related. Before switching it worked normally, but I'm not sure what triggered the change.
Is this the normal behavior?

No i haven't. We don't need the concurrentDOM facility and I was thinking we could save some bandwidth and server memory by deactivating it. Was I wrong?
Anyway ... I'll give it a try.
Could you please tell me what's the cost of turning the concurrent DOM on?
Thanx a lot
Update:
One little workaround I found would be as follows:
1. The Beans should be in request scope
2. Bind the DataPaginator to this bean through a field "private DataPaginator dataPaginator;", it's get/set methods and "binding" element in the xhtml file.
3. add a field "private boolean shouldGotoFirstPage = true;" to this bean
4. In the method where you return the list populating the dataTable add the lines
Code:
 		if (shouldGotoFirstPage) {
 			shouldGotoFirstPage = false;
 			getDataPaginator().gotoFirstPage();
 		}

In this way, the shouldGotoFirstPage is set to true on each navigation to this page (the bean is in request scope, remember) and set to false for all the subsequent calls to getXxxxList .....
Well ... that should be all!
I repeat ... it's a workaround.
In my opinion the dataPaginator should have the same scope as the bean to which it is binded.
Update:

After some trace through the getDataPagintor / setDataPaginator methods (from my bean) I came to the following conclusion:
the dataPaginator si created (or read from the bean) only once during the first parsing of my xhtml page (so during the construction of the component tree). This is the only time the getDataPaginator is called.

On the subsequent navigations to his page the request bean is recreated, but the dataPaginator created earlier is reused and only the setDataPaginator is called (everytime with the same DataPaginator object).

I don't know if this is a bug or was designed to be like that ... but I wished it had same lifespan as the main bean (that is request scope).
Hi philip!
Well ... the bean is in request scope (I checked and constructor is called for every new access to the page).
I added the dataPaginator binding and in the setDataPaginator of the bean I put the following lines
Code:
 		System.out.println("The main bean = " + this);
 		System.out.println("Data paginator = " + dataPaginator);
 


Now I go into my application, I go to this page ... I navigate (through a link) to a different page and then again through a link I come back to this page.
Th results are funny:
Code:
 The main bean = xxx.xxxxx.xxxxx.BlaBlaBlaBean@19a82ee
 Data paginator = com.icesoft.faces.component.datapaginator.DataPaginator@1609872
 
 The main bean = xxx.xxxxx.xxxxx.BlaBlaBlaBean@dd0099
 Data paginator = com.icesoft.faces.component.datapaginator.DataPaginator@1609872
 

So..... My bean is indeed in request scope ... but the dataPaginator, although it was binded to this request scoped bean ... is actually reused.
I don't know weather this is a good or a bad thing, but since I navigate to this page from a different one ... I don't know where to hook that gotoFirstPage call.
1. During bean constructor the dataPaginator is still null ...
2. The dataTable's value list is read for each page of results ... so putting the gotoFirstPage here would block me on the first page of results ...
3. During the setDataPaginator .. the dataTable is not initialised yet ... so I can't go to the first page ....
Hi there!
I don't know if this is a bug or another feature :), but I get this kind of undesired behavior:
I have a dataTable with a dataPaginator. I go for example to the third page of results. I navigate then to a completely different page (another .faces page). Then, if I navigate back to the first page, the one with the dataTable, the dataPaginator brings me back to that third page of results instead of the first one. While this would be desirable if I stay on the same .faces page, it is totally undesirable after a navigation to a different one and coming back.

I hope I was clear enough :)
Hi there!
Imagine this scenario:
I have a dataTable with "rows" set to 8 (doesn't matter so much) and 9(8+1) rows of data.
Using a dataPaginator I will have 8 rows on the first page and 1 on the second.
Now I go to the second page and remove that row from the backing list.
What happens is that I'm now stuck on the second page, no rows of data on this page, dataPaginator is not active anymore since all the data fits on the first page, and the only way to go further is to refresh the page and force the dataTable to reread the list.
Is there anyway to determine IceFaces to automatically navigate to the previous page when this last page gets empty?
Man .... first of all ... why would you mix jspx files and xhtml files ?
A good practice in my opinion would be to have in your web.xml a declaration like:
Code:
   <context-param>
     <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
     <param-value>.xhtml</param-value>
   </context-param>
 

especially if you're using MyFaces, and stick to xhtml files.

Second ... in your ui:include you have to give the source file name, so you would have a .xhtml extension (or a .jspx if you stick to jspx), not iface.
Yes, you understood me right, they should replace the FacesServlet declaration and its mappings.
But I repeat, this is the way to do it "in theory"; I've never done it, but if it's said it works ... this is the it should be ...

Good luck, and please let us know if it worked!
Did you try including the <ui:include></ui:include> in <f:subview> tags?
As Philip was saying try to make a copy/paste with your code and any abnormal output from the application server (check the logs for any exception stack trace).
I don't know if I'm right, but a fast solution in my opinion would be to store your options differently. Instead of using a looooooong list and expecting IceFaces to format it nicely, you could use a matrix (or an array of Lists, or a List of Lists) and then just go through them and generate the lines (one selectManyCheckbox per line).
It shouldn't be that difficult with a combination of forEach and selectManyCheckboxes. A bigger problem would be with radio buttons, but for check boxes ....
Good luck and let us know if you managed to do that :)
 
Profile for edykory -> Messages posted by edykory [319] Go to Page: Previous  1, 2, 3 ... 19 , 20, 21, 22 Next 
Go to:   
Powered by JForum 2.1.7ice © JForum Team