Clean up ServiceViewBean to ensure field names are better chosen

[mmoayyed]

Related to https://github.com/Unicon/cas/issues/39

• All classes under org.apereo.cas.mgmt.services.web.beans need to be removed, ideally. They are simply nothing but noise. Rather than using something like RegisteredServiceViewBean, we need to find a way to fall back onto RegisteredService for when definitions are displayed.
• RegisteredServiceFactory should also be removed along with family.
• FormDataPopulator also need to be removed along with family. Make the FormData a conditional bean that would allow adopters to replace it with anything they prefer.

[tsschmidt]

I can understand why removing RegisteredServiceViewBean is desirable, but it does serve an important purpose. Without it we would need to send fully defined RegisteredService objects for the list of services displayed on the Manage Services screen. If using the DefaultServiceManager, than this could mean sending hundreds if not thousands of heavyweight objects over the wire to the client all at once.

Using a view bean means we only send the information that needs to be displayed at that time. Another possible solution would be a different load mechanism for RegisteredService that only populates the needed fields for the list of services to be displayed. It would be less info sent, but perhaps not as efficient as a specific view bean.

[mmoayyed]

Welcome back :)

Thanks for the notes; I see how that might be useful. Is there opportunity to perhaps refactor and clean up some of the field names? For example, we have field names that are sasCasEnabled or assignedId. Just seems less than intuitive to me.

[tsschmidt]

Absolutely there is clean up that can be done here to make things simplified and clearer.

[tsschmidt]

Proposed clean up for this has been pushed to mgmt-serviceview-refactor for review.

[mmoayyed]

Closing in favor of https://github.com/Unicon/cas/issues/39