Hi Julien, thanks for your explanations.
It is indeed difficult to explain and understand, I suggest to provide some kind of diagram or maybe some very simple examples, if you can.
Please also have in mind that we need to have a migration plan from old to new and we should be able to run old and new in parallel for a while, at least during one full release. We have some responsibility towards existing users.
Thanks for your appreciated efforts, Michael Am 07.12.16 um 16:16 schrieb Julien NICOLAS:
It's a proposal for best practices, because of my own experience on making new theme and the impact for a consistency UI.For example, party details screen is a patchwork of xml screens and ftl screens. If you manage to change the HTML structure of a form, it'll affect only xml screen thanks to macro ftl. The pure ftl screen keep the old html structure and you have to adapt your theme rendering to the html structure of the ftl. It's a pity that we have to manage UI screen by screen.There is no guidelines on how to make a good screen, and you can find for the same usage ftl screen and xml screen with different UI... So, we lost consistency. If we engage a new start for UI using guidelines, allow to make ftl screen with new UI by new developer could be dangerous for maintenance.What I mean is not to forbid ftl screen, but to forbid it for common screens that can be managed by xml structured screen in OOTB. In that way, we keep the UI consistency in the OOTB.It's difficult to explain well my tough, I hope to not made a misunderstanding :)Julien. On 07/12/2016 14:45, Pierre Smits wrote:I am wondering how to understand this: better to not use ftl elsewhere than in macro Is not every ftl template providing macro functionalities? Do you desire that this project moves away from using ftl templates in any other place than in a theme? Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/On Wed, Dec 7, 2016 at 2:28 PM, Julien NICOLAS <julien.nico...@nereide.fr>wrote:If I understand well, yes. All html structure must be managed by the theme. In OOTB, it could bereally better to not use ftl elsewhere than in macro. This is a way thatcould be good to follow to have consistency for all screens in OFBiz. Julien. On 06/12/2016 11:59, Pierre Smits wrote:So you are considering the following: ‘A more flexible and extensible approach is to use the FTL XML processing features directly instead of going through Java classes. With this approachadding an attribute or support for a whole new element in the widget XMLfiles is just a matter of adding it to the FTL macros that process XML elements’ ? Best regards, Pierre Smits ORRTIZ.COM <http://www.orrtiz.com> OFBiz based solutions & services OFBiz Extensions Marketplace http://oem.ofbizci.net/oci-2/On Fri, Dec 2, 2016 at 2:05 PM, Julien NICOLAS <julien.nico...@nereide.frwrote: Pierre,I don't know if we'll need it or not for now. There is so many thing to define but it seems interesting. We will have to start this discussion onthe new theme topic. Julien. On 02/12/2016 11:55, pierre wrote: Hi JulienIs there any interest into the integration of a java UI framework suchas vaadin? regards, Pierre On 01/12/2016 23:26, Julien NICOLAS wrote: Hi all,I start a page about the POC for the UI improvement.I'm not sure if the content is enough but I was wanted to create it. We can now start some... Jira ? I was wondering one main Jira linkedto 4 other sub-jira.thanks to those Jira, we can have 4 teams or workgroup to go ahead inboth ways. https://cwiki.apache.org/confluence/display/OFBIZ/UI+Improvement Let me know if I'm doing well, Kind regards, Julien. PS : I'm currently checkout the common-theme provided by Nicolas's github (https://github.com/nmalin/ApacheOFBiz/tree/common-theme) On 28/11/2016 11:28, Sharan Foga wrote: Hi EveryoneAnother one of the topics that came up during the brainstorming in Seville was around the UI. In fact we had at least 2 presentations from the OFBiz track at Apachecon that were about how we could improve our UI. If the UI was the main focus - what could the strategy look like - User Interface - have 2 versions of the UI, one very clean and simple, the other more advanced. (Our current UI could be the advanced one....? - Separate the web part from the widgets - We have too many fields on one screen (many of them are notmandatory and are just included as optional). What if we slimmed down all the screens to have a sensible default UI for users. The UI couldalso be modifiable by service providers. Simplify the screens with defaults - Use Bootstrap / CSS / Angular - Isolate web related - Define a graphics charter to be used for the screens - Have a CSS convention - Remove web from the framework - it shouldn't be there What do people think? -Do people think it would be a good idea to have 2 versions of the UI? (a simple one and a more advanced one?)- Are these the things we would need to focus on or have in place ifwe wanted to focus on the UI?(Also I know Nicolas has mentioned that he has already started workon a Proof of Concept for a common theme - so do we need to make sure we agree conventions etc before much more work is done?) Thanks Sharan
smime.p7s
Description: S/MIME Cryptographic Signature