Generator-jhipster: Generate i18n mouseover/tooltip help from JDL comments

[agoncal]

Overview of the issue

When filling a JHipster form, we rely on a label and a entry field (textfield, combo...). But sometimes labels are not enough to give explanations. It would be good to generate some kind of i18n mouseover/tooltip help next to the label.

Motivation for or Use Case

JDL allows comments. So when we describe our model using JDL, this is what we can do:

/* This entity is complex and needs some documentation
*/
entity Complex {
    /** complex attribute */
    complexAttr1 String,
    /** another complex attribute */
    complexAttr2 Integer
}

These comments will be added to the Javadoc of the Entity, as well as the REST API

/**
 * This entity is complex and needs some documentation
 */
@ApiModel(description = "This entity is complex and needs some documentation")
@Entity
public class Complex implements Serializable {

    /**
     * complex attribute
     */
    @ApiModelProperty(value = "complex attribute")
    private String complexAttr1;

    /**
     * another complex attribute
     */
    @ApiModelProperty(value = "another complex attribute")
    private Integer complexAttr2;

For each comment, it would be great to generate an internationalized tooltip next to the label.

[deepu105]

Easiest solution would be to print the text as a title attribute for the
label or using the ng-bootstrap tooltip directive, but handling i18n would
be a PITA

In either case unless someone PRs this I don't think we have enough
bandwidth now

Thanks & Regards,
Deepu

On Mon, Dec 4, 2017 at 11:58 AM, Antonio Goncalves <[email protected]

wrote:

Overview of the issue

When filling a JHipster form, we rely on a label and a entry field
(textfield, combo...). But sometimes labels are not enough to give
explanations. It would be good to generate some kind of i18n
mouseover/tooltip help next to the label.
Motivation for or Use Case

JDL allows comments http://www.jhipster.tech/jdl/#commentingjdl. So
when we describe our model using JDL, this is what we can do:

/* This entity is complex and needs some documentation
/
entity Complex {
/* complex attribute /
complexAttr1 String,
/* another complex attribute */
complexAttr2 Integer
}

These comments will be added to the Javadoc of the Entity, as well as the
REST API

/**

• This entity is complex and needs some documentation
  */
  @ApiModel(description = "This entity is complex and needs some documentation")
  @Entity
  public class Complex implements Serializable {

/**
 * complex attribute
 */
@ApiModelProperty(value = "complex attribute")
private String complexAttr1;

/**
 * another complex attribute
 */
@ApiModelProperty(value = "another complex attribute")
private Integer complexAttr2;

For each comment, it would be great to generate an internationalized
tooltip next to the label.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/6797, or mute the
thread
https://github.com/notifications/unsubscribe-auth/ABDlF1S7TvWmdIV3V9Z-pLGRvkWE0x0Aks5s89BvgaJpZM4Q0d93
.

[agoncal]

@deepu105 i18 would not be that of a PITA. The i18n Json file could look like something like this, WDYT ?

{
    "commentsApp": {
            "complexAttr1": "Complex Attr 1",
            "complexAttr2": "Complex Attr 2",
            "noHelpAttr": "No Help Attr",
            "help": {
                "complexAttr1": "complex attribute",
                "complexAttr2": "another complex attribute"
            },
}

As for the bandwidth, why don't you label issues (like this one) differently ? This way they could be used during hackathons or people wanting to contribute. Issues can also be used as a reminder if you use a special label. WDYT ?

[deepu105]

we already label issues like thos with help_wanted or pr_needed. I'll do
the same here as well
For i18n technically its not difficult, but it means more stuff to add and
maintain in terms of templates

Thanks & Regards,
Deepu

On Mon, Dec 4, 2017 at 1:23 PM, Antonio Goncalves [e-mail]
wrote:

@deepu105 https://github.com/deepu105 i18 would not be that of a PITA.
The i18n Json file could look like something like this, WDYT ?

{
"commentsApp": {
"complexAttr1": "Complex Attr 1",
"complexAttr2": "Complex Attr 2",
"noHelpAttr": "No Help Attr",
"help": {
"complexAttr1": "complex attribute",
"complexAttr2": "another complex attribute"
},
}

As for the bandwidth, why don't you label issues (like this one)
differently ? This way they could be used during hackathons or people
wanting to contribute. Issues can also be used as a reminder if you use a
special label. WDYT ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jhipster/generator-jhipster/issues/6797#issuecomment-348947382,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABDlF6hU1e85NcTuO78b4ZWPm3V0c09Kks5s8-RGgaJpZM4Q0d93
.

[jdubois]

I'm sorry but I agree with @deepu105 we just have too many opened issues at the moment to do new features. That's really annoying, I know.
As soon as we have more than 20 tickets (one page on GitHub is 25 tickets) we always get lost, and mess up things.

[agoncal]

@jdubois I like the idea of "help wanted" label. You can tag issues like this ("good idea, but not crucial") and leave the community to implement them while the core team focuses on bugs and "important" issues. Then, you just have to filter them out.

Recently I've created a few "help wanted" kind of issues. Tag them, leave them open as a reminder, filter them out... and give the community a bit of time to implement them (I wouldn't mind implementing a few actually, I need them)

[jdubois]

Of course I'd love to have more contributions from "non core team" people

I'm OK with that as long as we put some new rules, which I should submit as a vote to the core team:

• "help wanted" issues should be for "easy to moderate" tickets, as we already know complex bugs won't be solved by non-core team people
• they should not have big impacts on the project: they improve something (like an Angular component), but they don't have impacts on several generator options (as those are much more complex to test)
• solution should be one PR, that will be easy to review by the core team (otherwise, do several tickets)
• they are kept opened for 2 months, and are closed after that if there is no activity

[agoncal]

@jdubois seems fair to me.