[Domino Visual Editor] Generate Royale Jewel Interface

[JustinProminic]

It is time we address this... FlexJS should be removed, in favor of Royale Jewel component output.

The general goal is for someone to build a working Royale Jewel application within 5 minutes after installing Moonshine, and no more than 10 mouse clicks.

[piotrzarzycki21]

@JustinProminic I'm not quite sure what do you mean here. If you have in mind having another type of project in Visual Editor where user can create UI interfaces by drag/drop on surface area - same as we have for PrimeFaces etc. - This is rather huger tasks and it should be named differently probably.

[JustinProminic]

@piotrzarzycki21 we already have a Visual Editor format which outputs to obsolete FlexJS. We need to end support for FlexJS and have it output support for Apache Royale Jewel UI components. At least basic stuff. Field labels, field input, etc. The basic functionality we had from the FlexJS visual builder should be able to fairly easily be re-purposed to use Jewel components in the UI definition file that is generated for Royale. @rat-moonshine please add your thoughts.

[rat-moonshine]

I probably a little confused, @JustinProminic . I believe we decided to obsolete FlexJS long back in Moonshine. I don't see we have any support for FlexJS either,

Perhaps, you meant about Visual Editor support that we have for Flex and PrimeFaces?

I think I understood that you wants same mock-up support for Royale Jewel projects, too - whether you wants to remove any existing type (Flex, PrimeFaces) and add Jewel, or it'll be just a new addition, that is not clear to me. I don't think we output for FlexJS through Visual Editor, though.

[JustinProminic]

@rat-moonshine @piotrzarzycki21 @JoelProminic

Visual Editor project needs to support - in the long run (no particular order here):

1. PrimeFaces (current support is rudimentary but functional at least)

2. Notes/Domino forms (under development by @feather812002 Bing)

3. Royale Jewel UI component -- a replacement for what we had in FlexJS. I did not realize we had ripped this out. I thought the code was still pretty much in Visual Editor but the output format was only targeting FlexJS.

and when Josh is ready:
4) FeathersUI for Haxe output, in various formats that FeathersUI will work (@joshtynjala )

These are the value added features that make Moonshine truly unique, and harken back to the Flash/Flex Builder days (but not attempting round-trip like it did).

So, if I misunderstood where we are at with the FlexJS code, we can talk about that on the next Wednesday meeting. I was merely trying to lay out the roadmap for updating this feature so that those kicking the tires on Royale Jewel components can use the existing Visual Editor to create a very basic form without coding.

[JustinProminic]

Furthermore, we had an entire system we built a while ago that would take Notes/Domino forms and convert them to FlexJS. I'm pretty sure the intermediate format was the Visual Editor XML. So the flow was Notes/Domino DXL -> Visual Editor -> FlexJS.

@JoelProminic am I misremembering this?

[piotrzarzycki21]

3. Royale Jewel UI component -- a replacement for what we had in FlexJS. I did not realize we had ripped this out. I thought the code was still pretty much in Visual Editor but the output format was only targeting FlexJS.

@JustinProminic We have never had in Visual Editor output to FlexJS, unless I'm not aware of something and code is laying somewhere on the Prominic sight where I don't have access. As @rat-moonshine said we do have output in Visual Editor to Flex and PrimeFaces. Making Visual Editor for Royale Jewel is something new and unexplored yet.

[rat-moonshine]

We need to discuss on feasibility of this requirement since this issue is long opened and moving through milestones. As I understand FlexJS is now dominates by its next generation RoyaleJS. Although, it appears that Apache still distributes FlexJS source through their website.

An issue like this is breadth of a milestone, do we want to keep this into our queued tasks?

[JustinProminic]

@feather812002 @rat-moonshine @JoelProminic @piotrzarzycki21

I have just sent you direct e-mail subject "Moonshine IDE -- Notes Client to FlexJS prototype -- Fix Visual Editor to output Royale Jewel components instead of FlexJS #675"

dated:
11/09/2021 01:43 AM Chicago Time

Please read it as it has the details on our past efforts on this aspect of conversion.

[piotrzarzycki21]

FlexJS is now dominates by its next generation RoyaleJS

@rat-moonshine no it's not "dominates" - It is exactly the same framework. We have changed project name to do not connect project fully with Flex.

[piotrzarzycki21]

Although, it appears that Apache still distributes FlexJS source through their website.

Yep and it will be. Each release is archived so there is no way it will just disappear. I'm not sure where do you see that but it will stay for sure.

[rat-moonshine]

