voyent
Messages posted by: edykory  XML
Profile for edykory -> Messages posted by edykory [319] Go to Page: Previous  1, 2, 3 , ... 20, 21, 22 Next 
Author Message
What I would like to add to what asherwin said:

The presence of the column must be independent to the particular row you are in at the moment t. This is logical from all points of view. So you should detect what columns you need from the very beginning and then use the rendered attribute for those columns (or you could check the ice:columns tag - notice the s in the end of column).

If the presence of the value in the column depends from row to row, then you could make all the columns "always renderable" (that is omit the rendered attribute on the ice:column tag) and use the renderable to the outputText or whatever you use for outputting the information. And in order to avoid IE's unpleasant rendering when cells are empty you could add the "empty-cells: show" style on the table.

Eduard

ext920 wrote:
I've tried your solution and it didn't work. in method
which is invoked in UPDATE_MODEL_VALUES before framework reset my value back to "".

tried to put my binded UIForm to your method or to get UIViewRoot from the FacesContext. 

Hi!

Yes, I also checked and it doesn't work. Let's hope the bug gets fixed some day soon.

But the code snippet is very useful so keep it. You'll need it if you change model values in an actionListener method or action method on a control marked with immediate=true (like a "delete" button or an "edit" commandLink in datatable when details have invalid info) or if you're trying to change values bound to controls from another form on the same page (like in master/detail scenario)

Eduard
Man, don't get scared ....
Actually there's nothing wrong with those lazy initialization exceptions. And they don't have anything to do with JPA vs Hibernate. Actually I think you're using JPA with Hibernate as the JPA Provider.

SO you have to understand that all your business usually takes place in the Invoke Application phase, while rendering takes place ... well, in the Rendering Phase. So if you close the session during Invoke application, of course you will get LIE when you try to access those fields during rendering. The only 2 solutions to this is either making sure all your object tree gets read while the session is still open or implementing something called OpenSession in Phase Listener / Open Session in Request and create different transactions / connections for the Invoke application phase and Render Response phase.

Or even, better, try JBoss Seam. It does the OpenSession In Phase Listener in quite a nice way ... Actually more like a OpenSession in Conversation...

But it's up to you

Cheers,

Eduard
if you're using icefaces you could use the partialsubmit attribute on those fields.

Eduard
You didn't get me. putting the controller in the session was not in order to solve the problem, but to simulate icefaces' "extendedRequestScope".

Of course, the easy workaround is to bind that control to an HtmlInputText and call
Code:
 i.setLocalValueSet(false);
 i.setValue(null);
 i.setSubmittedValue(null);
 

or, if you have more controls on your form, bind your form and use :
Code:
 	public static void forceRefresh(UIComponent parent) {
 		for (UIComponent c: parent.getChildren()) {
 			if (c instanceof UIInput) {
 				UIInput i = (UIInput) c;
 				i.setLocalValueSet(false);
 				i.setValue(null);
 				i.setSubmittedValue(null);
 			}
 			forceRefresh(c);
 		}
 	}
 

It looks like a lot of processing, but I profiled it and on a middle form (about 10 different input controlls) it takes 0 milliseconds according to System.currentTimeMillis


Eduard
OK, so your problem is actually very simple and it comes from the specification of the SelectOneMenu.
Beside the normal validation you would do on it, the SelectOneMenu ALWAYS checks that the value the user selected is inside it's item list.
This represents a problem when you're trying to use a converter from objects to and from items.
The best I could do until now was like this: use just the id's always and a standard javax.faces.Integer converter, or even just id's converted to strings. Make the mapping then from Integer (or String) selected by the user to your specific object just when you need it (in your business method).
You also avoid all the database traffic you get in converting each item in the Select Item to a String equivalent and back. Also don't forget that using Hibernate means you're getting a different Session (or EntityManager) on submit than you had on populating the fields => different objects could share the same id.
All in all, my advice is to have something like this:
Code:
@PostConstruct initValues() {
   List<Rating>ratings = ratingsManager.findAll(); // or whatever
   ratingSelectItemList = new ArrayList<Rating>(ratings.size());
   for (Rating r: Ratings)
     ratingSelectItemList.add(new SelectItem(r.id[eventually .toString()],
       someDescriptionFor(r)));
 }


