Enterprise Client Community

We have a status bar in our pages, created with as little parameters as possible, namely
Code:

<t:rowstatusbar id="g_sb" />

The status bar component always creates a sound component as child, and the sound file being an empty string.

On the client side (SOUNDElement), this empty sound file causes a request to the url
GET /ourapplication/faces/

this is answered by 404 not found which pollutes the server protocols, additionally (being handled by Faces servlet) it creates an extra tomcat session which will consume unnecessary server resources.

The handling of empty sound file (...empty or null!...) should be improved.
regards
Manfred

we have a t:combofield which happens to be disabled.

It has the strange behavior that the drop down icon gets visible when the user clicks into the field. When the icon is clicked, nothing happens, the list is not opened --> this is correct behavior since the field is disabled.

But it seems to annoy users if a seemingly clickable icon is shown, and then nothing happens when it is clicked.

regards
Manfred

Hi,
well - we already hacked our own class, and we might stick to it since we are likely to tweak other things as well.

But just to help make your implementation more robust here, lets further plunge into the details.

Lets use http://host:port/abc/def/jkl.ccwebstart as an example, with /abc/def being the root of the captain web application, and this directory contains a jkl.jsp file to be loaded.

problem is that (1) we do not have a globally fixed code base here, the dynamic way to obtain it is just fine, only it has to be done correctly (...but ok, we do handle such things using dynamic deployment elsewhere, so this could be circumvented...), and (2) this still does not produce the correct value in the pagename argument: This turns out to be

faces/def/jkl.jsp

when the

def

is already part of the code base, so this jsp is not found!

Have looked at your implementation and following comments sprung to my mind:

(1) the client jars are specified using a relative uri starting with eclnt (e.g. eclnt/lib/eclnt.jar), so the implementation clearly assumes that the directory of the request must be the root of the captain casa web application.

(2) as a consequence of this comes the specification that if the initial jsp page is in a subdirectory, this has to be provided using a dot notation instead of a slash (e.g. workplace.workplace.ccwebstart - as explained clearly in your documentation, although no motivation is given - and hopefully there are no dots somewhere else in the path).

(3) while this ensures that relative paths are resolved correctly from client point of view, the implementation of the servlet does not make any use of this. At a very early stage of processing all dots are replaced with slashes, and somewhere later, it tries to figure out where to split the url, using at one place the

second

slash, and somewhere else the

forth

. This is clearly bound to fail if anything is different from the usual installation scenario.

Taking into account what is explained in (1), it is both simpler and more flexible to take the split point as the last slashof the original url/uri, and once this is determined, this will yield the correct codebase argument, and, after replacing dots with slashes as a second step, the correct value for @@pagename@@.

While this fixes our queer configuration hope this does not mess up some other.

Manfred

Sorry but I could not extract too useful information solving the problem stated, except for the hint that we should probably implement this stuff by ourselves.

Which means duplicating the cookie stuff, and also face re-implementation of possible future improvements of your class.

But then the most important thing here was your idea how to deal with the cookies (thanks for that...), the implementation is just a few lines of code, so it is not something to worry about too much.

Manfred

Wanted to switch to *.ccwebstart to launch our application, to gain access to the new cookie handling.

Problem is: class AppletStarter seems to be rather strict on how captain casa is installed.

In our case the web application is available under
host:port/name1/name2, and apparently AppletStarter assumes that it is something like host:port/anyname, and gets mixed up by the additional directory level.

Could this be made more flexible somehow?
Manfred

Hello,
suppose you have now successfully sit out this "short-term activity".

In the meantime we have now found a different solution. The original idea would not have solved the problem anyway:

We wanted to get access to the current "bean". But when you only pass the BaseComponent that is handling the help request, as we had discussed, we would not be very much further. Is it correct that there is no simple path from any component to the bean since it is only connected through some dynamic expression, and therefore not easily resolvable if it should work for "any" component.

Because of this we are now using dynamic help id's via a #{d.MyBean.helpId} expression, and from this getHelpId() method, we again pass a String like #{d.d15.MyBean}theHelpId which then gets transmitted to the OnlineHelpProcessor,
and here wecan extract the part in braces, and evaluate it with something like
Code:

