Olivier Heintz <[email protected]> writes:
>> Would you be interested in spending some time integrating this view handler
>> inside the framework?
>
> of course, I can created a Jira with the java and update them when
> there are remarks or discussions
Excellent. :-)
>> The requirements for such task would be to lint the code, write some
>> integration tests, some javadoc, some comments explaining the non-obvious
>> parts of the implementation, ... well a non-negligeable amount of work which
>> is important for maintainability reasons.
> the amount of work is not the main problem ;-)
> My knowledge and skill will be more difficult to solve,
> I am a business/functional consultant and so a java copy/paste developer (or
> a "java simple/procedural" business process developer)
> not a java framework developer.
> In the team I'm working, other Co-workers are front-end developer or profile
> similar than me.
>
> So,
> 1) javadoc no problem and documentation in adoc format no problem too
For a JSON screen view handler I guess most documentation effort would be in
Javadoc making clear what kind of XML elements is handled by a method, what
cases are considered and what are the expected effects, stating if ‘null’
values are accepted and potentially returned.
The issue is that some interfaces like ‘FormStringRenderer’ are not documented
so it would be nice to add the documentation for those interface too.
The following link provides good advice and conventions for Javadoc:
https://www.oracle.com/technetwork/java/javase/documentation/index-137868.html#terminology
> 2) cleaning code, and applying best practice, no problem if reviewer can
> give me some link or example
Works for me. The first step is to remove commented code and run ‘gradlew
check’, to ensure that before and after your changes no linting errors are
introduced (alternatively you can configure your IDE to run ‘checkstyle’ lint
tool on your source files).
I can help with best practice guidance if needed.
> 3) integration test, when I read the ModelFormFieldTest.java I don't
> understand what it does and the java ... so I will need some help for this
> sub-task
ModelFormFieldTest is indeed tricky to understand because the semantics of the
tested feature is complex (which motivated writing those tests in the first
place). I guess what is hard for you to understand is related to the usage of
lambdas denoted by ‘… -> …’ and passed as parameter to the
‘ModelFormField#from(Consumer<ModelFormFieldBuilder>)’ static method ?
IMO There is no need to use lambdas to write maintainable code so this is not
a blocker.
Regarding the kind of tests that matters for JSON rendering, it is important
for example to make sure that screen values are mapped to an adequate JSON
types (for example that boolean, numbers, list of values), that <action>
elements are run and have the expected effects, that pagination is working and
that ‘null’ values are handled as intended.
>> Moreover on the features side, it might be interesting to make the
>> presentation related stuff optional for consumers only interested by the data
>> aspect of the data.
>>
>> What do you think?
> Yes it's in the POC plan, but currently we are more focus on having a clear
> user demonstration in a business environment.
> This month a large part of Party component have been done and we are working
> on solving all bugs/"form xml functionality not yet implemented"
> Hoping to have a usable demo next week.
> (https://ofbiz-selenium.ofbizextra.org/partymgrfjs/control/showPortalPage?portalPageId=PartyMgmtFrontJs)
>
> Next week I will do a mail with the detail of what is usable and which next
> step are possible
> If you or community think that implemented this option is a priority, we will
> do it, I think it will not too difficult.
Since you seem OK with spending some time in the reviewing process, feel free
to open a ticket on Jira with a first version that I can start reviewing.
Thanks.
--
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
