Studio Black Box Model
Studio was originally designed as a black box: you don't have to modify what Studio generates, basically it means that the way Studio's builders do their jobs is not interesting to the end user.
Unfortunately, it it not always true:
- People may use XML extension to override contributions generated by Studio
- For example to add details that are not configurable via Studio
- People may reuse Studio contributions IDs inside their code
- Reusing filterID
- Reusing layoutid -...
We recently had a very clear example of that (see NXP-11633 ):
- Default Workflow is Studio generated
- At application level people use the ID of the Studio generated filter to add DocumentTypes to the workflow
- We did some change in Studio that broke the ID generation
- It broke some projects
- We had to make a specific post build script to handle this issue
Fixing The Workflow
The workflow is both a good and a bad example:
- This is indeed a real life issue but
- There is not good reason for using a filter to define target document types
- This should be a dedicated extension point
There are basically 2 approaches to handle the issue:
- Make all IDs user changeable
- Make generation result and changes more visible
The first option is technically very complicated, especially when considering refactoring, cross references and multi-users mode.
The second option (that we are likely to choose) is to add a new tab on each feature that allows to see the generated XML:
- This is reasonably easy to do (and in a transversal way)
- This allows end users that want to override
- To see the XML without having to open the generated jar
- To easily check for ID changes is case of problem
Please tell us if you would like to see that.
Guillaume (our latest addition to the team, welcome!) is working on merging into the trunk, maybe for 5.7.1 (no pressure!), some of the UX improvements that had been prototyped:
- Safe Edit (started during a sprint and partially integrated for FICO)
- Ajax Tabs switching
- Access keys
Ajax and State Management
People have reported issues about some components not always being reseted when using Ajax navigation. This basically create a "caching behavior" during Ajax navigation.
Anahide fixed this in NXP-11566. She will soon provide some background and advices so that we can all help fixing issues and avoid creating new ones.
JSF/Seam state issues
The issues about JSF max logical views and Seam conversation concurrency are still here. We may need to quickly build a custom version of Seam to address this:
- Views state: extend Seam view State Manager to manage views on a per conversation basis?
- Conversation: limit locking on INVOKE_APPLICATION phase?
Targeting a custom Seam version may allow us to do some easy backport (that would be needed for most customers). See Make JSF/Seam more resilient to mulithreaded navigation NXP-11677 for more details
In the next days, we'll try to:
- Integrate it in default bundles (probably merge the content rather than adding a new module)
- Integrate it in layout demo
APM tools like AppDynamics or NewRelic are getting more and more traction.
However, so far, we have mitigated feedback:
- From customers that use one
- Conferences and discussion we had with people working in that area
Tools are important, but it looks like:
- It is very hard to impose a tool to "operation guys", especially if they have to pay for it
- Let's try with Mathieu!
- Even a good tool is useless if you don't configure properly and monitor the correct info
We should continue the work that we started with Metrics:
- Continue improving Monitoring on the intranet
- Write doc and guide lines
Benches and monitoring have shown that when doing massive import we end up having a lot of
EventBundlesstacked for latter processing. Even if
EventBundlesare as shallow as possible, having several x0 000 of shallow eventbundles can still create high memory pressure and slow performances.
We could at the very least add a hard limit to avoid stacking events to death. However in conjunction with the
EventServicebulk mode we should be able to find a better solution.
Of course an option could be to persist to disk the worker queues (that stack the async event handlers): that will be addressed in the context of the
Work on handling complex properties has been merged and Vlad has also added a lot of tests on marshaling.
Thanks to Stephane and Vlad, Automation client is now OSGi compliant.
Nicolas (new intern, welcome too!) is re-spawning the AndroidConnector that is actually an AutomationClient + cache++ . We'll see if we can, at some point, address the convergence issue.
New REST binding, are still in standby for now, but Damien seems to be in hurry to address that asap. We also plan to improve the "JS batch" interface that is actually used by both DnD and Android.
The next steps on Automation improvements include:
- Exception and debug management (already discussed in a previous tech report)
- Vlad with the help of Stephane will jump in when possible
- Long Running / Multi-Tx automation chains
- How to manage Tx on Automation chains that needs to process a lot of documents
- Is needed by several use cases (Archive, Retention, Automation Batch) and clients (Jeppesen)
- We'll need to fix the Session/Tx association issue NXP-11681
HTML5 DnD and DAM
DAM import dialog need to reuse the HTML5 DnD system. We will leverage this work to improve the existing infrastructure.
Leverage Action Properties
The current DnD system uses Actions for configuration. At the moment it was built, Actions had no properties and we are missing some attributes. The idea will be to realign to properties and update the documentation.
Re-align HTML Attributes Names
The current system is using custom attributes on div tag. We should align on what the best practices and use
data-prefix. We'll manage backward compat.
Modularize the JS
The JS code is already split in 3 parts:
- The Droppable zone handler: detects DnD
- The upload handler: manage upload in a pooled queue
- A UI handler: display progress and dialogs
For the DAM use case, we will need to provide a different UI handler. This means we need to be able to change the UI handler at init time.
Init From JSF
In the default DM case, the DnD is completely initialized from JS. In the case of DAM, DnD will be inside a Popup that is ajax rendered. This means we can initialize the DnD from the JSF side:
- Resolve actions
- Resolve context.