voyent
Messages posted by: ted.goddard  XML
Profile for ted.goddard -> Messages posted by ted.goddard [874] Go to Page: Previous  1, 2, 3 ... , 57, 58, 59 Next 
Author Message
Here's a workaround that should actually work; add a value binding expression to the outputDeclaration Tag to force it to be executed each time (the root cause of this bug is that the ICEfaces framework is marking the component as "static" and only executing it once). Note the isDynamic binding below with a simple expression below:

<ice:outputDeclaration doctypeRoot="HTML" doctypePublic="-//W3C//DTD HTML 4.01 Transitional//EN" doctypeSystem="http://www.w3.org/TR/html4/loose.dtd" isDynamic="#{}" />

It sounds as if the concurrentDOMViews setting is causing the AJAX connection to be partially lost; we have recently encountered this bug in another application and plan to fix it in an upcoming release. In the meantime, I suggest instead using the above workaround to maintain the DOCTYPE.
We're still looking into the bug, but have found that the following
context-param setting (in web.xml) seems to help in some cases:

<context-param>
    <param-name>com.icesoft.faces.concurrentDOMViews </param-name>
    <param-value>true </param-value>
</context-param>

Feel to free to ignore this suggestion, as it's not even a confirmed workaround, but perhaps it will help in your case.

concurrentDOMViews is a setting in ICEfaces that allows multiple windows to be open simultaneously. Page reloads will be in the same session, but will have new component trees built (rather than using an existing cached component tree).
We've observed this bug as well, but hadn't identified the conditions under
which it occurs. Some possible theories are:

- placement of ice:outputDeclaration must immediately follow f:view
- form used must be ice:form

We hope to have a workaround shortly and expect to fix it in the next
release.
The documentation should be available in your distribution here:

ICEfaces-0.3.1-Alpha/docs/tld/ice/outputDeclaration.html

To try it out, you can edit the the beginning of the Timezone tutorial
timezone.jspx so that it's as follows:

<pre>
<f:view xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:ice="http://www.icesoft.com/icefaces/component"
>
<ice:outputDeclaration
doctypeRoot="HTML"
doctypePublic="-//W3C//DTD HTML 4.01 Transitional//EN"
doctypeSystem="http://www.w3.org/TR/html4/loose.dtd" />
<html>
</pre>
...
We are evaluating the following mechanism:

FacesContext.getCurrentInstance().getExternalContext().redirect(url);

would be available as application-initiated calls, resulting in the browser
being redirected at any chosen time. Would this meet what you are thinking
of?
The problem here was twofold: the MyFaces LifecycleImpl was calling into the ICEfaces ViewHandler in a different sequence from the Sun LifecycleImpl (causing the delegateNonIface parameter to be ignored); and the MyFaces LifecycleImpl pre-processes the viewId (replacing .iface with .jsp). The root cause must be fixed in MyFaces, but we will provide a workaround via an initialization parameter:

  <context-param>
    <param-name>com.icesoft.faces.fakePathInfo</param-name<
    <param-value>true</param-value<
  </context-param<

This will be available in an upcoming release. Please contact product.support@icesoft.com for earlier resolution.
We have added a custom component for setting the DOCTYPE in an ICEfaces page (it should be available in the next release).

Could we ask you to attach or send to product.support@icesoft.com a small sample page containing both ICEfaces and the JS libraries that you wish to use?
The problems you are seeing are due to bugs in ICEfaces-0.3.0 (two bugs, actually):

<ol>
<li>XML declarations are discarded on input</li>
<li>The ICEfaces DOM is an HTML DOM and always has an HTML element as the document root</li>
</ol>

1. causes problems when doctype is inserted manually, and 2. prevents CDATA and f:verbatim from working.

The most expedient way to resolve this is likely for us to provide an ice:output custom component that allows the doctype to be set on the DOM (the other bugs will be addressed in a future release). This needs to be investigated further, however, so please contact product.support@icesoft.com if your deadline is critical.

