ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

Hi Philip,

i had problems using window.open() because i implemented it like <a href="javascript:window.open(...)" />, which ended up in the original window showing nothing but the line [object window]. It works when being implemented in the onClick-Handler.

Hi everybody,

i'd like to provide application help for my ICEfaces application, which i prefer to be in a separate popup window. Lacking the possibility to open a different window with window.open() i tried to use a draggable panelPopup which does work, but it has some "cosmetic problems".

The problem is that the help content is too large to fit in the popup. Placing the help content in a scrollable <div> inside the draggable panelPopup doesn't really solve my problem, as one is not able to scroll the div using the mouse - the mouse will stick to the panelPopup and drag it across the screen instead of scrolling the div.

Using a modal popup features the problem that you will have to set the "rendered"-property of the panelPopup to "true", which ends up in a vast amount of help data being transfered to the client even if there is no request for help.

Is there any way to make a <div> inside a draggable panelPopup scroll instead of the panel being dragged? Is there anything like "best-practices" on how to provide help for an ICEfaces application?

Any hints are welcome
Christian

In my app it works as easily as you describe it:

<form action="j_acegi_security_check" method="POST" >
<input type="text" name="j_username" value="" />
<input type="password" name="j_password" />
<input name="Login" value="Login" type="submit" />
</form>

--
p.s.: better use a normal html form for the login page, as ICEfaces will add it's something of it's own to the controls ' ids.

Message was edited by: Christian Teichert

Hi Todd,

just found your other acegi-thread in this forum.

To be honest, my integration of ICEfaces and acegi works only a little bit. Up to now i'm able to secure URLs reliably and to display components depending on the user role - as long as i use "normal", client initiated requests only.

One other thing that's working is MethodSecurity using the SecurityInterceptor. But I do *not* use the acegi-security api directly.

What I did do to get started was to put all the acegi jars i could grab on my /lib dir, including the tiger one (might be important for Java 5 ...?), adjusted the acegi configuration with the proper file names and user roles (using the inMemoryDao for simplicity-reasons) and added the filter entry and bean-definition in my web.xml. That's all that was needed to make the URL-Security work.

