Einav Cohen has posted comments on this change.
Change subject: userportal, webadmin: refactor: add model attribute for help
tags
......................................................................
Patch Set 3:
I apologize - I lost you in the last comment.
We can have a structured helpTag in the form of "dialogID=xxx;description=yyy"
(and nothing else at the moment, due to the reasons that I explained in the
previous comment) so we can "prepare the grounds" for additional meta-data if
such will ever be needed, for some reason, in the future.
[I am not sure if we have any string-limitations on the keys within a
.properties file - I assume that it cannot contain '=', for example, so that
would be one limitation for the description; also not sure how it handles
white-spaces within the key]
BTW - just realized that we can have in the code multiple instances for the
same 'dialog', but we wouldn't want to set the full dialog's help-meta-data for
each instance. I think that we need a way that will allow us to define the full
meta-data per dialog (not per instance), and define a dialog-identifier
(associated with the full meta-data) per dialog instance.
So if we have in the code instance1, instance2, instance3 of a specific dialog,
we should be able to do:
instance1.setHelpTag("dialogID=xxx;description=yyy");
instance2.setHelpTag("dialogID=xxx");
instance3.setHelpTag("dialogID=xxx");
[or the equivalent of "playing" with the setHelpTag() method parameters as they
are implemented now]
one way of ensuring that we won't have multiple descriptions for one 'dialog'
is to keep a .properties file (unrelated (?) to the .properties files that we
have discussed so far) with a dialogID/description mapping, but then I don't
like the idea that the developer would need to maintain another file when
adding a new dialog to the system.
the tool that auto-generates the mapping based on the code should be aware of
situations like that and generate a warning when two or more instances with the
same 'dialogID' contain a description/full-meta-data. also, it shouldn't
override an existing description with an 'empty' description that has been
discovered for an instance with the same ID later in the process.
--
To view, visit http://gerrit.ovirt.org/21052
To unsubscribe, visit http://gerrit.ovirt.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: Ia4074fcc2ecfcbdd2ea6c0855d92f2aa4bd26a5b
Gerrit-PatchSet: 3
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Greg Sheremeta <[email protected]>
Gerrit-Reviewer: Alexander Wels <[email protected]>
Gerrit-Reviewer: Alon Bar-Lev <[email protected]>
Gerrit-Reviewer: Einav Cohen <[email protected]>
Gerrit-Reviewer: Greg Sheremeta <[email protected]>
Gerrit-Reviewer: Vojtech Szocs <[email protected]>
Gerrit-Reviewer: oVirt Jenkins CI Server
Gerrit-HasComments: No
_______________________________________________
Engine-patches mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-patches
