Skip to Content.
Sympa Menu

grouper-dev - [grouper-dev] RE: UI customizations ( best practice / current design? )

Subject: Grouper Developers Forum

List archive

[grouper-dev] RE: UI customizations ( best practice / current design? )


Chronological Thread 
  • From: "Hyzer, Chris" <>
  • To: "Black, Carey M." <>, "" <>
  • Subject: [grouper-dev] RE: UI customizations ( best practice / current design? )
  • Date: Tue, 27 Jun 2017 19:20:51 +0000
  • Accept-language: en-US
  • Authentication-results: osu.edu; dkim=none (message not signed) header.d=none;osu.edu; dmarc=none action=none header.from=isc.upenn.edu;
  • Ironport-phdr: 9a23:oxNc6RTngCtTzLAaX3NsyzryJtpsv+yvbD5Q0YIujvd0So/mwa64YRyN2/xhgRfzUJnB7Loc0qyN7PCmBDRIyK3CmU5BWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnY6Uy/yPgttJ+nzBpWaz4Huj7jzqNXvZFACrj60arA2ZD6/twjA/uxQy8M2IKI4wRiP+yETU+NN2CVlKU/F21626d234YZu6WFctuwJ9shcXL/8crhiC7FUEX5uZ28v49DzuAOGQQaRznoaTmgMlBdUWU7I4AysDbnrtS6v/MpsyiSAeYXdTao1Qn7qu6JgSA76hT0vNiUytnzPh8p2yq9XvUTy9FRE34fIbdTNZ7JFdaTHcIZfHDIZUw==
  • Spamdiagnosticmetadata: NSPM
  • Spamdiagnosticoutput: 1:99

Yes, the more includes we have or pluggable views the more easily patched.
The old admin UI did that and it was a mess to figure out, so we need to make
it straightforward too. I think contributing customizations as options and
making things generic is the way to go :) i.e. your customization could be
a patch that defaults to not affect others if that is the desire :)

Thanks
Chris

-----Original Message-----
From: Black, Carey M.
[mailto:]

Sent: Tuesday, June 27, 2017 2:26 PM
To: Hyzer, Chris
<>;


Subject: RE: UI customizations ( best practice / current design? )

RE: " If you customize a file, and you try to apply a patch, it will fail and
let you know. "
Oh. Good to know. I had not found that in the docs that I have read
so far.
So far my customizations have been limited to config files. Before I
went farther I wanted to understand the designed approach for UI
customization.


Refs that I have reviewed:

https://spaces.internet2.edu/display/Grouper/Customising+the+Grouper+UI (
dated to prior to v 2.2 )
https://spaces.internet2.edu/display/Grouper/Grouper+new+UI ( looks
more relevant, but does not really address customizing.. more of an overview.)
https://spaces.internet2.edu/display/Grouper/Grouper+UI+Properties (
Ok.. promising, but I am not sure this is still the "right way" for v2.3.)



RE: " Then you can merge it in or whatever. Does that address it?"
It is something. But I don't think it is ideal.
Where does the "new/changed" files land on disk? When there is a
conflict detected?

I was hoping more for a process like the config overlay only for the
UI elements.

Generally something like:
/** or a config file to point to the local files instead of searched
directories all the time. */
/** Or at runtime by default use .../local/<file> instead of
../standard/<file> */
If (.../local/some.jsp ) {
/** use the file out of .../local/ */
.../local/some.jsp
} else {
/** use the default file */
../standard/some.jsp
}


I think such a model might allow for replacement/extension and allow
the "uprgrade" to more simply blindly replace the delivered UI without
concern of stomping on customizations.
The installer/upgrade could still issue "warnings" about
customizations that exist and should be validated.
It still requires the customizations to be validated after the
upgrade and "corrected/merged" as system level changes might have
added/changed/broken things too.
However, in that case the Users could choose to "suppress the
customizations" ( rename to different name) then fix and restore to original
name.
And it provides an "obvious" diff of what they created in
".../local/" vs ".../standard/".

--
Carey Matthew


-----Original Message-----
From: Hyzer, Chris
[mailto:]

Sent: Tuesday, June 27, 2017 11:32 AM
To: Black, Carey M.
<>;


Subject: RE: UI customizations ( best practice / current design? )

If you customize a file, and you try to apply a patch, it will fail and let
you know. Then you can merge it in or whatever. Does that address it?

Thanks
Chris

-----Original Message-----
From:


[mailto:]
On Behalf Of Black, Carey M.
Sent: Monday, June 26, 2017 5:18 PM
To:

Subject: [grouper-dev] UI customizations ( best practice / current design? )

I am looking for a general overview for "How to best customize the Grouper UI
(new)" so that you don't paint yourself into a corner for the next
upgrade/patch.
I know that the "upgrade" condition is a bit of a crystal ball type
question, but is there a plan for how someone can at least survive an "patch"
process without losing customizations?

Is there any guidelines or advice on the general topic?


Specifically , I am ok with using some of the localization tools to "adjust
text". But there are some more structural things that I would love to move
around too.
Example: I want to move at least some (if not all) of the "Loader"
functions from the "grouperLoaderViewMoreActionsButton" up to the
"groupViewMoreActionsButton".
I think I would ideally want to see a "sub section" on the
"groupViewMoreActionsButton" that would be the full list of items on the
"grouperLoaderViewMoreActionsButton". ( Plus the "Run Loader Diagnostics"
button function too.)
And the "sub section" would be guarded by the same
permissions as the "Loader jobs". ( So not every user would see the
sub-section.)
I find the separation of these functions into different
buttons almost as "jarring" as switching between the New UI and the Lite
UI/Admin UI.


--
Carey Matthew




Archive powered by MHonArc 2.6.19.

Top of Page