As the rest doesn't work really well i better won't try to advice you, my hints might prove worthless or even harmful .. :-( Unfortunately i discovered my problems only a few minutes ago, otherwise i wouldn't have tried to offer help on a topic that i apparently do not really understand myself - sorry for that. I'll let you know if i find a solution.

Greetz
Christian

Hello Ted,

i just tried to use the "renderedOnUserRole" in combination with the IntervalRenderer using ICEfaces 1.0.1 and acegi 1.0.1, but my problem remains: some components are being displayed correctly but the most of them are killed by the IntervalRenderer. Maybe the problem is that Tomcat cannot find the acegi- and spring-jars that i put in common/lib. Is there anything i have to do so that the application *does* use the jars in that directory?

Hi Todd,

as my collegue Thomas is on holidays i'll try to answer your question. First of all i'd like to recommend a Spring Acegi Tutorial (just in case haven't found it already: http://home.hccnet.nl/bart.van.riel/spring_acegi_tutorial.html)
It provides a good introduction and overview to acegi.

We use Spring 1.2.5 and acegi 1.0.1. From acegi you'll need acegi-security-1.0.1.jar and eventually acegi-security-tiger-1.0.1.jar. Additionally you'll need acegi-jsf-1.1.2.jar (avaliable via http://sourceforge.net/project/showfiles.php?group_id=137466).
And of course you need ICEfaces 1.0.1.

I'll attach the relevant parts of our web.xml and acegi.xml (and put in some english comments). That's all!

To provide you with better hints i'd need to know *where* you're stuck exactly and to see your configuration.

Hope i could help you a bit
Christian

Yes, we're using facelets.

I'm awfully sorry that at the moment we can't provide a clean test case. We have to finish some work pretty soon and on top of all our workaround only seems to work under certain circumstances, which we aren't able to define precisely, apart from: on a plain test page it does not work.

We'll have a closer look on it within the next weeks, but for now there's no time, unfortunately.

In the meanwhile thank you very much for your support. We appreciate it a lot!

Hello Ted,

we finally found a "solution" that works for us. Placing an empty <ice:outputText/> directly in front of the control to be unrendered does the trick.

This works
================================
<ice:panelGroup>
<p><ice:selectBooleanCheckbox partialSubmit="true" value="#{bug692.firstOn}" > First </ice:selectBooleanCheckbox></p>

</ice:panelGroup>

<br />

<ice:panelGroup>
<p>First:
<ice:outputText/>
<ice:inputText rendered="#{bug692.firstOn}" /></p>

</ice:panelGroup>
================================
.
.
... this doesn't.
================================
<ice:panelGroup>
<p><ice:selectBooleanCheckbox partialSubmit="true" value="#{bug692.firstOn}" > First </ice:selectBooleanCheckbox></p>
</ice:panelGroup>

<br />

<ice:panelGroup>
<p>First:
<ice:inputText rendered="#{bug692.firstOn}" /></p>

</ice:panelGroup>
================================
.
As we are in a bit of a hurry we'll be using this "workaround" until there will be a straight solution with one of the coming releases of ICEfaces, but still bearing in mind that the error might be in our own code.

Thanks
Christian

Hello Ted,

thank you for the testfiles.

There is one thing we had to change to make them work: instead of jsp files we're mapping xhtml files to be rendered with ICEfaces, and in this case it might be a hint to what causes the error, because: our problem remains.

We're able to switch a non-rendered inputText to be rendered, but the opposite switching is not possible: a once rendered control will remain rendered, no matter wether the checkbox is checked or not.

Apart from the test case, we're doing a bit more of evaluation in our app to determine the rendered state of a control. we're evaluating several object properties to do this. We tried to do this evaluation in different layers: withing the xhtml page via EL, within the backing bean via a dedicated method, and finally within the business object itself - once again via a dedicated method. All these strategies have one thing in common: they work for the disabled property but not for the rendered property.

finally a reply to your other question: every control in our application has it's own id. we migrated from myfaces/facelets, which made this more or less obligatory. so this didn't help either, unfortunately.

Wow, that fast! Where does the name ICEfaces come from? might very well be the german high-speed-train (called "ICE")!

Thanks a lot
Christian

... one thing i would like to add: if i use the identical expression to determine the disabled-property everything works as expected.

Hello all,

I'm trying to set the rendered-property of some controls in dependency of object-properties, desolatly with random success up to now.

This is the relevant part of the xhtml-page:

<ice:inputText rendered="#{BB.obj.visible}" />

Simple enough, but it doesn't work. It will display - or rather won't display the inputText - *correctly*, as long as i only view pages of objects with obj.visible == false. But after viewing one page of an object with obj.visible == true, the above control will be displayed for every object, regardless of the value returned by obj.visible.

The following lines, however, work, but this is intolerable, as the value of obj.visible itself will be displayed on the page:
<ice:outputText>#{BB.obj.visible}</ice:outputText>
<ice:inputText rendered="#{BB.obj.visible}" />

This wouldn't be altogether intolerable - intolerable for developers only but not for users -, but it doesn't work:
<ice:outputText rendered="false">#{BB.obj.visible}</ice:outputText>
<ice:inputText rendered="#{BB.obj.visible}" />

Another solution that doesn't work:
<div style="display:none">
<ice:outputText>#{BB.obj.visible}</ice:outputText>
</div>
<ice:inputText rendered="#{BB.obj.visible}" />

To be sure that obj.visible returns the expected values i put it's return-values in the log, and everything's fine there with one little irregularity: when the return-value is true the getter is called 4 times, otherwise only twice.

Well, after 5 hours i'm still clueless: where's my mistake?

Thank you Ted, that's what we already supposed. So we'll be patiently waiting until the very release and hope that our users will have their own watch, so they won't need the app's clock... ;-)

hello everybody,

we use acegi-security (http://acegisecurity.org/) in an application that we migrated from facelets to icefaces recently. acegi provides methods that respond to the component-properties "renderedOnUserRole" and "enabledOnUserRole". In a first try acegi seems to work fine with icefaces - these two integrated seamlessly.

But getting a bit deeper into icefaces we encountered a strange problem in combination of the security-related tasks and the IntervalRenderer. We added a clock to our app to display the current date and time and to keep the connection alive (which used to get lost accidentially). With the clock being displayed we have the problem, that all our components with the property "renderedOnUserRole" will disappear at the IntervalRenderer intervals. *Any* request coming from the client itself(including partialSubmits) restores those components again until the next IntervalRenderer interval will remove them once again.

Is there anything we have to consider when using the IntervalRenderer AND "renderedOnUserRole"?