Updating many documents (same doctype) in one jsp-page

X-Application Version: 3.1.3
Tamino Version : 3.1.4
Platform : Win2k,
WebContainer : Tomcat 3.3
JDK Version : 1.3.1

Is it possible to update many documents on the same page?
What I would like to do is to search for documents and view them in a updateble list.
Can List.jsp in the property-demo be modified so it will be updateble?
If so, can anyone give me hints on how to do that?

Eagle

Hello,

I looked for a simple solution with version 3.1.3. My first idea was to commit the complete BusinessDocumentPage (represents the of currently displayed documents of a browse tag). This could be solved by a plugin, so committing was not the problem.

When I tried out this solution I recognized that the edit tags for an element within the browse tag create the same path because the document context does not change. I could change the values of the input fields, but the result was stored within the last displayed document.

The question was,
(1) how to give the currently iterated document an individual name.
(2) how to address these documents with individual within the browse tag.

Giving a name was easy, via setvar tag and plugin:

<BR><xapp:browse document="multiEditDocs" pagesize="5"><BR>   <xapp:setvar name="docName">multiEditDocs<xapp:display select="$POS"/></xapp:setvar><BR>   <xapp:directcommand type="mapDocument" arg="${docName$}"/><BR>   ...<BR></xapp:browse><BR></pre><BR>The currently iterated document with name ?multiEditDocs? is mapped to ?multiEditDocs? + number. Instead of one document per iteration. The number of documents increases until the pagesize (5) is reached. At the end of the evaluation of the browse tag, we have documents with the names<BR><BR>?multiEditDocs1? , ?multiEditDocs2?,  ... , ?multiEditDocs5?<BR><BR>But now I didn?t find out a solution how to address documents with a xapp:form tag. The only way I found was to change the source code of the xapp:form tag. Instead of a ?fix? value of the attribute ?document?, the value is evaluated by a variable handler. In this way, the following code is possible <BR><BR><pre class="ip-ubbcode-code-pre"><BR><xapp:browse document="multiEditDocs" pagesize="5"><BR>   <xapp:setvar name="docName">multiEditDocs<xapp:display select="$POS"/></xapp:setvar><BR>   <xapp:directcommand type="mapDocument" arg="${docName$}"/><BR>   <xapp:form document="${docName$}"><BR>        <tr bgcolor="#DDDDDD"><BR>          <td width="30%"><xapp:display select="$ID" /></td><BR>          <td width="30%"><xapp:display select="/Property/Address/State" /></td><BR>          <td width="30%"><xapp:edit select="/Property/Price" /></td><BR>        </tr><BR>    </xapp:form><BR></xapp:browse><BR>



Before posting the solution, I will have a talk with my colleagues, if there is a simpler solution. And, if not, what are the risks of changing the form tag.


Bye,
Christian.

Hello,

I attached a zip file which contains
a) the modified source cod of the class FormTag.
b) An extension of the existing ‘advanced plugin’ example.

Two files of your existing X-Application installation will be overwriten:
- xapplication_313/src/com/softwareag/xtools/xapplication/jsp/taglib/FormTag.java
- xapplication_313/examples/jsp/plugin/advanced/xapplication.xml


If you want to try out this solution for ‘multiple document editing’ then follow the
installation steps:

Installation:


  • Extract the zip into the same directory where you extracted the
    xapplication_3_1_3.zip (parent directory of your xapplication_313).
  • Open a console.
  • Change to your directory xapplication_313.
  • Invoke ‘build’.
  • If started, shutdown your Tomcat.
  • Invoke ‘build examples.jsp.plugin.advanced’.
  • Startup Tomcat
  • Open an Internet Brower and request the following URL
    http://localhost:8080/xapp/plugin/advanced/MultipleDocumentPlugin.jsp


Remark: The JSP page ‘multiDocumentPlugin.jsp’ for this example does not contain
parts for:
- Displaying the JSP source: => open the JSP with a text editor to look at the tags
- Describing the approach: => post to the community if you need more information
about this solution.

I hope it helps you. Let me know whether you could install and try out the example
successfully or you had problems with the installation / understanding of the example.