FacesContext context = FacesContext.getCurrentInstance();
 Object bean = context.getApplication().createValueBinding(beanPath).getValue(context);

And take the rest as "real" help id for which we can display the help text.
(b.t.w. Is this the correct way to evaluate such a jsf expression on the fly?).

Happy looking for easter eggs
Manfred

we need to display pages in an external browser, for which we provide the url.
To our current knowledge this requires adding the swt jar, including a t:browser component in a page which loads some html code that contains something like

Code:

<body onload="javascript:window.open(the-desired-url)" >

Just encountered the java6 class java.awt.Desktop, with method
Desktop.getDesktop.browse(URI).

I think this is a very attractive solution avoiding any stability issues with activeX when (as in our case) this is really just needed to open a browser.

Could CaptainCasa provide such components?

maybe a nonvisible component named something like "externalUrlLauncher" with parameter this url,
or (and...) something like "externalLink", a visible component with parameters a text and a url, that displays the text as a clickable link and when clicked just invokes the url on the client without further roundtrip.

There is sessioncloser servlet that gets notified AFTER client is closed so that the server can clean up session data.

We would like to have a hook before the client is closed, to inform the user that there might be unsaved changes and if required veto the close action.

Hope this is possible in all scenarios (applet/webstart/standalone). Maybe the server roundtrip in this moment can be avoided, we could post the user message into the client in a previous roundtrip.

Manfred

Hi,
we have implemented some code that tries to find the "optimal" dimensions of the popup, so that for small text it is just wide enough to display this text, for larger texts it is correspondingly larger, and a scrollbar appears only when the text tends to be larger than the screen.

We could share this to be implemented in the standard.

And b.t.w. we would like to post a feature request to have an "official" way to set the dimensions of the YESNOPopup and OKPopup. Currently we use reflection to get hold of the underlying ModalPopup.

Manfred

thanks for the info, this was already one of my ideas.

But then come our captain and invokes
Code:

setCookiePolicy(CookiePolicy.ACCEPT_NONE);

and this is probably why it does not work.

So I think we need an official hook here...

is there any preferred way to identify the users computer on a subsequent session. This may not always be identical to a "user name".

In browser environment a persistent cookie would be used for this - while such cookies have a questionable reputation in "internet" scenario, they come in very handy in a trusted environment.
It looks like such cookies are explicitly not handled by captain-client (in class DataTransfer). Can this be customized, or is there any other preferred way to achieve this goal.

regards
Manfred

Hi,
Have already considered using the jsf phases.

Our problem here is that some information of what is rendered is currently only coded inside the jsp pages (e.g. what bean names, and what properties in these beans). And such a bean is instantiated through the jsf framework, when (after!) the ROWINCLUDE has requested its url property during the render phase, and it will not query it again.

So if you don't know any solution, we probably have to build up more meta information so that when some part of the framework decides that a particular jsp page is to be displayed, we know in advance its beans and some other properties, with these we can instantiate our beans by ourselves (and put them into Dispatcher), can validate these in an earlier phase, and then decide to change the original jsp file name to a different one. This extra meta data is not exactly what we want to maintain, but probably our only option?

Manfred

Is it possible to restart the "rendering" phase of jsf after it has begun.

In some exceptional cases, we have the situation that when the renderer invokes a certain property this causes a side effect that some other property changes, and it happens that this property has already been read by the renderer. So it would be nice if we could cause it to restart all (or better still a certain part (=rowdynamicinclude)) of the rendering.

regards
Manfred

Just one more bit (...found while setting some breakpoints in the client when I wanted to understand how this works, if it is our bug not...).

Repeatedly opening and closing (via click-outside) such a valuehelp modeless popup, these popups are collected in a hashset m_pagePopups in the Page object, and never removed. This is probably not what is intended.

This seems to be fixed now - in fact the popup appears.

But unless we really missed something, in this case the combobox list has lost the feature of "closeonclickoutside' when clicking in the (modal) dialog that hosts this combobox. It only closes when an entry is selected.

b.t.w. contrary to what you said in your previous answer about the "combobox popups", class IdAttributeSelection does not set the "startfromrootwindow" flag, nor does it honor the "suppressHeadline". But since we moved this class to our own implementation, this is currently no issue for us.

regards
Manfred