Open djay opened 8 years ago
I love the idea. I am pretty sure it is a lot of work, but such a tool would be very useful.
Maybe plone.restapi could be helpful (instead of implementing the backend endpoints needed by this single page app, we just use plone.restapi).
@djay FYI, I will have an intern working on that topic (starting in April)
@ebrehault thats fantastic news. We intend to work on helpers idea once we get client signoff (#618). One thing I didn't put in the mockups above was an alternative UI for helpers being virtual subobjects as well under Form or Field. I'm not really sure about it because then logically a helper instance should have a name, which it doesn't really need to. On the other hand, to include it inside the settings screen ( asin the mockup above) means its kind of a CRUD inside a CRUD. What do you think?
I think two additional things missing are
Use Mosaic to manipulate the form layout instead of TinyMCE sounds strange (physically, a Plomino form layout is an HTML string, Mosaic is not an HTML editor).
@djay work in progress! @Bo-Duke started today.
@ebrehault mosaic is actually an html editor. Just that it moves around place holders which are html, in the same way that plomino moves around place holders which are html. The difference is that mosaic placeholders have to be grid cells. I'm not sure how that would map into plomino.
But then how do you have fields inside a table for example? Either it would require something like shortcodes/line tiles (tinymcetiles) or two modes, mosaic vs tinymce.
@djay I don't think the technical difference is really the key thing here. I am more worried about the functionnal difference: when you edit a form layout, you really don't want to cut it down into columns and rows, or to snap to any grid. This is not flexible. When you design a form, you should be able to write it from top to down just like if it was an actual paper form. TinyMCE proposes a Word-like approach, while Mosaic is an Excel-like approach. My experience is that creating a form with Word is just fine, but creating one with Excel is a nightmare.
Nevertheless a dual mode could be useful in some cases.
Created a new issue that should really be part of this one. I don't think I really showed this in the mockups above and was just wondering if this was going to be included in the IDE work? https://github.com/plomino/Plomino/issues/736
@ebrehault I've been thinking about it more and I think settings shouldn't be in its own tab. I suggest that all form, field, action, hidewhen settings appear in a splitpane to the right of the form layout to which they belong. I think it will feel natural to use the layout to click on a field and then edit its settings without having to switch tabs. This will also reduce the opening and closing of tabs as only one settings within a form can be open at once. It also means you don't have lots of repeated fieldids cluttering the screen.
true, makes sense
New UI mockup. https://app.moqups.com/djay@pretaweb.com/jbaUkc1plo/view
Main differences are that
Need to get the visual fields feature working in the ide. To do this need to look at how the code in tinymce.js works from this branch - https://github.com/plomino/Plomino/tree/tinymce_field_settings and make it work instead when you drag a field from the left tree into tinymce in the IDE code here - https://github.com/plomino/Plomino/tree/tinymce_field_settings/ide.
Currently the IDE just inserts spans like this
Where as we want it to insert the same example widgets in the visual fields branch such as
Latest branch we are working on and instructions to build and test are in https://github.com/plomino/Plomino/blob/advanced_ide/ide/README.md
User problem
There are several places in the UI that require lots of clicking, switching screens in the process of creating forms. e.g.
Options
There are a bunch of ways to solve this. Here is a mockup of one idea.
1. [x] IDE Settings in tabs
Option 1 seems like a big change but with reusing code from the theming control panel it might not be too much work. Possibly the most work would be the code view but it doesn't have to be very smart to start with. It could throwing away code inbetween functions and not allow custom ordering. Later those could be fixed by storing in special comments.
2. [v] IDE settings in splitview
see https://app.moqups.com/djay@pretaweb.com/jbaUkc1plo/view
Similar to above except:
plan
Option 1 has been partially implemented in Angular 2 here - https://github.com/plomino/Plomino/tree/tinymce_field_settings/ide. This branch also has some enhancements such as fields in tinymce being more visual.
Option 2 (IDE with a tab per form) is better so we will refactor the code to incorporate these features.