@piotrzarzycki21 It could be, that FlexJS and Royale are same (because of the underlaying framework both uses) - but as a layman I see both are different products (I'm sure we also puzzled between using which products by their names), and suggested to use Royale over FlexJS.

I've seen the distribution at here: https://flex.apache.org/download-flexjs.html.

[JoelProminic]

In any case, I would expect the FlexJS code from our previous work to be obsolete at this point. I think we will probably be better off using the templates from #704 as an example.

@feather812002, take a look at the template created by @piotrzarzycki21. We will probably need some more examples to implement all of the DominoVisualEditor options, but this will be a good place to start.

[JoelProminic]

@feather812002 is getting ready to switch to this task, so I wanted to supply some useful references:

• Example project: Flex or Royale UI Based CRUD on Tabular Interface #704 (comment)
• Templates from Flex or Royale UI Based CRUD on Tabular Interface #704: https://github.com/Moonshine-IDE/Moonshine-IDE/tree/features/issue_704_royale_CRUD_tabular_interface/ide/MoonshineSharedCore/src/elements/templates
• Royale Documentation: https://royale.apache.org/docs/
• Jewel and Royale examples: https://royale.apache.org/tourdejewel/

[JoelProminic]

Unfortunately, I found that the example project was failing:

: /Users/-user-/Downloads/RoyaleTabularCRUDTemplate/src/RoyaleTabularCRUDTemplate.mxml(12): col: 2 Error: Cannot parse a value of type 'org.apache.royale.core.IApplicationView' from ''.
: 	<j:initialView>
: 	^
: /Users/-user-/Downloads/RoyaleTabularCRUDTemplate/src/RoyaleTabularCRUDTemplate.mxml(13): col: 3 Error: In initializer for 'j:initialView', type view.MainContent is not assignable to target type 'org.apache.royale.core.IApplicationView'.
: 		<view:MainContent />
: 		^
: /Users/-user-/Downloads/RoyaleTabularCRUDTemplate/src/view/MainContent.mxml(2): col: 1 Error: This tag could not be resolved to an ActionScript class. It will be ignored.
: <j:ApplicationResponsiveView xmlns:fx="http://ns.adobe.com/mxml/2009"
: ^

I did some minimal fixes to resolve the compilation errors, but I see that I can't submit the forms now. @rat-moonshine or @piotrzarzycki21, can you revisit this template when you have a chance. We can discuss this in more detail in the meeting tomorrow.

2021_11_16__RoyaleTabularCRUDTemplate_JoelProminic.zip

[piotrzarzycki21]

Unfortunately, I found that the example project was failing:

: /Users/-user-/Downloads/RoyaleTabularCRUDTemplate/src/RoyaleTabularCRUDTemplate.mxml(12): col: 2 Error: Cannot parse a value of type 'org.apache.royale.core.IApplicationView' from ''.
: 	<j:initialView>
: 	^
: /Users/-user-/Downloads/RoyaleTabularCRUDTemplate/src/RoyaleTabularCRUDTemplate.mxml(13): col: 3 Error: In initializer for 'j:initialView', type view.MainContent is not assignable to target type 'org.apache.royale.core.IApplicationView'.
: 		<view:MainContent />
: 		^
: /Users/-user-/Downloads/RoyaleTabularCRUDTemplate/src/view/MainContent.mxml(2): col: 1 Error: This tag could not be resolved to an ActionScript class. It will be ignored.
: <j:ApplicationResponsiveView xmlns:fx="http://ns.adobe.com/mxml/2009"
: ^

I did some minimal fixes to resolve the compilation errors, but I see that I can't submit the forms now. @rat-moonshine or @piotrzarzycki21, can you revisit this template when you have a chance. We can discuss this in more detail in the meeting tomorrow.

2021_11_16__RoyaleTabularCRUDTemplate_JoelProminic.zip

What version of Apache Royale did you use to build that example ? I just tried it and I'm able build with official release 0.9.8 and fresh nightly 0.9.9.

[rat-moonshine]

What version of Apache Royale did you use to build that example ? I just tried it and I'm able build with official release 0.9.8 and fresh nightly 0.9.9.

Does that means this basic template-codes is still valid with latest Royale nightly, and without any break?

[piotrzarzycki21]

What version of Apache Royale did you use to build that example ? I just tried it and I'm able build with official release 0.9.8 and fresh nightly 0.9.9.

Does that means this basic template-codes is still valid with latest Royale nightly, and without any break?

It looks like it is.

[JoelProminic]

I meant to discuss this in the meeting today, but it is just as well that we missed it with how late the meeting ran.

I tested with 0.9.9. I think this instance was a few weeks old though.

To be clear, I got the error on the previous example here. I resolved the compilation errors with my updated example.

However, I'm seeing that the submit button on the form doesn't do anything currently. Does this need to call some external API? I didn't notice any errors on the browser console in my test.

[piotrzarzycki21]

@JoelProminic I didn't put a notes. Do you remember if priority was in that order:

1. Make forms read only on demand
2. Put text and rich text editor into new line
3. Agreed on behaviour of paragraph

[JoelProminic]

The priorities I noted from yesterday's meeting were:

• fix missing newlines between labels and fields.
• Edit Mode/Read only

For the newline issue, I see that some of these cases have the command label and the field in the same paragraph (i.e. hostname), while others have separate paragraphs (i.e. uname -a):

I consider the same paragraph cases a bug in the conversion process. I'll create a separate issue for this after I retest.

We'll need to clarify the definition of the Paragraph component for the separate paragraphs case. We could either add clarification that Paragraph always indicates a separate line, or we can update the converted database to use vertical layout for the parent. I'll keep you updated on this.

For the read-only and edit modes, I see two common use cases:

• We want the interface to be read-only. This is case for OmniOS Performance Stats
• We want a full CRUD interface for the application.

We can brainstorm how we want to support these two cases.

• Separate options for read-only and CRUD interfaces? Would this result in more duplication?
• Configurable options for the forms for read-only/editable. I'm not sure if this fits with the current design, though.
• Would it make sense to always generate the CRUD interface and then provide flags/instructions to disable the read interface? This could be a unified solution if we aren't concerned that it will generate messy code.

We could handle the read-only and edit modes like we do for the MyDetails section in MyAccount. This logic seems clean on the UI side, but I'm not sure how well it would work for generated code.

[Aszusz]

I checked the weird wrapping in the long commands:

and it turns out, there's \n character in the original forms, so it's not a conversion issue

[JoelProminic]

Thanks @Aszusz, I didn't see this when I was comparing the interfaces yesterday. There will probably be other backslashes in the commands, so watch the escaping on this. I can see some other examples in your screenshot:

This is an unusual case that I wouldn't expect to see in other database, but this is one of the key databases we want to convert.

[piotrzarzycki21]

I have pushed changes related to "readonly" form to master. The changes I made is that every form has property which allows switch between readonly/edit mode. Once you convert domino project to Royale and open any view you will see inside property called isDisabled, default value is false - which means form is in edit mode - change it to true and recompile application.

However I'm not sure to which direction I should go from that point. I see two options:

1. User on it's own provides some Button/Switch for his form which changes in individual form property isDisabled to true/false
2. I'm adding during conversion such button, but I see in this action some inconsistency - cause this kind of button won't be something which is present in DXL. It's position may not be determined correctly.

Thoughts ?

[piotrzarzycki21]

or we can update the converted database to use vertical layout for the parent.

This part is something which may causes more issues. If parent of my paragraph has other children - not necessary paragraphs we may have them positioned in a weird way. Unless by that sentence you are saying about paragraph itself with children - and making that container vertical.

@JoelProminic please discuss this paragraph issue with Justin. I may not be able to join Wednesday's meeting, but I would like to have it implemented so you will be able to try it out.

[piotrzarzycki21]

I consider the same paragraph cases a bug in the conversion process. I'll create a separate issue for this after I retest.

@JoelProminic just to be clear this code is being considered as a bug ? Cause it translates in Moonshine as a one paragraph, but it should be two actually ?

    <par def="1007" paragraph="true" dominotype="paragraph" class="flexHorizontalLayout flexHorizontalLayoutLeft flexHorizontalLayoutTop">
        <run>
          <font color="system" style="normal"/>Key:  
        </run>
        <field useappletinbrowser="false" allowtabout="false" defaultfocus="false" protected="false" sign="false" storelocally="false" value="Key" type="text" kind="editable" computeaftervalidation="false" allowmultivalues="false" width="100pt" height="30pt" bgcolor="#ffffff" name="Key"/>
      </par>

I need to wait till you fix that ?

Currently we have following situation after conversion to Royale:

<VGroup> - Parent
     <HGroup> - Paragraph
     </HGroup>
</VGroup>

Each new paragraph is going to the new line. Is this how I should preserve that ?

[JoelProminic]

@piotrzarzycki21, your first example (from "ConfigValue") is correct as-is. The label and the field are on the saem line in this case. The layout should be like:

<VGroup> - Parent
     <HGroup> - Paragraph
        Label
        Field
     </HGroup>
</VGroup>

The problem is this case, from Host Config Snapshot:

                  <par def="1307" paragraph="true" dominotype="paragraph" class="flexHorizontalLayout flexHorizontalLayoutLeft flexHorizontalLayoutTop">
                    <run>
                      <font color="system" style="normal" name="monospace"/>$ hostname
                    </run>
                    <break/>
                    <run>
                      <font color="black" size="10pt" style="normal" name="sans-serif" pitch="variable" familyid="Roman" truetype="true"/><field listdisplayseparator="newline" listinputseparators="comma semicolon newline" useappletinbrowser="false" allowtabout="false" defaultfocus="false" storelocally="false" value="HostnameOutput" type="text" kind="editable" computeaftervalidation="false" allowmultivalues="false" width="106pt" height="30pt" bgcolor="#ffffff" name="HostnameOutput"/>
                    </run>
                  </par>

This example only has a single <par>, but it displays on two lines because of the <break/>. I'm not sure why Domino Designer did this for some of the cases, but I'd like for NSFConverter to normalize this as two paragraphs in the intermediate XML.

See #1033 for more details. In the meantime, you can treat the single <par> as a single line, so the layout will look the same as your example. <break/> doesn't appear in the Mockup (and i don't think it makes sense to have it) so I don't want to support it.

[JoelProminic]

The base code for this is working. We will handle the remaining work in separate issues like #1039 and #1040.