Bye,
Christian.
MultipleDocumentEditing.zip (8.53 KB)

Hello Christian thanks a lot for your reply.
I installed your solution and it works.
I also modified the source so that it works in my application.
But I only managed to let it work for elements which have minOccurs = “0” and maxOccurs = 1

I need to update a more complex which has
elements with minOccurs = “0” and maxOccurs = “unbounded”

Here is an example of the subtree that I am trying to modify.


8548.00

n1
v1


n2
v2



But I get an error which says that :
" the index within path fragment InvoiceDetail[2] is out of range [0…0]".

Do you have any idea what causes this error?

Best regards
eagle

Hello,

excuse me, but I am a little bit confused. There are three cases we have to check:
(1) Do you want to update multiple documents?
You are using a browse tag and need the extension for multiple editing I made for the form tag.
(2) Do you want to update a multiplicity within a document?
You are using a loop tag and can use a normal commit. It is standard functionality of X-Application.
(3) Do you want to update multiple documents which have multiplicities?
You are using a browse tag and a nested loop tag. You need the extension for multiple editing.

If we are talking about case (3), you must refer with the loop tag to the individual document. In this case we have to change the behavior of the loop tag too. Currently, it requires an own document context. We (you) could

(A) change it for it takes the document context of the enclosing context tag if its document context is not locally set (the document attribute would be optional).

(B) The other way, the evaluation of the attribute ?document? is not done within the form tag but in its super class Context Tag. In this way the attribute can refer to a variable for browse and loop tags also.

I will send a zip file for version B. You should change your page in the following way:

[CODE]

<xapp:browse document=?xDoc?>
… < !-- mapping →
<xapp:form document= ?${yDoc$}?>

<xapp:loop document=?${yDoc$}? …>

</xapp:loop>
</xapp:form>
</xapp:browse>

Have a look at the modified JSP. It contains a loop for the contact persons.

I hope with the new version your problem does not longer occur.

Bye,
Christian.

Hello,

I attached a zip file which contains
a) the modified source cod of the class ContextTag.
b) An extension of the existing ‘advanced plugin’ example.

Two files of your existing X-Application installation will be overwriten:
- xapplication_313/src/com/softwareag/xtools/xapplication/jsp/taglib/ContextTag.java
- xapplication_313/examples/jsp/plugin/advanced/xapplication.xml

[B]Remark:[B] The zip file contains also the original FormTag.java of X-Application 3.1.3
to overwriting an installation of the first zip file I posted to this topic.


If you want to try out this solution for ‘multiple document editing’ then follow the
installation steps:

Installation:

1. Extract the zip into the same directory where you extracted the
xapplication_3_1_3.zip (parent directory of your xapplication_313).
2. Open a console.
3. Change to your directory xapplication_313.
4. Invoke ‘build’.
5. If started, shutdown your Tomcat.
6. Invoke ‘build examples.jsp.plugin.advanced’.
7. Startup Tomcat
8. Open an Internet Brower and request the following URL
http://localhost:8080/xapp/plugin/advanced/MultipleDocumentPlugin.jsp


Remark: The JSP page ‘multiDocumentPlugin.jsp’ for this example does not contain
parts for:
- Displaying the JSP source: => open the JSP with a text editor to look at the tags
- Describing the approach: => post to the community if you need more information
about this solution.

I hope it helps you. Let me know whether you could install and try out the example
successfully or you had problems with the installation / understanding of the example.

Bye,
Christian.
MultipleDocumentEditing2.zip (14.2 KB)

Hello Christian,
Thanks again for your reply.

You guessed it right I am updating multiple documents which have multiplicities.
Which is case (3)(B).

I installed your solution and it works.
I also modified the source so that it works in my application.

I am very close solving my problem.

I can now modify the elements under
But I have one more problem and that is to modify the elements
which are and

I am using loop within loop. Which looks like this:

<xapp:loop document=“${docName$}” select=“.” iterate=“InvoiceRBDetail”
targetbase=“tb1”>

<xapp:loop select=“InvoiceRBDetail” iterate=“dBoklyk”
targetbase=“tb2” document=“${docName$}”>

