Page Comparison

...

Debugging, troubleshooting

Debugging in the UI layer

Poster - Firefox plug-in for POSTing
https://addons.mozilla.org/en-US/firefox/addon/poster/

...

Chrome has an equivalent; its UI is not great

In Firebug:

• To see the JSON request payload being sent by the UI layer to the app layer, set a breakpoint in DataContext.js, near the end of the BuildOpts function (e.g. var buildOpts = function (...)), in the if (data) ... statement.

...

• To see the JSON response payload being

...

• returned by the app layer to the

...

in var BuildOpts

• UI layer, set a breakpoint in DataContext.js, in the BuildOpts function, in the if (responseData && ...)

...

to see response data from the app layer

...

• statement.

Debugging in the App layer

Testing if a new field is working in the app layer
Set up new test in cspi-services
maybe not for extension

Inspect uispec, uischema coming out of the app layer
You should at least see the name of the field in there somewhere

(See App layer calls below for more details.)

Logging for troubleshooting

...

Adding a new procedure in the services layer

Choose an existing procedure, and clone it (e.g. with 'svn export' or git equivalent) to a new folder, alongside other procedures' folders in the services tree

Literally do these case-sensitive searches and replaces everywhere (e.g. if cloning 'Movement' procedure to 'Foo' procedure):
Movements -> Foos
movements -> foos
Movement -> Foo
movement -> foo
MOVEMENT -> FOO

The core classes you're going to care about include:
__Resource.java
in the 'service' folder of the module
and a Nuxeo-specific __DocHandler.java file

for authority services
has sub-resources, authority plus the authority item
have twin document handlers, one for the authority and one for the authority item
tend to have only logic around displayname computation, which might go away later on anyway

...

almost everything follows a pattern

once you're done modifying your service, and it at least builds

• There is an existing document on the wiki on how to hook a new procedure into the services layer

Adding a new procedure in the application layer

Add a new procedure in the app layer by making the following changes:

• in tomcat-main/src/main/resources/defaults:
  • add a new base-...xml file
  • add a new domain-...xml file
  • edit base-relations.xml to add new record type as a relate-able record type
    • (Per Chris M, this base-relations.xml file also has an 'all' keyword for all relation - or record? - types, but we don't appear to be using that currently)
  • edit the id / number pattern config file, base-other-idgenerator.xml, to add any automatically generated number patterns needed (also need to make the generator(s) in the services layer; there's a document on the DOC wiki about that)
• in tomcat-main/src/main/resources:
  • add an xml include line to point to your new procedure's base-* file, to *-tenant.xml (e.g. core-tenant.xml and lifesci-tenant.xml) (in app layer tree)
  or in
  • and to our-tenant-tenant.xml (in the mini-build)
• edit the id / number pattern config file to add any automatically generated number patterns needed (also need to make the generator(s) in the services layer; there's a document on the DOC wiki about that)

...

• • add an xml include line to point to your new procedure's base-* file, to default.xml (this file appears to still be used in populating the lists of record types, at least in app layer tests)

Inspect uispec, uischema coming out of the app layer You should at least see the name of the field in there somewhere

(See App layer calls below for more details.)

Create App layer tests, including test datafiles

Adding a new procedure in the UI layer

Add a new procedure in the UI layer by making the following changes:

• Add two (2) new HTML template files, cloning and editing from similar files
  • main record page (in defaults/html/pages)
  • advanced search page (in defaults/html/components)
• Add two (2) new JSON config files in the UI's defaults/config folder, cloning and editing from similar files
  • main record page (...json)
  • secondary tab page (...-tab.json)
• Bundle overlay file

...

• • ) (this config file is needed for a new procedure, but not for a new authority record type)
• Add text labels relevant to the new procedure to the default message bundle file, defaults/bundle/core-messages.properties

In addition, for authorities, need to edit js/Demands.js and clone and edit the relevant block, from an existing entry for another authority
per Yura, at some point you won't need to do that, app layer might be able to generate this for the UI

When working on the additions above, fetch the UISpec by making a call to the app layer, after doing app layer config, in order to make editing the HTML templates and message bundle easier. This will show you:

• Selector names needed in the HTML templatetemplates
• Message label keys needed for bundle

Finally, fetch the UISpec and UISchema by making calls to the app layer, and place those into src/test/uispecs and src/test/uischema. Those static JSON files are used for local testing of the UI layer.

Message bundle overlay - could this be per-tenant for contributions?
App layer might be able to read all files in bundle folder
App layer merges all overlay files just once

• App layer init doesn't rebuild that - it could be added

Create advanced search form template for your new procedure

...

...

Boolean fields

In UI, would add checkbox
Test cases added to ensure that's working
test/js/RendererTest.js

...

set datatype to boolean in app layer config, default value is false

Chris identified she needs to make a change to the XML/JSON conversion class to preserve the type as Boolean

Documentation

John K:
Removing lots of old cruft from the DOC wiki in the customizing area
some docs partly useful, but ...

...

• Document how to enable caching

App layer calls, tips, suggestions

...

A few additional calls are in
TenantServlet

• init
• composite

In TestUIRecords.java
testMisc()
will create 10 records of every object, procedure type
default /generator, may create 20 objects of each

...

Long discussion of <services-tenant-singular> in Ray's base-procedure-claim.xml app layer config file for Claims. Possible need to wildcard suffixes in relation searches in the services, to pick up extension DocTypes that are truly extensions of standard DocTypes but whose names might include a tenant identifier as a suffix.

Return last template used in Core part
Could be used to template - for Concept authority UI tweaks, perhaps even for extending services like Group for purposes like research visits

...