Please check the timezone tutorial for cleanly formatted XML .jspx documents.
Can you generate the array of rows from the database each time getRows() is called? Then each RowBean just needs to know its primary key (since each RowBean probably represents a record) to know where to commit back
to the database.
All questions related to ICEfaces and JSF are welcome on the forum; especially on an advanced JSF technique such as this.

The idea is to use an actual bean to define the contents of your row:

<pre>
public class RowBean {
public boolean getFlag() {
}
public void setFlag(boolean flag) {
}
}

public class TableBean {
public RowBean[] getRows() {
return rowBeans;
}
}
</pre>

<h:dataTable var="row" value="#{table.rows}">
  <h:column >
    <h:selectBooleanCheckbox value="#{row.flag}"/>
  </h:column >
</h:dataTable >

Then, each particular instance of the RowBean just needs to take care that it is associated with a unique piece of real data in the back end.

Does this seem like what you're looking for?
ICEfaces converts tags in .jsp pages so that the input can be processed as .jspx XML documents. Tag conversion should not be taking place if your documents are in XML format and have the .jspx extension.

We are considering adding support for the <jsp:output /> tag. Do you believe this would be sufficient?

Can you describe some of the features you wish to make use of in the cross-browser library? These may be features that ICEfaces should support directly in custom components.
If there are multiple users modifying the data, it's really up to your application to decide how to handle that. You probably don't want to lock the table just for reading. Ideally, when data is modified in the database, a notification should be sent to the application and any users viewing a modified item should have their view updated via an application-initiated render. However, they shouldn't lose what they're working on, either.

The database might not support this, or it might cause too much activity to perform well, so the next best thing would be to let users work on their data as they please but give them options when a conflict occurs. They could chose to apply their data on top of the conflicting data or discard their data, and you would probably want to show which other user entered the conflicting data. Note that this approach also works for offline operation.

So, solving the problem in general is complex and application-dependent, but there's probably a reasonable policy you can take for your particular case depending on how small the records are and what the conflicts mean in the real world (maybe you can just lock individual records). The conflicts in the table occur because two different users are trying to do two different things. In some ways it's more of a social problem than a software problem.

Can you give a concrete example of the data and a conflict?
Tiles with ICEfaces is experimental and has the current limitation that ICEfaces documents must be leaf nodes in the Tiles inclusion hierarchy. That is, references to ".iface" may only appear in the Tiles configuration file and ICEfaces pages may not themselves perform Tiles inclusions.

The stack trace from "jsp.error.parse.xml.line" is due to an incorrect DTD being included with ICEfaces-0.3.0-Alpha and will be fixed in the next release.

To obtain early access to a simple Tiles project and the ICEfaces Alpha, please contact Product Support: product.support@icesoft.com
ICEfaces integration with ADF is currently experimental, but in many cases ICEfaces and ADF Faces pages can coexist within the same application (ICEfaces and ADF Faces components cannot coexist within the same page.)

In your web.xml:

Ensure that the Faces Servlet javax.faces.webapp.FacesServlet is handling /faces/ or *.faces requests.

Ensure that the Persistent Faces Servlet com.icesoft.faces.webapp.xmlhttp.PersistentFacesServlet is handling *.iface requests and not *.jsp, *.jspx, *.faces, or *.jsf requests.

Set the following context parameter that configures ICEfaces to handle *.iface requests only:

<pre>
<!-- ICEfaces ViewHandler will delegate any page except .iface -->
<context-param>
<param-name>com.icesoft.faces.delegateNonIface</param-name>
<param-value>true</param-value>
</context-param>
</pre>
Rather than iterate over the UISelectBooleans in the table, it might make sense to bind each UISelectBoolean to a "row" bean. Then, when a single delete button is pressed, the application can iterate over the row beans and take action depending on their selected state.

Problems with asynchronous update could occur -- if the user is modifying the data while the application is modifying the data, there could easily be conflict. Perhaps each row bean could contain a unique key so that an item is not deleted simply because of its row index.
 
Profile for ted.goddard -> Messages posted by ted.goddard [874] Go to Page: Previous  1, 2, 3 ... , 57, 58, 59 Next 
Go to:   
Powered by JForum 2.1.7ice © JForum Team