</xapp:loop>
</xapp:loop>

The problem is that I always get element numer [2]
Maybe I am not using the loop right?

Here is an example of the document that I am editing:





8548.00

n1
v1


n2
v2



1000.00

n1
v1


n2
v2





It would be very helpful if you could tell me if I am using the loop within loop wrong or
if there are any restrictions, that you know of, that prevent modifications of elements
that have multiplicities within multiplicities within your solution.

Best regards
eagle

Things are working now.
I added → base=“tb1”
In the second loop tag and managed to make this work.

Now my loop tags look like this:

<xapp:loop document=“${docName$}” select=“.” iterate=“InvoiceRBDetail”
targetbase=“tb1”>

<xapp:loop select=“InvoiceRBDetail” iterate=“dBoklyk”
base=“tb1” targetbase=“tb2” document=“${docName$}”>

</xapp:loop>
</xapp:loop>


eagle

Hello,

I am going to update X-Application from version 313 to 411. I think that I will run into problems when I update because I am using tags that were modified.
Do you know if the modifications you did for me are in version 411 or will I have to insert them manually?

Best regards
Eagle

Hello,

I checked the topic about the last topic of updating multiple documents. The current version of X-Application (4.1.1) does not contain the modification of the ContextTag.

The changed behavior not to address the documents directly but using the variables handler to resolve the value of the attribute ‘document’ must be added to the source code X-Application.

Did you think, you can make this change by yourself?

It is only the class ContextTag.java that you have to modify. The Plugin code should work as before bacuase we didn’t change the interface for the plugin handling.

If the adaptation is to difficult, please send a post to the community and we will support you.

Bye,
Christian.

Hello Christian,
I am working on the upgrade.
I think I can change the ContextTag myself.
I have modified one method in it,
so now it looks like this:
public int doStartTagCore() throws XException {
// do not place this initialization in the constructor since tag instances
// might be re-used …
if (documentName != null){
setDocument(sessionContext.getVariablesHandler().evaluatingReplace(documentName));
}
return EVAL_BODY_TAG;
}

Then I built xapplication.jar and tried my application.
But I still get some errors which I think that are related to the plugin.

See attachment.

Best regards
Eagle
Error.txt (5.91 KB)

Hello,

the exception is thrown at this place because the collection information is not set.

Please check your xapp:action or xapp:directcommand tags of type=‘query’ and add the attribute ‘collection’. The value is the name of collection (e.g. collection=‘xapplication_test’)

Have a look also to the X-Application-Documentation how to define variables for collection within the xapplication.xml file. You would refer to the collection by the name of the variable (e.g. collection=‘${myCollection$}’).

When using variables you will have a very small effort when you deploy the application. A good example are the simple pages about queries.

Bye,
Christian.

Hello Christian,
Thank you for the reply. After adding collection and schema attributes, I can now display data. But I get an error when I try to update:

StoreException occurred: could not request the last modified date for object ‘declare namespace tf = “http://namespaces.softwareag.com/tamino/TaminoFunction” declare namespace itf = “http://namespaces.softwareag.com/tamino/InternalTaminoFunction” declare namespace xapp = “404” for $wrapper in input()/InvoiceRB where tf:getInoId($wrapper)=97934 return element xapp:Result { element xapp:NodeLocation {attribute id {tf:getInoId($wrapper)}, attribute nodeId {itf:getNodeId($wrapper)}, element doctype{itf:getDoctype($wrapper)}, element collection{tf:getCollection($wrapper)}, element timestamp{tf:getLastModified(root($wrapper))}} , element xapp:Body {$wrapper}}’

Have you got any ideas what this means?

Eagle

Hello,

Are you using database version 4.1.1 or 3.x?

Could you post the complete Stacktrace?

Many thanks,
Christian.

Hello Christian,
I am using Tamino v/4.1.1

Here comes the complete Stacktrace:

