Updated the method hat validates report template documents and moved it from RTMUtils to ReportTemplateDocument, Updated pom.xml to explicitly add surefire plugin with verstion specified to fix build problem, tweaked dev version of MRRT.ini for my dev environment, several other changes to fix test execution, picky javadoc generation and html validation
Fixed logging so logs to runDirectory, start changes to fix template format changes.Term tags have single code element with values moved to attributes from elements.
Remove the LOGIN button from the header; replace with a placeholder withempty lines. This probably needs to be revisited (formatting if there is
no login button).
Update Report Template Creator / Retrieve test to look and act like the other tests.1) All controls together in one table
2) Combine the Retrieve and Evaluate into a single action
Cosmetic changes on the pages for Report Template Creator: + Queries test + Store testPlace all control buttons in one place, formatted in a table.
Whitespace cleanup in html.
Remove all references to the /x folder. Move all code that defines a path to the ApplicationBean. This will make it easier to make changes in paths. There is still one reference to the QRXML files (something like that) that needs to change.Update the RC-Query test by removing extra buttons and putting all of
the needed buttons together in one location.
Update the MRRT-RCQuery test. Some cosmetics on the XHTML pages.In the backend code, replace all references to the "x" folder with newer
folder names.
All folder names/paths are now defined in the ApplicationBean for
consistency.
Deleted the runDirectory/x folder and replaced it with folders / namesthat are more indicative of purpose.
The "x" folder was meant to be a placeholder.
Changed the evaluation in the Report Template Creator test MRRT-RTCRetrieve.
The previous evaluation for Retrieve requests was trying to determine if
a template existed for the template UID. Changed the evaluation to make
sure the UID sent in for the request is legal. We do not care if a
template actually exists. That is a runtime error that is an application
issue. Maybe we will design another test to constrain the template IDs
that can be searched.
Progress on the RTC retrieve test. Added debugging; found out that theevaluation is checking for legal UIDs against our templates. We need to
change that to make sure the request is legal. We should not care if the
template exists.
Update the RTC Store test by removing the "Store Bad" control and makingother cosmetic changes.
Update the utilities code that stores corrupted report templates. The
old version assumed the file name was equal to the template ID. We
changed that assumption with new test data from Lynn.
Cleanup work on the retrieve test.We now display the HTTP responses from both the system under test and
the RTM simulator as well as an evaluation of the templates that are
returned.
Repair logging in ReportTemplateManager; we had forgotten to get a copy of the log object in the method that gets a template.Update the RTM Retrieve test to iterate through a list of identifiers
from a file and not hard-coded in java.
Still need to complete the validation for the Retrieve test.
Fix a typo in the display of the number of templates returned by the RTMunder test in response to queries. We had been displaying the count from
the RTM simulator.
Start the processing of replacing the "x" folder with a set of folders that are better named. The x was just a placeholder.Also, move all definitions of the names of the folders into the
ApplicationBean. Classes that need folders should get the path from the
ApplicationBean (lots of get methods) and not compute paths. This puts
all of the naming conventions in one place.
Cosmetic changes to the Store/Retrieve test.Update to the retrieve code to catch the exception for network
communication and return an appropriate error with comment.
That was in there for Joey's original implementation, but I had removed
it when I added my own method.
Update the RTM Store test1) Test is no longer hard-coded in java
2) Test can send one or more report templates based on UIDs in a text
file
3) HTTP status for each stored template is displayed.
4) Removed the evaluate button. Just display the store status for each
template.
ReportTempateManagerDatabase provides the back end functions for theReport Template Manager. This will allow us to separate the
file/database operations from the web queries.
ReportTemplateReference is a bean that references a report template thatis stored on disk. It contains the metadata and a file reference.
It does not contain the entire template.
Updates to the Template Manager query/retrieve test. This test is now driven by a table of queries in a text file rather than being hard coded in java.The retrieve part was removed and needs to be put back in. The basic
structure remains, but lots of little changes added up.
The Report Template Manager Store Bundle should now be complete. We read the list of template UIDs from a text file and store only those templates to the RTM under test.You can now edit that text file after installation if you want to modify
the test.
For the Store Bundle test for the Report Template Manager, read the list of template UIDs from a file at runtime.We are halfway through that transition. I have the file of UIDs in the
folder and the Application Bean has a copy of them. I still need to
alter the code to push those files and not the hard coded list from
before.
ReportTemplateMetadata is a bean with entries for each metadata item in a report template. It also contains a File object so we can have a unified reference to the metadata and the file.It does not have the template text itself (but you can find that by
opening the associated file).
store-bundle.txt is the list of template UIDs for report templates sent to a Report Template Manager as part of the Store Bundle test.It is just a list of UIDs to be read by the application. The application
will find the corresponding report template and push the template to the
Report Template Manager.
drm
Steve Moore