Moonshine-IDE
Subform Support in Royale Conversion
On of the big remaining features for Royale conversion is subform support. See more information about the configuration in #1015
UPDATE: I wroteup some design for the Royale and Agent structure here
I need to provide an example project for this, with examples of nesting.
Note that this is not dependent on a real NSFConverterPortalProject converted database. We can create the subforms from the mockup editor as well.
Here is the example database we discussed in the meeting. Let me know if you need more guidance for it: Database: TestSubform2.nsf.zip Converted project: TestSubform2_DominoVisualEditor.zip
Hey @feather812002 . Can you please explain what is the purpose of that file ? Why it should exists and is needed during conversion ?
@piotrzarzycki21 @JoelProminic Okay, if do you mean about this public static function convertDomino(file:FileLocation):void
The method work for that project export from NSFConvertProtal , The work flow as follow:
- Customer upload a NSF database and export a Visual project from NSFConvertProtal.
- Customer open the Moonshine-IDE , then open& import the Visual project with Moonshine-IDE. The method in here will convert the Visual project to Domino Form/Subofrm/Page or other some Domino element save as dxl file .
- Customer just run the build with ODP command with Moonshine-IDE or in the terminal , it should be build back to NSF database.
In short , the method work for auto convert the intermiddle xml that export from NSFConverprotal to dxl file , and let it can build to NSF database again , @JoelProminic know more details about this . If you have more question about this you can talk with @JoelProminic in the daily meeting direct , he must can explain more good than me .
Thanks.
To discuss for todays meeting:
- Where subforms should be placed in
/nsfs/nsf-moonshine/odp - Where subforms should be places after conversion to Royale
- Where subforms should be placed in
/nsfs/nsf-moonshine/odp
I think for this topic , it only have one answer :
The subform must should placed into /nsfs/nsf-moonshine/odp/SharedElements/Subforms
Then it can success build to NSF database again , if you put the subfrom dxl file in other place, it will break the NSF database build .
I hadn't put too much thought into the structure for the agents and value objects. We discussed thids today, and I suggested this design:
- The agents will return a flat list of the fields and in the form and subform
- Generate an
interfacefor each subform which will define the fields in the subform. This will be used for binding later - When generating the VOs for the forms, implement the referenced subforms
- Generate separate MXML views for the subforms, which will bind to the corresponding interface.
- The generated MXML views for the forms will have references to the subform views. The bound value object will need to be propogated to the subforms.
I ran out of time to writeup some clean examples today. I'll send an email with the raw examples from today's meeting, and let me know an example would be helpful.
Here is the example database we discussed in the meeting. Let me know if you need more guidance for it: Database: TestSubform2.nsf.zip Converted project: TestSubform2_DominoVisualEditor.zip
@JoelProminic when I double click on provided nsf I don't see anything in my Notes client.
That looks normal - I probably didn't include any example documents in this database. New documents can be created from the Create menu.
@JoelProminic as we have discussed I'm attaching example manually modified Royale app. TestSubform2_Royale.zip
Looking at the project, this is a bit off from the design I was proposing. I made a modified copy as an example. My changes:
- The Subform interface extend the interfaces for any nested subforms
- I removed IDominoVO from the subform interfaces. Subforms will not have separate documents, so they don't have separate DominoUniversalIDs
- Form VOs interfaces should implement the nested subform interfaces. The Form interface is probably not necessary here
- Remove the Subform references from the Form VOs - the fields will be implemented directly in the VO to satisfy the interface
- Copy the field implementations from the subform VOs to the form VOs
- Remove the Subform VOs - these will be implemented in the Forms VOs
- Update the subform binding in the Form and Subform Views to be the original object rather than a subform reference. Note that the type of itemVO is still does not change - it is the corresponding form or subform interface
The project compiles for me, but there may have been some changes that I missed. If this needs more explanation, we can discuss it tomorrow:
TestSubform2_Royale_Modified.zip
Looking at the project, this is a bit off from the design I was proposing. I made a modified copy as an example. My changes:
- The Subform interface extend the interfaces for any nested subforms
- I removed IDominoVO from the subform interfaces. Subforms will not have separate documents, so they don't have separate DominoUniversalIDs
- Form VOs interfaces should implement the nested subform interfaces. The Form interface is probably not necessary here
- Remove the Subform references from the Form VOs - the fields will be implemented directly in the VO to satisfy the interface
- Copy the field implementations from the subform VOs to the form VOs
- Remove the Subform VOs - these will be implemented in the Forms VOs
- Update the subform binding in the Form and Subform Views to be the original object rather than a subform reference. Note that the type of itemVO is still does not change - it is the corresponding form or subform interface
The project compiles for me, but there may have been some changes that I missed. If this needs more explanation, we can discuss it tomorrow:
I have pushed to master changes which allow transform sub forms to Royale according to our plan. Let's discuss what's next on our meeting.