2003-04-29 17:33:46 StandardWrapperValve[Controller]: Servlet.service() for servlet Controller threw exception
org.apache.jasper.JasperException: StoreException occurred: could not request the last modified date for object ‘declare namespace tf = “http://namespaces.softwareag.com/tamino/TaminoFunction” declare namespace itf = “http://namespaces.softwareag.com/tamino/InternalTaminoFunction” declare namespace xapp = “404” for $wrapper in input()/InvoiceRB where tf:getInoId($wrapper)=97934 return element xapp:Result { element xapp:NodeLocation {attribute id {tf:getInoId($wrapper)}, attribute nodeId {itf:getNodeId($wrapper)}, element doctype{itf:getDoctype($wrapper)}, element collection{tf:getCollection($wrapper)}, element timestamp{tf:getLastModified(root($wrapper))}} , element xapp:Body {$wrapper}}’
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:248)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:432)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:356)
at is.visa.invoice.event.EventHandlerBase._dispatch(EventHandlerBase.java:39)
at is.visa.invoice.event.EventHandlerBase.forward(EventHandlerBase.java:27)
at is.visa.invoice.Controller.doPost(Controller.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:432)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:386)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:534)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:530)
at java.lang.Thread.run(Thread.java:536)
----- Root Cause -----
javax.servlet.ServletException: StoreException occurred: could not request the last modified date for object ‘declare namespace tf = “http://namespaces.softwareag.com/tamino/TaminoFunction” declare namespace itf = “http://namespaces.softwareag.com/tamino/InternalTaminoFunction” declare namespace xapp = “404” for $wrapper in input()/InvoiceRB where tf:getInoId($wrapper)=97934 return element xapp:Result { element xapp:NodeLocation {attribute id {tf:getInoId($wrapper)}, attribute nodeId {itf:getNodeId($wrapper)}, element doctype{itf:getDoctype($wrapper)}, element collection{tf:getCollection($wrapper)}, element timestamp{tf:getLastModified(root($wrapper))}} , element xapp:Body {$wrapper}}’
at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:530)
at org.apache.jsp.faerslur_edit_jsp._jspService(faerslur_edit_jsp.java:1500)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:137)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:204)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:295)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:241)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:684)
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:432)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:356)
at is.visa.invoice.event.EventHandlerBase._dispatch(EventHandlerBase.java:39)
at is.visa.invoice.event.EventHandlerBase.forward(EventHandlerBase.java:27)
at is.visa.invoice.Controller.doPost(Controller.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:260)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:432)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:386)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:534)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:530)
at java.lang.Thread.run(Thread.java:536)

Best regards
Eagle

Hello,

the problem with the stacktrace is that it is the stacktrace of the wrapped exception that Tomcat generates

Could you create an error page that is invoked and prints out the stacktrace?

or

Could you run your application with Tomcat 3.3.1. It does not wrap the exception and shows the stacktrace of the original exception.

Thank you.

Bye,
Christian.

Hello,
I’m not sure if this errorpage will do the trick but here is a try:
I have an errorpage which looks like this:

<%@ page import=“java.io.*” %>
<%@ page session=“false” %>
<%@ page isErrorPage=“true” %>



JSP Exception Page




Exception Class Name: <%= exception.getClass().getName() %>


Exception Message: <%= exception.getMessage() %>


Exception Stacktrace:


<% exception.printStackTrace(new PrintWriter(out)); %>






And I have attached the output that comes from this errorpage.

Best regards
Eagle
OutputFromErrorPage.txt (6.73 KB)

Hello,

yes the stacktrace is ok.

The Error Message:

XQuery applied on non-namespace-clean doctype:, XQuery Applied on non-Namespace-Clean Doctype: InvoiceRB



says that the collection is not namespace clean.

Did you upgrade a Tamino Database Version 3 to Version 4?

If yes: There is one migration step ‘namespace clean’. Could you check if you run this step?

The problem is, that X-Application gets reported a database version 4. Therefore, XQuery is used to get document meta-information. But, without namespace cleaning your collection, the XQuery functionality is not available.

Bye,
Christian.

Hello,
Thank you for the reply.
Yes, I upgraded from version 3 to version 4. And you are right. I didn’t run namespace clean.

I’m currently working on the namespace cleaning. There are some problems with the migration tool which I sent directly to the helpdesk.

Best regards
Eagle