Than of course, in your xhtml you could use
<ice:selectOneMenu value="xxxx" converter="javax.faces.Integer" (if using ints instead of strings, but I don't see the reason for this use case)>
<f:selectItems value="#{controllerBean.ratingSelectItemList}" />
</ice:selectOneMenu>

and so on ....

Let me know if you have any more problems

Eduard

The presence of the page selector is controlled by the attribute paginator="true" | "false"

Eduard
I'm not trying to offend you, but could you please use English? Or at least your native language, maybe someone speaking it could help you.

What you're asking is not understandable at all ...

Eduard Korenschi
@mgroeneweg - you are a little bit off topic in this case
1. I checked the problem in detail: it really happens and I'm almost sure there's a little bug in the IceFaces server side diff composer; more specifically, the value get's set on the bean correctly, but the updates are not sent back to the client.
2. The method ext920 is using is an "action", and that happens in "Invoke Application" anyway (if immediate is not used, of course), and also there's no e object :).
3. Your solution is for this case: you have a ValueChangeListener (which is called before "Update Model" or an "ActionListener" + immediate="true") and want to change some values which would be overwritten by the "Update Model" phase => you move the listener execution to "after Update Model", that is "Invoke Application"

I made a more laborious comment on the behavior here: http://www.icefaces.org/JForum/posts/list/11581.page#46496
Hi there,
The usage scenario is a little bit complex, but please follow this through:
1. The controller:
Code:
 public class TestController {
 	private String value;
 	
 	public String getValue() {
 		System.out.println("Getting value: [" + value + "]");
 		return value;
 	}
 	public void setValue(String value) {
 		System.out.println("Setting value: [" + value + "]");
 		this.value = value;
 	}
 	public String submit() {
 		System.out.println("Submitting");
 		value = "testValue ";
 		return null;
 	}
 }
 

2. The view
Code:
 	<ice:form>
 		<h:inputText value="#{testController.value}" />
 		<hr />
 		<ice:commandButton value="Submit" action="#{testController.submit}" />
 	</ice:form>
 

3. The behavior:
I
a. submit empty value => the value gets set on the bean to "testValue" and shows on the page (updates happen on icefaces log console)
b. submit again empty value => value get set on the bean to testValue, but doesn't show on the page (no updates come back, according to icefaces log console)

II
a. submit any non empty value => value gets set on the bean to "testValue" and shows on the page
b. submit an empty value => values gets set on the bean to "testValue" but doesn't show on the page (no updates happen)

III
replace "testValue" with "testValue" + new Date() ==> it behaves correctly

Conclusion: the problems comes from the fact that in I and II the "testValue" is always the same coupled with the fact that submitted value is empty.

Observation:
1. testController is extendedRequestScoped
2. If i use a plain jsf project (putting testController in the session scope) everything works normally, which makes me think that the problem comes from computing the diff on the server side.

Cheers

Eduard Korenschi
I'm not using Visual Web nor Netbeans for developing icefaces applications, but basically, to validate a long value, you need something like this

<ice:inputText value="#{bean.longValue}" converter="javax.faces.Long">
<f:validateLongRange maximum="xxx" minimum="xxx" />
</ice:inputText>

Cheers
I'm not sure I understand your issue, but are you sure it's related to icefaces? You could try for example to play with cells styles to add things like wrapping (if that's what you need) or overflow=hidden

Cheers
This is nothing related to icefaces, but basically you can use
Code:
 <div id="myCenteredDiv" style="width: 500px; margin-left: auto; margin-right: auto">
 Put your content in here
 </div>
 


That should do it. It should also work with ice:panelGroup (since it gets rendered as a div)

Good luck
Man, without any desire to offend you, I think regex should be part of any programmer's arsenal. Especially once you decide to get into using JSF in general and Facelets in particular.

A little bit off topic (and hoping I'm not wrong), be careful:
Checking file sizes or file extensions can be done only server side, so only AFTER the file has been uploaded.

Eduard Korenschi
It's not a perfect solution, but you could also get from the map a list of Map.Entry (actually list = new ArrayList(map.entrySet())). Then, for each entry, you can use in the xhtml file entry.key and entry.value (thanks God, Map.Entry has getKey() and getValue(), so it looks like a bean ;) ).


I used it whenever I needed a List-type collection for dataTables, ui:repeat, panelSeries, etc.

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