From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH] zoneconf.cgi: Improve the usability of the zone configuration by marking assigned NICs in the zone color. The highlighting is initially applied to the static HTML output, and JavaScript is used to dynamically follow changes made by the user. Date: Wed, 11 Nov 2020 17:01:52 +0000 Message-ID: In-Reply-To: <88af4ce2-b824-37d8-bff0-1dc54c721ed7@leo-andres.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6253691996041180187==" List-Id: --===============6253691996041180187== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > On 11 Nov 2020, at 16:44, Leo Hofmann wrote: >=20 > Hi Jonatan, >=20 > thanks for your feedback. I'm not very familiar with your workflow yet, I h= ope you will excuse my mistakes. Absolutely. This is just to let you know what was different than expected. Also feel free to ask any questions whenever you are unsure :) > I guess I'll have to submit this patch a second time as well. If you don't = mind, could you please comment on my idea for the second attempt: >=20 > Patch 1: Only fix HTML output e.g. missing "<", indentation and so on. > I remember Michael suggested this in the past, but since it only affected a= few lines this time, I thought it was okay. I do this sometimes, too. A few probably can never be avoided. I wouldn=E2=80=99t have complained about this as long as this is in or close = to the lines that are being changed. > I just noticed another issue with the original zoneconf source. Some HTML e= lements are created with whitespace in their id tag, which isn't allowed by H= TML standard. > Should I fix this in the first patch as well, or would you like this to be = another patch? Please do this in another patch. That allows us to patch this very quickly be= cause it is very easy to review. > Patch 2 (or 3?): Add highlighting feature > This patch would rely on the changes introduced by the first patch. What's = the best way to make sure they don't get separated? Just send them in one go. If you are using =E2=80=9Cgit send-email=E2=80=9D it will automatically gener= ate a patchset which then looks like this: https://patchwork.ipfire.org/project/ipfire/list/?series=3D1600 > I will answer your comments below! I have also added a few specific questio= ns. >=20 > Regards > Leo -Michael > Am 11.11.2020 um 12:55 schrieb Jonatan Schlag: >> Hi, >>=20 >> thirst thank you for working on this so fast. I will comment on this >> patch inline, but first one note on the commit message. >>=20 >> The commit message should be split up. When you use >> 'git commit -sv' an editor will open and in this editor, the first line >> makes up the subject of the mail the lines after the second makes up >> the commit message. The first line should not be longer than 50 >> characters to avoid, a subject like in this E-Mail. >>=20 >> For further information on a good commit message see: >> https://blog.ipfire.org/post/how-to-write-a-good-commit-message >>=20 >>=20 >> "Leo-Andres Hofmann" hofmann(a)leo-andres.de =E2=80=93 10. November 2020 1= 3:37 >>> Discussion: lists.ipfire.org/pipermail/development/2020- >>> October/008567.html >>>=20 >>> Signed-off-by: Leo-Andres Hofmann >>> --- >>> html/cgi-bin/zoneconf.cgi | 89 +++++++++++++++++++++++++++++--------- >>> - >>> 1 file changed, 67 insertions(+), 22 deletions(-) >>>=20 >>> diff --git a/html/cgi-bin/zoneconf.cgi b/html/cgi-bin/zoneconf.cgi >>> index d99a3e611..2501901c4 100644 >>> --- a/html/cgi-bin/zoneconf.cgi >>> +++ b/html/cgi-bin/zoneconf.cgi >>> @@ -26,7 +26,7 @@ require '/var/ipfire/general-functions.pl'; >>> require "${General::swroot}/lang.pl"; >>> require "${General::swroot}/header.pl"; >>>=20 >>> -my $css =3D <>> +my $extraHead =3D <>> >>> + >>> + >>> END >>> ; >> Could you put this in a separate file (zoneconf.js) please? It's hard to r= ead here and we should try to at least avoid introducing new mixing of langua= ges (Perl and js). Also, we can use formatter and linter of this separate fil= e easier. This should apply to the CSS as well, but that is not your mistake = and therefore not part of the patch. > Where should I put this? Would html/include/zoneconf.js be the right place?= Are there any licensing headers I need to add? >>> @@ -162,7 +200,7 @@ foreach (@nics) { >>> } >>> } >>>=20 >>> -&Header::openpage($Lang::tr{"zoneconf title"}, 1, $css); >>> +&Header::openpage($Lang::tr{"zoneconf title"}, 1, $extraHead); >>> &Header::openbigbox('100%', 'center'); >>>=20 >>> ### Evaluate POST parameters ### >>> @@ -312,8 +350,8 @@ if ($cgiparams{"ACTION"} eq $Lang::tr{"save"}) { >>> print <>>
>>> >>> - >>> - >>> + >>> END >>> ; >>>=20 >>> @@ -332,7 +370,7 @@ foreach (@zones) { >>> my $red_restricted =3D ($uc eq "RED" && ! ($red_type eq "STATIC" || >>> $red_type eq "DHCP")); >>>=20 >>> if ($red_restricted) { >>> - print ""; >>> + print "\t\t\n"; >> @Micheal or somebody else, do we have a function to print lines >> intended like in the network code of ipfire 3.x? >> Something like print_indented > That would be great! I know this isn't really important, but creating clean= HTML makes it much easier for me to check my work. >>> next; # We're done here >>> } >>> @@ -350,7 +388,7 @@ foreach (@zones) { >>> } >>>=20 >>> print <>> - "; >>> +print "\t\n"; >>>=20 >>> my $slightlygrey =3D ""; >>>=20 >>> @@ -370,12 +408,13 @@ foreach (@nics) { >>> my $nic =3D $_->[1]; >>> my $wlan =3D $_->[2]; >>>=20 >>> - print ""; >>> + print "\t\n\t\t\n"; >>>=20 >>> # Iterate through all zones and check if the current NIC is assigned >>> to it >>> foreach (@zones) { >>> my $uc =3D uc $_; >>> my $dev_name =3D $ethsettings{"${uc}_DEV"}; >>> + my $highlight =3D ""; >>>=20 >>> if ($dev_name eq "") { # Again, skip the zone if it is not activated >>> next; >>> @@ -391,9 +430,10 @@ foreach (@nics) { >>>=20 >>> if ($mac eq $ethsettings{"${uc}_MACADDR"}) { >>> $checked =3D "checked"; >>> + $highlight =3D $_; >>> } >>>=20 >>> - print ""; >>> + print "\t\t\n"; >>> next; # We're done here >> This is very hard to read, could we split this up please? > I'll split it! >> } >> } >> @@ -430,21 +470,26 @@ foreach (@nics) { >>=20 >> $access_selected{"NONE"} =3D ($access_selected{"NATIVE"} eq "") && >> ($access_selected{"VLAN"} eq "") ? "selected" : ""; >> my $vlan_disabled =3D ($wlan) ? "disabled" : ""; >> + >> + # If the interface is assigned, hightlight table cell >> + if ($access_selected{"NONE"} eq "") { >> + $highlight =3D $_; >> + } >>=20 >> print <> - >> + >> END >> ; >> } >> Same here, when you only change the indention it is hard to see the >> actual change of the javascript. >>=20 >> To sum things up, please do not get upset about my comments. It might be s= ometimes annoying, but doing things in a high-quality way makes our work in a= few years when we might have a look at this again easier. >> Greetings Jonatan >> - print ""; >> + print "\t\n"; >>=20 >> if ($slightlygrey) { >> $slightlygrey =3D ""; >> -- >> 2.27.0.windows.1 --===============6253691996041180187==--
>>> +
$uc ($red_type)$uc ($red_type)$uc
>>> + 		$uc
>> Should be not part of this patch, but does not matter much. You can >> use 'git add -i' to pick those changes and but them in a separate patch >> like "cleaning up code". >>>
$nic
$mac
>> textcenter'>$nic
$mac		>> id=3D'PPPACCESS $mac' name=3D'PPPACCESS' value=3D'$mac' $checked>>> type=3D'radio' id=3D'PPPACCESS $mac' name=3D'PPPACCESS' value=3D'$mac' da= ta- >>> zone=3D'RED' data-mac=3D'$mac' onchange=3D'highlightAccess(this)' >>> $checked> >> - >> - > $mac" min=3D"1" max=3D"4095" value=3D"$zone_vlan_id" $field_disabled> >> - >> + >> + > $mac" min=3D"1" max=3D"4095" value=3D"$zone_vlan_id" $field_disabled> >> +